text:
Adjust GTOID nullability

I don’t see any way that SHA could be nil without having bigger problems like malloc failing. So I think we’re safe to claim it’s not nullable.
/cc @phatblat

:+1: These seem good and right to me.

Cool beans. I was a bit cautious in applying those nullable attributes.

I was a bit cautious in applying those nullable attributes.

:+1: I think that was the right route. We can tighten them up as needed.

authors: joshaber mdiep phatblat


text:
Is the ecdsa algorithm related operation one of the bottle neck of the performance?

Hi team,
I am from a hardware company (accelor.io) and one of our focus is accelerating blockchain via various means, including using FPGA doing ecdsa sign/verify for the blockchain.
I would appreciate if  anyone could share a profiling result to illustrate the percentage of ecdsa related computation in the whole performance profiling result.
By the way, providing a TEE(trusted execution environment, which is expected to be more secure than Intel SGX) for blockchain is also one of our focus.
Best Regards,
Xiang
accelor.io

I did some benchmarking of ECDSA (as implemented here https://github.com/bitcoin-core/secp256k1) a few years back and was able to achieve around 2 million keys per core per minute. I wouldn't think its a bottleneck.
However i've just had a (quick) look through the codebase and it doesnt appear to be used here?

hey, closing as this hasn't received much response.

source: gharchive/issue

authors: GingerMoon barrystyle mimoo

repo: libra/libra

license_type: permissive

license_source: github-api


text:
[storage] Downgrade GRPC logs to trace

Summary
In our current setup, we log at debug level and the storage GRPC log messages are extremely noisy. We have noticed perf issues before when we were logging too much. Fewer logs also helps debugging.

:hourglass: Testing commit 0c3ec9baee9914fac5f8cfff0c9d534b1862a0a4 with merge 67b2c898c276c2ce4a48e49d9efab376bbc048f7...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: lightmark
Pushing 67b2c898c276c2ce4a48e49d9efab376bbc048f7 to master...

source: gharchive/pull-request

authors: ankushagarwal bors-libra


text:
[move cli] Allow republishing by default

By default, 'check' and 'publish' now overwrite existing modules in storage
This can be turned off with --no-republish

Motivation

The hope is that this will provide a more intuitive experience, as by default you do not get errors about duplicate module definitions

Test Plan

One big test, should probably have more but I'm trying to get this in quickly

Related PRs
#6763

/land

:broken_heart: Test Failed - commit-workflow

/land

:broken_heart: Test Failed - commit-workflow

/land

:broken_heart: Test Failed - commit-workflow

/land

authors: bors-libra tnowacki


text:
Support for Zelotes C-12

I'd like to have support for the Zelotes C-12 gaming mouse. It has 9 customizable extra buttons on the side, a "+" and a "-" button to switch between 4 different DPI modes (customizable too I think) and highly customizable LEDs (RGB colors, brightness, blinking). Device drivers are available online but only for Windows. I could dump USB data if needed.
Here's the info from sudo lsusb -vd 12c9:1028:

Bus 003 Device 003: ID 12c9:1028 SOAI USB Gaming Mouse
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x12c9
  idProduct          0x1028
  bcdDevice            2.10
  iManufacturer           1 SOAI
  iProduct                2 USB Gaming Mouse
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x005b
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      71
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      1 Keyboard
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     117
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      32
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               4
Device Status:     0x0000
  (Bus Powered)

Since this mouse would require writing a new driver, let's close this until someone volunteers to write one. :)

Here's data from a USB sniffing tool: https://gist.github.com/darealshinji/57ec8b50dfa8faf41e170a86469358cf
You can especially see the 64 bytes data packet to change the color and brightness of the lights. But that's all I could figure out. Turning this into an actual driver is beyond my capabilities. Maybe someone with more experience could help me?

repo: libratbag/libratbag

license: MIT


text:
IMG_Load segfault after SDL_FreeSurface

SDL ver. 2.26.5, SDL_image ver. 2.6.3. Both built by me using CMake.
Only crashes with LLDB attached, but this is preventing me getting to a different bug in my own code.
(lldb) ru
Process 12792 launched: '<snip>\a.exe' (x86_64)
Process 12792 stopped
* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x7ff8f02a8e55: Access violation reading location 0xffffffffffffffff
    frame #0: 0x00007ff8f02a8e55 SDL2.dll`SDL_DYNAPI_entry + 1202181
SDL2.dll`SDL_DYNAPI_entry:
->  0x7ff8f02a8e55 <+1202181>: cmp    eax, dword ptr [rcx]
    0x7ff8f02a8e57 <+1202183>: jne    0x7ff8f02a8e86            ; <+1202230>
    0x7ff8f02a8e5d <+1202189>: mov    rax, qword ptr [rsp + 0x20]
    0x7ff8f02a8e62 <+1202194>: mov    ecx, dword ptr [rax + 0x2c]
(lldb) bt
* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x7ff8f02a8e55: Access violation reading location 0xffffffffffffffff
  * frame #0: 0x00007ff8f02a8e55 SDL2.dll`SDL_DYNAPI_entry + 1202181
    frame #1: 0x00007ff8f02b0633 SDL2.dll`SDL_DYNAPI_entry + 1232867
    frame #2: 0x00007ff8f02b102a SDL2.dll`SDL_DYNAPI_entry + 1235418
    frame #3: 0x00007ff8f01809ff SDL2.dll`SDL_CreateRGBSurfaceWithFormatFrom + 79
    frame #4: 0x00007ff8f4b1d0d9 SDL2_imaged.dll`IMG_LoadSTB_RW(src=0x0000024f5f837440) at IMG_stb.c:117:19
    frame #5: 0x00007ff8f4b15063 SDL2_imaged.dll`IMG_LoadPNG_RW(src=0x0000024f5f837440) at IMG_png.c:509:12
    frame #6: 0x00007ff8f4b11838 SDL2_imaged.dll`IMG_LoadTyped_RW(src=0x0000024f5f837440, freesrc=1, type="png") at IMG.c:289:17
    frame #7: 0x00007ff8f4b116db SDL2_imaged.dll`IMG_Load(file="Q:\\IMG\\759483405020430377_1048984769142214736.png") at IMG.c:205:12
    frame #8: 0x00007ff6f5ec2892 a.exe`main((null)=1, (null)=0x0000024f549a8aa0) at main.cc:35:5
    frame #9: 0x00007ff6f5ec13d7 a.exe`__tmainCRTStartup at crtexe.c:321:15
    frame #10: 0x00007ff6f5ec1436 a.exe`mainCRTStartup at crtexe.c:202:9
    frame #11: 0x00007ff96fb67614 kernel32.dll`BaseThreadInitThunk + 20
    frame #12: 0x00007ff96fca26a1 ntdll.dll`RtlUserThreadStart + 33
(lldb) ki
Process 12792 exited with status = 0 (0x00000000)
(lldb) (lldb) q

Attached is minimal code to trigger it and my build "script", look for "<snip>" in the script
main.cc.txt
build.bat.txt

I can't reproduce this with Visual Studio 2019, using SDL 2.26.5 and SDL_image 2.6.3 (self-built from git), and lldb version 9.0.0 (supplied by clion). I don't have clang installed.
Your lldb session shows that it is using SDL2.dll, whereas build.bat says you link to libSDL2.dll.a.
Please verify you don't have a stray SDL2.dll in any folder in your %PATH% environment variable,
and copy freshly built SDL2d.dll/SDL2_imaged.dll to directory where you build your application.
Using the lldb command image list, you can see what modules have been loaded + their path.
I used the source below.
Perhaps you can modify the IMG_Load/SDL_FreeSurface sequence in a way that fails for you?
#define SDL_MAIN_HANDLED
#include "SDL.h"
#include "SDL_image.h"

static const char* pngPath = "image.png";

static SDL_Surface *img_load_and_check(const char *path) {
    SDL_Surface *surface = IMG_Load(path);
    if (surface == NULL) {
        SDL_Log("IMG_Load failed: %s", IMG_GetError());
    }
    return surface;
}

int main(int argc, char* argv[]) {
	if (SDL_Init(SDL_INIT_VIDEO) < 0) {
        SDL_Log("SDL_Init() failed: %s", SDL_GetError());
        return 1;
    }

	if (IMG_Init(IMG_INIT_PNG) != IMG_INIT_PNG) {
        SDL_Log("IMG_Init() failed: %s", SDL_GetError());
        return 1;
    }

	SDL_Window *window = SDL_CreateWindow("title", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 640, 480, 0);
	SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC);

    SDL_Surface *surface = NULL;
    SDL_Surface *surface2 = NULL;
    SDL_Surface *surface3 = NULL;

    SDL_Texture *texture = NULL;

#if 1
    surface = img_load_and_check(pngPath);
    surface2 = img_load_and_check(pngPath);
    surface3 = img_load_and_check(pngPath);
    SDL_FreeSurface(surface);
    surface = surface2; surface2 = NULL;
#else
    surface = img_load_and_check(pngPath);
    SDL_FreeSurface(surface);
    surface = img_load_and_check(pngPath);
    surface2 = img_load_and_check(pngPath);
    surface3 = img_load_and_check(pngPath);
#endif

    texture = SDL_CreateTextureFromSurface(renderer, surface);

    SDL_FreeSurface(surface);
    SDL_FreeSurface(surface2);
    SDL_FreeSurface(surface3);

    if (texture == NULL) {
        SDL_Log("SDL_CreateTextureFromSurface failed: %s", SDL_GetError());
    }

	int exit = 0;

	while (1) {
		for (SDL_Event e; SDL_PollEvent(&e); ) {
			if (e.type == SDL_QUIT || (e.type == SDL_KEYDOWN && e.key.keysym.scancode == SDL_SCANCODE_ESCAPE)) {
				exit = 1;
				break;
			}
		}

		if (exit) {
            break;
        }

		SDL_SetRenderDrawColor(renderer, 0x3b, 0x3b, 0x3b, 0xff);
		SDL_RenderClear(renderer);
        if (texture) {
            SDL_RenderCopy(renderer, texture, NULL, NULL);
        }
		SDL_RenderPresent(renderer);
	}

    SDL_DestroyTexture(texture);

    SDL_DestroyRenderer(renderer);
    SDL_DestroyWindow(window);

	IMG_Quit();
	SDL_Quit();
}

authors: FullPtrDereference madebr

license: Zlib


text:
testimage svg failures after commit 9f5859e

