Vim segfaults on macOS 10.13/14 on hitting n right after startup

I can only partly reproduce this segfaulting, but it almost always happens (when it does happen) when I start up vim and then the first thing I do is hit n.   Sometimes I have to move the cursor first before hitting n.
If I manually edit my viminfo to delete the "last search pattern", the crash temporarily disappears.  If I search for something with / and then quit, usually the very next vim instance will segfault as soon as I hit n.
This happens on Vim and also MacVim.
I did a git-bisect, and the culprit is 8.1.0351:
198cb66d652d3d8ac16226dcc929a11b0b720151 is the first bad commit
commit 198cb66d652d3d8ac16226dcc929a11b0b720151
Author: Bram Moolenaar<EMAIL_ADDRESS>Date:   Thu Sep 6 21:44:17 2018 +0200

    patch 8.1.0351: 'incsearch' for :/foo/s//<Esc> changes last search pattern

    Problem:    'incsearch' for :/foo/s//<Esc> changes last search pattern.
    Solution:   Save the last search pattern earlier.

Here is what appears to be the relevant portion of the macOS crash report, if it helps:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x0000000112cb948a __kill + 10
1   vim                           	0x000000010f795c89 0x10f680000 + 1137801
2   vim                           	0x000000010f8905b3 0x10f680000 + 2164147
3   libsystem_platform.dylib      	0x0000000112ce2f5a _sigtramp + 26
4   com.apple.CoreData            	0x000000011471afdb 0x11442d000 + 3071963
5   vim                           	0x000000010f7feb4c 0x10f680000 + 1567564
6   vim                           	0x000000010f772edc 0x10f680000 + 995036
7   vim                           	0x000000010f76ea79 0x10f680000 + 977529
8   vim                           	0x000000010f766676 0x10f680000 + 943734
9   vim                           	0x000000010f890b66 0x10f680000 + 2165606
10  vim                           	0x000000010f8900dd 0x10f680000 + 2162909
11  vim                           	0x000000010f88eb50 0x10f680000 + 2157392
12  libdyld.dylib                 	0x0000000112860015 start + 1

That's part a crash report for Vim.  The ones for MacVim might be a bit more helpful:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00000001175dd48a __kill + 10
1   Vim                           	0x000000010fb11291 mch_exit + 257
2   Vim                           	0x000000010fc2b077 getout + 615
3   libsystem_platform.dylib      	0x0000000117602f5a _sigtramp + 26
4   com.apple.CoreData            	0x0000000112ea7fdb 0x112bba000 + 3071963
5   Vim                           	0x000000010fb7b1bc do_search + 892
6   Vim                           	0x000000010faed86c normal_search + 76
7   Vim                           	0x000000010fae9269 nv_next + 57
8   Vim                           	0x000000010fae0dc6 normal_cmd + 6022
9   Vim                           	0x000000010fc2b676 main_loop + 1510
10  Vim                           	0x000000010fc2aceb vim_main2 + 3675
11  Vim                           	0x000000010fc292c9 main + 9993
12  libdyld.dylib                 	0x00000001171cf015 start + 1

Hm, I cannot seem to reproduce this. Can you compile with SANITIZER_FLAGS enabled (see src/Makefile)? Also, since the offending commit is about incsearch, I assume one must have :set incsearch, so  vim -u NONE -N -c ':set incsearch' should be enough to trigger this bug? (not using --clean since that would skip reading the viminfo file for the last used pattern). I tried, but it worked okay in a local ASAN enabled build.

I do not have incsearch set when this segfault happens.  (Or ever, for that matter.)  The commit appears to have changed interaction with the last pattern whether or not &insearch is set.
I will try your test later today when I get a chance.  I will also try to see what part of my vimrc/startup script is involved, but I've already been working on that and its difficult.  I can get reliable reproduction, and then I comment out a random line in the startup files and the crash goes away for the next startup or two, then returns.

I tried both ways mentioned in the Makefile for compiling with SANITIZER_FLAGS.   The Makefile says results should be printed to stderr, but I didn't get any output that I wasn't already getting.

@chdiza wrote:

but I didn't get any output that I wasn't already getting.

Maybe that's not a memory error then. Still, to be sure, you could try with valgrind.
You need to build normally without the address sanitizer (as it's not compatible
with valgrind) then you can run vim with:
$ valgrind ./vim 2> valgrind.log

Errors found with valgrind will be sent to valgrind.log.  Vim will be slow with valgrind but it should be fine to reproduce your bug.

@dpelle OK, I'll try that.  In the meantime I somehow managed to run lldb and get the following:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)                                      16:04  11.11.18     0K
  * frame #0: 0x00007fff6db4e712 libsystem_platform.dylib`_platform_strlen + 18
    frame #1: 0x000000010017ea6c vim`___lldb_unnamed_symbol2707$$vim + 892
    frame #2: 0x00000001000f2dfc vim`___lldb_unnamed_symbol2214$$vim + 76
    frame #3: 0x00000001000ee999 vim`___lldb_unnamed_symbol2184$$vim + 57
    frame #4: 0x00000001000e6596 vim`___lldb_unnamed_symbol2113$$vim + 6006
    frame #5: 0x0000000100210b66 vim`___lldb_unnamed_symbol3726$$vim + 1430
    frame #6: 0x00000001002100dd vim`___lldb_unnamed_symbol3724$$vim + 2861
    frame #7: 0x000000010020eb50 vim`___lldb_unnamed_symbol3721$$vim + 6592[All]
    frame #8: 0x00007fff6d96808d libdyld.dylib`start + 1
(lldb)

Don't know if that helps.

I re-tried lldb, this time on the `Vim' embedded in MacVim, and got the following:
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007fff6db4e712 libsystem_platform.dylib`_platform_strlen + 18
    frame #1: 0x0000000100185a9c Vim`do_search + 892
    frame #2: 0x00000001000f78ac Vim`normal_search + 76
    frame #3: 0x00000001000f3299 Vim`nv_next + 57
    frame #4: 0x00000001000eadf6 Vim`normal_cmd + 6022
    frame #5: 0x0000000100236596 Vim`main_loop + 1510
    frame #6: 0x0000000100235c0b Vim`vim_main2 + 3675
    frame #7: 0x00000001002341e9 Vim`main + 9993
    frame #8: 0x00007fff6d96808d libdyld.dylib`start + 1
(lldb)

FYI I can reproduce this on multiple machines, on both 10.13.6 and 10.14.1.

I can only partly reproduce this segfaulting, but it almost always
happens (when it does happen) when I start up vim and then the first
thing I do is hit n.   Sometimes I have to move the cursor first
before hitting n.
If I manually edit my viminfo to delete the "last search pattern", the
crash temporarily disappears.  If I search for something with / and
then quit, usually the very next vim instance will segfault as soon as
I hit n.
This happens on Vim and also MacVim.
I did a git-bisect, and the culprit is 8.1.0351:
198cb66d652d3d8ac16226dcc929a11b0b720151 is the first bad commit
commit 198cb66d652d3d8ac16226dcc929a11b0b720151
Author: Bram Moolenaar<EMAIL_ADDRESS>Date:   Thu Sep 6 21:44:17 2018 +0200

    patch 8.1.0351: 'incsearch' for :/foo/s//<Esc> changes last search pattern

    Problem:    'incsearch' for :/foo/s//<Esc> changes last search pattern.
    Solution:   Save the last search pattern earlier.

I don't see how this patch would break this.  I do notice that in one
place the search pattern is not restored.  I'll fix that and add a check
that the save and restore are balanced.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@brammool Thanks, but that doesn't fix the crash.
I'm very close to being able to provide a minimal reproduction case (at least for macOS).  It's taking awhile to comment out portions of a 2000-line script!

I can now reproduce this every time, and also now on a third machine running a third version of macOS (10.11).  This uses a tiny vimrc that makes little sense (it was trimmed down from a huge script), but that shouldn't segfault.
Use the following as the vimrc:
set nocp
set viminfo+=n~/testviminfo

nnoremap r :call Foobar()<CR>
nnoremap <silent> 0 :call cursor(".", 2)<CR>

function Foobar()
  call setline(1, "Happy")
  silent g/f.*\n/d
  "Invokes the nnoremap above:
  normal 0
endfunction

call Foobar()

And a optionally make a file "testviminfo" that contains just something simple as the last search entry, e.g.
# Last Search Pattern:
~MSle0/bar

Now start with vim.  If you pre-seeded the testviminfo file, just hit n and on macOS vim should segfault immmediately.  (If it doesn't, hit r' and then hit n.)  If you did not pre-seed the testviminfo file, use the slash to enter barand hit return, then hitr, then hit n`.  Segfault.
The setline() isn't actually required to generate the segfault, but I put it there lest anyone think the segfault is just something that happens with empty buffers.
Also, I verified that on all three machines, the patch that breaks vim is 8.1.0351.  (8.1.0350 is fine with no segfault.)
FYI, I built vim with the following configuration flags:
    --disable-gui
    --without-x
    --disable-netbeans
    --disable-nls

I can reproduce the mentioned segfault for the case:

If you did not pre-seed the testviminfo file, use the slash to enter bar and hit return, then hit r, then hit n.

The backtrace I got is:
(master %=)% lldb
(lldb) process attach --waitfor --name vim
Process 38325 stopped
* thread #1: tid = 0x19af2a3, 0x00007fff67095fd3 dyld`ImageLoaderMachOCompressed::trieWalk(unsigned char const*, unsigned char const*, char const*) + 259, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff67095fd3 dyld`ImageLoaderMachOCompressed::trieWalk(unsigned char const*, unsigned char const*, char const*) + 259
dyld`ImageLoaderMachOCompressed::trieWalk:
->  0x7fff67095fd3 <+259>: movq   %r14, %rbx
    0x7fff67095fd6 <+262>: addq   $0x2, %rbx
    0x7fff67095fda <+266>: cmpb   $0x0, (%rax)
    0x7fff67095fdd <+269>: movq   %rax, %r14

