Re: [perl #130692] [BUG] IO::Socket::Async broken in 6.d.PREVIEW

Great, thanks for the update. On 15 Sep 2017 15:17, "jn...@jnthn.net via RT" wrote: > On Wed, 01 Feb 2017 13:11:21 -0800, j...@gellyfish.co.uk wrote: > > With 6.d.PREVIEW the simplest code for IO::Socket::Async mis-behaves: > > > > use v6.d.PREVIEW; > > > >

Re: [perl #125243] [SEGV] NativeCall segfault on rw struct pointer

No I think you're right. A naive ticket :) On Thu, 2016-10-06 at 13:45 -0700, Stefan Seifert via RT wrote: > I'm rejecting this ticket because the given example is simply wrong. > NativeCall translates a Str to char *, i.e. a pointer to a character > array. Thus it will reserve the memory to

Re: [perl #128469] [BUG] done() on first entry to whenever block does not exit react {}

Yep, Just confirmed here with all the original examples I gave, all good. Now to remember where it was I had hacked round this :-\ On Wed, 2016-09-07 at 10:40 -0700, Zoffix Znet via RT wrote: > This now appears to have been fixed by some of the recent async > fixes. > > Tests now pass and have

Re: [perl #128469] [BUG] done() on first entry to whenever block does not exit react {}

Yep, Just confirmed here with all the original examples I gave, all good. Now to remember where it was I had hacked round this :-\ On Wed, 2016-09-07 at 10:40 -0700, Zoffix Znet via RT wrote: > This now appears to have been fixed by some of the recent async > fixes. > > Tests now pass and have

Re: [perl #127860] [BUG][PRECOMP] Wrapped method fails when precompiled

precompilation" On Sat, 2016-04-09 at 03:24 -0700, Lloyd Fournier via RT wrote: > For reference this is another related to: > > https://rt.perl.org/Public/Bug/Display.html?id=125634 > > On Sat, Apr 9, 2016 at 7:10 AM Jonathan Stowe <perl6-bugs-followup@pe > rl.org&g

Re: [perl #125408] [BUG] CArray[num64] numiness optimised away

Good thing I didn't take the related TODO tests in my modules out :) On Fri, 2015-10-23 at 11:56 -0700, Will Coleda via RT wrote: > On Thu Sep 17 13:37:30 2015, FROGGS.de wrote: > > Fixed by jnthn++ with commit: > > > > https://github.com/MoarVM/MoarVM/commit/60a48e85b4928a9d66f2f8b87c5 > >

[perl #125408] [BUG] CArray[num64] numiness optimised away

This has come back again on Linux too with This is perl6 version 2015.07.1-88-gaf75bd7 built on MoarVM version 2015.07-8-gb8fdeae

[perl #125365] [BUG] Segfault on 0.^methods(:all).sort

gdb says: Program received signal SIGSEGV, Segmentation fault. 0x77952fb7 in push () from /home/jonathan/.rakudobrew/moar-nom/install/lib/libmoar.so and valgrind says: ==16279== Invalid write of size 8 ==16279==at 0x4FB4FB7: push (in

[PATCH(es)] round up of warning fixes

Parrot_Encoding struct parrot_encoding_t * /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[PATCH] Fix last warnings in encodings stuff

; +const char *end = start + s-bufused; int sign = 1; BOOLVAL seen_dot = 0; BOOLVAL seen_e = 0; /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[PATCH] Warning in packfile.c

, segment_size, sizeof(opcode_t)); +debug, segment_size, (long)sizeof(opcode_t)); return 0; } return 1; /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[Not OK] SCO_SV pigment 3.2 5.0.5 i386

at it - this should be considered FYI rather than something that should stop 0.04 ;-} /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[PATCH] Does jit.c warning reveal a bug ?

: address = (INTVAL *)s-type; BTW. Does anyone know why I get this in gdb : #0 0x8178324 in ?? () at eval.c:41 41 eval.c: No such file or directory. I can't find any '#file eval.c' in any of the source files. /J\ -- Jonathan Stowe | http://www.gellyfish.com

i386 jit print_s

for the time being perhaps we ought to skip the failing tests if we are doing 'testj' ? /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[PATCH] typo in jit/i386/string.jit

\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

Re: [PATCH] Bash some more warnings

, is the cast necessary? realloc() returns void*, after all... The cast is necessary with the warning level that we have currently :) /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[REPATCH] Re: [PATCH] Bash some more warnings

(struct Parrot_Interp *, char * pat, ...); +STRING* Parrot_sprintf_c(struct Parrot_Interp *, const char * pat, ...); void Parrot_sprintf(struct Parrot_Interp *, char *targ, char *pat, ...); Everything still appears to be working and no obvious leaks /J\ -- Jonathan Stowe

[REPATCH] Re: [PATCH] Bash some more warnings

)) { - KEY_PAIR* pair = key-keys[idx]; + KEY_PAIR* pair = (KEY_PAIR *)key-keys[idx]; pair-type++; } else { /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

RE: [Parrot-Newbie] Fooling around with parrot

: ~/parrotassemble.pl examples/assembly/euclid.pasm test.pbc ~/parrotpbc2c.pl test.pbc test.c Use of uninitialized value in sprintf at lib/Parrot/OpTrans/CGoto.pm line 97. ~/parrot Don't worry about the warnings ;-} /J\ -- Jonathan Stowe | http://www.gellyfish.com

[REPATCH]Re: [PATCH] Nearly the last of the warnings.

On Tue, 5 Feb 2002, Jonathan Stowe wrote: This might spoil someones future plans but doesn't break anything existing AFAICT - apart from those pesky ones left in misc.c the only ones left should be from generated code which I have a plan for which I will share later :) This is the same

RE: [REPATCH]Re: [PATCH] Nearly the last of the warnings.

On Wed, 6 Feb 2002, Brent Dax wrote: Jonathan Stowe: # - if(!(targ=Parrot_sprintf_c(interpreter, %S at %S line # %d.\n, targ, interpreter-current_file, # interpreter-current_line))) { # + if(!(targ=Parrot_sprintf_c(interpreter, (const char # *)%S at %S line %d.\n, targ, interpreter

[PATCH misc.c] Fix up *some* of the warnings

); targ=string_concat(interpreter, targ, cstr2pstr(t2), 0); break; -- Jonathan Stowe | http://www.gellyfish.com | This space

[PATCH] Nearly the last of the warnings.

*, const char * pat, ...); void Parrot_sprintf(struct Parrot_Interp *, char *targ, char *pat, ...); Have fun /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

Re: [PATCH] Nearly the last of the warnings.

; case 6: -address = (INTVAL *)s-encoding; +address = (INTVAL *)s-encoding; Gasp -- an example of a warning actually identifiying a bug!? Surprised me - it got away in the storm of warnings no doubt ;-} /J\ -- Jonathan Stowe