Commit 9f5859e merged rounding changes from mainstream: memononen/nanosvg@b30716c and its follow-up memononen/nanosvg@cb0ae54 (memononen/nanosvg#247)
That resulted in testimage failures. The output files zipped + attached: outfiles-bmp.zip
The results seems visually same to me, but please have a look and advise
(github doesn't seem to allow bmp attachments, therefore they are converted
to png with 0-compression using gimp.) These results are from a run on an
i686-linux setup.
CC: @smcv, @slouken
ERROR: 10/25/23 13:59:33: Comparison of pixels with allowable error of 0 failed 125 times.
ERROR: 10/25/23 13:59:33: First detected occurrence at position 30,4 with a squared RGB-difference of 3.
ERROR: 10/25/23 13:59:33: Surfaces from failed comparison saved as 'CompareSurfaces0050_TestOutput.bmp' and 'CompareSurfaces0050_Reference.bmp'
ERROR: 10/25/23 13:59:33: Assert 'Surface differed from reference by at most 0 in 125 pixels': Failed
INFO: /tmp/SDL_image/test/svg-class.svg:
[...]

ERROR: 10/25/23 13:59:33: Comparison of pixels with allowable error of 0 failed 125 times.
ERROR: 10/25/23 13:59:33: First detected occurrence at position 30,4 with a squared RGB-difference of 3.
ERROR: 10/25/23 13:59:33: Surfaces from failed comparison saved as 'CompareSurfaces0051_TestOutput.bmp' and 'CompareSurfaces0051_Reference.bmp'
ERROR: 10/25/23 13:59:33: Assert 'Surface differed from reference by at most 0 in 125 pixels': Failed
INFO: /tmp/SDL_image/test/svg-class.svg:
[...]

ERROR: 10/25/23 13:59:33: Comparison of pixels with allowable error of 0 failed 125 times.
ERROR: 10/25/23 13:59:33: First detected occurrence at position 30,4 with a squared RGB-difference of 3.
ERROR: 10/25/23 13:59:33: Surfaces from failed comparison saved as 'CompareSurfaces0052_TestOutput.bmp' and 'CompareSurfaces0052_Reference.bmp'
ERROR: 10/25/23 13:59:33: Assert 'Surface differed from reference by at most 0 in 125 pixels': Failed
INFO: /tmp/SDL_image/test/svg-class.svg:
[...]

ERROR: 10/25/23 13:59:33: Comparison of pixels with allowable error of 0 failed 125 times.
ERROR: 10/25/23 13:59:33: First detected occurrence at position 30,4 with a squared RGB-difference of 3.
ERROR: 10/25/23 13:59:33: Surfaces from failed comparison saved as 'CompareSurfaces0053_TestOutput.bmp' and 'CompareSurfaces0053_Reference.bmp'
ERROR: 10/25/23 13:59:33: Assert 'Surface differed from reference by at most 0 in 125 pixels': Failed
INFO: /tmp/SDL_image/test/svg-class.svg:
[...]

I think that's close enough, and it would make sense to consider this to be an intentional nanosvg change and update the expected bmps to match the real output.

I think that's close enough, and it would make sense to consider this to be an intentional nanosvg change and update the expected bmps to match the real output.

Agreed.

Updated reference svg-class.bmp in both SDL2 and SDL3 branches.

authors: sezero slouken smcv


text:
Proper UTF-16 and characters outside the BMP support

This bug report was migrated from our old Bugzilla tracker.
Reported in version: unspecified
Reported for operating system, platform: Windows 10, x86_64
Comments on the original bug report:
On 2018-09-03 07:21:42 +0000, pjz wrote:

I propose a patch with added proper UTF-16 and characters outside the BMP support, which extends the fix to the bug # 3762. The code can be found at https://github.com/acmepjz/SDL_ttf/tree/utf16-fix.

Change the UCS-2 code to UTF-16 code, which allows characters outside the BMP range

Change various public functions (TTF_GlyphIsProvided, TTF_GlyphMetrics, TTF_RenderGlyph_***, etc.) to accept Uint32 for character instead of Uint16

Also added a UTF-32 to UTF-8 conversion routine (which is only used in TTF_RenderGlyph_***)

Duplicate of https://github.com/libsdl-org/SDL_ttf/issues/230

authors: SDLBugzilla slouken


text:
Crash on uv_loop_close after freeing watcher handle

I'm seeing crashes in uv_loop_close when closing a loop that's had all its watchers stopped. This happens when the memory allocated for the watcher handle is released before the loop is closed.
Here is a slightly contrived example to illustrate the problem:
static void timer_callback(uv_timer_t * handle) {
    uv_timer_stop(handle);
}

void test() {
    uv_loop_t loop;
    uv_loop_init(&loop);

    uv_timer_t * timer = (uv_timer_t*)malloc(sizeof(uv_timer_t));
    uv_timer_init(&loop, timer);
    uv_timer_start(timer, timer_callback, 0, 1000);
    uv_run(&loop, UV_RUN_DEFAULT);
    free(timer);

    uv_loop_close(&loop);  /* crash occurs here */
}

It seems that uv_timer_stop is not enough to remove the watcher from the loop's internal list of watchers. Is this an error, or am I just using the API incorrectly?

Is this an error, or am I just using the API incorrectly?

User error. :-)  You should not free the timer until you have either uv_close'd it and the close callback has been called, or the event loop has been shut down with uv_loop_close().

Ah, thanks. I knew there must be something. I didn't realize uv_close applied to timers too.  Now I know!  Thanks.

authors: beevik bnoordhuis

repo: libuv/libuv


text:
undefined reference to uv_library_shutdown

Hi,
Using a very simple code below:
#include <uv.h> int main (int argc, char *argv[]) {     uv_loop_t *loop = uv_default_loop();     uv_run(loop, UV_RUN_DEFAULT);     uv_loop_close(loop);     uv_library_shutdown(); }
Compiling with: gcc src/main.cpp -o main -luv
getting the following error:
/usr/bin/ld: /tmp/ccMg1mqF.o: in function 'main':   main.cpp:(.text+0x3a): undefined reference to 'uv_library_shutdown'   collect2: error: ld returned 1 exit status
Executing nm /usr/local/lib/libuv.so  show the symbol defined:
0000000000011596 T uv_library_shutdown.
Pulled and compiled the very latest libuv, any idea why I'm getting this?

Version: 1.38.1.-dev
Platform: Linux eos 5.4.0-29-generic #33-Ubuntu SMP Wed Apr 29 14:32:27 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Have a look at your link path, there's probably another, older libuv.so in e.g. /usr/lib.


text:
test,unix: fix race in test runner

The test runner inserted a 250 ms delay to give helper processes time to
settle. That's intrinsically race-y and caused tests to intermittently
fail on platforms like AIX.
Instead of a fixed delay, pass a file descriptor to the helper process
and wait until it closes the descriptor. That way we know for sure the
process has started.
Incidentally, this change reduces the running time of the test suite
from 112 to 26 seconds on my machine.
Fixes: #2041
CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1086/

I applied this change and ran the test in the offending machine (CI, BE-2) and it did not recreate in 200 iterations.

changes LGTM, one question though:
when a helper (mostly a server) notifies its parent (runner), it has put up the server socket, but is not yet listening - that happens only when you run the loop. So is there still a race in the hiding, though tiny ?

The helpers bind their sockets before calling uv_run() so there should be no race any longer; the child doesn't notify the parent until right before entering uv_run().

authors: bnoordhuis gireeshpunathil


text:
unix,fs: fix realpath calls that use the system allocator

Make sure we allocate the memory with uv__malloc so it's in turn freed with uv__free.
Fixes: https://github.com/libuv/libuv/issues/4329

@bnoordhuis I checked all usages of realpath and it's a much smaller change than I anticipated. Only these 2 need fixing, so I went ahead and made copies where necessary rather than add special cases so free is used.

ASAN failures look related (although not immediately obvious to me why they fail - uv_fs_req_cleanup calls uv__free, right?)

ASAN failures look related (although not immediately obvious to me why they fail - uv_fs_req_cleanup calls uv__free, right?)

Good guy ASAN! There was a bug, I wasn't free-ing the tmp buffer in the success case. Should be good now, let's see.

authors: bnoordhuis saghul


text:
version 1.0.10 doesn't work on Mac

Throws
Error: dlopen(/.../node_modules/libxmljs/build/Release/xmljs.node, 0x0001): tried: '/.../node_modules/libxmljs/build/Release/xmljs.node' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/.../node_modules/libxmljs/build/Release/xmljs.node' (no such file), '/.../node_modules/libxmljs/build/Release/xmljs.node' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))
Can be fixed by downgrading to previous 1.0.9

I am also seeing the same behaviour. Thank you for opening the issue

authors: ableda orept

repo: libxmljs/libxmljs

license: mit

license_source: bigquery


text:
[Go Http客户端] 朋友圈消息无法成功保存到数据库

原因是刷新朋友圈之后获取到的朋友圈信息的id超过的数据库message表id（int）的范围
报错信息：
time=2024-08-14T10:16:18.650+08:00 level=ERROR msg="trace error" Logger=gorm error="sql: converting argument $1 type: uint64 values with high bit set are not supported" sql="INSERT INTO message (id,is_self,is_group,type,ts,roomid,content,sender,sign,thumb,extra,xml,remark,created_at,updated_at) VALUES (14458594525450547936,false,false,0,1723598781,"-","********************","wxid_p19dofnd1zpj22","","","","14458594525450547936wxid_p19dofnd1zpj221723598781000⚠安全生产许可证，需提前3个月延期\n💢到期不能公开投标，影响施工\n📣需要安许延期的客户抓紧时间\n☎一站式申报服务 ，免费咨询000000101445859452607202582420<url type=""1"" md5=""a7406f99e52c2983141531f644756ced"">http://shmmsns.qpic.cn/mmsns/UDT6e41Bw6LnGw8dvibJ49YwiawWCazzA4YZ8a6LJeQK89V1gksbHjiaiaDeJd5gud9KSib68H4Y6Xo0/0<thumb type=""1"">http://shmmsns.qpic.cn/mmsns/UDT6e41Bw6LnGw8dvibJ49YwiawWCazzA4YZ8a6LJeQK89V1gksbHjiaiaDeJd5gud9KSib68H4Y6Xo0/1500.0<size totalSize=""51150.0"" width=""800.0"" height=""800.0""><location poiClassifyId="""" poiName="""" poiAddress="""" poiClassifyType=""0"" city="""">","",1723601778,1723601778) RETURNING rd" rows=0 elapsed=9.5544ms

请按格式报 bug 并提供足够的复现信息。随时重新打开。


text:
Invalid value of AF read; Flag ingerpretation

Hi,
I have met surprising behaviour while loading this simple VCF with 2.1 version.
The source vcf looks like:
##fileformat=VCFv4.2
##INFO=<ID=AC,Number=A,Type=Integer,Description="Allele count in genotypes, for each ALT allele, in the same order as listed">
##INFO=<ID=AF,Number=A,Type=Float,Description="Allele Frequency, for each ALT allele, in the same order as listed">
##INFO=<ID=AN,Number=1,Type=Integer,Description="Total number of alleles in called genotypes">
##INFO=<ID=DB,Number=0,Type=Flag,Description="dbSNP Membership">
##INFO=<ID=DP,Number=1,Type=Integer,Description="Total depth of called genotypes">
##INFO=<ID=MAJ,Number=1,Type=String,Description="Major allele is REF or ALT">
##contig=<ID=MT,length=16569>
#CHROM  POS     ID      REF     ALT     QUAL    FILTER  INFO
1       10109   rs376007522     A       T       22940.40        .       AC=86;AN=176;AF=0.4886;DP=17307;MAJ=REF;DB
1       10150   rs371194064     C       T       2276.70 .       AC=31;AN=176;AF=0.1761;DP=15279;MAJ=REF;DB

I read it using com.lifeomic.variants and below is what is read.
scala> val myVcf = spark.read.format("com.lifeomic.variants").option("use.info.map", "true").option("use.info.type", "true").load("....vcf")
scala> myVcf.show
+-----+-----+-----+-----+-----------+---+---+--------+------+---+---+-----+-----+----+----+
|chrom|  pos|start| stop|         id|ref|alt|    qual|filter| an|maj|   dp|   af|  ac|  db|
+-----+-----+-----+-----+-----------+---+---+--------+------+---+---+-----+-----+----+----+
|    1|10109|10108|10109|rs376007522|  A|  T|22940.40|     .|176|REF|17307|[0.0]|[86]|null|
|    1|10150|10149|10150|rs371194064|  C|  T| 2276.70|     .|176|REF|15279|[0.0]|[31]|null|
+-----+-----+-----+-----+-----------+---+---+--------+------+---+---+-----+-----+----+----+

What is suprising is:

The AF data is lost. It is set 0.0 without visible reason.
Flag DB is not interpreted correctly, I would expect db to have boolean value, while the DB data is lost completely here...

Thank you for your time, best wishes,
Piotr

Yeah, I'll take a look. Thanks.

My guess is the vcfs that we have looked at expect the info fields to be there. I'll try to get a patch up that tests with null info columns.

Found the bug. A fix will be up momentarily and I can push it to maven central. Thanks for reporting it.

Released version 0.3.0. https://oss.sonatype.org/#nexus-search;quick~lifeomic .
Some important notes that will be apart of the release notes. Type Info fields will now have a prefix attached to the key of info_ due to the fact there were cases of collision in names with format fields.

repo: lifeomic/spark-vcf


text:
update changes

:white_check_mark: UI

[ ] Identify and resolve any new warnings in the console
[ ] Identify and resolve any new errors in the console
[ ] If there are modifications to configurations such as vite.config.ts, tsconfig.json etc., ensure to include a description

:white_large_square: Automation Scripts

[ ] Identify and resolve any new warnings in the console
[ ] Identify and resolve any new errors in the console
[ ] If there are modifications to configurations such as vite.config.ts, tsconfig.json etc., ensure to include a description

LGTM

repo: lifeparticle/binarytree


text:
Fix patch to enable utilisation of commercial license

The patch to enable using commercial license stuff was not mergeable anymore as quite a number of PR's were merged since the patch was created. This may happen again in the future...
The approach using a patch is still the easiest I think...

@raboof this is actually a good candidate for automated checking: on each PR, we verify that the patch can be applied...

repo: lightbend/Pi-Akka-Cluster


text:
Release Kalix JavaScript SDK

Prepare