Executable module set to "/Users/kazu/Documents/projects/vim/src/./vim".
Architecture set to: x86_64-apple-macosx.
(lldb) c
Process 38325 resuming
Process 38325 stopped
* thread #1: tid = 0x19af2a3, 0x00007fff8dbe6132 libsystem_c.dylib`strlen + 18, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00007fff8dbe6132 libsystem_c.dylib`strlen + 18
libsystem_c.dylib`strlen:
->  0x7fff8dbe6132 <+18>: pcmpeqb (%rdi), %xmm0
    0x7fff8dbe6136 <+22>: pmovmskb %xmm0, %esi
    0x7fff8dbe613a <+26>: andq   $0xf, %rcx
    0x7fff8dbe613e <+30>: orq    $-0x1, %rax
(lldb) bt
* thread #1: tid = 0x19af2a3, 0x00007fff8dbe6132 libsystem_c.dylib`strlen + 18, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007fff8dbe6132 libsystem_c.dylib`strlen + 18
    frame #1: 0x00000001046e89d2 vim`do_search(oap=0x00007fff5b6ded68, dirc=47, pat=0x0000000000000000, count=1, options=542, tm=0x0000000000000000, timed_out=0x0000000000000000) + 1458 at search.c:1377
    frame #2: 0x0000000104656ba8 vim`normal_search(cap=0x00007fff5b6decc0, dir=0, pat=0x0000000000000000, opt=512) + 136 at normal.c:6384
    frame #3: 0x0000000104650e43 vim`nv_next(cap=0x00007fff5b6decc0) + 67 at normal.c:6352
    frame #4: 0x0000000104645513 vim`normal_cmd(oap=0x00007fff5b6ded68, toplevel=1) + 5795 at normal.c:1121
    frame #5: 0x00000001047b38d7 vim`main_loop(cmdwin=0, noexmode=0) + 2007 at main.c:1371
    frame #6: 0x00000001047b23ab vim`vim_main2 + 2475 at main.c:917
    frame #7: 0x00000001047af8ef vim`main(argc=1, argv=0x00007fff5b6deee0) + 1167 at main.c:441
    frame #8: 0x00007fff8fe575ad libdyld.dylib`start + 1

The Vim was built on macOS 10.11.6 with
$ make CFLAGS="-O0 -g"

And the version is 8.1.551.

Thanks @nuko8  for the valgrind report.  Since it shows use of uninitialized memory, valgrind will give even more information with these options:
$ valgrind --track-origins=yes --num-callers=50 vim

The --track-origins=yes option helps to show where the uninitialized memory comes (at the cost of being slower) from and the --num-callers=50 helps avoiding truncated stack traces.

