On Sat, 19 Dec 2015 20:29:14 -0800, alex.jakime...@gmail.com wrote:
> Code:
> ∞
>
> Result:
> (no output)
>
> Same thing with NaN and Inf. I was expecting a warning.
>
> Something like this:
>
> Code:
> 42
>
> Result:
> WARNINGS for -e:
> Us
On Sat, 19 Dec 2015 20:29:14 -0800, alex.jakime...@gmail.com wrote:
> Code:
> ∞
>
> Result:
> (no output)
>
> Same thing with NaN and Inf. I was expecting a warning.
>
> Something like this:
>
> Code:
> 42
>
> Result:
> WARNINGS for -e:
> Us
# New Ticket Created by Will Coleda
# Please include the string: [perl #131670]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131670 >
There are a class of warnings that do not emit their warnings on
$*ERR, but always on
v6d.pod
Log Message:
---
Propose fatalization of all redeclaration warnings
Hi,
>From https://docs.perl6.org/language/5to6-nutshell#warnings
"Warnings are now on by default.
no warnings is currently NYI, but putting things in a quietly {} block will
silence."
On 2017-01-12 03:42:22 GMT, ToddAndMargo wrote:
> Hi All,
>
> Is there a perl 6
Instead of enabling warnings, you disable them on a case by case basis with
"quietly" e.g. perl6 -e 'my $foo; quietly say "is $foo"'. Likewise,
"strict" is the default.
On Thu, Jan 12, 2017 at 12:12 AM, Lloyd Fournier
wrote:
> Nope. Perl6 warns you wi
Nope. Perl6 warns you without asking for it.
LL
On Thu, Jan 12, 2017 at 2:43 PM ToddAndMargo wrote:
Hi All,
Is there a perl 6 equivalent of perl 5's "use warnings"?
Many thanks,
-T
Hi All,
Is there a perl 6 equivalent of perl 5's "use warnings"?
Many thanks,
-T
rent signatures up to 20 but all I
> got was small linear compile time increase, no infinite locks).
I added 3 files to the ticket - the gist (please attach file to the ticket), a
shell script showing the code I ran, and the output of that script. I'm not
getting the error; I'm getting a ton of warnings.
--
Will "Coke" Coleda
On 04/16/2016 10:08 PM, David Warring (via RT) wrote:
> # New Ticket Created by David Warring
> # Please include the string: [perl #127908]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127908 >
>
>
> Consider:
>
> $ perl
# New Ticket Created by David Warring
# Please include the string: [perl #127908]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127908 >
Consider:
$ perl6 -v
This is Rakudo version 2016.03-124-g4b0e5bd built on MoarVM versio
# New Ticket Created by Pawel Pabian
# Please include the string: [perl #127811]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127811 >
To reproduce:
1. Save https://gist.github.com/bbkr/19ba6903358445410812bc09b0c0ec9c as Fo
ing.
Something like this:
Code:
42
Result:
WARNINGS for -e:
Useless use of constant integer 42 in sink context (line 1)
-bits.pod
M S04-control.pod
M S06-routines.pod
Log Message:
---
Explication of lazy warnings
Lazy warning are to be used for +, ~ and ? conversions, as well as
for the ??? stub.
Commit: 838a4b983e8bbc35796a67c4cbe9b20a198e5aae
https://github.com/perl6/specs/commit
# New Ticket Created by Will Coleda
# Please include the string: [perl #107244]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=107244 >
$ more foo
sub MAIN($a, :$b) {
say "$a, $b";
}
$ perl6 foo -b=3 4
use of uniniti
s warning from now on
>>
>> Though I'm hesitant to use comment syntax for that. A statement prefix
>> might be more appropriate. We've currently reserved "quietly" for simple
>> run-time warning suppression, but that's kinda long, and not defi
On 2010-06-18, at 10:48 am, Larry Wall wrote:
> If you make it the default to not warn, then the people who really need the
> warnings will almost never turn them on. If you make it default to warn,
> then people will have to turn off the warnings forever.
Doesn't the site-poli
=
use v6;
my %h;
say %h;
If this is within a test as follows, the warnings is not printed
use v6;
use Test;
plan 1;
ok(1);
my %h;
say %h;
Currently Test.pm disables the warnings to prevent tons of "Use of
uninitialized value" warnings when running the spectests.
Personally I think the spectests should not produce these warnings in
the first place, but I haven't found a good way to avoid/disable them yet.
Pm
.pm eats the "Use of uninitialized value" warnings",
> a summary of which appears below.
>
> There is no need to reply to this message right now. Your ticket has been
> assigned an ID of [perl #63038].
>
> Please include the string:
>
> [perl #63038]
>
>
Mark J. Reed wrote:
Arity 2 and a 1-elem list seems to be special-cased; otherwise, it
consistently warns once per undefined value in the expansion:
1-elem List reduce patch attached. Test added in r24567
--
Bacek
commit 9c1a3058064067dacab4c5f623a59ae768f19182
Author: Vasily Chekalkin
Date:
Ok, so with that patch, the case of a 1-element list and a binary sub
now behaves the same as any other combination of arity n with a list
whose length is not k(n-1)+1. I guess that's progress. :) Thanks,
Vasily.
I'd still like to see the undef warnings reduced to one, rather th
Arity 2 and a 1-elem list seems to be special-cased; otherwise, it
consistently warns once per undefined value in the expansion:
(1..4).reduce({$^a+$^b+$^c+$^d})# no warnings
(1..5).reduce({$^a+$^b+$^c+$^d})# two warnings: (1+2+3+4)+5+undef+undef
(1..6).reduce({$^a+$^b+$^c+$^d})# one
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #61610]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=61610 >
rakudo: say (1..10).reduce({$^a + $^b + $^c})
rakudo 34244: OUTPUT[Use of uninitialize
On Wed, Dec 3, 2008 at 7:25 PM, Will Coleda via RT <
[EMAIL PROTECTED]> wrote:
> On Tue Jan 09 06:43:10 2007, particle wrote:
> > compilers\imcc\imclexer.c(4310) : warning C4018: '<' : signed/unsigned
> > mismatch
> > compilers\imcc\imcc.l(662) : warning C4090: 'function' : different
> > 'const' q
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #60288]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60288 >
warnings compiling in 10.5.5 Core 2 Duo unibody macbook.
Seems that some stuff
The warning of inconsistent dll linkage no longer occurs on microsoft
visual studio, which resolves this issue.
kjs
On Dom. 19 Oct. 2008 13:47:11, kjs wrote:
> I think the issue of inconsistent dll linkage has been resolved
recently
> by adding the YYMALLOC and YYFREE #defines to imcc source.
>
> Can other windows people confirm this? Then this ticket can be closed.
> Thank you very much,
Confirmed. Parrot r
I think the issue of inconsistent dll linkage has been resolved recently
by adding the YYMALLOC and YYFREE #defines to imcc source.
Can other windows people confirm this? Then this ticket can be closed.
Thank you very much,
kjs
hey don't tell us anything about what warnings are
being emitted one phase earlier during 'make'. Such warnings are
presumably not causing Parrot to fail to build, but they may be
useful in diagnosing test failures. And, in any event, from a
scientific point of view they w
On Thursday 10 July 2008 10:44:51 NotFound wrote:
> On Wed, Jul 9, 2008 at 9:33 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> > The other warnings I get on Solaris are just these:
> >
> > "src/stm/backend.c", line 969: warning: statement not reached
>
On Thursday 10 July 2008 13:12:41 NotFound wrote:
> On Thu, Jul 10, 2008 at 7:44 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> >> Except the src/pmc/nci.pmc line 486, there is not such line in the
> >> file, and I'm unable to locate the problem.
> >
> > If you look in the generated src/pmc/nci.c
On Thu, Jul 10, 2008 at 7:44 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
>> Except the src/pmc/nci.pmc line 486, there is not such line in the
>> file, and I'm unable to locate the problem.
>
> If you look in the generated src/pmc/nci.c file at line 486, it has a #line
> directive that purports
On Wed, Jul 9, 2008 at 9:33 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> The other warnings I get on Solaris are just these:
>
> "src/stm/backend.c", line 969: warning: statement not reached
> "./src/pmc/nci.pmc", line 486: warning: statement not reach
On Wednesday 09 July 2008 12:03:19 chromatic wrote:
> On Wednesday 09 July 2008 08:27:35 Andrew Johnson wrote:
> > Confirmed, those warnings have gone. I'm still getting loads of
> > "warning: statement not reached" but I'll work out how to suppress those
>
Closing ticket
On Wednesday 09 July 2008 08:27:35 Andrew Johnson wrote:
> > Done in r29179, please confirm that gives no warning now.
>
> Confirmed, those warnings have gone. I'm still getting loads of "warning:
> statement not reached" but I'll work out how to suppress those
th adding a comment into parrot.h to clarify that
> > PARROT_const_cast should *only* be used for c/v qualifier changes, and
> > that additional casting may be necessary.
>
> Done in r29179, please confirm that gives no warning now.
Confirmed, those warnings have gone. I'm s
On Mon, Jun 23, 2008 at 4:37 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
>> Here is the patch. It avoids the warning both in C and C++ with gcc.
> Works fine for me, no warning.
> It might be worth adding a comment into parrot.h to clarify that
> PARROT_const_cast should *only* be used for c/v q
# New Ticket Created by Will Coleda
# Please include the string: [perl #56532]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56532 >
We get a lot of tickets regarding build warnings; we'd like to
eventually have
On Mon Apr 09 01:17:50 2007, pcoch wrote:
> In the file src/ops/io.ops there is the todo item:
>
> "all results from string_to_cstring() need freeing
> but this generates ugly warnings WRT discarding the const
> qualifier"
>
> free the results but also
On Monday 23 June 2008 09:08:07 NotFound wrote:
> Here is the patch. It avoids the warning both in C and C++ with gcc.
Works fine for me, no warning.
It might be worth adding a comment into parrot.h to clarify that
PARROT_const_cast should *only* be used for c/v qualifier changes, and that
addi
know how to write it without a long explanation of
the rationale that avoids people takes it as an invitation to add more
casts, 'just in case'. I like better to have these warnings and
carefully review each case than to hide them.
Maybe a comment that says 'Check each usage of thi
Here is the patch. It avoids the warning both in C and C++ with gcc.
--
Salu2
Index: src/packfile.c
===
--- src/packfile.c (revisión: 28668)
+++ src/packfile.c (copia de trabajo)
@@ -348,7 +348,7 @@
#ifdef PARROT_HAS_HEADER_SYSMMAN
On Sat, Jun 21, 2008 at 11:10 AM, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 20 June 2008 10:53:55 Andrew Johnson wrote:
>
>> I'm concluding that these warnings are due to incorrect casting inside of
>> packfile.c.
>>
>> In both cases, the cod
On Friday 20 June 2008 10:53:55 Andrew Johnson wrote:
> I'm concluding that these warnings are due to incorrect casting inside of
> packfile.c.
>
> In both cases, the code generating the warnings looks like this:
>
> munmap(PARROT_const_cast(opcode_t *, pf->src),
"src/packfile.c", line 878: warning: argument #1 is incompatible with
> prototype:
> prototype: pointer to char : "/usr/include/sys/mman.h", line 161
> argument : pointer to long
I'm concluding that these warnings are due to incorrect casting inside of
pa
On Thursday 19 June 2008 13:33:13 Andrew Johnson wrote:
> These warnings occur when compiling on Solaris, both x86 and sparc:
>
> "src/packfile.c", line 351: warning: argument #1 is incompatible with
> prototype:
> prototype: pointer to char : "/usr
# New Ticket Created by Andrew Johnson
# Please include the string: [perl #56110]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56110 >
These warnings occur when compiling on Solaris, both x86 and sparc:
"src/pa
On Tuesday 10 June 2008 12:05:18 NotFound wrote:
> This patch solves the casting problems that breaks or generates
> warnings in src/io/io_unix.c allowing clean compiling with C or C++,
> with or without --optimize.
Applied in r28251.
> Also drops the const in argv in several m
# New Ticket Created by NotFound
# Please include the string: [perl #55590]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55590 >
This patch solves the casting problems that breaks or generates
warnings in src
On Monday 09 June 2008 22:26:10 Geoffrey Broadwell wrote:
> > This is on a Gentoo linux amd64 machine, with Parrot trunk r28204, and an
> > unstable (git) version of mesa built from the "x11" overlay.
> >
> > Is this normal?
>
> Nope, not normal.
>
> Try the attached patch. It's an update of the p
> This is on a Gentoo linux amd64 machine, with Parrot trunk r28204, and an
> unstable (git) version of mesa built from the "x11" overlay.
>
> Is this normal?
Nope, not normal.
Try the attached patch. It's an update of the patch in #55228; I'll
update that RT in a moment.
-'f
diff --git a/co
On Mon, Jun 9, 2008 at 8:36 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Mon Jun 09 17:23:40 2008, coke wrote:
>
>>
>> I think the goal is to eliminate warnings from the default build,
>> while turing on as many warnings as possible. (like with the coding
&
On Mon Jun 09 17:23:40 2008, coke wrote:
>
> I think the goal is to eliminate warnings from the default build,
> while turing on as many warnings as possible. (like with the coding
> standard tests; as more pass, we should run them by default.)
>
So does this mean I should no
On Mon Jun 09 17:13:32 2008, infinoid wrote:
>
> Update: these warnings are gone, looks like D2FPTR has been removed from
> the above lines (which are now lines 361 and 370 of dynext.c).
>
> Mark
Thanks, Mark. Running 'make' just now, I got no warnings with
src/dy
On Mon, Jun 9, 2008 at 8:16 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> Since we're always going to have some build warnings on different
> OS/platform combinations, I think we can resolve this ticket.
I think the goal is to eliminate warnings from the default build,
w
I'm not on Gentoo, but on Debian. Running 'perl Configure.pl' at
r28211, I don't get any of these warnings.
$ uname -a
Linux li11-226 2.6.23.1-linode36 #1 Sun Nov 4 12:03:06 EST 2007 i686
GNU/Linux
Since we're always going to have some build warnings on different
OS/platform combinations, I think we can resolve this ticket.
If, on a particular OS, we have a pattern of warnings emerging --
particularly if those are warnings not previously observed -- then we
can open new tickets
; 315:load_func = (PMC * (*)(Interp *))D2FPTR(Parrot_dlsym(handle,
> cload_func_name));
>
>
> 322:init_func = (void (*)(Interp *, PMC
> *))D2FPTR(Parrot_dlsym(handle,
> cinit_func_name));
Update: these warnings are gone, looks like
Jerry, Mark, anyone: Can someone provide an update on the status of
issues raised in this ticket?
Thank you very much.
kid51
# New Ticket Created by Mark Glines
# Please include the string: [perl #55530]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55530 >
Hi,
Generating OpenGL bindings...In OpenGL header '/usr/include/GL/amesa.h', found
a no
On Friday 30 May 2008 15:12:31 NotFound wrote:
> On Fri, May 30, 2008 at 5:56 PM, Geoffrey Broadwell <[EMAIL PROTECTED]>
wrote:
> > Nit: three of those lines look like they've either got a real tab at the
> > front, or some other spacing oddity that makes them not line up
> > properly.
>
> Sorry,
tetragon:
Patch applied to trunk in r27953, along with tests to cover that
condition. Let me know if this doesn't do the trick. Thanks.
kid51
On Fri, May 30, 2008 at 5:56 PM, Geoffrey Broadwell <[EMAIL PROTECTED]> wrote:
> Nit: three of those lines look like they've either got a real tab at the
> front, or some other spacing oddity that makes them not line up
> properly.
Sorry, forgot to cross-copy to the list the fixed version.
http:
On Thu, 2008-05-29 at 09:41 -0700, NotFound wrote:
> +# Dirty way of checking if compiling with c++
> + my $nocpp = index($conf->data->get('cc'), '++') < 0;
> +
> -$self->set_result("set for gcc");
> + if ($nocpp) {
> +for my $maybe_warning
> (@{ $self->{pote
# New Ticket Created by "Seneca Cunningham"
# Please include the string: [perl #55074]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55074 >
_handle_darwin_for_macports doesn't check to see if the value of
$ports_include_d
# New Ticket Created by NotFound
# Please include the string: [perl #55050]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55050 >
Recent versions of g++ warns when gcc warnings that makes no sense in
c++ are used,
];
return \%data;
}
@@ -145,6 +148,9 @@
print "\n" if $verbose;
if ( defined $conf->data->get('gccversion') ) {
+# Dirty way of checking if compiling with c++
+my $nocpp = index($conf->data->get('cc'), '++') <
I have seen now that the functions if'ed out by DO_LOOP_OPTIMIZATION
are mentioned and proposed for deletion in #46291, this ticket can be
merged with him or closed.
--
Salu2
On May 12, 2008, at 3:11 AM, NotFound wrote:
Maybe the solution is to avoid the problem, that is, put the
declarations outside of the HEADERIZER block. What's the point of
having static functions inside one?
So that declaration and definition are always in sync.
--
Andy Lester => [EMAIL PRO
On Mon, May 12, 2008 at 4:34 AM, Andy Lester via RT
<[EMAIL PROTECTED]> wrote:
> This won't work because it modifies the sections in between HEADERIZER
> BEGIN & END sections. As of this writing, there is no solution for this
> problem.
Maybe the solution is to avoid the problem, that is, put t
# New Ticket Created by NotFound
# Please include the string: [perl #53990]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53990 >
Hello.
In recent revisions there are warning about unused static functions in
compilers/imc
On Friday 25 April 2008 10:36:02 Will Coleda wrote:
> a default build on feather is generating the following warnings:
>
> src/jit_emit.h:1725: warning: cast discards qualifiers from pointer target
> type src/jit_emit.h:1764: warning: cast discards qualifiers from pointer
>
On Monday 28 April 2008 14:00:28 NotFound wrote:
> The attached patch redoes the changes in these files with the new name.
Thanks! Applied in r27223.
-- c
chromatic wrote
> What if the PMC passed in isn't a Key PMC, but has an integer value?
Ah (sound of scales falling from my eyes) - the reason for the
test/switch:
if (VTABLE_isa(interp, key, CONST_STRING(interp, "Key"))) {
switch (PObj_get_FLAGS(key) & KEY_type_FLAGS) {
...
is to handl
The attached patch redoes the changes in these files with the new name.
--
Salu2
Index: src/encodings/utf16.c
===
--- src/encodings/utf16.c (revisión: 27222)
+++ src/encodings/utf16.c (copia de trabajo)
@@ -708,7 +708,7 @@
On Mon, Apr 28, 2008 at 10:05 PM, chromatic <[EMAIL PROTECTED]> wrote:
> I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than
> your version) and applied it as r27222.
Thanks, but in 27222 looks like only include/parrot/parrot.h reflects
the changes, not the files in sr
On 26 April 2008 chromatic wrote:
> src/key.c:306: warning: switch missing default case
Fixed in 27195.
Just a query, wouldn't:
Index: src/key.c
===
--- src/key.c (revision 27216)
+++ src/key.c (working copy)
@@ -329,12 +329,14
On Monday 28 April 2008 11:15:56 NotFound wrote:
> The attached patch adds the macro STRUCT_COPY_ST, and uses it in the
> src/charset charset init functions.
>
> All test pass with 27216 in my system (Ubuntu 8.04)
I renamed it to STRUCT_COPY_FROM_STRUCT (but that's only a little better than
your
On Mon, Apr 28, 2008 at 8:15 PM, NotFound <[EMAIL PROTECTED]> wrote:
> All test pass with 27216 in my system (Ubuntu 8.04)
Sorry, I mean 27219, 27216 was from the modified files.
--
Salu2
On Sat, Apr 26, 2008 at 8:16 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > A possible solution is to add another macro taking as second argument
> > the struct instead of a pointer.
> That seems cleaner to me; want to try that patch?
The attached patch adds the macro STRUCT_COPY_ST, and uses it
On Monday 28 April 2008 10:40:02 [EMAIL PROTECTED] wrote:
> Just a query, wouldn't:
> Index: src/key.c
> ===
> --- src/key.c (revision 27216)
> +++ src/key.c (working copy)
> @@ -329,12 +329,14 @@
> }
> case
On Sat, Apr 26, 2008 at 8:16 PM, chromatic <[EMAIL PROTECTED]> wrote:
> That seems cleaner to me; want to try that patch?
I'm out for the weekend, tomorrow I will work on it.
--
Salu2
On Fri Jul 07 09:05:57 2006, particle wrote:
> compilers\imcc\imcparser.c
> imcparser.c
> compilers\imcc\imcparser.c(878) : warning C4273: 'malloc' :
> inconsistent dll linkage
> compilers\imcc\imcparser.c(885) : warning C4273: 'free' : inconsistent
> dll linkage
>
> compilers\ast\astparser.c
> as
On Sat, Apr 26, 2008 at 7:39 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 25 April 2008 10:50:24 Will Coleda wrote:
>
> > Miscellaneous build warnings that need to be cleaned up.
> >
> > src/key.c:306: warning: switch missing default case
>
> Fix
On Friday 25 April 2008 10:50:24 Will Coleda wrote:
> Miscellaneous build warnings that need to be cleaned up.
>
> src/key.c:306: warning: switch missing default case
Fixed in 27195.
> compilers/imcc/imclexer.c:4288: warning: switch missing default case
> compilers/imcc/imclexer.
On Saturday 26 April 2008 09:03:12 NotFound wrote:
> I'v taken a look a those warnings some days ago. The macro STRUCT_COPY
> is generic and asserts his two parameter as non null, but is used in
> several places with arguments that the compiler knows is not, making
> the asserti
Hello
> The following lines that use the STRUCT_COPY macro are generating
> build warnings.
>
> src/charset/ascii.c:792: warning: the address of 'base_set' will
> always evaluate as 'true'
(snip)
> For example, the last line here is:
>
>
# New Ticket Created by Will Coleda
# Please include the string: [perl #53356]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53356 >
Miscellaneous build warnings that need to be cleaned up.
src/key.c:306: warning: swi
# New Ticket Created by Will Coleda
# Please include the string: [perl #53352]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53352 >
The following lines that use the STRUCT_COPY macro are generating
build warnings.
# New Ticket Created by Will Coleda
# Please include the string: [perl #53350]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53350 >
a default build on feather is generating the following warnings:
src/jit_emit.h:1
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51990]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51990 >
Fixed two compiler warnings in src/io/io_win32.c, and updated a
> # http://rt.perl.org/rt3/Ticket/Display.html?id=51984 >
>
>
> The file src/utils.c was producing a number of compile-time warnings
> involving possible loss of data in conversions from const int to
> unsigned char. This stemmed from the macro "move_reg", which passed
&
# New Ticket Created by "Andrew Whitworth"
# Please include the string: [perl #51984]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51984 >
The file src/utils.c was producing a number of compile-time warni
James Keenan via RT wrote:
This thread petered out after January 30, which was fine with me because
we couldn't diagnose why Allison's proposed patch was causing
Configure.pl to throw warnings on Darwin (OS X 10.4.11, ppc, gcc-3.3) at
config/auto/readline.pm. Configure.pl quietly did
On Sunday 16 March 2008 09:19:47 Matt Kraai wrote:
> The attached patch fixes the following warnings:
>
> make[1]: Entering directory `/home/kraai/src/parrot/languages'
> Makefile:352: warning: overriding commands for target `dotnet.realclean'
> Makefile:242: warning:
# New Ticket Created by Matt Kraai
# Please include the string: [perl #51798]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=51798 >
Howdy,
The attached patch fixes the following warnings:
make[1]: Entering direct
This thread petered out after January 30, which was fine with me because
we couldn't diagnose why Allison's proposed patch was causing
Configure.pl to throw warnings on Darwin (OS X 10.4.11, ppc, gcc-3.3) at
config/auto/readline.pm. Configure.pl quietly did its thing for me for
the ne
Thanks, applied as r25875.
-- c
1 - 100 of 613 matches
Mail list logo