[x] Make sure all important PRs have been merged
[x] Check that the latest build successfully finished
[x] Make sure a version of the proxy that supports the protocol version the SDK expects has been deployed to production

You can see the proxy version on prod on grafana or using various other methods.
Cutting the release

[x] Edit the draft release notes and create the appropriate tag

CircleCI will automatically publish the @kalix-io/kalix-javascript-sdk package to the npm registry based on the tag
CI will update the docs/current branch

Check availability

[x] Check that docs/kalix-current has been updated
[x] Check the release in the npm registry

Fix and publish docs

[ ] Update the supported version in the main docs if relevant (affects Supported Versions)
[ ] Add an item to the Release Notes in the documentation
[ ] Release the Kalix documentation to get the SDK docs updates published

Update to the latest version

[x] Run samples/bin/update.sh to update the samples to the latest released versions.

Check docs update

[ ] After quite a while TechHub shows updated docs (see the timestamp on the bottom of the page)

Announcements

[ ] Announce in the forum

tag with Kalix, releases and announcement

[ ] Inform Lightbend marketing and engineering if it's a noteworthy release
[ ] Close this issue

I think this is sufficient for a milestone release

repo: lightbend/kalix-javascript-sdk


text:
browsermob-proxy:jar:2.1.0-beta-4  not deployed to Maven Central

Can you please deploy newest version to Maven Central?
http://search.maven.org/#artifactdetails|net.lightbody.bmp|browsermob-proxy|2.1.0-beta-4|pom
lists only

browsermob-proxy-2.1.0-beta-4.pom
browsermob-proxy-2.1.0-beta-4.pom.asc

and no jars

To the contrary, beta-4 is most definitely available on Central. Please see the README displayed at the Github page for usage instructions.

authors: dzieciou jekh

repo: lightbody/browsermob-proxy


text:
BrowserMobProxy with browserstack is not intercepting the response

I am using JAVA + SELENIUM web-driver + browser mobproxy + browserstacklocal ( embeded)
compile 'com.browserstack:browserstack-local-java:1.0.2'
compile 'net.lightbody.bmp:browsermob-core:2.1.5'

Locally its working fine as I am able to intercept the api response and override the response code ( as example 200-OK to 502-BAD_GATEWAY)
However while running this test in the browserstack , its not working as seems mobproxy is not intercepting the response and overriding that. So assertion fails in the test steps. Other tests which does not depend on mobproxy are working fine in browsestack.
Proxy seleniumProxy = ProxyUtils.getInstance().createSeleniumProxy();
String host=seleniumProxy.getHttpProxy()
            .substring(0,seleniumProxy.getHttpProxy().indexOf(":"));
String port=seleniumProxy.getHttpProxy()
            .substring(seleniumProxy.getHttpProxy()
            .indexOf(":")+1,seleniumProxy.getHttpProxy().length());
browserStackLocalArgs.put("key", <key>);
browserStackLocalArgs.put("localIdentifier", <identifier>);
browserStackLocalArgs.put("forcelocal", "true");
browserStackLocalArgs.put("force", "true");
browserStackLocalArgs.put("forceproxy", "true");
browserStackLocalArgs.put("localProxyHost", host);
browserStackLocalArgs.put("localProxyPort", String.valueOf(port));
browserStackLocalArgs.put("--daemon", "start");
browserStackLocal.start(browserStackLocalArgs);

I have used both localProxyHost and -local-proxy-host but no luck.
I am adding the set capability for the browserstack as well.
ChromeOptions chromeOptions = new ChromeOptions();
chromeOptions.setCapability(CapabilityType.PROXY, proxy);
browserStackCapabilities.setCapability(ChromeOptions.CAPABILITY, chromeOptions);

While doing ps -ef | grep browserstack it returns me
505   921     1   0  6:33pm ??         0:00.86 /Users/ITAS4/.browserstack/BrowserStackLocal -d start key -forceproxy -localIdentifier browserstack_local_machine -force -localProxyPort 49676 ---daemon start -forcelocal -localProxyHost CHISIMAC0123.local -daemonInstance
505   943   921   0  6:33pm ??         0:02.29 /Users/ITAS4/.browserstack/BrowserStackLocal key -forceproxy -localIdentifier browserstack_local_machine-browserstack-fork-0 -localProxyPort 49676 ---daemon start -forcelocal -localProxyHost CHISIMAC0123.local -daemonInstance
505   944   921   0  6:33pm ??         0:00.79 /Users/ITAS4/.browserstack/BrowserStackLocal key -forceproxy -localIdentifier browserstack_local_machine-browserstack-fork-1 -localProxyPort 49676 ---daemon start -forcelocal -localProxyHost CHISIMAC0123.local -daemonInstance
505   945   921   0  6:33pm ??         0:00.80 /Users/ITAS4/.browserstack/BrowserStackLocal key -forceproxy -localIdentifier browserstack_local_machine-browserstack-fork-2 -localProxyPort 49676 ---daemon start -forcelocal -localProxyHost CHISIMAC0123.local -daemonInstance
505   946   921   0  6:33pm ??         0:00.79 /Users/ITAS4/.browserstack/BrowserStackLocal key -forceproxy -localIdentifier browserstack_local_machine-browserstack-fork-3 -localProxyPort 49676 ---daemon start -forcelocal -localProxyHost CHISIMAC0123.local -daemonInstance
505   947   921   0  6:33pm ??         0:00.80 /Users/ITAS4/.browserstack/BrowserStackLocal key -forceproxy -localIdentifier browserstack_local_machine-browserstack-fork-4 -localProxyPort 49676 ---daemon start -forcelocal -localProxyHost CHISIMAC0123.local -daemonInstance

@arihan  What was the solution/WA you found to this ?

authors: arihan vinayvennela


text:
[bug] MintingBatch will not trigger until restarting tarod

Using latest version on main for taro, and ca501d for LND
Started with fresh taro directory, and all lnd funds on a p2wkh address
2022-12-02 18:31:05.239 [INF] GRDN: Creating new MintingBatch w/ AssetSeedling(name=habibtaro_usd, type=Normal, amt=21000000) received
2022-12-02 18:31:05.239 [DBG] TARO: Deriving new key for fam_family=219
2022-12-02 18:31:05.291 [INF] GRDN: Request for new seedling: AssetSeedling(name=habibtaro_usd, type=Normal, amt=21000000) received