Re: [PATCH] Nearly the last of the warnings.

On Tue, 5 Feb 2002, Andy Dougherty wrote: On Tue, 5 Feb 2002, Jonathan Stowe wrote: AFAICT - apart from those pesky ones left in misc.c the only ones left should be from generated code which I have a plan for which I will share later :) Well, those and the 86 cast increases

[PATCH global_setup.h] Bash another warning

(void); +void Parrot_Array_class_init(void); void Parrot_PerlHash_class_init(void); void Parrot_ParrotPointer_class_init(void); void Parrot_IntQueue_class_init(void); /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[PATCH test_main.c config_h.in] Warning in test_main.c

+ #define setopt(flag) Parrot_setflag(interpreter, flag, (*argv)[0]+2); char * /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

[PATCH embed.c] More warnings

(interpreter, userargv, /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

Re: [PATCH test_main.c config_h.in] Warning in test_main.c

On Fri, 1 Feb 2002, Jonathan Stowe wrote: This shuts up the implicit declaration warning in test_main.c : +#include parrot/config.h ... On closer examination that line is probably not needed :) /J\ -- Jonathan Stowe | http://www.gellyfish.com

RE: [PATCH test_main.c config_h.in] Warning in test_main.c

On Fri, 1 Feb 2002, Brent Dax wrote: Jonathan Stowe: # This shuts up the implicit declaration warning in test_main.c : # # --- config_h.in~Fri Feb 1 07:39:42 2002 # +++ config_h.in Fri Feb 1 07:40:06 2002 # @@ -51,9 +51,10 @@ # #define INTVAL_FMT ${intvalfmt} # #define

Re: CPP Namespace pollution

with a shell on the CVS (and the appropriate permissions :) server to move the files to the new layout ... /J\ -- Jonathan Stowe | http://www.gellyfish.com | This space for rent |

Re: mem_allocate_aligned

On Mon, 10 Dec 2001, Dan Sugalski wrote: We need an allocate zeroed call too. We can get zeroed pages faster in some cases than we can allocate pages and zero them ourselves. Isn't that calloc() ? /J\ -- Jonathan Stowe | http://www.gellyfish.com