-J
>>>
>>
>
> Jarkko,
>
> I never got a response from anyone. How would you feel about closing
> this bug?
I don't think it can be closed until at least another big-endian 64-bit
platform (like IRIX 64 is/was) has been used to verify that things work.
> -J
>
>
>
The latest changes by Leo seem to have fixed this one, and similarly
#37338 and #37337.
Jarkko Hietaniemi wrote:
> Jarkko Hietaniemi wrote:
>
>>>io/io_unix.c does not compile because socklen_t is not defined.
>>>
>>>According to the standards, is needed to get socklen_t.
>>>
>>>One could try including that the right way into io/io_unix.c, but I do
>>>not know enough of Parrot conven
From Schwern's comment:
I'll consider putting in some more information into the
Test::Builder->details so information like the file and line number
where the test occured can be gotten without scraping.
I'd really like to have this as well. Current projects could really use
it.
--- Joe M.
On Oct 5, 2005, at 11:38 AM, Michael G Schwern wrote:
I'm done talking about this until I see some attempt at fixing
Test::Builder::Tester. It could have been done by now.
I'll do it tomorrow unless someone else already has.
--- Joe M.
Some more test failures confirmations...
Test::Exception is uninstallable.
Test::SubCalls is uninstallable.
Test::Pod is uninstallable.
Test::Warn is uninstallable.
test_fail() which is the problem in TB::Tester was really only a
convenience function for test_diag( Failed at ... ).
Pretty
> --- config/init/hints/dec_osf.pl.dist 2005-10-05 20:29:30.0 +0300
> +++ config/init/hints/dec_osf.pl2005-10-05 20:31:25.0 +0300
> @@ -6,6 +6,10 @@
> if ( $ccflags !~ /-pthread/ ) {
> $ccflags .= ' -pthread';
> }
> +if ( $ccflags !~ /-D_XOPEN_SOURCE=/ ) {
> +#
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37358]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37358 >
Many of the tests write temp files into the current working dir. Even
worse, some of
On Wed, Oct 05, 2005 at 01:45:24AM -0700, Peter Sinnott via RT wrote:
> On Tue, Oct 04, 2005 at 09:04:57PM -0700, Joshua Hoblitt via RT wrote:
>
> I do not have access to the same machine any longer so I have retested
> with solaris 2.8 , gcc 3.2.1 and the 2005-10-05_071500 parrot
> snapshot. This
On 10/5/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 05, 2005 at 11:22:40PM +1000, Adam Kennedy wrote:
> > Please ignore these bad reports. I've contacted Schwern to get that
> > specific change to Test::More backed out ASAP. These problem, if you get
> > any, should go away short
> Once Test-URI is upgraded, we are going to need to make sure the newest
> version is installed, so could the authors of the following modules
> please note you will need to do a new release to update this dependency.
>
> Amethyst SHEVEK
> Apache-ACEProxy MIYAGAWA
> Apache-DoCoMoProxy
AFAIK there is only one module of consequence which does screen scraping
on Test::More and that's Test::Builder::Tester (Test::Warn, it turns out,
fails because of Test::Builder::Tester). Fix that, upload a new version
and the problem goes away.
Which is not true at all. Test::More gets upgra
Just grab the previous stable tarball, unroll it, change the version to
a higher one, and release. If it's a bitch to backout that one path,
backout the entire stable release to the previous one.
Did you see the number of bug fixes between 0.60 and 0.61? No, I'm not
rolling back the entire re
I'm disinclined to back this change out. See the bug for reasoning.
http://rt.cpan.org/NoAuth/Bug.html?id=14936
To sum up:
* There was ample warning.
* You shouldn't be relying on screen scraping.
* The fix to Test::Builder::Tester is trivial.
* Rolling back the change is a pain in my ass.
The
* Rolling back the change is a pain in my ass.
BTW, this shouldn't be true.
Just grab the previous stable tarball, unroll it, change the version to
a higher one, and release. If it's a bitch to backout that one path,
backout the entire stable release to the previous one.
It's 5 lines of cod
On Wed, Oct 05, 2005 at 13:00:55 -0600, Luke Palmer wrote:
> I don't think it was a "how is this possible", but more of a "what
> business does it have?". And as far as I gathered, they're saying
> pretty much what you've been saying, but in a different way. It's
> about the continuation boundar
On Wed, Oct 05, 2005 at 13:41:37 -0700, Dave Whipp wrote:
> Reading this thread, I find myself wondering how a resumable exception
> differs
> from a dynamically scropted function. Imagine this code:
This is sort of like what I mean, except that there is no
encapsulation breakage, since the inte
On Wed, Oct 05, 2005 at 03:01:35PM -0700, chromatic wrote:
> On Mon, 2005-10-03 at 17:05 -1000, Joshua Hoblitt wrote:
>
> > I'm wondering if this wouldn't be better split up into RT tickets
> > similar to the way TODOs are handled. Having everything in one coherent
> > document is great but I sus
On Wed, Oct 05, 2005 at 09:22:34PM -0700, Joshua Juran via RT wrote:
> Parrot itself builds successfully, but 'make' fails here:
>
> ...
> ./parrot -o runtime/parrot/library/Stream/Sub.pbc
> runtime/parrot/library/Stream/Sub.imc
> ./parrot -o runtime/parrot/library/Stream/Writer.pbc
> runtime/pa
On Thu, Oct 06, 2005 at 08:20:22AM +0300, Jarkko Hietaniemi wrote:
>
> > --- config/init/hints/dec_osf.pl.dist 2005-10-05 20:29:30.0 +0300
> > +++ config/init/hints/dec_osf.pl2005-10-05 20:31:25.0 +0300
> > @@ -6,6 +6,10 @@
> > if ( $ccflags !~ /-pthread/ ) {
> > $c
Andy Dougherty wrote:
On Tue, 4 Oct 2005, Leopold Toetsch via RT wrote:
Anyway, does:
p = (struct Parrot_Context *) ( (char *) p + ALIGNED_CTX_SIZE );
help, or better is it "more correct"?
While this does indeed replace the warning by a different warning ("cast
increases required alig
On 10/5/05, Joe McMahon <[EMAIL PROTECTED]> wrote:
> From Schwern's comment:
>
> I'll consider putting in some more information into the
> Test::Builder->details so information like the file and line number
> where the test occured can be gotten without scraping.
>
> I'd really like to have this a
On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> -J
>
>
>
>
> >>>
> >>
> >
> > Jarkko,
> >
> > I never got a response from anyone. How would you feel about closing
> > this bug?
>
> I don't think it can be closed until at least another big-endi
On Thu, Oct 06, 2005 at 02:03:45AM -0700, Joshua Hoblitt via RT wrote:
> On Wed, Oct 05, 2005 at 01:45:24AM -0700, Peter Sinnott via RT wrote:
> > On Tue, Oct 04, 2005 at 09:04:57PM -0700, Joshua Hoblitt via RT wrote:
> >
> > I do not have access to the same machine any longer so I have retested
>
On Thu, 6 Oct 2005, Joshua Hoblitt wrote:
> On Thu, Oct 06, 2005 at 01:17:57AM -0700, Jarkko Hietaniemi via RT wrote:
> > > Jarkko,
> > >
> > > I never got a response from anyone. How would you feel about closing
> > > this bug?
> >
> > I don't think it can be closed until at least another big-
Leopold Toetsch wrote:
... When now this pointer (ctx.rctx) is
declared being 'void *' it should be compatible with any other pointer
to a structure.
I've now rewritten the questioanable code to use a (void*) allocation
pointer. I hope it's better now.
Could you please try r9367, and repor
On Thu, 6 Oct 2005, Peter Sinnott wrote:
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> t/examples/japh.t1 256151 6.67% 12
> t/op/trans.t 1 256191 5.26% 13
On 10/5/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
> > I'm just wondering why you feel that we need to be so careful.
>
> Because I can think of at least three reasonable and useful default behaviours
> for zipping lists of differing lengths:
>
> # Minimal (stop at first exhau
Luke Palmer wrote:
zip :: [a] -> [b] -> [(a,b)]
It *has* to stop at the shortest one, because it has no idea how to
create a "b" unless I tell it one. If it took the longest, the
signature would have looked like:
zip :: [a] -> [b] -> [(Maybe a, Maybe b)]
Anyway, that's just more of t
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > > Piers Cawley wrote:
> > > >>Exactly which exception is continued?
> > > > The bottommost one. If you want to return to somew
On Thu, Oct 06, 2005 at 10:31:50AM -0600, Luke Palmer wrote:
> If we make zip return a list of tuples rather than an interleaved
> list, we could eliminate the final 1/3 of those errors above using the
> typechecker. That would make the for look like this:
>
> for @a Y @b -> ($a, $b) {...}
I
A few more commands are inlined (including [for]). I've begun to
unify the three different compilers that are currently available: the
compreg'd version, the internal version for code, and the internal
version for expressions. All now use the same mechanism to ultimately
compile the PIR cod
Dave Whipp skribis 2005-10-06 9:57 (-0700):
> Given that my idea about using optional binding for look-ahead didn't
> fly, maybe it would work here, instead:
> @a Y @b -> $a, $b { ... } # stop at end of shortest
> @a Y @b -> $a, ?$b { ... } # keep going until @a is exhaused
> @a Y @b ->
On 10/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> for @foo Y @bar Y @baz -> $quux, $xyzzy { ... }
>
> is something you will probably not see very often, it's still legal
> Perl, even though it looks asymmetric. This too makes finding the
> solution in arguments a non-solution.
Don't be silly. Th
C properties get attached to a value, and are available when the
value is passed to other functions/ etc. I would like to be able to
define a property of a value that is trapped in the lexical scope where
it is defined. The example that set me thinking down this path is
sub foo( $a, ?$b = rand
On Thu, Oct 06, 2005 at 18:11:38 +0100, Peter Haworth wrote:
> The highest level exception is the only one a caller has any right to deal
> with, but even then it doesn't really know what will happen if it resumes
> some random continuation attached to the exception.
But then we gain nothing
> >
On 10/6/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
> sub foo( $a, ?$b = rand but :is_default )
> {
> ...
> bar($a,$b);
> }
>
> sub bar( $a, ?$b = rand but :is_default )
> {
>warn "defaulting \$b = $b" if $b.is_default;
>...
> }
>
>
> It would be unfortunate if the "is_default" proper
On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> when i can't open a file and $! tells me why i couldn't open, i
> can resume with an alternative handle that is supposed to be the
> same
>
> when I can't reach a host I ask a user if they want to wait any
>
On Thu, Oct 06, 2005 at 10:32:40PM +0300, Jarkko Hietaniemi wrote:
> >
> > Since I don't think anyone else can test this on tru64, would you mind
> > consolidating all of the fixes discussed in this thread into a single
> > patch?
>
> Attached.
>
Applied as r9383. Thanks.
-J
--
pgpkIO9aqKnh
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #37369]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37369 >
Hi Jonathan,
I've added test 22 in imcc/t/syn/const.t, which is currently fail
Luke Palmer skribis 2005-10-06 14:23 (-0600):
> my role is_default {} # empty
> sub foo($a, ?$b = 0 but is_default) {...}
Would this work too?
0 but role {}
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution
On 10/6/05, Juerd <[EMAIL PROTECTED]> wrote:
> Luke Palmer skribis 2005-10-06 14:23 (-0600):
> > my role is_default {} # empty
> > sub foo($a, ?$b = 0 but is_default) {...}
>
> Would this work too?
>
> 0 but role {}
Most certainly, but you would have no way to refer to that r
"Bernhard Schmalhofer (via RT)" <[EMAIL PROTECTED]> wrote:
I've added test 22 in imcc/t/syn/const.t, which is currently failing.
Could you have a look at it. It looks like empty lines a lost in here
documents.
If the intended behavior is different, I'll adapt the test.
The test is right. There
On Thu, Oct 06, 2005 at 10:08:22AM +0100, Fergal Daly wrote:
> > I'll consider putting in some more information into the
> > Test::Builder->details so information like the file and line number
> > where the test occured can be gotten without scraping.
> >
> > I'd really like to have this as well. C
Autrijus convinced me that we have to really nail down the semantics
of type annotation without "use static". Let's first nail down what
I meant by "semantics" in that sentence. Basically, when do various
things get checked? Run time or compile time (not coercion; I have a
proposal for that com
On Thu, Oct 06, 2005 at 17:44:10 -0600, Luke Palmer wrote:
> Autrijus convinced me that we have to really nail down the semantics
> of type annotation without "use static". Let's first nail down what
> I meant by "semantics" in that sentence. Basically, when do various
> things get checked? Run
On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
> On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > when i can't open a file and $! tells me why i couldn't open, i
> > can resume with an alternative handle that is supposed to be the
> > same
> >
> >
On 10/6/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> So we're in line one of a Perl program, with static typing/inference
> disabled (or at least inference *checking* disabled; perl may still
> use it for optimization). When do the following die: compile time
> (which includes CHECK time), run tim
"Peter Haworth" <[EMAIL PROTECTED]> writes:
> On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
>> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
>> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
>> > > Piers Cawley wrote:
>> > > >>Exactly which exception is continued?
>> > >
Yuval Kogman wrote:
>On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
>
>
>>On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>>
>>
>>>when i can't open a file and $! tells me why i couldn't open, i
>>>can resume with an alternative handle that is supposed to be t
50 matches
Mail list logo