Won't mint until restarting the daemon:
2022-12-02 18:31:25.513 [INF] GRDN: Starting ChainPlanter
2022-12-02 18:31:25.514 [INF] GRDN: Retrieved 1 non-finalized batches from DB
2022-12-02 18:31:25.514 [INF] GRDN: Launching ChainCaretaker(0231ae594e8601b0ce08da2d6ff5f361962b966d4c41851cae51649d4728592284)
2022-12-02 18:31:25.515 [INF] GRDN: Starting asset custodian
2022-12-02 18:31:25.515 [INF] GRDN: BatchCaretaker(0231ae594e8601b0ce08da2d6ff5f361962b966d4c41851cae51649d4728592284), advancing from state=BatchStatePending to state=BatchStateBroadcast
2022-12-02 18:31:25.515 [INF] GRDN: Freezing MintingBatch(key=0231ae594e8601b0ce08da2d6ff5f361962b966d4c41851cae51649d4728592284, num_assets=1
2022-12-02 18:31:25.515 [DBG] GRDN: Subscribing to new on-chain transactions
2022-12-02 18:31:25.515 [INF] GRDN: Gardener for ChainPlanter now active!
2022-12-02 18:31:25.515 [INF] GRDN: Loading pending inbound asset events
2022-12-02 18:31:25.515 [INF] FRTR: Starting ChainPorter
2022-12-02 18:31:25.515 [INF] GRDN: Resuming 0 pending inbound asset events
2022-12-02 18:31:25.515 [INF] GRDN: Loading wallet transactions starting at block height 0
2022-12-02 18:31:25.516 [INF] FRTR: Resuming delivery of 0 pending asset parcels
2022-12-02 18:31:25.516 [INF] RPCS: Starting RPC Server
2022-12-02 18:31:25.516 [INF] SRVR: Taro Daemon fully active!
2022-12-02 18:31:25.516 [INF] GRDN: BatchCaretaker(0231ae594e8601b0ce08da2d6ff5f361962b966d4c41851cae51649d4728592284): transition states: BatchStatePending -> BatchStateFrozen
2022-12-02 18:31:25.516 [INF] GRDN: BatchCaretaker(0231ae594e8601b0ce08da2d6ff5f361962b966d4c41851cae51649d4728592284): attempting to fund GenesisPacket
2022-12-02 18:31:25.517 [INF] GRDN: BatchCaretaker(0231ae594e8601b0ce08da2d6ff5f361962b966d4c41851cae51649d4728592284): creating skeleton PSBT: (*psbt.Packet)(0xc0005b0190)({
 UnsignedTx: (*wire.MsgTx)(0xc0005ad6c0)({
  Version: (int32) 2,

Tried to repro on that exact lnd commit, and on the current main branch, and everything worked w/o a repro.
Perhaps try to increase the debug/logging level on both sides?

Hmm, how long does it take for the batch to get created? Tried waiting 4 minutes and still happened again.
Lnd w/ debug created too much spam so couldn't catch those logs, but taro log output was exactly the same as OP
Also here is CLI input
tarocli assets mint --type normal --name habibtaro_2 --supply 210000001 --meta "habibtaro.com" --enable_emission false --skip_batch true
{
    "batch_key": "02fb11462d2fd8bb448ace4dff00c71aef39bda26fe0226327f7d75a32e730a0c5"
}

If you're on lnd master branch then you need to try with https://github.com/lightninglabs/taro/pull/206 that fixes an issue with default Taproot change addresses. Otherwise you can try with lnd at commit ca501d92 which doesn't have that PR yet.

@guggero weird thing is I am on ca501d92
Seems Roasbeef was unable to reproduce, wondering if this happens on your end?

You didn't see any errors in the Taro log?

None.. it appeared as if it didn't even try to mint the asset

@habibitcoin the default interval is 10 minutes. You can change that with the batch-minting-interval flag.

I am experiencing same issue as @habibitcoin . The flag --skip-batch is not helping. Only restart of tarod helps .

If you reduce batch-minting-interval to say, 1 second, do you still encounter the issue? Do you have any logs of a triggered instance?

@Roasbeef definitely still happening :/ tried waiting for the batch to run, but you'd think --skip-batch would skip the batch by definition
See logs below; note that I had to stop tarod for the batch to finally mint (much more than 10 mins later)
2023-01-03 15:18:10.540 [INF] GRDN: Creating new MintingBatch w/ AssetSeedling(name=habibtaro_usd2, type=Normal, amt=21000000) received
2023-01-03 15:18:10.543 [DBG] TARO: Deriving new key for fam_family=219
2023-01-03 15:18:10.732 [INF] GRDN: Request for new seedling: AssetSeedling(name=habibtaro_usd2, type=Normal, amt=21000000) received

.... no output for >10 mins

2023-01-03 15:34:33.918 [INF] RPCS: RPC server listening on 127.0.0.1:10029
2023-01-03 15:34:33.921 [INF] RPCS: gRPC proxy started at 127.0.0.1:8089
2023-01-03 15:34:33.921 [INF] GRDN: Starting ChainPlanter
2023-01-03 15:34:33.927 [INF] GRDN: Retrieved 1 non-finalized batches from DB
2023-01-03 15:34:33.927 [INF] GRDN: Launching ChainCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2)
2023-01-03 15:34:33.928 [INF] GRDN: Starting asset custodian
2023-01-03 15:34:33.928 [INF] GRDN: Gardener for ChainPlanter now active!
2023-01-03 15:34:33.928 [DBG] GRDN: Subscribing to new on-chain transactions
2023-01-03 15:34:33.928 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2), advancing from state=BatchStatePending to state=BatchStateBroadcast
2023-01-03 15:34:33.928 [INF] GRDN: Freezing MintingBatch(key=02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2, num_assets=1
2023-01-03 15:34:33.930 [INF] GRDN: Loading pending inbound asset events
2023-01-03 15:34:33.930 [INF] FRTR: Starting ChainPorter
2023-01-03 15:34:33.932 [INF] FRTR: Resuming delivery of 0 pending asset parcels
2023-01-03 15:34:33.932 [INF] RPCS: Starting RPC Server
2023-01-03 15:34:33.932 [INF] SRVR: Taro Daemon fully active!
2023-01-03 15:34:33.932 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): transition states: BatchStatePending -> BatchStateFrozen
2023-01-03 15:34:33.932 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): attempting to fund GenesisPacket
2023-01-03 15:34:33.933 [INF] GRDN: Resuming 0 pending inbound asset events
2023-01-03 15:34:33.933 [INF] GRDN: Loading wallet transactions starting at block height 0
2023-01-03 15:34:33.933 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): creating skeleton PSBT: (*psbt.Packet)(0xc000a56140)({
 UnsignedTx: (*wire.MsgTx)(0xc000a30300)({
  Version: (int32) 2,
  TxIn: ([]*wire.TxIn) (cap=15) {
  },
  TxOut: ([]*wire.TxOut) (len=1 cap=15) {
   (*wire.TxOut)(0x2f651e0)({
    Value: (int64) 1000,
    PkScript: ([]uint8) (len=34 cap=34) {
     00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     00000020  00 00                                             |..|
    }
   })
  },
  LockTime: (uint32) 0
 }),
 Inputs: ([]psbt.PInput) {
 },
 Outputs: ([]psbt.POutput) (len=1 cap=1) {
  (psbt.POutput) {
   RedeemScript: ([]uint8) <nil>,
   WitnessScript: ([]uint8) <nil>,
   Bip32Derivation: ([]*psbt.Bip32Derivation) <nil>,
   TaprootInternalKey: ([]uint8) <nil>,
   TaprootTapTree: ([]uint8) <nil>,
   TaprootBip32Derivation: ([]*psbt.TaprootBip32Derivation) <nil>
  }
 },
 Unknowns: ([]psbt.Unknown) {
 }
})

2023-01-03 15:34:33.957 [INF] GRDN: Checking 14 wallet transactions for inbound assets, this might take a while
2023-01-03 15:34:33.957 [DBG] GRDN: Inspecting tx 82bc5a12120222de4114a2296ab8ed11be6641d4e59cdd176b3dba54162bf0a1 for Taro address outputs
2023-01-03 15:34:33.975 [DBG] GRDN: Inspecting tx 9ec6ca5637ce2a32e2f528ea64c8decae3a79f22f9ff840e5ef18ae1e5f846a3 for Taro address outputs
2023-01-03 15:34:33.975 [DBG] GRDN: Inspecting tx 2412a1a403065503eff8af7d1117232ea1a2b056146d637974483bd08388ef70 for Taro address outputs
2023-01-03 15:34:33.987 [DBG] GRDN: Inspecting tx 31e82e90e09dd75d9eab55707538d11e8f92f01bf58e271143dd8834afcfd395 for Taro address outputs
2023-01-03 15:34:33.988 [DBG] GRDN: Inspecting tx 063280c2cd2a1c1cf42cf2fc3fb21cd6660a097e22dadc8db5f733ce36216a3d for Taro address outputs
2023-01-03 15:34:33.988 [DBG] GRDN: Inspecting tx e3dcdfe1f03821430a13742189af3a8c451635b113e852f690b4b59dd864a643 for Taro address outputs
2023-01-03 15:34:33.988 [DBG] GRDN: Inspecting tx 1c63ea00e732e556cbc37f629b51c14ca9c8a615dfa6e05cfe4fe299ec7dd482 for Taro address outputs
2023-01-03 15:34:33.988 [DBG] GRDN: Inspecting tx f43fc199624accf9ed8be6e8087bfc69d4cdaa846b91dba5265ee27955422c9f for Taro address outputs
2023-01-03 15:34:33.989 [INF] GRDN: Starting main custodian event loop
2023-01-03 15:34:34.010 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): funded GenesisPacket obtained: (tarogarden.FundedPsbt) {
 Pkt: (*psbt.Packet)(0xc000a57360)({
  UnsignedTx: (*wire.MsgTx)(0xc000a31a00)({
   Version: (int32) 2,
   TxIn: ([]*wire.TxIn) (len=1 cap=1) {
    (*wire.TxIn)(0xc000a138c0)({
     PreviousOutPoint: (wire.OutPoint) 82bc5a12120222de4114a2296ab8ed11be6641d4e59cdd176b3dba54162bf0a1:1,
     SignatureScript: ([]uint8) {
     },
     Witness: (wire.TxWitness) <nil>,
     Sequence: (uint32) 4294967295
    })
   },
   TxOut: ([]*wire.TxOut) (len=2 cap=2) {
    (*wire.TxOut)(0xc000a31a40)({
     Value: (int64) 1000,
     PkScript: ([]uint8) (len=34 cap=34) {
      00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
      00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
      00000020  00 00                                             |..|
     }
    }),
    (*wire.TxOut)(0xc000a31a60)({
     Value: (int64) 5772931,
     PkScript: ([]uint8) (len=34 cap=34) {
      00000000  51 20 1e 1d fd 34 57 4a  a2 47 86 e0 73 b0 f5 3f  |Q ...4WJ.G..s..?|
      00000010  82 b9 2a 42 49 06 46 29  4b a0 ae ec 0c 1b e2 fb  |..*BI.F)K.......|
      00000020  47 4f                                             |GO|
     }
    })
   },
   LockTime: (uint32) 0
  }),
  Inputs: ([]psbt.PInput) (len=1 cap=1) {
   (psbt.PInput) {
    NonWitnessUtxo: (*wire.MsgTx)(0xc000a31a80)({
     Version: (int32) 2,
     TxIn: ([]*wire.TxIn) (len=1 cap=1) {
      (*wire.TxIn)(0xc000a13920)({
       PreviousOutPoint: (wire.OutPoint) 9ec6ca5637ce2a32e2f528ea64c8decae3a79f22f9ff840e5ef18ae1e5f846a3:1,
       SignatureScript: ([]uint8) {
       },
       Witness: (wire.TxWitness) (len=2 cap=2) {
        ([]uint8) (len=71 cap=71) {
         00000000  30 44 02 20 0e 33 25 e2  e7 9c 5e 9e 2a 5a e2 f6  |0D. .3%...^.*Z..|
         00000010  2d c4 58 5a 18 f6 2f 84  7c 0c 65 2d 0b 5b 52 d8  |-.XZ../.|.e-.[R.|
         00000020  c3 93 9c c1 02 20 60 f8  1a ff 6d a7 32 ad 98 db  |..... `...m.2...|
         00000030  30 09 8a 22 b0 f0 ed 2a  8d b3 e1 39 0c 2c 5a 55  |0.."...*...9.,ZU|
         00000040  6d a6 a8 b5 cd 79 01                              |m....y.|
        },
        ([]uint8) (len=33 cap=33) {
         00000000  03 c3 65 e2 ad 46 62 b9  85 d8 5f cc ec 19 bb d2  |..e..Fb..._.....|
         00000010  4c 8b 9b 50 30 32 e7 74  cb 2f bd 29 9e 2a bd e2  |L..P02.t./.).*..|
         00000020  8e                                                |.|
        }
       },
       Sequence: (uint32) 4294967295
      })
     },
     TxOut: ([]*wire.TxOut) (len=2 cap=2) {
      (*wire.TxOut)(0xc000a31ac0)({
       Value: (int64) 1000,
       PkScript: ([]uint8) (len=34 cap=34) {
        00000000  51 20 83 78 40 60 9a fc  6d fa 06 d5 c7 ba 42 4a  |Q .x@`..m.....BJ|
        00000010  ef 46 27 eb d7 e3 d4 57  75 8d 45 9f ea f3 cb 47  |.F'....Wu.E....G|
        00000020  b9 84                                             |..|
       }
      }),
      (*wire.TxOut)(0xc000a31ae0)({
       Value: (int64) 5782181,
       PkScript: ([]uint8) (len=22 cap=22) {
        00000000  00 14 a1 ed 73 84 02 c9  fd 4a b4 7a f1 88 b0 5d  |....s....J.z...]|
        00000010  f4 ac 7e 21 43 bf                                 |..~!C.|
       }
      })
     },
     LockTime: (uint32) 0
    }),
    WitnessUtxo: (*wire.TxOut)(0xc000157d60)({
     Value: (int64) 5782181,
     PkScript: ([]uint8) (len=22 cap=22) {
      00000000  00 14 a1 ed 73 84 02 c9  fd 4a b4 7a f1 88 b0 5d  |....s....J.z...]|
      00000010  f4 ac 7e 21 43 bf                                 |..~!C.|
     }
    }),
    PartialSigs: ([]*psbt.PartialSig) <nil>,
    SighashType: (txscript.SigHashType) 1,
    RedeemScript: ([]uint8) <nil>,
    WitnessScript: ([]uint8) <nil>,
    Bip32Derivation: ([]*psbt.Bip32Derivation) (len=1 cap=1) {
     (*psbt.Bip32Derivation)(0xc000a31b00)({
      PubKey: ([]uint8) (len=33 cap=33) {
       00000000  02 bf bd 68 da 15 02 f8  e6 94 c9 64 e2 0b 8d a0  |...h.......d....|
       00000010  19 51 e5 64 7f b2 b2 56  75 71 ef 29 dc 71 1e 80  |.Q.d...Vuq.).q..|
       00000020  a3                                                |.|
      },
      MasterKeyFingerprint: (uint32) 0,
      Bip32Path: ([]uint32) (len=5 cap=8) {
       (uint32) 2147483732,
       (uint32) 2147483648,
       (uint32) 2147483648,
       (uint32) 1,
       (uint32) 5
      }
     })
    },
    FinalScriptSig: ([]uint8) <nil>,
    FinalScriptWitness: ([]uint8) <nil>,
    TaprootKeySpendSig: ([]uint8) <nil>,
    TaprootScriptSpendSig: ([]*psbt.TaprootScriptSpendSig) <nil>,
    TaprootLeafScript: ([]*psbt.TaprootTapLeafScript) <nil>,
    TaprootBip32Derivation: ([]*psbt.TaprootBip32Derivation) <nil>,
    TaprootInternalKey: ([]uint8) <nil>,
    TaprootMerkleRoot: ([]uint8) <nil>,
    Unknowns: ([]*psbt.Unknown) <nil>
   }
  },
  Outputs: ([]psbt.POutput) (len=2 cap=2) {
   (psbt.POutput) {
    RedeemScript: ([]uint8) <nil>,
    WitnessScript: ([]uint8) <nil>,
    Bip32Derivation: ([]*psbt.Bip32Derivation) <nil>,
    TaprootInternalKey: ([]uint8) <nil>,
    TaprootTapTree: ([]uint8) <nil>,
    TaprootBip32Derivation: ([]*psbt.TaprootBip32Derivation) <nil>
   },
   (psbt.POutput) {
    RedeemScript: ([]uint8) <nil>,
    WitnessScript: ([]uint8) <nil>,
    Bip32Derivation: ([]*psbt.Bip32Derivation) (len=1 cap=1) {
     (*psbt.Bip32Derivation)(0xc000a31b40)({
      PubKey: ([]uint8) (len=33 cap=33) {
       00000000  02 86 03 53 37 31 a0 73  5f e9 59 27 4d ea 66 6c  |...S71.s_.Y'M.fl|
       00000010  c5 18 20 8c 90 49 f4 14  b1 82 3a 74 8e 17 bc f7  |.. ..I....:t....|
       00000020  cb                                                |.|
      },
      MasterKeyFingerprint: (uint32) 0,
      Bip32Path: ([]uint32) (len=5 cap=8) {
       (uint32) 2147483734,
       (uint32) 2147483648,
       (uint32) 2147483648,
       (uint32) 1,
       (uint32) 2
      }
     })
    },
    TaprootInternalKey: ([]uint8) (len=32 cap=32) {
     00000000  86 03 53 37 31 a0 73 5f  e9 59 27 4d ea 66 6c c5  |..S71.s_.Y'M.fl.|
     00000010  18 20 8c 90 49 f4 14 b1  82 3a 74 8e 17 bc f7 cb  |. ..I....:t.....|
    },
    TaprootTapTree: ([]uint8) <nil>,
    TaprootBip32Derivation: ([]*psbt.TaprootBip32Derivation) (len=1 cap=1) {
     (*psbt.TaprootBip32Derivation)(0xc000a57310)({
      XOnlyPubKey: ([]uint8) (len=32 cap=32) {
       00000000  86 03 53 37 31 a0 73 5f  e9 59 27 4d ea 66 6c c5  |..S71.s_.Y'M.fl.|
       00000010  18 20 8c 90 49 f4 14 b1  82 3a 74 8e 17 bc f7 cb  |. ..I....:t.....|
      },
      LeafHashes: ([][]uint8) {
      },
      MasterKeyFingerprint: (uint32) 0,
      Bip32Path: ([]uint32) (len=5 cap=8) {
       (uint32) 2147483734,
       (uint32) 2147483648,
       (uint32) 2147483648,
       (uint32) 1,
       (uint32) 2
      }
     })
    }
   }
  },
  Unknowns: ([]psbt.Unknown) <nil>
 }),
 ChangeOutputIndex: (int32) 1,
 ChainFees: (int64) 0,
 LockedUTXOs: ([]wire.OutPoint) (len=1 cap=1) {
  (wire.OutPoint) 82bc5a12120222de4114a2296ab8ed11be6641d4e59cdd176b3dba54162bf0a1:1
 }
}