@dpelle Here you are :)
==43619== Memcheck, a memory error detector
==43619== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==43619== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==43619== Command: ./vim
==43619==
==43619== Conditional jump or move depends on uninitialised value(s)
==43619==    at 0x7FFF5FC23DC7: bcmp (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC11AF4: ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC16D6A: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC10C5E: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC038C2: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC085BF: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC082DF: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC08044: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC07799: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0347A: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0315E: dyld::load(char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC088F9: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0EA4D: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0ED21: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0E753: ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC04A11: dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC05BE3: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01275: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01035: _dyld_start (in /usr/lib/dyld)
==43619==  Uninitialised value was created by a stack allocation
==43619==    at 0x7FFF5FC10B38: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==
==43619== Use of uninitialised value of size 8
==43619==    at 0x7FFF5FC23DDF: bcmp (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC11AF4: ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC16D6A: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC10C5E: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC038C2: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC085BF: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC082DF: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC08044: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC07799: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0347A: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0315E: dyld::load(char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC088F9: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0EA4D: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0ED21: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0E753: ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC04A11: dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC05BE3: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01275: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01035: _dyld_start (in /usr/lib/dyld)
==43619==  Uninitialised value was created by a stack allocation
==43619==    at 0x7FFF5FC10B38: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==
==43619== Use of uninitialised value of size 8
==43619==    at 0x7FFF5FC23DE4: bcmp (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC11AF4: ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC16D6A: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC10C5E: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC038C2: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC085BF: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC082DF: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC08044: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC07799: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0347A: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0315E: dyld::load(char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC088F9: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0EA4D: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0ED21: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0E753: ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC04A11: dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC05BE3: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01275: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01035: _dyld_start (in /usr/lib/dyld)
==43619==  Uninitialised value was created by a stack allocation
==43619==    at 0x7FFF5FC10B38: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==
==43619== Conditional jump or move depends on uninitialised value(s)
==43619==    at 0x7FFF5FC11AF7: ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC16D6A: ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC10C5E: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC038C2: dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC085BF: dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC082DF: dyld::loadPhase4(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC08044: dyld::loadPhase3(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC07799: dyld::loadPhase1(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0347A: dyld::loadPhase0(char const*, char const*, dyld::LoadContext const&, std::__1::vector<char const*, std::__1::allocator<char const*> >*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0315E: dyld::load(char const*, dyld::LoadContext const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC088F9: dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0EA4D: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0ED21: ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC0E753: ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC04A11: dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC05BE3: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01275: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)
==43619==    by 0x7FFF5FC01035: _dyld_start (in /usr/lib/dyld)
==43619==  Uninitialised value was created by a stack allocation
==43619==    at 0x7FFF5FC10B38: ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==43619==
--43619-- UNKNOWN host message [id 219, to mach_host_self(), reply 0x60f]
==43619== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==43619==          the SIGUSR2 signal is used internally by Valgrind
--43619-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option
--43619-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)
--43619-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)
--43619-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 8 times)
==43619== Conditional jump or move depends on uninitialised value(s)
==43619==    at 0x102C992A6: strnlen (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x102CA9451: stpncpy (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x102D1CB74: __strncpy_chk (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x100110C1B: vim_strncpy (misc2.c:1754)
==43619==    by 0x1002A151D: store_sb_text (message.c:2443)
==43619==    by 0x1002A0F9C: msg_puts_display (message.c:2297)
==43619==    by 0x10029AB84: msg_puts_attr_len (message.c:2056)
==43619==    by 0x10029A9D7: msg_outtrans_len_attr (message.c:1585)
==43619==    by 0x10029AA0C: msg_outtrans_len (message.c:1479)
==43619==    by 0x1000A3C0F: draw_cmdline (ex_getln.c:3328)
==43619==    by 0x1000A43C5: put_on_cmdline (ex_getln.c:3494)
==43619==    by 0x1000A26C2: getcmdline_int (ex_getln.c:2379)
==43619==    by 0x10009ECA5: getcmdline (ex_getln.c:807)
==43619==    by 0x10012F918: nv_search (normal.c:6331)
==43619==    by 0x100125512: normal_cmd (normal.c:1121)
==43619==    by 0x1002938D6: main_loop (main.c:1371)
==43619==    by 0x1002923AA: vim_main2 (main.c:917)
==43619==    by 0x10028F8EE: main (main.c:441)
==43619==  Uninitialised value was created by a heap allocation
==43619==    at 0x1003B9681: malloc (vg_replace_malloc.c:302)
==43619==    by 0x10010FAD1: lalloc (misc2.c:969)
==43619==    by 0x10010FA77: alloc (misc2.c:867)
==43619==    by 0x1000A3978: draw_cmdline (ex_getln.c:3261)
==43619==    by 0x1000A43C5: put_on_cmdline (ex_getln.c:3494)
==43619==    by 0x1000A26C2: getcmdline_int (ex_getln.c:2379)
==43619==    by 0x10009ECA5: getcmdline (ex_getln.c:807)
==43619==    by 0x10012F918: nv_search (normal.c:6331)
==43619==    by 0x100125512: normal_cmd (normal.c:1121)
==43619==    by 0x1002938D6: main_loop (main.c:1371)
==43619==    by 0x1002923AA: vim_main2 (main.c:917)
==43619==    by 0x10028F8EE: main (main.c:441)
==43619==
==43619== Conditional jump or move depends on uninitialised value(s)
==43619==    at 0x102C992D2: strnlen (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x102CA9451: stpncpy (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x102D1CB74: __strncpy_chk (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x100110C1B: vim_strncpy (misc2.c:1754)
==43619==    by 0x1002A151D: store_sb_text (message.c:2443)
==43619==    by 0x1002A0F9C: msg_puts_display (message.c:2297)
==43619==    by 0x10029AB84: msg_puts_attr_len (message.c:2056)
==43619==    by 0x10029A9D7: msg_outtrans_len_attr (message.c:1585)
==43619==    by 0x10029AA0C: msg_outtrans_len (message.c:1479)
==43619==    by 0x1000A3C0F: draw_cmdline (ex_getln.c:3328)
==43619==    by 0x1000A43C5: put_on_cmdline (ex_getln.c:3494)
==43619==    by 0x1000A26C2: getcmdline_int (ex_getln.c:2379)
==43619==    by 0x10009ECA5: getcmdline (ex_getln.c:807)
==43619==    by 0x10012F918: nv_search (normal.c:6331)
==43619==    by 0x100125512: normal_cmd (normal.c:1121)
==43619==    by 0x1002938D6: main_loop (main.c:1371)
==43619==    by 0x1002923AA: vim_main2 (main.c:917)
==43619==    by 0x10028F8EE: main (main.c:441)
==43619==  Uninitialised value was created by a heap allocation
==43619==    at 0x1003B9681: malloc (vg_replace_malloc.c:302)
==43619==    by 0x10010FAD1: lalloc (misc2.c:969)
==43619==    by 0x10010FA77: alloc (misc2.c:867)
==43619==    by 0x1000A3978: draw_cmdline (ex_getln.c:3261)
==43619==    by 0x1000A43C5: put_on_cmdline (ex_getln.c:3494)
==43619==    by 0x1000A26C2: getcmdline_int (ex_getln.c:2379)
==43619==    by 0x10009ECA5: getcmdline (ex_getln.c:807)
==43619==    by 0x10012F918: nv_search (normal.c:6331)
==43619==    by 0x100125512: normal_cmd (normal.c:1121)
==43619==    by 0x1002938D6: main_loop (main.c:1371)
==43619==    by 0x1002923AA: vim_main2 (main.c:917)
==43619==    by 0x10028F8EE: main (main.c:441)
==43619==
==43619== Conditional jump or move depends on uninitialised value(s)
==43619==    at 0x102CA945E: stpncpy (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x102D1CB74: __strncpy_chk (in /usr/lib/system/libsystem_c.dylib)
==43619==    by 0x100110C1B: vim_strncpy (misc2.c:1754)
==43619==    by 0x1002A151D: store_sb_text (message.c:2443)
==43619==    by 0x1002A0F9C: msg_puts_display (message.c:2297)
==43619==    by 0x10029AB84: msg_puts_attr_len (message.c:2056)
==43619==    by 0x10029A9D7: msg_outtrans_len_attr (message.c:1585)
==43619==    by 0x10029AA0C: msg_outtrans_len (message.c:1479)
==43619==    by 0x1000A3C0F: draw_cmdline (ex_getln.c:3328)
==43619==    by 0x1000A43C5: put_on_cmdline (ex_getln.c:3494)
==43619==    by 0x1000A26C2: getcmdline_int (ex_getln.c:2379)
==43619==    by 0x10009ECA5: getcmdline (ex_getln.c:807)
==43619==    by 0x10012F918: nv_search (normal.c:6331)
==43619==    by 0x100125512: normal_cmd (normal.c:1121)
==43619==    by 0x1002938D6: main_loop (main.c:1371)
==43619==    by 0x1002923AA: vim_main2 (main.c:917)
==43619==    by 0x10028F8EE: main (main.c:441)
==43619==  Uninitialised value was created by a heap allocation
==43619==    at 0x1003B9681: malloc (vg_replace_malloc.c:302)
==43619==    by 0x10010FAD1: lalloc (misc2.c:969)
==43619==    by 0x10010FA77: alloc (misc2.c:867)
==43619==    by 0x1000A3978: draw_cmdline (ex_getln.c:3261)
==43619==    by 0x1000A43C5: put_on_cmdline (ex_getln.c:3494)
==43619==    by 0x1000A26C2: getcmdline_int (ex_getln.c:2379)
==43619==    by 0x10009ECA5: getcmdline (ex_getln.c:807)
==43619==    by 0x10012F918: nv_search (normal.c:6331)
==43619==    by 0x100125512: normal_cmd (normal.c:1121)
==43619==    by 0x1002938D6: main_loop (main.c:1371)
==43619==    by 0x1002923AA: vim_main2 (main.c:917)
==43619==    by 0x10028F8EE: main (main.c:441)
==43619==
==43619== Invalid read of size 1
==43619==    at 0x1003BAE93: strlen (vg_replace_strmem.c:474)
==43619==    by 0x1001C89D1: do_search (search.c:1377)
==43619==    by 0x100136BA7: normal_search (normal.c:6384)
==43619==    by 0x100130E42: nv_next (normal.c:6352)
==43619==    by 0x100125512: normal_cmd (normal.c:1121)
==43619==    by 0x1002938D6: main_loop (main.c:1371)
==43619==    by 0x1002923AA: vim_main2 (main.c:917)
==43619==    by 0x10028F8EE: main (main.c:441)
==43619==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==43619==
--43619-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--43619-- si_code=1;  Faulting address: 0x7000084EA000;  sp: 0x700006d7db98

valgrind: the 'impossible' happened:
   Killed by fatal signal

host stacktrace:
==43619==    at 0x25805B020: ???
==43619==    by 0x2580CA0EA: ???
==43619==    by 0x2580C0864: ???
==43619==    by 0x2580BF1A7: ???
==43619==    by 0x2580BD1BA: ???
==43619==    by 0x2580CE8A7: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 2567)
==43619==    at 0x102DE78EA: __kill (in /usr/lib/system/libsystem_kernel.dylib)
==43619==    by 0x10016352B: may_core_dump (os_unix.c:3425)
==43619==    by 0x1001633FA: mch_exit (os_unix.c:3391)
==43619==    by 0x100292F75: getout (main.c:1553)
==43619==    by 0x10010B10A: preserve_exit (misc1.c:9830)
==43619==    by 0x1001688D9: deathtrap (os_unix.c:1191)
==43619==    by 0x25805D0CB: ???

Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

I can now reproduce this every time, and also now on a third machine
running a third version of macOS (10.11).  This uses a tiny vimrc that
makes little sense (it was trimmed down from a huge script), but that
shouldn't segfault.
Use the following as the vimrc:
set nocp
set viminfo+=n~/testviminfo

nnoremap r :call Foobar()<CR>
nnoremap <silent> 0 :call cursor(".", 2)<CR>

function Foobar()
  call setline(1, "Happy")
  silent g/f.*\n/d
  "Invokes the nnoremap above:
  normal 0
endfunction

call Foobar()

And a optionally make a file "testviminfo" that contains just
something simple as the last search entry, e.g.
# Last Search Pattern:
~MSle0/bar

Now start with vim.  If you pre-seeded the testviminfo file, just
hit n and on macOS vim should segfault immmediately.  (If it
doesn't, hit r' and then hit n.)  If you did not pre-seed the testviminfo file, use the slash to enter barand hit return, then hitr, then hit n`.  Segfault.
The setline() isn't actually required to generate the segfault, but
I put it there lest anyone think the segfault is just something that
happens with empty buffers.
Also, I verified that on all three machines, the patch that breaks vim
is 8.1.0351.  (8.1.0350 is fine with no segfault.)
FYI, I built vim with the following configuration flags:
    --disable-gui
    --without-x
    --disable-netbeans
    --disable-nls

Thanks for the example.  I could reproduce the problem.  Somehow it was
using the last substitute pattern, instead of the last search pattern,
and you managed to make the last substitute pattern empty.
I'll make a fix.
--
[The rest of the ARMY stand around looking at a loss.]
INSPECTOR END OF FILM: (picks up megaphone) All right!  Clear off!  Go on!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Thanks @brammool for the fix and to all others for the efforts at reproduction.
I wonder why valgrind didn't show me anything, but it showed @nuko8 a lot of stuff.  I too built with -O0 -g.
Also, I wonder how 8.1.0351 triggered this.

Also, I wonder why the crash required almost every single line in that sample vimrc, instead of occurring regardless of vimrc whenever one's viminfo file had an empty previous substitute pattern.  E.g., there needed to be that mapping; if the RHS goes directly in the function, the crash doesn't happen.

@brammool  I think the fix broke something else.
Now the testviminfo file has bar as the last search pattern.  So when I hit n, it should tell me that there's no bar in the buffer ("pattern not found"), or if there happens to be a bar in the buffer it should jump to it.  But instead it tells me E35: No previous regular expression.

To reproduce the latest inadvertent breakage, use the above vimrc and testviminfo:

Start vim.
Type /pp<CR>
Observe the cursor on the first "p" in "Happy", and observe "search hit BOTTOM, continuing at TOP".
Type r.
Type n.

Expected: the cursor is on the first "p" in "Happy", and "search hit BOTTOM, continuing at TOP" is shown.
Actual: observe "E35: No previous regular expression".

To reproduce the latest inadvertent breakage, use the above vimrc and
testviminfo:

Start vim.
Type /pp<CR>
Observe the cursor on the first "p" in "Happy", and observe "search hit BOTTOM, continuing at TOP".
Type r.
Type n.

Expected: the cursor is on the first "p" in "Happy", and "search hit
BOTTOM, continuing at TOP" is shown.
Actual: observe "E35: No previous regular expression".

That is strange...  Ah, when saving/restoring search patterns there are
two mechanisms, and they use separate saved patterns, but both use
saved_last_idx.  Thus it gets mixed up when searching inside a function.
I'll fix that.
--
The MS-Windows registry is no more hostile than any other bunch of state
information... that is held in a binary format... a format that nobody
understands... and is replicated and cached in a complex and largely
undocumented way... and contains large amounts of duplicate and obfuscated
information...  (Ben Peterson)
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@brammool  I think the fix broke something else.
Now the testviminfo file has bar as the last search pattern.  So
when I hit n, it should tell me that there's no bar in the buffer
("pattern not found"), or if there happens to be a bar in the buffer
it should jump to it.  But instead it tells me E35: No previous regular expression.

The pattern is actually empty, try:
:echo @/
The viminfo you gave adds 'bar' as the last search pattern, but doesn't
have the "~" character to indicate it's the last used one.  So in a way
this viminfo is wrong.  This normally can't happen.
--
A disclaimer for the disclaimer:
"and before I get a huge amount of complaints , I have no control over the
disclaimer at the end of this mail :-)" (Timothy Aldrich)
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///


Simplify code

Use Redis.current instead of creating global $redis variable in tests
Move Feature class to its own file.

a follow up task could be to create a Rollout.current that acts similar to Redis.current so we don't need to pollute the runtime with global variables. I didn't do it here because I thought it warranted a conversation first, as its a bit more complex than how Redis.current works.

@lifeiscontent thanks!


clean-webpack-plugin 已升级 配置项发生改变

describe your changes...

[ ] Read and sign the CLA. PRs that haven't signed it won't be accepted.
[ ] Make sure your PR complies with the writer's guide.
[ ] Review the diff carefully as sometimes this can reveal issues.
Remove these instructions from your PR as they are for your eyes only.

@dear-lizhihua 老铁, 你们的PR审阅也太慢了吧, 这个老兄28天之前就提交PR了

清明节合并吧，pr 积累得有点多，一直在忙工作上面的事情。


[FEATURE] Federated PPL Query Engine - support for victoriametrics

Is your feature request related to a problem?
This is not related to a current problem
What solution would you like?
With the forthcoming "Federated PPL Query Engine" feature , please look to support/validate/test against victoriametrics.
It should be "line compatible' with the prometheus protocol already being developed.
For example, grafana can already use victoriametrics as a prometheus datastore.
It has a backwards-compatible PromQL inspired query language called MetricsQL
https://docs.victoriametrics.com/MetricsQL.html
I do not know if there would be enough interested in supporting its additional features.
What alternatives have you considered?
n/a
Do you have any additional context?
VictoriaMetrics: PromQL compliance
https://medium.com/@romanhavronenko/victoriametrics-promql-compliance-d4318203f51e

@rajiv_taori / @nitin_c

@anirudha any update on this?

cross reference: https://github.com/VictoriaMetrics/VictoriaMetrics/issues/3235


[Feature]: FACodec training

Will you release the source code for the FACodec training pipeline?

Hi, thank you very much for your attention, we are still developing the training code.

Hi, thank you very much for your attention, we are still developing the training code.

@HeCheng0625 Do you plan to release another FACodec checkpoint that supports different hop size, such as 320, which is commonly used in other SSL pre-trained models?

Hi @TechInterMezzo , we're releasing the FACodec training code in Amphion (it's now in a PR #229  and will be merged soon). You're welcome to check it out. Thanks!


Add Vagrant 1.7.2 and Virtualbox 4.3.30-101610

Problem
Virtualbox 5.0 was released and in response Vagrant released version 1.7.3 to maintain "current" support, but the package is still relatively broken. The latest versioned package for Vagrant is 1.7.1 and the latest for Virtualbox is 4.3.28, both outdated.
Solution

Package Vagrant 1.7.2
Package Virtualbox 4.3.30

In the future, please submit separate pull requests for each cask, as more often than not this type of pull request brings problems with one or more of them, and it halts the inclusion of the other ones.

In the future, please submit separate pull requests for each cask, as more often than not this type of pull request brings problems with one or more of them, and it halts the inclusion of the other ones.
Either way, these should definitely be separate commits.

I have to +1 for issues of vagrant 1.7.3. Downgrading to 1.7.2 fixes the issue. Very appreciate this PR. Thanks!

@vitorgalvao I understand your desire for separate PRs, but in this case these two pieces of software are intrinsically linked, and having one without the other defeats the purpose.

@mitchellnemitz I believe the convention in that case is to highlight in the description of the dependent PR that it must not be merged until its parent is, and possibly prefix the title with "[HOLD UNTIL #XX]". What do you think, @vitorgalvao?

@jawshooah Agreed.


File backend: Close lock file after creation

Unclosed file descriptors eventually lead to "Too many open files" error.

Hey @xuhcc thanks for the patch. The tests are now fixed, is this PR ready to go?

Hi @cameronmaske  !
Yes, it's ready


[SPARK-26592][SS][DOC] Add Kafka proxy user caveat to documentation

What changes were proposed in this pull request?
Since this caveat added to the DStreams documentation it would be good to add to Structured Streaming as well.
How was this patch tested?
cd docs/
SKIP_API=1 jekyll build
Manual webpage check.

@vanzin I was thinking about whether it worth to create a new jira and decided to open the PR against SPARK-26592 since its really small change and belongs to there.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Test build #103045 has started for PR 23974 at commit ca5f9b6.

Test build #103045 has finished for PR 23974 at commit ca5f9b6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/103045/
Test PASSed.

Merging to master.


Actix web hello world

making a hello-world server using actix-web

Codecov Report

Merging #1 (5fd20f5) into main (5737da7) will decrease coverage by 50.00%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #1       +/-   ##
==========================================
- Coverage   50.00%   0.00%   -50.00%
==========================================
  Files           1       1
  Lines           2       9        +7
==========================================
- Hits            1       0        -1
- Misses          1       9        +8

Impacted Files
Coverage Δ

intrepion/src/main.rs
0.00% <0.00%> (-50.00%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5737da7...5fd20f5. Read the comment docs.


[SPARK-49518][K8S][BUILD] Change to using build-helper-maven-plugin to manage the code for volcano

What changes were proposed in this pull request?
The main changes in this pr are as follows:

In resource-managers/kubernetes/core/pom.xml and resource-managers/kubernetes/integration-tests/pom.xml, the build-helper-maven-plugin configuration has been added for the volcano profile to ensure that when the profile is activated with -Pvolcano, the volcano/src/main/scala directory is treated as an additional source path, and volcano/src/test/scala directory is treated as an additional test code path.

resource-managers/kubernetes/core/pom.xml

      <build>
        <plugins>
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>build-helper-maven-plugin</artifactId>
            <executions>
              <execution>
                <id>add-volcano-source</id>
                <phase>generate-sources</phase>
                <goals>
                  <goal>add-source</goal>
                </goals>
                <configuration>
                  <sources>
                    <source>volcano/src/main/scala</source>
                  </sources>
                </configuration>
              </execution>
              <execution>
                <id>add-volcano-test-sources</id>
                <phase>generate-test-sources</phase>
                <goals>
                  <goal>add-test-source</goal>
                </goals>
                <configuration>
                  <sources>
                    <source>volcano/src/test/scala</source>
                  </sources>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>

resource-managers/kubernetes/integration-tests/pom.xml

      <build>
        <plugins>
          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>build-helper-maven-plugin</artifactId>
            <executions>
              <execution>
                <id>add-volcano-test-sources</id>
                <phase>generate-test-sources</phase>
                <goals>
                  <goal>add-test-source</goal>
                </goals>
                <configuration>
                  <sources>
                    <source>volcano/src/test/scala</source>
                  </sources>
                </configuration>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>

Removed the management configuration for volcano-related source/test code in SPARK-36061 | https://github.com/apache/spark/pull/35422.

Since Spark uses the sbt-pom-reader plugin in its sbt configuration, the behavior of the build-helper-maven-plugin will also propagate to the sbt build process. Therefore, no additional configuration is required in SparkBuild.scala after this pr.
Why are the changes needed?
The previous configuration way was not very friendly to IntelliJ developers: when debugging code in IntelliJ, regardless of whether they were needed or not, the volcano profile had to be activated; otherwise compilation errors would occur when running tests that depended on the kubernetes module's source code, for example org.apache.spark.shuffle.ShuffleChecksumUtilsSuite :

Does this PR introduce any user-facing change?
No
How was this patch tested?

Pass GitHub Actions

https://github.com/LuciferYang/spark/actions/runs/10714343021/job/29707907464

https://github.com/LuciferYang/spark/actions/runs/10714343021/job/29707906573

It can be seen that the test cases VolcanoFeatureStepSuite  and VolcanoSuite have been successfully executed.

Manual Testing Using sbt

Run build/sbt clean "kubernetes/testOnly *VolcanoFeatureStepSuite" -Pkubernetes, and without -Pvolcano, no tests will be executed:

[info] Passed: Total 0, Failed 0, Errors 0, Passed 0
[info] No tests to run for kubernetes / Test / testOnly

Run build/sbt clean "kubernetes/testOnly *VolcanoFeatureStepSuite" -Pkubernetes -Pvolcano, and with -Pvolcano, VolcanoFeatureStepSuite will pass the tests:

[info] VolcanoFeatureStepSuite:
[info] - SPARK-36061: Driver Pod with Volcano PodGroup (74 milliseconds)
[info] - SPARK-36061: Executor Pod with Volcano PodGroup (8 milliseconds)
[info] - SPARK-38455: Support driver podgroup template (224 milliseconds)
[info] - SPARK-38503: return empty for executor pre resource (1 millisecond)
[info] Run completed in 1 second, 268 milliseconds.
[info] Total number of tests run: 4
[info] Suites: completed 1, aborted 0
[info] Tests: succeeded 4, failed 0, canceled 0, ignored 0, pending 0
[info] All tests passed.

run build/sbt clean  "kubernetes/package" -Pkubernetes -Pvolcano, and with -Pvolcano, confirm that spark-kubernetes_2.13-4.0.0-SNAPSHOT.jar contains VolcanoFeatureStep.class

run build/sbt clean  "kubernetes/package" -Pkubernetes, and without -Pvolcano, confirm that spark-kubernetes_2.13-4.0.0-SNAPSHOT.jar not contains VolcanoFeatureStep.class

Manual Testing Using Maven

Run build/mvn clean test -pl resource-managers/kubernetes/core -am -Dtest=none -DwildcardSuites=org.apache.spark.deploy.k8s.features.VolcanoFeatureStepSuite -Pkubernetes, and without -Pvolcano, no tests will be executed:

Discovery starting.
Discovery completed in 80 milliseconds.
Run starting. Expected test count is: 0
DiscoverySuite:
Run completed in 99 milliseconds.
Total number of tests run: 0
Suites: completed 1, aborted 0
Tests: succeeded 0, failed 0, canceled 0, ignored 0, pending 0
No tests were executed.

Run build/mvn clean test -pl resource-managers/kubernetes/core -am -Dtest=none -DwildcardSuites=org.apache.spark.deploy.k8s.features.VolcanoFeatureStepSuite -Pkubernetes -Pvolcano, and with -Pvolcano, VolcanoFeatureStepSuite will pass the tests:

Discovery starting.
Discovery completed in 263 milliseconds.
Run starting. Expected test count is: 4
VolcanoFeatureStepSuite:
- SPARK-36061: Driver Pod with Volcano PodGroup
- SPARK-36061: Executor Pod with Volcano PodGroup
- SPARK-38455: Support driver podgroup template
- SPARK-38503: return empty for executor pre resource
Run completed in 624 milliseconds.
Total number of tests run: 4
Suites: completed 2, aborted 0
Tests: succeeded 4, failed 0, canceled 0, ignored 0, pending 0
All tests passed.

run build/mvn clean package -pl resource-managers/kubernetes/core -am -DskipTests -Pkubernetes -Pvolcano and with -Pvolcano, confirm that spark-kubernetes_2.13-4.0.0-SNAPSHOT.jar contains VolcanoFeatureStep.class

run build/mvn clean package -pl resource-managers/kubernetes/core -am -DskipTests -Pkubernetes and without -Pvolcano, confirm that spark-kubernetes_2.13-4.0.0-SNAPSHOT.jar not contains VolcanoFeatureStep.class

Testing in IntelliJ (both imported as a Maven project and as an sbt project):

By default, do not activate volcano, and confirm that volcano-related code is not recognized as source/test code, and does not affect the compilation and testing of other code.
Manually activate volcano, and confirm that volcano-related code is recognized as source/test code, and can be compiled and tested normally.

Similar tests were conducted on kubernetes-integration-tests module to confirm the validity of the volcano profile.

Was this patch authored or co-authored using generative AI tooling?
No

Test first

+1, LGTM (Pending CIs). Thank you, @LuciferYang .

CI Passed, looks ok

cc @Yikun

Merged to master. Thank you, @LuciferYang and all!

Thanks @dongjoon-hyun ~

thanks for fixing this, a small suggestion about the folder layout.
instead of
<module>/src/main/scala
<module>/volcano/src/main/scala

how about
<module>/src/main/scala
<module>/src/main/volcano

the former makes volcano like a sub-module but it is not, the latter is also commonly used in the following situations
<module>/src/main/antlr
<module>/src/main/thrift
<module>/src/main/scala
<module>/src/main/scala-2.12
<module>/src/main/scala-2.13

Thank you for your suggestion. The current directory structure is based on the structure of the compatibility dir under the hive module.

<module>/src/main/scala
<module>/src/main/volcano

For the proposed design mentioned above, should all scala packages and files be placed under the src/main/volcano? And how should we organize the Java code if there will be Java files under the volcano directory in the future?


Update navigation component to use core.navigation extension

As discussed with @florkbr during scrum, the console. extensions are being handled on HAC Core for backward compatibility for OpenShift Console based plugins. There will need to be more discussion before we can pull this out.


Not supporting in-toto DSS payloadType in verify-attestation

Description
I've created an in-toto attestation and uploaded it to a image registry. When I tried to use cosign verify-attestation --policy my.cue ... the policy written in CUE was not asserted. When debugging it seems to have been ignored because of the payloadType check[1] against known policies, and application/vnd.in-toto+json not being defined/handled there.
As far as I understand the application/vnd.in-toto+json should be the correct DSSE payload type for the in-toto attestation and this should be allowed to assert against a supplied policy.
This is the image reference of the image and attestation:
$ docker pull zregvart/blank:latest # image
$ docker pull zregvart/blank:sha256-76addd9802ebcdb49bd3beac67d1b6c4ff2514bf867bb02f2b3605f633ba7f3b.att # attestation

Given this CUE policy:
predicate: passed: false

Verify attestation should fail, but it doesn't
$ cosign verify-attestation docker.io/zregvart/blank:latest \
  --key cosign.pub \
  --policy policy-test.cue
Verification for docker.io/zregvart/blank:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key
{"payloadType":"application/vnd.in-toto+json","payload":"eyJfdHlwZSI6Imh0dHBzOi8vaW4tdG90by5pby9TdGF0ZW1lbnQvdjAuMSIsInByZWRpY2F0ZVR5cGUiOiJjb3NpZ24uc2lnc3RvcmUuZGV2L2F0dGVzdGF0aW9uL3YxIiwic3ViamVjdCI6W3sibmFtZSI6ImluZGV4LmRvY2tlci5pby96cmVndmFydC9ibGFuayIsImRpZ2VzdCI6eyJzaGEyNTYiOiI3NmFkZGQ5ODAyZWJjZGI0OWJkM2JlYWM2N2QxYjZjNGZmMjUxNGJmODY3YmIwMmYyYjM2MDVmNjMzYmE3ZjNiIn19XSwicHJlZGljYXRlIjp7IkRhdGEiOiJ7XG4gIFwiX3R5cGVcIjogXCJodHRwczovL2luLXRvdG8uaW8vU3RhdGVtZW50L3YwLjFcIixcbiAgXCJwcmVkaWNhdGVUeXBlXCI6IFwiaHR0cHM6Ly9leGFtcGxlLmNvbS9UZXN0UmVzdWx0L3YxXCIsXG4gIFwic3ViamVjdFwiOiBbXG4gICAge1xuICAgICAgXCJuYW1lXCI6IFwiZG9ja2VyLmlvL3pyZWd2YXJ0L2JsYW5rXCIsXG4gICAgICBcImRpZ2VzdFwiOiB7XG4gICAgICAgIFwic2hhMjU2XCI6IFwiNzZhZGRkOTgwMmViY2RiNDliZDNiZWFjNjdkMWI2YzRmZjI1MTRiZjg2N2JiMDJmMmIzNjA1ZjYzM2JhN2YzYlwiXG4gICAgICB9XG4gICAgfVxuICBdLFxuICBcInByZWRpY2F0ZVwiOiB7XG4gICAgXCJwYXNzZWRcIjogdHJ1ZVxuICB9XG59XG4iLCJUaW1lc3RhbXAiOiIyMDIyLTAzLTI5VDEyOjA0OjA1WiJ9fQ==","signatures":[{"keyid":"","sig":"MEUCIQDIJIRqkvxWyZWczeFwfBYRh2PffJHVQmq+IRszfKqo4QIgLRRSWZ9zghJ6l45OMcdqYYt41snTwe2eBGKmxoCLvl8="}]}

The attestation was created using cosign:
$ cosign attest --key cosign.key --predicate predicate.json docker.io/zregvart/blank:latest

[1] https://github.com/sigstore/cosign/blob/ba50ee05c87701f532c63ec6d0fd0d7f3c03d34d/cmd/cosign/cli/verify/verify_attestation.go#L204

zomg :) I just hit this myself and went to create an issue and found this :)

Looks like there's a few folks that have been hitting this issue, and I personally don't have enough confidence / knowledge on what all kinds of other formats might break here, so in addition to removing the sanity check that does not seem to me to work, I also started sketching what e2e tests may look like (lots of refactorings, etc. clearly needed to keep on adding, but hopefully a start to see where I was thinking this may go, and then should be able to run e2e tests locally as well) so that we can keep adding tests here to validate the payload formats as well as predicate types, etc.
https://github.com/sigstore/cosign/pull/1685
Also would be nice to get some of the rego tests fixed here into e2e tests:
https://github.com/sigstore/cosign/pull/1672
I personally kind of like having these kinds tests that use cosign to both create / verify the attestation so we get nice round-trip tests.
Thoughts?
You can seen an example passing run here (includes one passing cue policy and one failing):
https://github.com/sigstore/cosign/runs/5747763172?check_suite_focus=true

Thoughts?

Very much so, test-first approach should be the way to go here. I think #1680 is a stronger candidate to fix this than what I patched together to make it work for my use case I'll close #1680 in favor of #1685.

@vaikas looks like you have a clear idea of what needs to be done, my only concern is that some of it seems orthogonal to this issue (e.g. the use of Mage), though I do see how that would make the code easier to grok and adding/refactoring tests always gets a big +1 from me.


Training the default perceptron tagger with bigger corpus

The default pickle for the PerceptronTagger is nice but it's a little too small for realistic usage:
>>> from nltk import PerceptronTagger
>>> len(PerceptronTagger(load=True).tagdict)
1549

Would it be possible to retrain a model on something like the full Penn TreeBank or BNC? Is the model then releasable on NLTK?

Yes, a trained model is not a derived work, so long as the original data cannot be reconstructed from it.

@syllog1sm Is there a reason for the high freq_thresh = 20 at https://github.com/nltk/nltk/blob/develop/nltk/tag/perceptron.py#L268 ?

I tried to set the tag dictionary hyper-parameters such that impact on accuracy is really minimal. I don't remember how much I tested this across domains. The POS tagger blog post did include a cross-domain evaluation at the end, but I think I considered this a test set and only did the experiment after I'd finalised the model.
I think you should be quite careful about setting the tag dictionary thresholds more aggressively. It's easy to make the model very brittle to domain changes with this mechanism. Using the tag dictionary for rarer words types also doesn't help much for efficiency. You're only extending the tag dictionary to a few % of tokens.


Assertion snippets

Assertions: https://github.com/sindresorhus/ava#assertions
Docs: https://atom.io/docs/latest/using-atom-snippets
I'm thinking the prefix should be t<name>, so tis, tsame, etc.

Could be easily adapted from the Sublime plugin if https://github.com/sindresorhus/sublime-ava/issues/1 is closed before this one.

// @sotojuan In case this is something you'd be interested in doing ;) No worries if not.

I'll definitely give it a shot, though I am busy these few days (but definitely by the end of the week). Thanks for the mention!

No rush at all :)

https://github.com/SamVerschueren/vscode-ava/pull/2
Feedback more then welcome!

I'm not sure what the best practices for snippets are, but I personally like really short ones. For example, for t.notSame I'd do tns. That said, I could see the argument for tnotsame. What about pass or fail? Again, for me it's quicker to do tp or tf but that may be too short (?).

Not sure for Atom and Sublime, but in VS Code, when typing tp, it shows an auto-complete box with the first match selected. And what about t.false. That's tf as well :).

https://github.com/sindresorhus/atom-ava/commit/bd1ce093049f67bf7cb86587a556a21bf54142d5


feat: Expose the actual service on FargateService

Adds a public property fargateService to the FargateService-class, akin to cluster in Cluster.
We need this in order to access the service name for creating service-related alarms, but it may be useful to have access to other attributes of the service for other alarms later.
There is, however, significant overlap between the exposed properties; e.g. securityGroup and taskDefinition are properties of fargateService, but are exposed individually. If you prefer to just expose the service name as a string-property for now, and potentially more properties later, that's fine, but I think exposing the service itself should be good enough.

Good stuff! Yeah, we do have access to it from the outside; this change mainly helps when composing with the FargateService-class, or when it's passed as a parameter 👍🏻

:tada: This PR is included in version 2.18.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


use beta-asset.transparencylog.net

With the rename in #5, API update in #6, this tool will need to use a new API endpoint at beta-asset.transparencylog.net as well. We will keep the beta API URL for sometime as we focus on getting users.

Done.


[UI] - Perfomance Profile Certificate label wrongly updated

Current Behavior

When editing a profile which already has a certificate, when you upload a new cert, the name field is not updated, instead label is updated.
Desired Behavior

When editing a profile which already has a certificate, when you upload a new cert, the name field should be updated.
To reproduce, navigate to https://playground.meshery.io/performance/profiles, then click on a card which already has a certificate uploaded.
Screenshots/Logs

Environment

Browser: Chrome Safari Firefox
Host OS: Mac Linux Windows
Meshery Server Version: stable-v
Meshery Client Version: stable-v
Platform: Docker Kubernetes

Contributor Guides and Handbook

🎨 Wireframes and designs for Meshery UI in Figma (open invite)
🖥 Contributing to Meshery UI
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

please assign me

Sure. Go ahead @EraKin575

@UsmanDev09  what changes should I make in the label?

Label should be Upload SSL Certificate eg. .crt file

@EraKin575 i made here a quick fix since you already assigned to other issues


Custom mat-datepicker header in ngxformly

@aitboudad
I am using mat-datepicker with custom header. Where I want to use (click) method events on next and previous button click. So that I want to get which is current month in the view when I click next and previous navigation. So how can I get that method response in json as a custom method in templateOptions:{}.
https://github.com/ngx-formly/ngx-formly/issues/2127#issuecomment-826261079

it should be added in V6 instead, since V5 supports Material >=v7 which doesn't that feature.
So I suggest creating a custom type that overrides the existing datepicker type until its v6 is released.
https://github.com/ngx-formly/ngx-formly/blob/v5/src/material/datepicker/src/datepicker.type.ts

@aitboudad
I have follow your contributions in Angular Formly and I thank you for upgrading a tool I use.
There is an error where you call: (MatInput, { static: true })
It would be a pleasure to contact you.

@josem234 sure!


[Addition]:

Hotspot b58 Addresses
11XmXDvGogw5npthaC6eNjUe1NpBWYEaEVu2i9K3qigBSjMm5C1
112n3oKX3hTUP9dNbWVzJ4ptFHVJsQpJDNnyoPa9pXshkBbqLGbR
Discord Handle
No response
Reason(s)
Our community has found a cheater or gaming scheme that has over than +100 HS always near to other hotspots and imposible locations, +2500mts, this person is installing HS like every day in every ocupied hexagons.
Address owner
136VeVFCCXNTupsHywygSf2JTkC1NA3FBWKRWpk1k7kdZT4CSgi


Unrecognised format with Nabu Casa

System Health details
System Information

version
core-2023.9.2

installation_type
Unknown

dev
false

hassio
false

docker
false

user
root

virtualenv
false

python_version
3.11.5

os_name
Linux

os_version
5.10.0-23-amd64

arch
x86_64

timezone
Europe/Paris

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
4993

Installed Version
1.33.0

Stage
running

Available Repositories
1299

Downloaded Repositories
35

Home Assistant Cloud

logged_in
true

subscription_expiration
27 October 2023 at 02:00

relayer_connected
true

relayer_region
eu-central-1

remote_enabled
true

remote_connected
true

alexa_enabled
true

google_enabled
true

remote_server
eu-central-1-14.ui.nabu.casa

certificate_status
ready

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Dashboards

dashboards
4

resources
21

views
14

mode
storage

Recorder

oldest_recorder_run
26 September 2023 at 06:40

current_recorder_run
26 September 2023 at 20:47

estimated_db_size
611.00 MiB

database_engine
mysql

database_version
11.1.2

Checklist

[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of currently previous issues..

Describe the issue
I installed this plugin via HACS and cannot get the chime to work, the debug logs looks like there is incompatibility with the file format and that the speech is not returned from Nabu Casa causing a 404. I am running HA in Kubernetes (i.e. docker container) and using tts from Nabu Casa, which works.
Please see debug log for details
Reproduction steps
alias: Apartment Doorbell Ring
description: ""
trigger:
  - platform: device
    domain: mqtt
    device_id: 2f2b67f724a6bdd6c301aa1c95e57b3e
    type: action
    subtype: pressed
    discovery_id: 0x5c0272fffee7c4c7 action_pressed
condition: []
action:
  - service: chime_tts.say
    data:
      end_chime_path: custom_components/chime_tts/mp3s/chirp.mp3
      delay: 450
      final_delay: 0
      tts_playback_speed: 100
      volume_level: 0.5
      message: Theres someone at the door
      tts_platform: cloud
      chime_path: custom_components/chime_tts/mp3s/bells_2.mp3
    target:
      entity_id: media_player.homepod_office
mode: single

Debug logs
2023-09-27 08:04:41.974 INFO (MainThread) [homeassistant.components.automation.apartment_doorbell_ring] Apartment Doorbell Ring: Executing step call service
2023-09-27 08:04:44.203 ERROR (MainThread) [root] Failed to parse metadata
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/pyatv/protocols/raop/audio_source.py", line 263, in get_buffered_io_metadata
    return await get_metadata(buffer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyatv/support/metadata.py", line 25, in get_metadata
    in_file = await loop.run_in_executor(None, _open_file, file)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/pyatv/support/metadata.py", line 15, in _open_file
    in_file = MediaFile(file)
              ^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/mediafile.py", line 165, in wrapper
    return mutagen_call('loadfile', '', f, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/mediafile.py", line 137, in mutagen_call
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/mutagen/_util.py", line 155, in wrapper
    return func(self, h, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/mediafile.py", line 1586, in __init__
    raise FileTypeError(self.filename)
mediafile.FileTypeError: 'https://ogift7s3cbaedvngj0m5til283tegh8j.ui.nabu.casa/media/local/sounds/temp/chime_tts/jw5dmpx0.mp3?authSig=<REDACTE>?': not in a recognized format
2023-09-27 08:04:44.213 WARNING (MainThread) [custom_components.chime_tts] An unexpected error occurred: Got status 404 with message: Not Found

Diagnostics dump
No response

Hi @nlindblo,
Sorry to hear you're having an issue with the TTS audio. It would be helpful if you could turn on debug logging for the integration so that I can get a clearer idea of what's going on:

Turn on debug logging:

service: logger.set_level
data:
  custom_components.chime_tts: debug

Call the service chime_tts.say again.

Check your log messages in Home Assistant:

https://{YOUR_HOME_ASSISTANT_ADDRESS}:8123/config/logs?filter=chime_tts

and click LOAD FULL LOGS

Here you go
2023-09-27 09:14:52.473 DEBUG (MainThread) [custom_components.chime_tts] Executing queued job #0
2023-09-27 09:14:52.473 DEBUG (MainThread) [custom_components.chime_tts] ----- Chime TTS Say Called -----
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * entity_ids = ['media_player.homepod_office_room']
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * hass = <homeassistant.core.HomeAssistant object at 0x7f8c31e7a850>
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * chime_path = custom_components/chime_tts/mp3s/bells_2.mp3
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * end_chime_path = custom_components/chime_tts/mp3s/chirp.mp3
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * delay = 450.0
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * message = Theres someone at the door
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * tts_platform = cloud
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * tts_playback_speed = 100.0
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * volume_level = 0.5
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * join_players = False
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * cache = False
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] * announce = False
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] ------
2023-09-27 09:14:52.474 DEBUG (MainThread) [custom_components.chime_tts] async_get_playback_audio_path
2023-09-27 09:14:52.475 DEBUG (MainThread) [custom_components.chime_tts] get_audio_from_path("custom_components/chime_tts/mp3s/bells_2.mp3", 0, audio)
2023-09-27 09:14:52.475 DEBUG (MainThread) [custom_components.chime_tts] - Retrieving audio from path: "custom_components/chime_tts/mp3s/bells_2.mp3"...
2023-09-27 09:14:52.568 DEBUG (MainThread) [custom_components.chime_tts] - ...audio with duration 1.279s retrieved successfully
2023-09-27 09:14:52.568 DEBUG (MainThread) [custom_components.chime_tts] async_request_tts_audio(hass, tts_platform="cloud", message="Theres someone at the door", cache="False", language="None", tld="None", gender="None", tts_playback_speed="100.0"))
2023-09-27 09:14:52.568 DEBUG (MainThread) [custom_components.chime_tts] - Generating TTS audio...
2023-09-27 09:14:53.330 DEBUG (MainThread) [custom_components.chime_tts] - ...TTS audio completed in 761.809 ms
2023-09-27 09:14:53.333 DEBUG (MainThread) [custom_components.chime_tts] get_audio_from_path("custom_components/chime_tts/mp3s/chirp.mp3", 450.0, audio)
2023-09-27 09:14:53.333 DEBUG (MainThread) [custom_components.chime_tts] - Retrieving audio from path: "custom_components/chime_tts/mp3s/chirp.mp3"...
2023-09-27 09:14:53.408 DEBUG (MainThread) [custom_components.chime_tts] - ...audio with duration 0.395s retrieved successfully
2023-09-27 09:14:53.409 DEBUG (MainThread) [custom_components.chime_tts] - Final audio created:
2023-09-27 09:14:53.409 DEBUG (MainThread) [custom_components.chime_tts] - Duration = 5.022s
2023-09-27 09:14:53.409 DEBUG (MainThread) [custom_components.chime_tts] Creating final audio file
2023-09-27 09:14:53.409 DEBUG (MainThread) [custom_components.chime_tts] - Temp folder exists: /media/sounds/temp/chime_tts/
2023-09-27 09:14:53.409 DEBUG (MainThread) [custom_components.chime_tts] - Creating temporary mp3 file...
2023-09-27 09:14:53.409 DEBUG (MainThread) [custom_components.chime_tts] - temp_obj = <tempfile._TemporaryFileWrapper object at 0x7f8c041d76d0>
2023-09-27 09:14:53.409 DEBUG (MainThread) [custom_components.chime_tts] - Filepath = '/media/sounds/temp/chime_tts/q3tr0u21.mp3'
2023-09-27 09:14:53.506 DEBUG (MainThread) [custom_components.chime_tts] - File saved successfully
2023-09-27 09:14:53.506 DEBUG (MainThread) [custom_components.chime_tts] - audio_dict = {'audio_path': '/media/sounds/temp/chime_tts/q3tr0u21.mp3', 'audio_duration': 5.022}
2023-09-27 09:14:53.506 DEBUG (MainThread) [custom_components.chime_tts] - Setting 'media_player.homepod_office_room' volume level to 0.5
2023-09-27 09:14:53.506 DEBUG (MainThread) [custom_components.chime_tts] - async_set_volume_level("media_player.homepod_office_room", 0.5)
2023-09-27 09:14:53.506 DEBUG (MainThread) [custom_components.chime_tts] - Seting volume_level of media player "media_player.homepod_office_room" to: 0.5
2023-09-27 09:14:53.710 DEBUG (MainThread) [custom_components.chime_tts] - Volume set
2023-09-27 09:14:53.710 DEBUG (MainThread) [custom_components.chime_tts] Calling media_player.play_media service with data:
2023-09-27 09:14:53.710 DEBUG (MainThread) [custom_components.chime_tts] - media_content_type: music
2023-09-27 09:14:53.711 DEBUG (MainThread) [custom_components.chime_tts] - media_content_id: media-source://media_source/local/sounds/temp/chime_tts/q3tr0u21.mp3
2023-09-27 09:14:53.711 DEBUG (MainThread) [custom_components.chime_tts] - entity_id: ['media_player.homepod_office']
mediafile.FileTypeError: 'https://ogift7s3cbaedvngj0m5til283tegh8j.ui.nabu.casa/media/local/sounds/temp/chime_tts/q3tr0u21.mp3?authSig=<REDACTED>': not in a recognized format
2023-09-27 09:14:54.966 WARNING (MainThread) [custom_components.chime_tts] An unexpected error occurred: Got status 404 with message: Not Found
2023-09-27 09:14:54.969 DEBUG (MainThread) [custom_components.chime_tts] Waiting 5.022s for audio playback to complete...
2023-09-27 09:14:59.992 DEBUG (MainThread) [custom_components.chime_tts] Returning media_player.homepod_office_room's volume level to 0.264
2023-09-27 09:14:59.992 DEBUG (MainThread) [custom_components.chime_tts] - async_set_volume_level("media_player.homepod_office_room", 0.264)
2023-09-27 09:14:59.993 DEBUG (MainThread) [custom_components.chime_tts] - Seting volume_level of media player "media_player.homepod_office_room" to: 0.264
2023-09-27 09:15:00.059 DEBUG (MainThread) [custom_components.chime_tts] - Volume set
2023-09-27 09:15:00.059 DEBUG (MainThread) [custom_components.chime_tts] ----- Chime TTS Say Completed in 7585.525 ms -----
2023-09-27 09:15:00.059 DEBUG (MainThread) [custom_components.chime_tts] Removing current queued service call.
2023-09-27 09:15:00.059 DEBUG (MainThread) [custom_components.chime_tts] Queue emptied. Reinitializing values.

Based on your debug log messages it looks like Chime TTS successfully retrieves the audio from the 'chime' mp3 files and TTS audio, and also succeeds in generating a temp mp3 file for playback.
The issue occurs when trying to play the temp mp3 file via 'media_player.play_media`:
2023-09-27 09:14:53.710 DEBUG (MainThread) [custom_components.chime_tts] Calling media_player.play_media service with data:
2023-09-27 09:14:53.710 DEBUG (MainThread) [custom_components.chime_tts] - media_content_type: music
2023-09-27 09:14:53.711 DEBUG (MainThread) [custom_components.chime_tts] - media_content_id: media-source://media_source/local/sounds/temp/chime_tts/q3tr0u21.mp3
2023-09-27 09:14:53.711 DEBUG (MainThread) [custom_components.chime_tts] - entity_id: ['media_player.homepod_office']
mediafile.FileTypeError: 'https://ogift7s3cbaedvngj0m5til283tegh8j.ui.nabu.casa/media/local/sounds/temp/chime_tts/q3tr0u21.mp3?authSig=<REDACTED>': not in a recognized format

The media_content_id source looks correct but perhaps your Home Assistant instance doesn't have access to the media folder.
Can you please try adding the following YAML to your configurations.yaml file, restart, and try calling chime_tts.say again?
homeassistant:
  media_dirs:
    local: /media

Happy to hear it! 👍


Add support for RSA-OAEP decryption

Changes from https://github.com/mozilla-services/pkcs7/pull/48 are included with this PR. Slightly adapted to fit with how we work with crypto.Decrypter.
Changes from https://github.com/mozilla-services/pkcs7/pull/44 for decryption are included with this PR.

A few details, we should consider to maintaining this ourselves in go.step.sm/crypto

I think keeping the core pkcs7 library in a separate repository is clearer, at least for the time being, but I can see the utility of that. It could be a way forward after making this an officially maintained fork, then update the README to point to /crypto/pkcs7?
I've also though about changing some details of this package, as there's a couple of things I don't really like, such as how encryption algorithms need to be set globally before encrypting. Those would break the current API, so it might be possible to put that in a safe wrapper around this lib and put that in /crypto instead or in addition to the low level library.

I've also thought about changing some details of this package, as there's a couple of things I don't really like, such as how encryption algorithms need to be set globally before encrypting. Those would break the current API, so it might be possible to put that in a safe wrapper around this lib and put that in /crypto instead or in addition to the low level library.

Sure, we can keep the pkcs7, and if we add a wrapper into crypto we should include the PKCS#8 thing.

Ok, because this package is intended to have backward compatibility with the original package.
Things that can be added in a go.step.sm/crypto/pkcs8 wrapper:
* MGFHash support

* Proper parsing of key

* Encrypted key support

* Better API

* ...

Noted!


[dockerize]: make sure that docker secrets volume exists

make sure that /root/.docker/secrets exists and shared with the
builder container as a volume. In the past /root/.docker was shared as a volume.
The /root/.docker/secrets path is used by the upstream CI infra in order to mount the secret
into the bootstrap container pod. In the long-term we will change this location in order not to abuse
the docker configuration directory.
Signed-off-by: Igor Bezukh<EMAIL_ADDRESS>What this PR does / why we need it:
Recent runs of FOSSA and goveralls lanes have failed because of open /root/.docker/secrets/coveralls/token: no such file or directory error.
The assumption is that the directory /root/.docker wasn't created because of the conditional bind mount in the dockerize
script.
Release note:
NONE

/cc @dhiller @jean-edouard

/approve
Creating files in people's home directories is not ideal, maybe in the future we can rethink that part.
In the meantime, approving this to un-break test lanes. (sorry!)


add a few openCV image methods

Description
Add a few opencv methods

Codecov Report
Base: 72.08% // Head: 74.26% // Increases project coverage by +2.17% :tada:

Coverage data is based on head (835bd81) compared to base (bb5073f).
Patch coverage: 75.10% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2320      +/-   ##
============================================
+ Coverage     72.08%   74.26%   +2.17%
- Complexity     5126     6708    +1582
============================================
  Files           473      659     +186
  Lines         21970    29177    +7207
  Branches       2351     3016     +665
============================================
+ Hits          15838    21668    +5830
- Misses         4925     6042    +1117
- Partials       1207     1467     +260

Impacted Files
Coverage Δ

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <ø> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...main/java/ai/djl/modality/cv/output/Rectangle.java
72.41% <0.00%> (ø)

...i/djl/modality/cv/translator/BigGANTranslator.java
21.42% <0.00%> (-5.24%)
:arrow_down:

.../modality/cv/translator/ImageFeatureExtractor.java
0.00% <0.00%> (ø)

.../ai/djl/modality/cv/translator/YoloTranslator.java
27.77% <0.00%> (+18.95%)
:arrow_up:

...ain/java/ai/djl/modality/cv/util/NDImageUtils.java
67.10% <0.00%> (+7.89%)
:arrow_up:

api/src/main/java/ai/djl/modality/nlp/Decoder.java
63.63% <ø> (ø)

... and 603 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


spec: load statements may not be nested in any other statement

This is a potentially breaking language change, but I suspect
few users care. If you are one of them, please report the issue.
Fixes https://github.com/google/starlark-go/issues/275

@laurentlb


dash in table names breaks AR joins

Following code will break if there is a dash (-) in the table name and you use the AR join function.
I found this line to be the problem. It's in DB_Active_record.php in the public function join($table, $cond, $type = '')
if (preg_match('/([\w\.]+)([\W\s]+)(.+)/', $cond, $match))
The fix
if (preg_match('/([\w\.-]+)([\W\s]+)(.+)/', $cond, $match))

@CroNiX I'd recommend escaping the hyphen. I know PHP still accepts it as a match, but inside the square brackets it's supposed to indicate a range of characters (unless it's the very first character after the [ bracket, which would mean it's just a hyphen).


[Android] Fix filepicker crash issue.

This patch is to fix the filepicker crash issue on some customized ROMs.
In some ROMs, "/sdcard/Pictures" was removed, verify this directory
before create image file.
BUG=XWALK-3983

@lincsoon @axinging @fujunwei Please help to review, thanks.

About the code calling createImageFile() in showFileChooser(), I have some questions although it's old problems.

Is it necessary to call takePictureIntent.putExtra("PhotoPath", mCameraPhotoPath); if the photoFile is null
Is it okay to put mCameraPhotoPath into takePictureIntent before changing the path.
The code is bloated. If we don't change the logic, the code could be:

    try {
        File photoFile = createImageFile();
        takePictureIntent.putExtra("PhotoPath", mCameraPhotoPath);
        mCameraPhotoPath = "file:" + photoFile.getAbsolutePath();
        takePictureIntent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(photoFile));
    } catch (IOException | NullPointerException ex) {
        // Error occurred while creating the File
        Log.e(TAG, "Unable to create Image File", ex);
        takePictureIntent = null;
    }

Is it necessary to call takePictureIntent.putExtra("PhotoPath", mCameraPhotoPath); if the photoFile is null.It's no necessary.
Is it okay to put mCameraPhotoPath into takePictureIntent before changing the path.It's okay but it's better to change the path at first.
Thanks.

@lincsoon Done, Thanks.


Adding info for BEP20 token 'EuropaCoin'.

Adding info for BEP20 token 'EuropaCoin'.
PR created by TW Assets Management
Ursprünglich gepostet von @EuropaCoinFun in https://github.com/trustwallet/assets/pull/29882

Hello @Xyvern26
Thanks for reporting this
This will be review on pull request!
Use the official support to get more information reading this via support

Hello @Xyvern26 Thanks for reporting this This will be review on pull request! Use the official support to get more information regarding this via support

Hello, what is this repository responsible for ?


<EMAIL_ADDRESS>hash check failed

scoop install caffeine
Installing 'caffeine' (1.90) [64bit]
caffeine.zip (301,7 KB) [=======================================================================================================================================================================] 100%
Checking hash of caffeine.zip ... ERROR Hash check failed!
App:         extras/caffeine
URL:         https://www.zhornsoftware.co.uk/caffeine/caffeine.zip
First bytes: 50 4B 03 04 14 00 00 00
Expected:    fc0191ac02a90400c340317720c4446c19267cdc016c42451035154f8d33711b
Actual:      feeb7f7643d660c125e22e9d34b7eaa1b02c0f62d5536648eef9eac7e3800dbe

Please try again or create a new issue by using the following link and paste your console output:
https://github.com/lukesampson/scoop-extras/issues/new?title=caffeine%401.90%3A+hash+check+failed


[bug] dev copy address success, product copy failed

Link to minimal reproducible example
modal copy address failed when i deploy to server
Summary

List of related npm package versions
"@wagmi/core": "^1.4.12",
"@web3modal/wagmi": "^3.5.2",
"use-wagmi": "^0.4.9",
"viem": "^1.21.0",

Could you please update the dependencies to Wagmi v2 and Web3Modal v4 latest. This should be fixed already, you can test it here


Add GeoJSON Analyzer

Add support for GeoJSON search analyzer (Arango 3.8) plus test.
I skipped the options as I wasn't sure how to add hash map serialization, and also they are not normally tunable by end users.

Unfortunately this repository hasn't been updated for a while, if you want your MR to be released somewhere I suggest opening it for arangors_lite that I created to be able to maintain the driver for aragog


Use the right Batch creator to register stats.

gocql.NewBatch is deprecated and doesn't register the observer.

This change is

LGTM!
On Sun, 1 Apr 2018 at 08:31, Goutham Veeramachaneni <
<EMAIL_ADDRESS>wrote:

gocql.NewBatch is deprecated and doesn't register the observer.
You can view, comment on, or merge this pull request online at:
https://github.com/weaveworks/cortex/pull/782
Commit Summary

Use the right Batch creator to register stats.

File Changes

M pkg/chunk/cassandra/storage_client.go
https://github.com/weaveworks/cortex/pull/782/files#diff-0 (2)

Patch Links:

https://github.com/weaveworks/cortex/pull/782.patch
https://github.com/weaveworks/cortex/pull/782.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/cortex/pull/782, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbGhd8ThtdoiOBaeQ18MlODacL0aYZvks5tkIJHgaJpZM4TCvq0
.


Update MD file on new branch 2017-12-03_19-30-45

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


ImportError: cannot import name 'quote'

After last yarl module update, our build is brocken. I've open a issue on aiohttp.
https://github.com/KeepSafe/aiohttp/issues/1447

#4691 will take care about this.


fix(cli): add plugin-fuses to import script

[x] I have read the contribution documentation for this project.
[x] I agree to follow the code of conduct that this project follows, as appropriate.

Summarize your changes:
fixes #3509

Add @electron/plugin-fuses as development dependancy to electron-forge import
Now  start, package and make commands of electron-forge works seamlessly.

Tested locally with npm run make and seems to work.


Fix text format

This PR documents the print-prim and print-enum functions, and makes the "indent" parameter more sensible.
Previously, indent was either a number or t. If it was a number, then indent that amount. If it was t, then don't indent. Now, indent is either a number or nil (if nil, don't indent).

I'm not sure if this test failing is a bug or not. I think the test can fail as protobuf does not guarantee anything about the order of the fields, and the test asserts that the fields will be in a certain order. I'll try running this code on another computer and see if I can reproduce the failure.

Hey Ben, whats the state of this?

Hey Ben, whats the state of this?

I removed the test which could've been failing, and it's still failing on github. I'm not able to reproduce the error on the cloudtop, but will try tomorrow on another machine.

IT's feiling because it's sending skip field for #-

Changing skip-field's ecase to
(or #: #-)
I see
Original msg:
#S(CL-PROTOBUFS.TEST-PROTO:TEXT-FORMAT-TEST
:%INT-FIELD 100
:%SINT-FIELD -1
:%UINT-FIELD 1
:%FLOAT-FIELD 1.5
:%DOUBLE-FIELD 1.5d0
:%STRING-FIELD "A string"
:%STRING-FIELDS ("First" "Second")
:%EMBEDDED-COMMENT-A 0
:%EMBEDDED-COMMENT-B 0
:%EMBEDDED-COMMENT-C 0
:%EMBEDDED-COMMENT-D 0
:%EMBEDDED-COMMENT-E 0
:%EMBEDDED-COMMENT-F 0
:%EMBEDDED-COMMENT-G 0
:%ONE-LEVEL-NESTING NIL
:%ENUM-VALS (:NONE :TWENTY-ONE)
:%BYTES NIL
:%%IS-SET #*11111110000000010)
Parsed msg:
#S(CL-PROTOBUFS.TEST-PROTO:TEXT-FORMAT-TEST
:%INT-FIELD 100
:%SINT-FIELD -1
:%UINT-FIELD 1
:%FLOAT-FIELD 1.5
:%DOUBLE-FIELD 1.5d0
:%STRING-FIELD "A string"
:%STRING-FIELDS ("First" "Second")
:%EMBEDDED-COMMENT-A 0
:%EMBEDDED-COMMENT-B 0
:%EMBEDDED-COMMENT-C 0
:%EMBEDDED-COMMENT-D 0
:%EMBEDDED-COMMENT-E 0
:%EMBEDDED-COMMENT-F 0
:%EMBEDDED-COMMENT-G 0
:%ONE-LEVEL-NESTING NIL
:%ENUM-VALS (:NONE NIL)
:%BYTES NIL
:%%IS-SET #*11111110000000010)

Fix:
(defun print-enum (val enum field stream indent)
"Print enum to stream
Parameters:
VAL: The enum value.
ENUM: The enum descriptor.
FIELD: The field which contains this value.
STREAM: The stream to print to.
INDENT: Either a number or nil.
- If indent is a number, indent this print
by (+ indent 2) and write a newline at
the end.
- If indent is nil, then do not indent and
do not write a newline."
(when val
(if indent
(format stream "~&~VT~A: " (+ indent 2) (proto-name field))
(format stream "~A: " (proto-name field)))
(let* ((e (find (keywordify val)
(enum-descriptor-values enum)
:key #'enum-value-descriptor-value))
(value (and e (enum-value-descriptor-value e)))
(proto-keyword-value (substitute #_ #- (string value))))
  (format stream "~A" proto-keyword-value)
  (if indent
    (format stream "~%")
    (format stream " ")))))

Warning:
CheckLint found errors.
Lines should be under 100 columns. (LINE-TOO-LONG)
//depot/google3/third_party/lisp/cl_protobufs/text-format.lisp:114
Lines should be under 100 columns. (LINE-TOO-LONG)
//depot/google3/third_party/lisp/cl_protobufs/text-format.lisp:121


Sometimes recipient receiving multiple identical emails

Issue Summary
A summary of the issue and the environment in which it occurs. If suitable, include the steps required to reproduce the bug. Please feel free to include screenshots, screencasts, code examples.
Steps to Reproduce

This is the first step
This is the second step
Further steps, etc.

Any other information you want to share that is relevant to the issue being reported. Especially, why do you consider this to be a bug? What do you expect to happen instead?
Technical details:

sendgrid-php Version: master (latest commit: [commit number])
PHP Version: 5.4 to 7.2 (as of February 1, 2018)

Hello @shrutijathar,
Could you please provide us with some further details? Is it possible to share the code that is causing this problem?
With Best Regards,
Elmer

@thinkingserious I ran some tests and they were working fine. This issue is not replicable and I don't seem to have any problems with multiple identical emails being sent.

Close this issue as this is not a replicable bug.
I ran unit tests - https://github.com/sendgrid/sendgrid-php/tree/master/test/unit


Story 5 - Add AR instructions fragment as it should be

This happened:
first step as ar instruction
small change
initial fragment and activity for ar instructions.
next button added and functionality for the click that also can be used for the progress bar
an horisontal progress list added at the top with a button for every progress step
part list created
Changed color of the progress list
Added placeholder for chair view, no relative position. 4 images of chair stages.
moved the 3d chair to match the rest
color of previous and finished steps are green in progressbar
new colors depending on current or prev step
all fragment elements connected in harmony

I think it look good. :shipit:

@johan999 Hänvisar till ovanstående diskussion.

Sen är det lite radbyten och grejer som inte stämmer överens. Orkar vi bry oss?


feat: execute js challenges saga

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

Closes #XXXXX
Before run JS challenges we transform them by babel with a loop protect plugin. For some challenges it prevents pass the tests. For https://learn.freecodecamp.org/coding-interview-prep/project-euler/problem-10-summation-of-primes, a correct solution does not pass the tests.
This PR proposes run JS challenges without loop protect in a worker with a timeout.

@ValeraS So currently its only for the challenge you've mentioned? Problem 35 and Problem 47 would also benefit from this.

@ezioda004 All these challenges will benefit from this.


Removal of unavailable Jobs

some Job positions are filled or not available at the moment.  update the Readme.md by removing those job roles

@priynshuchouhn would you like to go ahead with the pr for the same?

yes. I am working on it. please assign me this task.

@priynshuchouhn if you have made a pr please make sure to link it to the issue, or if you are currently working on it then you can also create a draft pr for the same :D


Error from provider: Cannot read properties of undefined (reading 'map')

VS Code Version: Code spaces
OS Version:  Code spaces extension version v0.12.2
Logs:

Steps to Reproduce:

search for something and then after response try to ask again which throws the below error

``Error from provider: Cannot read properties of undefined (reading 'map')
Uninstalled it and installed it again but no luck.
Below are the only logs accessible to me
2024-03-12 20:50:35.706 [info] [auth] Logged in as hashik4d
2024-03-12 20:50:37.045 [info] [chat] copilot token chat_enabled: true
2024-03-12 20:50:37.045 [info] [githubTitleAndDescriptionProvider] Initializing GitHub PR title and description provider provider.
2024-03-12 20:50:37.045 [info] [auth] Got Copilot token for hashik4d
2024-03-12 20:50:37.612 [info] [auth] Logged in as hashik4d
2024-03-12 20:50:37.697 [info] [chat] copilot token chat_enabled: true
2024-03-12 20:50:37.697 [info] [auth] Got Copilot token for hashik4d
2024-03-12 20:50:37.941 [info] [githubTitleAndDescriptionProvider] Successfully activated the GitHub.vscode-pull-request-github extension.
2024-03-12 20:50:37.941 [info] [githubTitleAndDescriptionProvider] Successfully registered GitHub PR title and description provider.

Hi thank you for posting this issue. Could you include the stack trace you see when you experience the issue, inside of the developer tools. You can open the developer tools using the command Developer: Toggle Developer Tools.

Hi @hashik4d, to do this, you can click cmd + p if on mac os (ctrl + p if on windows) and type > then type Developer: Toggle Developer Tools. The dev tools should show up in VS Code. Then you can try to reproduce the issue you posted about, and there should be an error message in red. You can then paste here the error message.

I see that's curious, note taken.
This issue will be closed.