2023-01-03 15:34:34.012 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): mapping 1 seedlings to asset sprouts, with genesis_point=82bc5a12120222de4114a2296ab8ed11be6641d4e59cdd176b3dba54162bf0a1:1
2023-01-03 15:34:34.014 [DBG] TARO: Deriving new key for fam_family=219
2023-01-03 15:34:34.037 [DBG] TARO: Deriving new key for fam_family=219
2023-01-03 15:34:34.093 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): committing sprouts to disk
2023-01-03 15:34:34.096 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): transition states: BatchStateFrozen -> BatchStateCommitted
2023-01-03 15:34:34.096 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): finalizing GenesisPacket
2023-01-03 15:34:34.098 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): GenesisPacket finalized: (*psbt.Packet)(0xc00003ce60)({
 UnsignedTx: (*wire.MsgTx)(0xc000c4c640)({
  Version: (int32) 2,
  TxIn: ([]*wire.TxIn) (len=1 cap=1) {
   (*wire.TxIn)(0xc00073a540)({
    PreviousOutPoint: (wire.OutPoint) 82bc5a12120222de4114a2296ab8ed11be6641d4e59cdd176b3dba54162bf0a1:1,
    SignatureScript: ([]uint8) {
    },
    Witness: (wire.TxWitness) <nil>,
    Sequence: (uint32) 4294967295
   })
  },
  TxOut: ([]*wire.TxOut) (len=2 cap=2) {
   (*wire.TxOut)(0xc000c4c680)({
    Value: (int64) 1000,
    PkScript: ([]uint8) (len=34 cap=34) {
     00000000  51 20 c5 a8 80 5c 05 aa  48 4a 10 32 23 ed 17 66  |Q ...\..HJ.2#..f|
     00000010  dd 20 84 c0 67 b2 87 04  ca ee 52 51 5a f8 f3 01  |. ..g.....RQZ...|
     00000020  f4 d0                                             |..|
    }
   }),
   (*wire.TxOut)(0xc000c4c6a0)({
    Value: (int64) 5772931,
    PkScript: ([]uint8) (len=34 cap=34) {
     00000000  51 20 1e 1d fd 34 57 4a  a2 47 86 e0 73 b0 f5 3f  |Q ...4WJ.G..s..?|
     00000010  82 b9 2a 42 49 06 46 29  4b a0 ae ec 0c 1b e2 fb  |..*BI.F)K.......|
     00000020  47 4f                                             |GO|
    }
   })
  },
  LockTime: (uint32) 0
 }),
 Inputs: ([]psbt.PInput) (len=1 cap=1) {
  (psbt.PInput) {
   NonWitnessUtxo: (*wire.MsgTx)(0xc000c4c6c0)({
    Version: (int32) 2,
    TxIn: ([]*wire.TxIn) (len=1 cap=1) {
     (*wire.TxIn)(0xc00073a5a0)({
      PreviousOutPoint: (wire.OutPoint) 9ec6ca5637ce2a32e2f528ea64c8decae3a79f22f9ff840e5ef18ae1e5f846a3:1,
      SignatureScript: ([]uint8) {
      },
      Witness: (wire.TxWitness) (len=2 cap=2) {
       ([]uint8) (len=71 cap=71) {
        00000000  30 44 02 20 0e 33 25 e2  e7 9c 5e 9e 2a 5a e2 f6  |0D. .3%...^.*Z..|
        00000010  2d c4 58 5a 18 f6 2f 84  7c 0c 65 2d 0b 5b 52 d8  |-.XZ../.|.e-.[R.|
        00000020  c3 93 9c c1 02 20 60 f8  1a ff 6d a7 32 ad 98 db  |..... `...m.2...|
        00000030  30 09 8a 22 b0 f0 ed 2a  8d b3 e1 39 0c 2c 5a 55  |0.."...*...9.,ZU|
        00000040  6d a6 a8 b5 cd 79 01                              |m....y.|
       },
       ([]uint8) (len=33 cap=33) {
        00000000  03 c3 65 e2 ad 46 62 b9  85 d8 5f cc ec 19 bb d2  |..e..Fb..._.....|
        00000010  4c 8b 9b 50 30 32 e7 74  cb 2f bd 29 9e 2a bd e2  |L..P02.t./.).*..|
        00000020  8e                                                |.|
       }
      },
      Sequence: (uint32) 4294967295
     })
    },
    TxOut: ([]*wire.TxOut) (len=2 cap=2) {
     (*wire.TxOut)(0xc000c4c700)({
      Value: (int64) 1000,
      PkScript: ([]uint8) (len=34 cap=34) {
       00000000  51 20 83 78 40 60 9a fc  6d fa 06 d5 c7 ba 42 4a  |Q .x@`..m.....BJ|
       00000010  ef 46 27 eb d7 e3 d4 57  75 8d 45 9f ea f3 cb 47  |.F'....Wu.E....G|
       00000020  b9 84                                             |..|
      }
     }),
     (*wire.TxOut)(0xc000c4c720)({
      Value: (int64) 5782181,
      PkScript: ([]uint8) (len=22 cap=22) {
       00000000  00 14 a1 ed 73 84 02 c9  fd 4a b4 7a f1 88 b0 5d  |....s....J.z...]|
       00000010  f4 ac 7e 21 43 bf                                 |..~!C.|
      }
     })
    },
    LockTime: (uint32) 0
   }),
   WitnessUtxo: (*wire.TxOut)(0xc0003ea360)({
    Value: (int64) 5782181,
    PkScript: ([]uint8) (len=22 cap=22) {
     00000000  00 14 a1 ed 73 84 02 c9  fd 4a b4 7a f1 88 b0 5d  |....s....J.z...]|
     00000010  f4 ac 7e 21 43 bf                                 |..~!C.|
    }
   }),
   PartialSigs: ([]*psbt.PartialSig) <nil>,
   SighashType: (txscript.SigHashType) 0,
   RedeemScript: ([]uint8) <nil>,
   WitnessScript: ([]uint8) <nil>,
   Bip32Derivation: ([]*psbt.Bip32Derivation) <nil>,
   FinalScriptSig: ([]uint8) <nil>,
   FinalScriptWitness: ([]uint8) (len=108 cap=108) {
    00000000  02 48 30 45 02 21 00 8a  b0 9d 6f 17 2e 9a 98 6b  |.H0E.!....o....k|
    00000010  16 e6 2c 53 7d 1d a2 a2  e8 91 9c 99 23 4a 32 58  |..,S}.......#J2X|
    00000020  80 77 31 64 d8 e6 dd 02  20 67 83 53 bd 5f 7f d9  |.w1d.... g.S._..|
    00000030  0b b1 13 4b 6b 51 14 c8  a2 df 00 c7 d9 94 3f 46  |...KkQ........?F|
    00000040  06 63 ab 3b b8 cb f8 74  ae 01 21 02 bf bd 68 da  |.c.;...t..!...h.|
    00000050  15 02 f8 e6 94 c9 64 e2  0b 8d a0 19 51 e5 64 7f  |......d.....Q.d.|
    00000060  b2 b2 56 75 71 ef 29 dc  71 1e 80 a3              |..Vuq.).q...|
   },
   TaprootKeySpendSig: ([]uint8) <nil>,
   TaprootScriptSpendSig: ([]*psbt.TaprootScriptSpendSig) <nil>,
   TaprootLeafScript: ([]*psbt.TaprootTapLeafScript) <nil>,
   TaprootBip32Derivation: ([]*psbt.TaprootBip32Derivation) <nil>,
   TaprootInternalKey: ([]uint8) <nil>,
   TaprootMerkleRoot: ([]uint8) <nil>,
   Unknowns: ([]*psbt.Unknown) <nil>
  }
 },
 Outputs: ([]psbt.POutput) (len=2 cap=2) {
  (psbt.POutput) {
   RedeemScript: ([]uint8) <nil>,
   WitnessScript: ([]uint8) <nil>,
   Bip32Derivation: ([]*psbt.Bip32Derivation) <nil>,
   TaprootInternalKey: ([]uint8) <nil>,
   TaprootTapTree: ([]uint8) <nil>,
   TaprootBip32Derivation: ([]*psbt.TaprootBip32Derivation) <nil>
  },
  (psbt.POutput) {
   RedeemScript: ([]uint8) <nil>,
   WitnessScript: ([]uint8) <nil>,
   Bip32Derivation: ([]*psbt.Bip32Derivation) (len=1 cap=1) {
    (*psbt.Bip32Derivation)(0xc000c4c740)({
     PubKey: ([]uint8) (len=33 cap=33) {
      00000000  02 86 03 53 37 31 a0 73  5f e9 59 27 4d ea 66 6c  |...S71.s_.Y'M.fl|
      00000010  c5 18 20 8c 90 49 f4 14  b1 82 3a 74 8e 17 bc f7  |.. ..I....:t....|
      00000020  cb                                                |.|
     },
     MasterKeyFingerprint: (uint32) 0,
     Bip32Path: ([]uint32) (len=5 cap=8) {
      (uint32) 2147483734,
      (uint32) 2147483648,
      (uint32) 2147483648,
      (uint32) 1,
      (uint32) 2
     }
    })
   },
   TaprootInternalKey: ([]uint8) (len=32 cap=32) {
    00000000  86 03 53 37 31 a0 73 5f  e9 59 27 4d ea 66 6c c5  |..S71.s_.Y'M.fl.|
    00000010  18 20 8c 90 49 f4 14 b1  82 3a 74 8e 17 bc f7 cb  |. ..I....:t.....|
   },
   TaprootTapTree: ([]uint8) <nil>,
   TaprootBip32Derivation: ([]*psbt.TaprootBip32Derivation) (len=1 cap=1) {
    (*psbt.TaprootBip32Derivation)(0xc00003cd20)({
     XOnlyPubKey: ([]uint8) (len=32 cap=32) {
      00000000  86 03 53 37 31 a0 73 5f  e9 59 27 4d ea 66 6c c5  |..S71.s_.Y'M.fl.|
      00000010  18 20 8c 90 49 f4 14 b1  82 3a 74 8e 17 bc f7 cb  |. ..I....:t.....|
     },
     LeafHashes: ([][]uint8) {
     },
     MasterKeyFingerprint: (uint32) 0,
     Bip32Path: ([]uint32) (len=5 cap=8) {
      (uint32) 2147483734,
      (uint32) 2147483648,
      (uint32) 2147483648,
      (uint32) 1,
      (uint32) 2
     }
    })
   }
  }
 },
 Unknowns: ([]psbt.Unknown) <nil>
})

2023-01-03 15:34:34.185 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): transition states: BatchStateCommitted -> BatchStateBroadcast
2023-01-03 15:34:34.185 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): extracted finalized GenesisTx: (*wire.MsgTx)(0xc00071a3c0)({
 Version: (int32) 2,
 TxIn: ([]*wire.TxIn) (len=1 cap=1) {
  (*wire.TxIn)(0xc00056a0c0)({
   PreviousOutPoint: (wire.OutPoint) 82bc5a12120222de4114a2296ab8ed11be6641d4e59cdd176b3dba54162bf0a1:1,
   SignatureScript: ([]uint8) <nil>,
   Witness: (wire.TxWitness) (len=2 cap=2) {
    ([]uint8) (len=72 cap=72) {
     00000000  30 45 02 21 00 8a b0 9d  6f 17 2e 9a 98 6b 16 e6  |0E.!....o....k..|
     00000010  2c 53 7d 1d a2 a2 e8 91  9c 99 23 4a 32 58 80 77  |,S}.......#J2X.w|
     00000020  31 64 d8 e6 dd 02 20 67  83 53 bd 5f 7f d9 0b b1  |1d.... g.S._....|
     00000030  13 4b 6b 51 14 c8 a2 df  00 c7 d9 94 3f 46 06 63  |.KkQ........?F.c|
     00000040  ab 3b b8 cb f8 74 ae 01                           |.;...t..|
    },
    ([]uint8) (len=33 cap=33) {
     00000000  02 bf bd 68 da 15 02 f8  e6 94 c9 64 e2 0b 8d a0  |...h.......d....|
     00000010  19 51 e5 64 7f b2 b2 56  75 71 ef 29 dc 71 1e 80  |.Q.d...Vuq.).q..|
     00000020  a3                                                |.|
    }
   },
   Sequence: (uint32) 4294967295
  })
 },
 TxOut: ([]*wire.TxOut) (len=2 cap=2) {
  (*wire.TxOut)(0xc000970600)({
   Value: (int64) 1000,
   PkScript: ([]uint8) (len=34 cap=34) {
    00000000  51 20 c5 a8 80 5c 05 aa  48 4a 10 32 23 ed 17 66  |Q ...\..HJ.2#..f|
    00000010  dd 20 84 c0 67 b2 87 04  ca ee 52 51 5a f8 f3 01  |. ..g.....RQZ...|
    00000020  f4 d0                                             |..|
   }
  }),
  (*wire.TxOut)(0xc000970620)({
   Value: (int64) 5772931,
   PkScript: ([]uint8) (len=34 cap=34) {
    00000000  51 20 1e 1d fd 34 57 4a  a2 47 86 e0 73 b0 f5 3f  |Q ...4WJ.G..s..?|
    00000010  82 b9 2a 42 49 06 46 29  4b a0 ae ec 0c 1b e2 fb  |..*BI.F)K.......|
    00000020  47 4f                                             |GO|
   }
  })
 },
 LockTime: (uint32) 0
})

2023-01-03 15:34:34.188 [DBG] GRDN: Inspecting tx a7f6398606cf5249f2b722e6c622bd89a8ae5ba3883fbe1c48bec1f53c1f7954 for Taro address outputs
2023-01-03 15:34:39.214 [INF] GRDN: BatchCaretaker(02c8d4ae739d05c75393cb0e3f55644aaa4dc5cd05849cd26756783780887d8fb2): transition states: BatchStateBroadcast -> BatchStateBroadcast

@Roasbeef oddly enough, exact same behavior even when starting tarod with --batch-minting-interval="1s"

I keep getting the same error, even when I change the minting interval.
My LND commit hash is: c03de26dc
My Taro commit hash is: ddb0e0d
I have built LND using the command:
git checkout master && make && make install tags="autopilotrpc chainkit chainrpc invoicesrpc peersrpc routerrpc signrpc walletrpc watchtowerrpc wtclientrpc"

And I am using this command to mint:
tarocli assets mint --type normal --name "test asset" --supply 88 --enable_emission false --meta "test asset description" --skip_batch

Ok I think we found the issue with the batch tick w/o skip_batch, working on tests, then that should be resolved.
@snow884 your issue is with the CLI commands, you need to use an = instead of just a space. Here's a version that'll work:
tarocli assets mint --type=normal --name="test asset 2" --supply=88 --enable_emission=false --meta="test asset description" --skip_batch

@Roasbeef official documentation uses spaces though
tarocli assets mint --type normal --name fantasycoin --supply 100 --meta "fantastic money" --skip_batch typo?

The issue with the command above is that with the way the CLI library works, doing something like --enable_emission false, is actually the same as enable_emission=true (it's a bool flag, so it's off by default, setting that makes it true).
If you remove that and just drop it off, then things work properly.

@habibitcoin this should be fixed on master now - closing this issue but please re-open if the issue persists.
The default batch timer is 10 mintes.

Hmm, @jharveyb not sure this fix worked :/ running latest on main and still same behavior:
MacBook-Pro taro % tarocli assets mint --type normal --name habibtaro_usd_jan --supply 21000000 --meta "habibtaro.com_jan" --enable_emission true --skip_batch=true
{
    "batch_key": "0285127fca8f36e75b0508e6a6a561ab5db97003523f227596bc4f7be436a9b7a4"
}
MacBook-Pro taro % tarocli assets mint --type normal --name habibtaro_usd_jan_noem --supply 21000000 --meta "habibtaro.com_jan_noem" --enable_emission false --skip_batch true
{
    "batch_key": "0285127fca8f36e75b0508e6a6a561ab5db97003523f227596bc4f7be436a9b7a4"
}

Try with either "--enable-emission" or no emission flag. Writing true or false after is incorrect, the docs are still being updated.

Ayy that worked thank you!

authors: Roasbeef guggero habibitcoin jharveyb snow884

repo: lightninglabs/taro


text:
On-chain resolution flow ignores htlc interceptor settles

With the htlc interceptor API it is possible to settle intercepted htlcs with a preimage.
It seems possible though that the interceptor signals settle, but it turns out to be impossible to settle the htlc. One reason for this is that the peer went offline before the settle was fully locked in. The interceptor will not be aware of this and assume the htlc is indeed settled.
When the peer doesn't come online anymore, lnd will consider going to chain with the channel. This decision is made in the channel arbitrator and depends on the availability of the preimage. The channel arbitrator currently isn't aware of the settle signal given by the interceptor and will not go to chain even though it should.
When the htlc times out, the counterparty can claim back the htlc. The interceptor will never find out that this happened and keep assuming that the money is in the pocket.
Similarly the incoming onchain resolver needs the preimage in order to settle the htlc that the interceptor considers settled.

Related issue: https://github.com/lightningnetwork/lnd/issues/4910

Repro scenario:

Nodes A, B and C
Node A is patched with:

diff --git a/lnwallet/channel.go b/lnwallet/channel.go
index ac72852d5..2693c729c 100644
--- a/lnwallet/channel.go
+++ b/lnwallet/channel.go
@@ -5259,6 +5259,8 @@ func (lc *LightningChannel) SettleHTLC(preimage [32]byte,
 // log, and error is returned. Similarly if the preimage is invalid w.r.t to
 // the referenced of then a distinct error is returned.
 func (lc *LightningChannel) ReceiveHTLCSettle(preimage [32]byte, htlcIndex uint64) error {
+       return errors.New("NEVER SETTLE")
+
        lc.Lock()
        defer lc.Unlock()

Create invoice on node C with preimage P
Run htlc interceptor on node B and settle htlcs with hash H(P)
Pay invoice from node A

Then what happens is:

B intercepts and settles
A fails the channel and goes to chain because of the patch
Block is mined
B sees the force-close and spins up an htlcIncomingContestResolve.
More blocks are mined
B never queries the interceptor for the preimage and lets the htlc timeout, even though the interceptor settled it previously.

Another potential problem here is that after an lnd restart, the htlc interceptor may not be quick enough to register itself. When a link comes up and htlcs are replayed and the interceptor isn't there, lnd could fail back the htlc. Even though the interceptor settled it on an earlier run.

Another potential problem here is that after an lnd restart, the htlc interceptor may not be quick enough to register itself. When a link comes up and htlcs are replayed and the interceptor isn't there, lnd could fail back the htlc. Even though the interceptor settled it on an earlier run (but that settle never made it to the database for some reason).

We've had this happen to us. We have a changeset that adds a flag that registers the interceptor queue as soon as the node starts to avoid it. Whenever there's HTLCs that couldn't be properly resolved, on startup they get queued and when the interceptor propper is registered via RPC, it gets called with all the HTLCs in the queue. The changeset is rather small & simple, I can submit it's interesting enough to merge.

Created separated issue for startup race condition: https://github.com/lightningnetwork/lnd/issues/6161

I think the missing repro tag can be removed now

authors: Roasbeef champo joostjager

repo: lightningnetwork/lnd


text:
时间选择控件的优化

场景：希望使用时间选择控件选择年月日，比如2017-12-20。
当控件初始值为2017-12-20（y-m-d格式）的时候，会报错，错误如下：

图片中可以看到jquery-weui版本是1.2.0
当控件初始值为2017-12-20 00:00:00（y-m-d H:i:s格式）的时候，没有问题。
猜测是在分割时分秒的没有对时分秒是否存在做判断所出现的问题。
如果没有上述错误的情况，就可以通过下面代码去控制只选择年月日了。

另外，日历控件在选择年月日的时候，还是不如时间控件方便。特别是选择年的时候，如果出生日期在1980年的话，那么点年份就会点击很多次，很不方便。

可以自定义解析函数来解决，看源码自己改一下配置就可以了
$("#").datetimePicker({
times: function () {
return [
{values: ['']}
];
},
onChange: function (picker, values, displayValues) {
values[3]='';
},
parse: function (str) {
// 自定义解析函数
var t = str.split(this.datetimeSplit);
return t[0].split(/\D/).concat("");
}
});

谢谢：）


text:
Handles unknown bucket errors that don't require a response

Changes the handling of unknown bucket errors to never emit error
events. If the error is related to a request that does not need a
response the error is logged directly in the Request Handler.
By not emitting errors we avoid breaking the stream pipe which could
would end in new requests not being passed to the RequestHandler.

I've merged by mistake before CMS I'll rollback if we need to deploy before.

authors: CriGoT dafortune

repo: limitd/limitd


text:
direct jQuery handle to existing html

When I'm referencing with e.g. $(".my-custom-modal-content") to an existing html object in the html part I can open the modal window only once. On a second try I get this:
Uncaught TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node'.

Please include a jsfiddle in order for us to be able to reproduce the issue.
JSFiddle template: https://jsfiddle.net/limon/ad3quksn/

I'm closing this issue due to inactivity, add jsfiddle and reopen if needed.

Sorry I forgot about it 💃
Here is the example: https://jsfiddle.net/ad3quksn/39/
Just klick the button, then try it a second time

Thank you @baum1234 for the jsfiddle. The issue is fixed in v4.2.6

Thank you :)
Maybe allowing the same jQuery reference in titles? That way it would be possible to use e.g. a checkbox in the title that is created with javascript before.

Maybe allowing the same jQuery reference in titles? That way it would be possible to use e.g. a checkbox in the title that is created with javascript before.

I'm not sure right now this right now, it would be great if you create the new issue for this with maybe more argumentation when it could be needed.

I just found out that your fix removed all handles.
https://jsfiddle.net/ad3quksn/40/
Click on the button and then into the input

I just found out that your fix removed all handles.

I'm not sure I understand you. Could you please specify expected and actual behavior?

If you use the older version, before the fix, it was possible to click into the input and a datepicker (from jquery ui) showed up. Now nothing happens.
I changed the fiddle a little bit: https://jsfiddle.net/ad3quksn/41/
The input outside the hidden container is what I expect and in the hidden container is the actual behavior.

Yes, because of copying DOM element instead of moving it to the modal, you need to add the handler to add dynamically the datepicker to that input:
https://jsfiddle.net/ad3quksn/42/
The only thing I added is:
$('body').on('focus', ".swal2-modal .picker", function() {
  $(this).removeClass('hasDatepicker').datepicker();
});

But why did it work in the version before? Just use the version before and my code, everything worked fine.


text:
tag_autocomplete is searching against the database?

tag_autocomplete is searching against the database?
why my tag_autocomplete request always get empty response?

when I typing in search, I see it continuing send http request named, tag_autocomplete,
is it searching against the database?
why my suggestion response is always empty?

repo: lincanbin/Carbon-Forum


text:
S82 QSO Dataset

Adds the Stripe 82 QSO dataset from http://faculty.washington.edu/ivezic/cmacleod/qso_dr7/Southern.html, with the Light Curve files converted into a source parquet file, and the DB_QSO_S82.dat file converted into an object parquet file.
Adds some basic unit tests to validate the ability to load these datasets into TAPE (lsstseries).

unit tests are blocked by lsstseries v0.1.0, new TAPE release should resolve this.


text:
Can't Get 128 to Generate

Whether I store the JS locally or reference it from a local drive, I can't get any type of CODE128 barcodes to generate.  The first 2 barcodes look fine. The last one doesn't show anything, even when I use "CODE128", "CODE128 A", etc.
<!DOCTYPE HTML>

    <meta charset="UTF_8">
    <title>Test Page</title>

Barcode 3

Barcode 3

Barcode 4

        <svg id="barcode4"></svg>

Ignore. As soon as I ran it locally on web server it worked fine. Thanks! ;-) Very good library1

repo: lindell/JsBarcode


text:
Cacheable javadocs download task

Motivation:
Currently, javadoc offline links are cached under the gradle cache directory which may differ between environments.
For this reason, it has been proposed that the download task itself can be cacheable.
By doing so, the offline links may be used from the gradle cache (either local or remote).
Modifications:

Create a separate OfflineLinkDownloadTask task
Copy over logic for addOfflineLink, downloadListFile into OfflineLinkDownloadTask
Modify so that tasks with type Javadoc now depend on OfflineLinkDownloadTask
In order to use the downloaded url to file mappings, defined an output property OfflineLinkDownloadTask.url2File
Before any javadoc task is run, added the offlineLinks option for each OfflineLinkDownloadTask.url2File entry

Result:

javadoc is now cacheable even for remote builds

Sample task runs done from my local env:
https://ge.armeria.dev/c/dtzddibam7nh4/p3bxrunucik72/task-inputs

Note: I think we should wait until local/remote build caches are enabled before merging this PR

repo: line/armeria


text:
Treat RpcResponse.cause as log's cause if not explicitly set.

In GrpcService, I call responseContent but not endResponse, and as a result LoggingService never sees any exception. While I could call endResponse as well, it was very unintuitive to me that setting a failure response wasn't enough to log the error, and feels repetitive to have to call twice with the same exception. WDYT?

@anuraaga Suggestion sounds good to me. Would you mind adding a test case for this?

Thanks, @anuraaga !

authors: anuraaga trustin


text:
Support Arithmetic function CEILING

Backgrounds

Kotlin JDSL does not yet support an arithmetic function CEILING.

Objects

Support an arithmetic function CEILING.

Requirements

Creates ceiling() function in com.linecorp.kotlinjdsl.dsl.jpql.Jpql for supporting an arithmetic function CEILING.

Contribution

Please check if there is an assignee in this issue. And if it don't have an assignee, please leave comment to assign.
Please check the commit convention through the commitlint.config.js file. The commit  convention also described in the PR template.
When you use intellij, please set the code style through the .editorconfig file.
Please create the PR for develop as the base branch.
If you have any questions, please leave comment in Kotlin-JDSL Discord Channel in LINE Open Source

Can I contribute to this issue?

Hi esperar!
I assigned this issue to you. Thank you for your help!

authors: esperar shouwn

repo: line/kotlin-jdsl


text:
Update Logo on Website

yeah doesnt need further explaining

Sure! Thank you! :)

authors: Jomyy lujjjh

repo: linearmouse/linearmouse


text:
Better image sampling

Constrains image sampling to the actual atlas region for a given image and adds a half pixel adjustment to sample from the pixel center.
Addresses #719 and maybe #656
Example 2x2 image with red, blue, cyan and magenta pixels:

@dfrg can I adopt this PR to get it over the finish line?

If you have the bandwidth, please feel free. I do have the fine code to handle extend modes and nearest neighbor sampling but it’s not plumbed through. Would you like me to push that to this branch?

If it's not plumbed through yet, I think a follow-up draft PR would be better. But if you want to make that PR now, and let me do the rebase, that would be fine by me.

I’m not by a computer at the moment so if you’d like to just push this one through, I’ll send a follow up later.

@dfrg requesting your review on the GPU side code. I'll wire up the tests tomorrow.

Removal of clamp LGTM but Raph was fairly insistent on only doing texture loads when area[i] != 0.

And that's why we ask for review :)

One thing I notice is that there's an apparent visual discontinuity along the boundary points, i.e. where we move from sampling one set of pixels to sampling a different set of pixels.
That's especially visible in the cyan parts in your example image. I presume that's an expected artifact of bilinear filtering?

One thing I notice is that there's an apparent visual discontinuity along the boundary points, i.e. where we move from sampling one set of pixels to sampling a different set of pixels.
That's especially visible in the cyan parts in your example image. I presume that's an expected artifact of bilinear filtering?

Indeed, particularly in this case where we’re upsampling a 2x2 image 300x.
Thanks for pushing this through!

authors: DJMcNab dfrg

repo: linebender/vello


text:
UI Buttons is not working in wherehows 1.0

Some of the ui button is not working. ETL job was successful but when i am trying to add owner or comment i am getting js errors.
Add owner:
Uncaught (in promise) TypeError: Cannot read property 'userEntitiesMaps' of undefined
    at wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
    at <anonymous>
(anonymous) @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
Promise rejected (async)
r @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97186
updateDataset @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97373
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97369
onQueryChanged @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97612
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97762
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97761
flush @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96695
trigger @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96686
setQuery @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96911
onInput @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96868
proxy @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5249
dispatch @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9489
elemData.handle @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9301
wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7 Uncaught (in promise) TypeError: Cannot read property 'userEntitiesMaps' of undefined
    at wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
    at <anonymous>
(anonymous) @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
Promise rejected (async)
r @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97186
updateDataset @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97373
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97369
onQueryChanged @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97612
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97762
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97761
flush @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96695
trigger @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96686
setQuery @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96911
onInput @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96868
proxy @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5249
dispatch @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9489
elemData.handle @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9301
wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7 Uncaught (in promise) TypeError: Cannot read property 'userEntitiesMaps' of undefined
    at wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
    at <anonymous>
(anonymous) @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
Promise rejected (async)
r @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97186
updateDataset @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97373
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97369
onQueryChanged @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97612
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97762
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97761
flush @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96695
trigger @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96686
setQuery @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96911
onInput @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96868
proxy @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5249
dispatch @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9489
elemData.handle @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9301
wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7 Uncaught (in promise) TypeError: Cannot read property 'userEntitiesMaps' of undefined
    at wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
    at <anonymous>
(anonymous) @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
Promise rejected (async)
r @ wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97186
updateDataset @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97373
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
update @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97369
onQueryChanged @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97612
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97762
reverseArgs @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96394
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5117
each @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96392
(anonymous) @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:97761
flush @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96695
trigger @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96686
setQuery @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96911
onInput @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:96868
proxy @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:5249
dispatch @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9489
elemData.handle @ vendor-5cd4a04843eff9daa8f4c3209720659e.js:9301
wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7 Uncaught (in promise) TypeError: Cannot read property 'userEntitiesMaps' of undefined
    at wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:7
    at <anonymous>

Add comment:
Uncaught TypeError: Cannot read property 'replace' of undefined
    at Class.create (wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:1)
    at Class.send (vendor-5cd4a04843eff9daa8f4c3209720659e.js:52089)
    at Class.superWrapper [as send] (vendor-5cd4a04843eff9daa8f4c3209720659e.js:51836)
    at vendor-5cd4a04843eff9daa8f4c3209720659e.js:25424
    at Object.flaggedInstrument (vendor-5cd4a04843eff9daa8f4c3209720659e.js:31764)
    at vendor-5cd4a04843eff9daa8f4c3209720659e.js:25423
    at Backburner.run (vendor-5cd4a04843eff9daa8f4c3209720659e.js:15274)
    at Object.run (vendor-5cd4a04843eff9daa8f4c3209720659e.js:35472)
    at ActionState.handler (vendor-5cd4a04843eff9daa8f4c3209720659e.js:25403)
    at HTMLButtonElement.<anonymous> (vendor-5cd4a04843eff9daa8f4c3209720659e.js:53172)

Watch dataset:
wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:2 Uncaught TypeError: Cannot read property 'id' of undefined
    at Class.watch (wherehows-web-3b06ffa5dd68513c4510b1a3ee340af7.js:2)
    at Class.send (vendor-5cd4a04843eff9daa8f4c3209720659e.js:52089)
    at Class.superWrapper [as send] (vendor-5cd4a04843eff9daa8f4c3209720659e.js:51836)
    at vendor-5cd4a04843eff9daa8f4c3209720659e.js:25424
    at Object.flaggedInstrument (vendor-5cd4a04843eff9daa8f4c3209720659e.js:31764)
    at vendor-5cd4a04843eff9daa8f4c3209720659e.js:25423
    at Backburner.run (vendor-5cd4a04843eff9daa8f4c3209720659e.js:15274)
    at Object.run (vendor-5cd4a04843eff9daa8f4c3209720659e.js:35472)
    at ActionState.handler (vendor-5cd4a04843eff9daa8f4c3209720659e.js:25403)
    at HTMLElement.<anonymous> (vendor-5cd4a04843eff9daa8f4c3209720659e.js:53172)

I was also getting the same error. I checked the whole flow. The problem was that there is no csrf token in the frontend. So what i did is in the respective js files I set token as ''(empty string).
This worked for me. I know this is a hack but this was the only way to get it working for that time

Dear issue owner,
Thanks for your interest in WhereHows. We have recently announced DataHub which is the rebranding of WhereHows. LinkedIn improved the architecture of WhereHows and rebranded WhereHows into DataHub and replaced its metadata infrastructure in this direction. DataHub is a more advanced and improved metadata management product compared to WhereHows.
Unfortunately, we have to stop supporting WhereHows to better focus on DataHub and offer more help to DataHub users. Therefore, we will drop all issues related to WhereHows and will not accept any contribution for it. Active development for DataHub has already started on datahub branch and will continue to live in there until it's finally merged to master and project is renamed to DataHub.
Please check the datahub branch to get familar with DataHub.
Best,
DataHub team

authors: Ash-Mishra keremsahin1 mpostument

repo: linkedin/WhereHows


text:
Support markdown for glossary term descriptions

Describe the solution you'd like
I would like to be able view glossary term descriptions in mardkown
Describe alternatives you've considered
n/a
Additional context
n/a

Hi folks! I've added this to our new feature request portal - https://feature-requests.datahubproject.io/b/User-Experience/p/business-glossary-markdown-support

We'll close out this issue in GitHub & rely on engagement with the request portal post above. Feel free to reach out to me on DataHub Slack with any questions!

authors: gabe-lyons maggiehays

repo: linkedin/datahub


text:
Support for running test harness on Azkaban

Added a class to enable running the test harness on Azkaban. The class reads a properties file hardcoded to testharness.gobblin.azkaban.properties in the working directory. This file may be used to run different configurations of tests using the Test Harness.

Minor comment, can you also do a git pull and merge. There were some updates to gobblin-test-harness to fix a bunch of the license headers.

LGTM!

authors: sahilTakiar suvodeep-pyne

repo: linkedin/gobblin


text:
Hive registration initial commit

This is the initial commit for Hive registration. It mainly contains interfaces, abstract classes, base implementations, as well as the main class HiveRegister.

HiveRegister performs Hive registration given a HiveSpec, which specifies which path, which db, which table, etc., to register.  There are several extensions to HiveSpec, including HiveSpecWithPredicates, HiveSpecWithPreActivities and HiveSpecWithPostActivities. A base implementation SimpleHiveSpec is included.

A HiveSpec is generated by a HiveRegistrationPolicy given a Path. A base implementation HiveRegistrationPolicyBase is included.

To do Hive registration, a StorageDescriptor and some schema properties are often required. These are managed by HiveStorageDescriptorManager and HiveSchemaManager.

@sahilTakiar @ydai1124 can you review?

@sahilTakiar updated 45d36e8

@sahilTakiar @ydai1124 @cwsteinbach updated 99035f7
Main changes:

Use a pool of HiveMetaStoreClients instead of a single HiveMetaStoreClient, because HiveMetaStoreClient doesn't seem to support concurrent requests.
Added a striped lock class (HiveStripedLocks) as suggested by @cwsteinbach
When creating a table/partition, if the table/partition already exists, it checks whether the table or partition needs to be altered (needToUpdateTable and needToUpdatePartition). For example, update is needed if there's a schema change. If so it alters the table or partition.
Addressed other comments.

@sahilTakiar @ydai1124 updated 7855bf7

A few more minor comments, overall it looks good.

LGTM


text:
Could not resolve dependencies for project org.linlinjava:litemall-all:jar:0.1.0: The following artifacts could not be resolved: org.linlinjava:litemall-core:jar:0.1.0, org.linlinjava:litemall-db:jar:0.1.0, org.linlinjava:litemall-wx-api:jar:0.1.0, org.linlinjava:litemall-admin-api:jar:0.1.0: Failure to find org.linlinjava:litemall-core:jar:0.1.0 in http://maven.aliyun.com/nexus/content/repositories/central/ was cached in the local repository, resolution will not be reattempted until the update interval of alimaven has elapsed or updates are forced ->

构建时出现上面错误  貌似时all 没有打包

请仔细按照快速启动文档再次尝试，这里应该没有问题。
如果还是有问题，请给出详细步骤怎么重现。

authors: hemingyang linlinjava

repo: linlinjava/litemall


text:
Reset root password should have no disk option when there is only one disk

At this point we mostly try not change fields to make it less difficult when their contents change. Closing.

repo: linode/manager


text:
fix render of required property attribute in docs

Coverage increased (+0.03%) to 71.375% when pulling 4386c87fff91c2814f3ce4269786c14821085028 on displague:fix-required into edd99dc4e1be5ab8190f243c3dbf8b830716255e on linode:master.

Change base to release 14.2 instead?

authors: coveralls displague eatonphil


text:
Override bootstrap default column breakpoints

Closes #637. Could probably still use some tweaking but it's an improvement and demonstrates the concept.

Coverage remained the same at 83.973% when pulling 74e27045cf19c24af8ea55472b17623a0474684f on eatonphil:override-bootstrap-default-breakpoints into 965c740fe753be12bdb9f3f755afe94a0a79fd20 on linode:master.

authors: coveralls eatonphil


text:
代码中的单词拼写错误较多，看着别扭啊。。。

intance=>instance
failse=>failed?
能否修改一下？

好，多谢提醒

failse=>failed?
第一个改了，这个没找见在哪

搜索 setDisplayCaseFailse()

authors: axeon lipangit

repo: lipangit/JieCaoVideoPlayer


text:
Please ass EU flag

Missing european union flag

https://github.com/lipis/flag-icon-css/issues?utf8=✓&q=+eu

authors: dimafern lipis

repo: lipis/flag-icon-css


text:
incrementBy and startWith column attributes produce incorrect autoincrement clause

Search first

[X] I searched and no similar issues were found

Description
Incorrect autoincrement clause when using the following construction:
        <createTable tableName="test_table">
            <column name="id" type="integer" autoIncrement="true" startWith="100" incrementBy="5"/>
        </createTable>

It results in error with such cause:

syntax error at or near ","
Position: 92 [Failed SQL: (0) CREATE TABLE public.test_table (id INTEGER GENERATED BY DEFAULT AS IDENTITY (START WITH 100, INCREMENT BY 5))],

which says that there should be no comma between those START WITH 100 and INCREMENT BY 5.
Steps To Reproduce
Execute the following changelog:
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
    <changeSet author="me" id="test"
               logicalFilePath="empty">
        <createTable tableName="test_table">
            <column name="id" type="integer" autoIncrement="true" startWith="100" incrementBy="5"/>
        </createTable>
    </changeSet>
</databaseChangeLog>

Expected/Desired Behavior
The table should be created.
Liquibase Version
3.6.3 but seems to be reproducible on 4.21.1 as well
Database Vendor & Version
Postgres 15
Liquibase Integration
maven
Liquibase Extensions
No response
OS and/or Infrastructure Type/Provider
No response
Additional Context
I guess the issue is related to this code: https://github.com/liquibase/liquibase/blob/master/liquibase-core/src/main/java/liquibase/database/AbstractJdbcDatabase.java#L595
Are you willing to submit a PR?

[ ] I'm willing to submit a PR (Thank you!)

Hello @eugene-ivakhno , thank you for providing the section of code that's causing the error, that was really helpful!
It seems like that function is general for all databases, and currently this appears to be affecting only Postgres (it works fine with MSSQL, and MySQL simply doesn't support the incrementBy clause).
For this bug to be fixed, a Postgres-specific function should be created in order to override the general function.
Would you like to submit a PR? If you would, and you need help, just ask and someone from our team will get in contact with you.
Thanks again!

Hello,
I am facing a similar issue related to a table creation on MariaDB,
I'm using the Spring boot latest version 3.2.1 and the bug is potentially related to this upgrade I did last week.
Here is my changeSet:
 <changeSet id="create table xxx" author="nid">         <createTable tableName="xxx">             <column name="id" type="bigint"><constraints primaryKey="true" nullable="false"/></column>             <column name="reference" type="varchar(64)"/>             <column name="description" type="varchar(128)"/>         </createTable>         <addAutoIncrement columnName="id" columnDataType="bigint" incrementBy="1" tableName="xxx"/>         <createIndex tableName="xxx" indexName="idx_xxx_reference">             <column name="reference" type="varchar(255)"/>         </createIndex>         <addForeignKeyConstraint constraintName="fk_xxx_other"                                  baseTableName="xxx" baseColumnNames="other"                                  referencedTableName="other" referencedColumnNames="id"/>     </changeSet>
The error message is: incrementBy="1" no more accepted MariaDB
Of course, I can remove this parameter, as MariaDB considers 1 as the default incrementation step for the auto-increment index, but this seems pretty new for me, as it was still working last week.
Is there no way to implement this parameter - as it was supposed to be as described here
Thank you in advance

authors: eugene-ivakhno nicoesiea tati-qalified

repo: liquibase/liquibase


text:
[bug] cuda_convnet not found with mode=DebugMode

Not sure if this is Theano or Pylearn2 bug. Here it goes:
On a fresh install (or if you clean the cached compilation results in ~/.theano) following flags will prevent me from training a MLP model:
import os
os.environ['THEANO_FLAGS'] ='optimizer=None,mode=DebugMode,allow_gc=False,exception_verbosity=high,device=gpu,floatX=float32'

The process fails to build cuda code with this error:
/usr/bin/ld: cannot find -lcuda_convnet

Relevant frames:
  File "~/pylearn2/pylearn2/models/mlp.py", line 488, in __init__
    self._update_layer_input_spaces()
  File "~/pylearn2/pylearn2/models/mlp.py", line 553, in _update_layer_input_spaces
    layers[0].set_input_space(self.get_input_space())
  File "~/pylearn2/pylearn2/sandbox/rnn/models/mlp_hook.py", line 337, in outer
    return set_input_space(self, input_space)
  File "~/pylearn2/pylearn2/models/maxout.py", line 724, in set_input_space
    dummy_p = dummy_p.eval()
  File "~/theano/theano/gof/graph.py", line 413, in eval
    self._fn_cache[inputs] = theano.function(inputs, self)
  File "~/theano/theano/compile/function.py", line 266, in function
    profile=profile)
  File "~/theano/theano/compile/pfunc.py", line 511, in pfunc
    on_unused_input=on_unused_input)
  File "~/theano/theano/compile/function_module.py", line 1468, in orig_function
    defaults)
  File "~/theano/theano/compile/debugmode.py", line 2424, in create
    _fn, _i, _o = self.linker.make_thunk(input_storage=input_storage)
  File "~/theano/theano/gof/link.py", line 559, in make_thunk
    output_storage=output_storage)[:3]
  File "~/theano/theano/compile/debugmode.py", line 1686, in make_all
    output_storage=node_output_storage)
  File "~/theano/theano/gof/cc.py", line 1072, in make_thunk
    keep_lock=keep_lock)
  File "~/theano/theano/gof/cc.py", line 1014, in __compile__
    keep_lock=keep_lock)
  File "~/theano/theano/gof/cc.py", line 1441, in cthunk_factory
    key=key, lnk=self, keep_lock=keep_lock)
  File "~/theano/theano/gof/cmodule.py", line 1075, in module_from_key
    module = lnk.compile_cmodule(location)
  File "~/theano/theano/gof/cc.py", line 1353, in compile_cmodule
    preargs=preargs)
  File "~/theano/theano/sandbox/cuda/nvcc_compiler.py", line 423, in compile_str
    'for cmd', ' '.join(cmd))

the command that was issued:
/usr/local/cuda-6.5/bin/nvcc -shared -O3 -use_fast_math -arch=sm_30 -m64
    -Xcompiler-fno-math-errno,-Wno-unused-label,-Wno-unused-variable,-Wno-write-strings,-DCUDA_NDARRAY_CUH=b0c165044f8fd1e0f58745b1202dab6e,-D NPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION,-fPIC
    -Xlinker -rpath,~/.theano/compiledir_Linux-3.13--generic-x86_64-with-debian-jessie-sid-x86_64-2.7.9-64/cuda_ndarray
    -Xlinker -rpath,/usr/local/cuda-6.5/lib
    -Xlinker -rpath,/usr/local/cuda-6.5/lib64
    -I~/.theano/compiledir_Linux-3.13--generic-x86_64-with-debian-jessie-sid-x86_64-2.7.9-64/cuda_ndarray
    -I/usr/local/cuda-6.5/include
    -I~/pylearn2/pylearn2/sandbox/cuda_convnet/
    -I~/anaconda/lib/python2.7/site-packages/numpy/core/include
    -I~/anaconda/include/python2.7
    -I~/theano/theano/sandbox/cuda
    -o ~/.theano/compiledir_Linux-3.13--generic-x86_64-with-debian-jessie-sid-x86_64-2.7.9-64/tmp08k3eU/9da75eac8cce435a25905399484c7f9d.so mod.cu
    -L~/.theano/compiledir_Linux-3.13--generic-x86_64-with-debian-jessie-sid-x86_64-2.7.9-64/cuda_ndarray
    -L~/.theano/compiledir_Linux-3.13--generic-x86_64-with-debian-jessie-sid-x86_64-2.7.9-64/cuda_convnet
    -L~/anaconda/lib
    -lpython2.7 -lcudart -lcublas -lcuda_ndarray -lcuda_convnet

and ls ~/.theano/compiledir_Linux-3.13--generic-x86_64-with-debian-jessie-sid-x86_64-2.7.9-64 returns:
cuda_ndarray  cutils_ext  __init__.py  lazylinker_ext  tmp_BgUSu  tmpGZiioy  tmpLzQSKt  tmpwIsazn  tmpxsY8_t

It obviously expects libcuda_convnet.so in cuda_convnet directory but those are not generated.
Following flags will work:
import os
os.environ['THEANO_FLAGS'] ='optimizer=fast_compile,exception_verbosity=high,device=gpu,floatX=float32'

and I can go back to initial set of flags, as now there is a cuda_convnet directory with a libcuda_convnet.so inside.
I'm using latest source for both Theano and Pylearn2.

Thanks for the report. It looks like a problem in DebugMode, which tries to compiles the C thunk of the pooling node before calling the make_thunk method of the op itself, which is supposed to call convnet_available() to ensure it has already been compiled.
The long-term fix would be to get rid of the special linker used by DebugMode, and make it behave like the regular Mode.
Before that, I'll try to see if we can make DebugMode call make_thunk in the right place.
In the short term, the work-around you found (manually filling the cache by launching an experiment without DebugMode) is probably the best you can get.

I tried to address that in https://github.com/Theano/Theano/pull/2729, it was easier than I expected...
It would be great if you could test that branch and check that it solves your problem.
Thanks for the report!

I will but my spot instance is rather busy right now.
As soon as they kick me out and I have to instantiate a new one I will test it.
Thanks.
PS
I see that there is a comment on your PR. Is it relevant to my test?

THe PR is merged. So just update Theano to test it again.
The comment was about old comment that was moved in the PR. It wasn't
affecting you.
On Fri, Apr 3, 2015 at 8:04 AM, Nicu Tofan notifications@github.com wrote:

I will but my spot instance is rather busy right now.
As soon as they kick me out and I have to instantiate a new one I will
test it.
Thanks.
PS
I see that there is a comment on your PR. Is it relevant to my test?
—
Reply to this email directly or view it on GitHub
https://github.com/lisa-lab/pylearn2/issues/1463#issuecomment-89267637.

authors: TNick lamblin nouiz


text:
Improve French results - system prompt

Planning some changes to the system prompt this morning to:

improve French (and other language) results by instructing the answer service to translate the question into English before deriving the answer in English - Ryan suggested this idea
the instruction to translate back into Canada.ca style French is already there
to store any found possible citations in a scratch pad while it derives the answer (it is currently ignoring possible French citation links that are right in the scenarios and/or updates files). This may help the English as well.
to use the search results as a possible source of citation links (again may help the FR more than EN)
to balance search results against system prompt instructions better
to rebalance away from one sentence answers - I tuned the prompt last week to reduce long run-on sentences and hallucinations and it's flipped the other way to too-frequent one sentence answers.
Re-order system prompt so role is first (am going to add this to the systemPrompt builder file rather than create another separate file as the role definition seems to be working well and hasn't changed in ages)

Merged.
Still seeing "Je vais vérifier l'information sur le renouvellement de passeport avec un changement de nom" which it is NOT supposed to do. Dang. Will have to come back to this and try again.

French responses are much improved and expert confirms that our approach is likely most effective- that translating into English first and the translating answer back into original language is best for LLM.

repo: lisafast/react-answers