ps crashes

Hi @landley
We found that ‘PS’ accidentally crashed when doing some automated tests

Build: Android 10.0
https://android.googlesource.com/platform/external/toybox/+log/d362c3db9f259110d485b908cd2874141e736432

Stack:
pid: 31459, tid: 31459, name: ps >>> ps <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
x0<PHONE_NUMBER>917188 x1 0000005dc1b16052 x2 0000007ff72b9b90 x3 0000005dc1b7ff24
x4<PHONE_NUMBER>000008 x5<PHONE_NUMBER>008000 x6 636f675e6673ff5c x7 7f7f7f7f7f7f7f7f
x8<PHONE_NUMBER>000000 x9<PHONE_NUMBER>000008 x10 0000007ff72b9b90 x11<PHONE_NUMBER>000002
x12 0000007ff72b94fa x13 000000756f1635a8 x14<PHONE_NUMBER>000010 x15 000000756f16339a
x16 000000756f168810 x17<PHONE_NUMBER>000000 x18<PHONE_NUMBER>5d4000 x19 000000756f163470
x20 0000005dc1b16054 x21<PHONE_NUMBER>000000 x22<PHONE_NUMBER>000000 x23<PHONE_NUMBER>917188
x24 0000007ff72b9500 x25 00000000ffffffff x26<PHONE_NUMBER>00002a x27<PHONE_NUMBER>000000
x28 0000005dc1b16054 x29 0000007ff72b9a80

Stack Trace:
RELADDR FUNCTION FILE:LINE
00000000000ab50c __vfprintf+1576 bionic/libc/stdio/vfprintf.cpp:?
v--------------> vfprintf bionic/libc/stdio/stdio.cpp:998
00000000000c8dd4 printf+164 bionic/libc/stdio/stdio.cpp:898
0000000000061f08 show_ps+360 external/toybox/toys/posix/ps.c:684
0000000000062b90 get_ps+2636 external/toybox/toys/posix/ps.c:978
000000000002a2e8 dirtree_handle_callback+36 external/toybox/lib/dirtree.c:112
000000000002a3f0 dirtree_recurse+124 external/toybox/lib/dirtree.c:156
000000000002a340 dirtree_handle_callback+124 external/toybox/lib/dirtree.c:115
0000000000061520 ps_main+1016 external/toybox/toys/posix/ps.c:1351
0000000000030a18 toy_exec_which+76 external/toybox/main.c:169
0000000000030624 toybox_main+44 external/toybox/main.c:190
0000000000030af0 main+112 external/toybox/main.c:250
000000000006a050 __libc_init+108 bionic/libc/bionic/libc_init_dynamic.cpp:136

 683     if (TT.tty) width -= draw_trim(out, pad, len);
 684     else width -= printf("%*.*s", pad, len, out);
 685     if (!abslen) putchar('+');
 686     if (!width) break;

It may caused by 'out'  was NULL
Could "string_field" return NULL sametimes, and could we add if(out == NULL) to prevent it ?
Thanks
Raymond

do you have the symbols for that OS build so you can see where in printf this is dying? bionic's printf() replaces nullptr with "(null)" internally, so it's not what you think it is.
(rather than just assume that, i've added these tests to the bionic tests, and they pass:
+TEST(STDIO_TEST, printf_NULL) {
+  char buf[128];
+  char* null = nullptr;
+  EXPECT_EQ(4, snprintf(buf, sizeof(buf), "<%*.*s>", 2, 2, null));
+  EXPECT_STREQ("<(n>", buf);
+  EXPECT_EQ(8, snprintf(buf, sizeof(buf), "<%*.*s>", 2, 8, null));
+  EXPECT_STREQ("<(null)>", buf);
+  EXPECT_EQ(10, snprintf(buf, sizeof(buf), "<%*.*s>", 8, 2, null));
+  EXPECT_STREQ("<      (n>", buf);
+  EXPECT_EQ(10, snprintf(buf, sizeof(buf), "<%*.*s>", 8, 8, null));
+  EXPECT_STREQ("<  (null)>", buf);
+}

interestingly, glibc 2.28 gets two of them wrong:
<  >
<(null)>
<        >
<  (null)>

but that's still not a null pointer dereference.)

I try to disassemble libc.so I used and found  __vfprintf+1576  was ab50c and I am trying to found the  releated cpp source
  ab50c:   b9400116    ldr w22, [x8]

b4fc:   91002109    add x9, x8, #0x8
   ab500:   f9000149    str x9, [x10]
   ab504:   1100056b    add w11, w11, #0x1
   ab508:   f90057eb    str x11, [sp,#168]
   ab50c:   b9400116    ldr w22, [x8]
   ab510:   f9405ff9    ldr x25, [sp,#184]
        if (width >= 0) goto rflag;
   ab514:   36ffe5d6    tbz w22, #31, ab1cc <__vfprintf+0x2e8>
   ab518:   320103e8    orr w8, wzr, #0x80000000
        if (width == INT_MIN) goto overflow;
   ab51c:   6b0802df    cmp w22, w8
   ab520:   54010da0    b.eq    ad6d4 <__vfprintf+0x27f0>
        width = -width;
   ab524:   4b1603f6    neg w22, w22
        flags |= LADJUST;
   ab528:   321e0231    orr w17, w17, #0x4
   ab52c:   17ffff27    b   ab1c8 <__vfprintf+0x2e4>
          if (argtable == nullptr) {
   ab530:   f940bbe8    ldr x8, [sp,#368]
   ab534:   f9405ff9    ldr x25, [sp,#184]
   ab538:   2a1403e9    mov w9, w20

given the tbz is checking the top bit of w22, that faulting ldr should be loading width. in my local libc.so, the value in x8 comes from these earlier instructions:
     59c:       f94043ea        ldr     x10, [sp,#128]
     5a0:       f9400148        ldr     x8, [x10]

(i don't understand the double indirection there given that width is just a local though.)
weird. you said you'd seen this in automated testing --- have you seen it more than once?

@enh-google
We have met these issue about 5 times,  4 times crash in vfprintf , 1 times in svfscanf another crash stack is following
0000000000cb494  __svfscanf+4120     = cb494
  cb464:   362ffd16    tbz w22, #5, cb404 <__svfscanf+0xf88>
   cb468:   f9401fe8    ldr x8, [sp,#56]
   cb46c:   b9800108    ldrsw   x8, [x8]
   cb470:   36f800c8    tbz w8, #31, cb488 <__svfscanf+0x100c>
   cb474:   f9401fea    ldr x10, [sp,#56]
   cb478:   11002109    add w9, w8, #0x8
   cb47c:   7100013f    cmp w9, #0x0
   cb480:   b9000149    str w9, [x10]
   cb484:   5400026d    b.le    cb4d0 <__svfscanf+0x1054>
   cb488:   f9400328    ldr x8, [x25]
   cb48c:   91002109    add x9, x8, #0x8
   cb490:   f9000329    str x9, [x25]
   cb494:   f9400108    ldr x8, [x8]
   cb498:   b94047e9    ldr w9, [sp,#68]
   cb49c:   f9000100    str x0, [x8]
          nassigned++;

Searching for native crashes in<EMAIL_ADDRESS>Reading symbols from ../pscrash/system_symbol_file/symbols
Revision: '0'
pid: 22492, tid: 22492, name: ps  >>> ps <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
    x0<PHONE_NUMBER>000000  x1<PHONE_NUMBER>000000  x2<PHONE_NUMBER>00000a  x3  3a516769000a3020
    x4<PHONE_NUMBER>000018  x5<PHONE_NUMBER>000070  x6  39506667ff092f1f  x7  7f7f7f7f7f7f7f7f
    x8<PHONE_NUMBER>000000  x9<PHONE_NUMBER>000008  x10<PHONE_NUMBER>000001  x11<PHONE_NUMBER>00000a
    x12<PHONE_NUMBER>000000  x13 0000007ee306922e  x14<PHONE_NUMBER>000010  x15 0000007ee311639a
    x16 0000007ee311c6c8  x17 0000007ee30bda58  x18 0000007ee42f2000  x19<PHONE_NUMBER>000001
    x20 0000007ffbde45e8  x21 0000007ee3069132  x22<PHONE_NUMBER>000010  x23 0000007ffbde423c
    x24 0000005bea6f3fd1  x25 0000007ffbde45c0  x26<PHONE_NUMBER>000001  x27 0000007ffbde423c
    x28 00000000fffe5fff  x29 0000007ffbde45b0
Using arm64 toolchain from: ./prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/

Stack Trace:
  RELADDR           FUNCTION                     FILE:LINE
<PHONE_NUMBER>0cb494  __svfscanf+4120              bionic/libc/stdio/vfscanf.cpp:?
<PHONE_NUMBER>0b7f70  vsscanf+148                  bionic/libc/upstream-openbsd/lib/libc/stdio/vsscanf.c:57
<PHONE_NUMBER>0c9604  sscanf+108                   bionic/libc/stdio/stdio.cpp:985
<PHONE_NUMBER>0622e0  get_ps+412                   external/toybox/toys/posix/ps.c:749
<PHONE_NUMBER>02a2e8  dirtree_handle_callback+36   external/toybox/lib/dirtree.c:112
<PHONE_NUMBER>02a3f0  dirtree_recurse+124          external/toybox/lib/dirtree.c:156
<PHONE_NUMBER>02a340  dirtree_handle_callback+124  external/toybox/lib/dirtree.c:115
<PHONE_NUMBER>061520  ps_main+1016                 external/toybox/toys/posix/ps.c:1351
<PHONE_NUMBER>030a18  toy_exec_which+76            external/toybox/main.c:169
<PHONE_NUMBER>030624  toybox_main+44               external/toybox/main.c:190
<PHONE_NUMBER>030af0  main+112                     external/toybox/main.c:250
<PHONE_NUMBER>06a050  __libc_init+108              bionic/libc/bionic/libc_init_dynamic.cpp:136

Stack Data:
  ADDR              VALUE     FUNCTION  FILE:LINE
  0000007ffbde4158  0000007ffbde423c    [stack]
  0000007ffbde4168  0000007ffbde45c0    [stack]
  0000007ffbde4178  0000007ffbde423c    [stack]
  0000007ffbde4190  0000007ffbde45e8    [stack]
  0000007ffbde41a0  0000007ffbde45b0    [stack]
  0000007ffbde41b0  0000007ffbde4a50    [stack]
  0000007ffbde41b8  0000007ffbde45c8    [stack]
  0000007ffbde41c0  0000007ffbde4441    [stack]
  0000007ffbde41c8  0000007ffbde4449    [stack]
  0000007ffbde41d0  0000007ffbde423d    [stack]
  0000007ffbde41d8  0000007ffbde45c0    [stack]
  0000007ffbde41e8  0000007ffbde45d8    [stack]
  0000007ffbde41f8  0000007ffbde439d    [stack]
  0000007ffbde4208  0000007ffbde4a58    [stack]
  0000007ffbde4220  0000007ffbde4814    [stack]
  0000007ffbde4610  0000007ffbde46e0    [stack]
  0000007ffbde4740  0000007ffbde47c0    [stack]
  0000007ffbde4750  0000007ffbde4860    [stack]
  0000007ffbde4758  0000007ffbde47f0    [stack]
  0000007ffbde48a0  0000007ffbde48f8    [stack]
  0000007ffbde48b0  0000007ffbde48d0    [stack]
  0000007ffbde4a20  0000007ffbde4a60    [stack]
  0000007ffbde4a60  0000007ffbde4a90    [stack]
  0000007ffbde4a90  0000007ffbde4b60    [stack]
  0000007ffbde4b18  0000007ffbde5e68    [stack]
  0000007ffbde4b80  0000007ffbde4be0    [stack]
  0000007ffbde4bc8  0000007ffbde4ca0    [stack]
  0000007ffbde4bd0  0000007ffbde4c88    [stack]
  0000007ffbde4be0  0000007ffbde4c10    [stack]
  0000007ffbde4c00  0000007ffbde4c88    [stack]
  0000007ffbde4c10  0000007ffbde4c40    [stack]
  0000007ffbde4c40  0000007ffbde4c70    [stack]
  0000007ffbde4c88  0000007ffbde5e65    [stack]
  0000007ffbde4c90  0000007ffbde5e68    [stack]

i talked to one of our compiler folks -- @pirama-arumuga-nainar -- who pointed out that the GETASTER macro is setting the width local, from one of the varargs arguments. so the multiple indirection makes sense. first we load the va_list from its fixed position on the stack:
     59c:       f94043ea        ldr     x10, [sp,#128]

then we indirect through that because its first element is void* __stack; // next stack param:
     5a0:       f9400148        ldr     x8, [x10]

then we indirect through that because we want *(int*) x8 to pull that next int out:
     5b4:       b9400116        ldr     w22, [x8]

so your crash means that the pointer to the next stack argument in the va_list struct is 0. (or the load failed?)
do you have a full tombstone? if so, it would be good to see the memory dump around the register that's being dereferenced in the load that fails for you.
(one other thing i'd normally suggest is making sure you have automated https://source.android.com/devices/tech/debug/hwasan runs. but here i don't think this is any kind of memory corruption because i still don't see how that makes sense. this still looks more like a cpu erratum. you don't have to tell me what SoC you're using, but i'd definitely check whether all the failures you've seen have been on the same SoC...)
@stephenhines too.

Yes, it is weird. We do these tests day by day but only receive the crash report these days. Will trace if the issue only reproduced on this model.

My line numbers are a bit off from yours, but if the printf() on line 692 (for me) is getting NULL, how did the strlen() on line 660 not have a NULL? There aren't any function calls between the two that could be stomping the stack, I don't see any array dereferences, pointer arithmetic, or typecasts that could be the wrong size in between on the local variables, and they're at the same level in a loop with no goto labels in between so the flow has to come from strlen() to printf().
Does bionic check for NULL in strlen?

read my comments. the original guess is completely off. it's not yet clear what the problem is here, but this is definitely not toybox's fault.

I read them, but wanted double-check. Good luck tracking this down.

Thanks eh-google, landley, I will close this issue first and keep tracking.


Add io.kompose.service label to every object & use reaper to delete BuildConfig

Add  io.kompose.service label to BuildConfig, DaemonSet, ReplicationController and Pod.
Use reaper to delete BuildConfig (deletes also pods used for build)

Now every object created by Kompose should have this label.
Only some of the objects had this label before. This fixes #382

@surajssd template.ObjectMeta.Labels = transformer.ConfigLabels(name)  sets labels only for PodTemplate in controller object, but on for object itself.
But I will update this PR so labels are set in one place in this function and not for every object separately as its now.

@kadel oh yes, thanks for clarifying that one.

ping @cdrage @surajssd @procrypt @containscafeine

I don't see anything wrong with the code, testing it, it works as intended!
LGTM!


Missing Dtool_BorrowThisReference

Every interrogate-compiled module contains this function.
I had to add this to the bottom of every panda3d-stubs/*/__init__.pyi:
def Dtool_BorrowThisReference(from_in, to_in) -> None: ...

Yeah, I noticed those, but I couldn't figure out what they were or how they were used. Do you know what the parameters to the function should be annotated as?

Yeah, there's not a good way to annotate that at the moment, and it's probably not worth it for just these functions. I'll leave them without parameter annotations for now.


The LSP should show non-user defined files as read-only editors

As we begin to implement LSP features such as go to references or go to definition, we need to be cognizant of the special case that occurs when we take users to the definition/reference of definitions that are sourced from non-user files such as the Core Spec and plugin-provided yaml files. These files that are outside the control of the user should still be incorporated in lookup results, but only as read-only files.
AC:

[ ] When users are sent to non-user defined files via LSP features those files are presented as read-only

I like where you're heading with this but I'm curious, how are we defining "non-user files" (other than the examples you provided)?
For example, if I'm working on Team A and I have some files that depend on models, etc from Team B, I would think those would qualify as "non-user files" (based on the name) but without packages, or some other way of determining "file ownership" how would we know to open Team B's file as read-only? Are we dictating that if a file is in the AaC python package, it's a "non-user file" and any other file is a "user file"?

I like where you're heading with this but I'm curious, how are we defining "non-user files" (other than the examples you provided)?
For example, if I'm working on Team A and I have some files that depend on models, etc from Team B, I would think those would qualify as "non-user files" (based on the name) but without packages, or some other way of determining "file ownership" how would we know to open Team B's file as read-only? Are we dictating that if a file is in the AaC python package, it's a "non-user file" and any other file is a "user file"?

I'm using it to define any files that aren't on the filesystem in the project directory. So, any AaC files that are sourced from the core package, plugins, and eventually shared libraries would be considered a file that isn't defined by the user.

If we approach it like this, I'd say we should have an option to allow users to re-open the file(s) as editable. This extra ability would allow someone to experiment with different designs, etc in a shared library that is being used but isn't directly controlled by them.
An example of this, in action, is our Python virtual environments - the code in those libraries is able to be modified and I've actually used this ability to work around bugs in libraries before.


There's no way to overwrite existing pattern files

Suggest a -f flag to force saving when the pattern file exists

Would also be nice to have an 'edit mode' that launched $EDITOR ~/.gf/<pattern>.json


Improvements in "Installing kubeadm" document

Whats this PR?
This PR improves the Installing kubeadm document with following improvements:

When mentioning Kubernetes version, it's consistent to use v1.29 than 1.29.
In Linux, use of the term "directory" is more preferable than folder.
In Debian, there's missing command to ensure kubelet is started and enabled on startup.

please keep the commits squashed to 1.

squash the commits to 1 please, then i can LGTM

/assign @drewhagen

@tuladhar you have 6 commits here. it should be 1.

@neolit123 Yeah, should be good now.


Proxy to facilitate tracing from WASM environment

Add --wasm-tracing CLI flag; which must be used in combination with --tracing-targets and optionally --tracing-receiver.
Add 2 new host functions to allow tracing span enter and exit. The tracing API requires span target and name to be const, so it's not possible to create spans directly with the actual target and name; instead all are created with a single pre-defined identifier, with the span's fields containing the actual target and name, which is then patched in the tracing Subscriber in client.
Each span is stored in the TracingProxy along with it's associated guard until a call to exit is received, at which point it's dropped, triggering a span exit call to the tracing Subscriber.
The overhead of the entire tracing system including the new Proxy, measured using a noop (drop span and guard immediately following creation) ranges from 50-120ns on a running substrate client on my development machine.
Adding in the overhead of the host function calls from wasm (interpreted) adds approximately 200-400ns - so a total cost of 250-520ns per trace from WASM.

With the temporary spans added to decl_module here are graphs for the first few minutes of running a dev chain:

Just updated this PR to use a different way to create tracing spans, rather than rely on a brittle mechanism of pre-registered spans, this way reserves a special span name WASM_TRACE_IDENTIFIER to signal to the subscriber in client::tracing that the actual span name and target should instead be extracted from the spans' associated Fields.

I don't know that much about how tracing works, but looks good to me if it works :)

It works and while not as pure from the POV of tracing, I think it's a better solution for substrate at the moment.

There's one outstanding thing that needs to be decided now that we switched to dispatch all spans from the same target, which is how to filter. Currently the subscriber signals to tracing whether to bypass a trace, but seeing as this is not possible for proxied traces due to having the same target, it should probably be handled in the subscriber per trace.

There's one outstanding thing that needs to be decided now that we switched to dispatch all spans from the same target, which is how to filter. Currently the subscriber signals to tracing whether to bypass a trace, but seeing as this is not possible for proxied traces due to having the same target, it should probably be handled in the subscriber per trace.

Since there's no way to know a Field's value at time of Callsite filtering, the wasm traces are instead filtered in span creation.

Looks good, but how do we disable tracing? This currently means we always call into native for doing tracing, even if it is not enabled all. This will hurt the performance for something that isn't required always.

Right now there isn't a way - but I assume that for this we should add a cli flag in client to enable/disable all wasm traces, rather than try to filter them discretely (in wasm) based on target/level parameter?

/bench import/wasm

Benchmarks on development machine with 11,885 noop tx per block:
master:
Import benchmark (Noop, Wasm, RocksDb backend): avg 2.014290569 s, w_avg 2.016015722 s
this branch:
Import benchmark (Noop, Wasm, RocksDb backend): avg 2.03035147 s, w_avg 2.032696572 s

With a more typical transaction, 4669 each per block:
cargo run --release -p node-bench -- ::node::import::wasm::sr25519::transfer_reaping::rocksdb::full
master:
Import benchmark (RandomTransfersReaping, Wasm, RocksDb backend): avg 962.843668 ms, w_avg 964.26981 ms
this branch:
Import benchmark (RandomTransfersReaping, Wasm, RocksDb backend): avg 967.951686 ms, w_avg 968.714354 ms

@bkchr you happy with the changes now?

I can give it another review, but AFAIK he is still working on it.

I've been working some more today to try out some alternative implementations, but actually I think where it is now is probably best, so ready for another review - thanks.
Checked with polkadot dev chain and picking up traces there too:

First, sorry for the long delay :(

No problem - lots going on right now!

It already looks much better!
What I still don't understand, why do we got an extra cli option for enabling wasm tracing?

This is because we may want to enable some tracing targets that will be executed in both native and wasm, and perhaps only want traces for native.

And please add more tests, especially around tracing from WASM.

Ok

You already tried to benchmark this or? We should not see any slowdown?

I did benchmark this using:
cargo run --release -p node-bench -- ::node::import::wasm::sr25519::noop::rocksdb::full
This should be worst-case because a noop extrinsic will give the tracing overhead more significance.
Results for:
master branch:
Import benchmark (Noop, Wasm, RocksDb backend): avg 1.9429 s, w_avg 1.9472 s
this branch, wasm tracing disabled - just extra 1 host call per block, plus one instantiation TracingSpanGuard and drop per extrinsic)
Import benchmark (Noop, Wasm, RocksDb backend): avg 1.9741 s, w_avg 1.9775 s
this branch, wasm tracing manually enabled (inc also the host function calls):
Import benchmark (Noop, Wasm, RocksDb backend): avg 1.9939 s, w_avg 1.9978 s
These are results from the first run - I'm getting around 0.5% variation in results between runs of the same build and much greater variation between blocks of the same run. I would have expected to see slightly less difference between the master branch and this branch with tracing disabled; although the extra cost is only ~0.03s per 11885 transactions. With such small tolerances it's also important to consider the affect of outside factors such as CPU temperature fluctuations and other processes on the benchmarking machine (Ryzen 3960X, Ubuntu 20.4 LTS).

/bench import/full-wasm

@bkchr you happy with the changes now?

@bkchr If you're happy with the CLI (no defaults for tracing-targets) then I think all the things you mentioned are now addressed except concerning the rental crate.
Regarding that, I've had an idea for how we can manage this that wouldn't require it.
If we treat each invocation of the wasm runtime as a single span, perhaps we could use tracing Events  to signal enter/exit of 'spans' in the runtime. Technically they wouldn't be spans any more - but seeing as we don't have (and probably wont want in future) the ability to record events / values associated with individual spans from within wasm, I think this could be a more efficient way to accomplish the same result.
This could also be done in a follow-up PR

Ty for your work! :)

Thanks all for helping get this one done!
Made final check with Polkadot master and should be ready to merge now.
Just reiterating that this runtime will be incompatible with earlier versions of the client due to the new host functions utilised by it. (Client upgrade is critical on runtime upgrade.)

hmm... is there no way to make it compatible assuming we're not using the new runtime functions? i can't really merge this any time with our current need to have some degree of release stability and a fairly regular upgrade schedule across two live chains.

But what is the problem? We just need to make sure we have a node release before applying the runtime upgrade.

Just to also clarify that the client is compatible with earlier runtime versions (currently syncing Polkadot CC1 with client based from this branch).

But what is the problem? We just need to make sure we have a node release before applying the runtime upgrade.

The problem is that we have two network with hundreds of validators between them, as well as a tendency to do runtime upgrades from master branch every day or two. As soon as I merge this, then I won't be able to make a runtime ugrade on Polkadot until everybody has upgraded their nodes, same for Kusama. Requiring validators to upgrade on such a short timespan is not something that I want to do outside of a real emergency.

@gavofyork Would you agree to splitting this PR into two?
1st stage include the new host functions and related features in client (minus CLI options).
2nd stage at some point in future we can then add the runtime features to make use of them, also adding the CLI parameters to enable it.
This would allow us to give whatever window seems appropriate to allow everyone to upgrade.

Perfect.

closing because of inactivity.


[WIP] add contribution and reviewer checklist to issue

In order to make the contribution process more visible, I have added abbreviated versions of what is available on the Wiki to the content contribution issue template.

Thanks for updating this. Instead of updating the initial submission template with Google Docs information, I would suggest we make a separate template. So we would have:

Tanzu Content Proposal
Tanzu Content Proposal - Google Docs Method

The reason I say this is because a person who doesn't feel comfortable with GitHub will have the following characteristics:

Most likely be sent a link directly to the file a new issue and not self-discover it
Seeing all the markdown appear with the textual checkboxes, and formatting as opposed to rendered will be intimidating.

Therefore on the Google Docs method one it can be simple and in plain text ask for basic information and the Google Docs link, etc.

@djschny Ya I thought about that too. My thinking was that folks contributing via GDocs probably wouldn't open their own issue either. So we could make due with 1 template. The messaging thus far has been that GDocs contributors fill out our Google Form, and that's pretty much it. The reviewer that picks up the contribution would open the issue, etc. In the event the reviewer caught wind of a piece of content prior to it being submitted (which is not the common case) they would open the issue at that time.

My thinking was that folks contributing via GDocs probably wouldn't open their own issue either.

If that is the case then why even bother to put Google Docs info in the template?


Use publishConfig instead of workspace-alias

Fixes #877

Codecov Report

Merging #879 (c3eb16c) into main (316ff07) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head c3eb16c differs from pull request most recent head c5bf010. Consider uploading reports for the commit c5bf010 to get more accurate results

@@           Coverage Diff           @@
##             main     #879   +/-   ##
=======================================
  Coverage   99.39%   99.39%
=======================================
  Files         114      114
  Lines         825      825
  Branches      234      234
=======================================
  Hits          820      820
  Misses          5        5

Continue to review full report at Codecov.

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

Closing for now as this may not be the best approach


fix: set listener Context order

Fixes: https://github.com/envoyproxy/gateway/issues/533
Signed-off-by: bitliu<EMAIL_ADDRESS>

Codecov Report

Merging #535 (bb4cee1) into main (b8f234b) will increase coverage by 0.09%.
The diff coverage is 62.50%.

@@            Coverage Diff             @@
##             main     #535      +/-   ##
==========================================
+ Coverage   62.72%   62.81%   +0.09%
==========================================
  Files          42       42
  Lines        4496     4497       +1
==========================================
+ Hits         2820     2825       +5
+ Misses       1532     1529       -3
+ Partials      144      143       -1

Impacted Files
Coverage Δ

internal/gatewayapi/contexts.go
77.51% <50.00%> (+0.13%)
:arrow_up:

internal/gatewayapi/helpers.go
66.66% <100.00%> (ø)

internal/provider/kubernetes/gatewayclass.go
73.91% <0.00%> (+2.89%)
:arrow_up:

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


autorandr: 1.1 -> 1.4

Built successfully on NixOS
Ran autorandr binary

@GrahamcOfBorg build autorandr

Success on x86_64-linux (full log)
Partial log (click to expand)
    udevadm control --reload-rules

post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/jf3d5ryh2qk12q3c8f256lamfpvfxs2d-autorandr-1.4
strip is /nix/store/5qj61lcvzlap87rf6blvf8p577d482bv-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/jf3d5ryh2qk12q3c8f256lamfpvfxs2d-autorandr-1.4/lib  /nix/store/jf3d5ryh2qk12q3c8f256lamfpvfxs2d-autorandr-1.4/bin
patching script interpreter paths in /nix/store/jf3d5ryh2qk12q3c8f256lamfpvfxs2d-autorandr-1.4
/nix/store/jf3d5ryh2qk12q3c8f256lamfpvfxs2d-autorandr-1.4/bin/autorandr: interpreter directive changed from "/usr/bin/env python" to "/nix/store/87wc186a9xq5y6yxvar6f2sm5cbqzpzr-python3-3.6.4/bin/python"
checking for references to /tmp/nix-build-autorandr-1.4.drv-0 in /nix/store/jf3d5ryh2qk12q3c8f256lamfpvfxs2d-autorandr-1.4...
/nix/store/jf3d5ryh2qk12q3c8f256lamfpvfxs2d-autorandr-1.4

Success on aarch64-linux (full log)
Partial log (click to expand)
    udevadm control --reload-rules

post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/vk5f5qhb0gx3180wfh10h8ck3lyb92p9-autorandr-1.4
strip is /nix/store/xmpjypwjmp2qi1chs5kr0hacnh161ls4-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/vk5f5qhb0gx3180wfh10h8ck3lyb92p9-autorandr-1.4/lib  /nix/store/vk5f5qhb0gx3180wfh10h8ck3lyb92p9-autorandr-1.4/bin
patching script interpreter paths in /nix/store/vk5f5qhb0gx3180wfh10h8ck3lyb92p9-autorandr-1.4
/nix/store/vk5f5qhb0gx3180wfh10h8ck3lyb92p9-autorandr-1.4/bin/autorandr: interpreter directive changed from "/usr/bin/env python" to "/nix/store/4yfkb61l14x37pkqdmg4ck61xh5wg49z-python3-3.6.4/bin/python"
checking for references to /build in /nix/store/vk5f5qhb0gx3180wfh10h8ck3lyb92p9-autorandr-1.4...
/nix/store/vk5f5qhb0gx3180wfh10h8ck3lyb92p9-autorandr-1.4

Failure on x86_64-darwin (full log)
Partial log (click to expand)
error: while evaluating the attribute 'installPhase' of the derivation 'autorandr-1.4' at /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/stdenv/generic/make-derivation.nix:148:11:
while evaluating 'callPackageWith' at /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/lib/customisation.nix:113:35, called from /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/top-level/all-packages.nix:13472:13:
while evaluating 'makeOverridable' at /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/lib/customisation.nix:72:24, called from /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/lib/customisation.nix:117:8:
while evaluating anonymous function at /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/os-specific/linux/systemd/default.nix:1:1, called from /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/lib/customisation.nix:74:12:
assertion failed at /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/os-specific/linux/systemd/default.nix:9:1


Allow repeated '--program-args'

The Flink API specifies
program args should be passed as a comma separated list, which may not
be obvious to users. It's also annoying to pass large numbers of
arguments at once.

Codecov Report

Merging #38 into master will not change coverage.
The diff coverage is 66.66%.

@@           Coverage Diff           @@
##           master      #38   +/-   ##
=======================================
  Coverage   52.91%   52.91%
=======================================
  Files          13       13
  Lines         567      567
=======================================
  Hits          300      300
  Misses        218      218
  Partials       49       49

Impacted Files
Coverage Δ

cmd/cli/operations/update_job.go
85% <ø> (ø)
:arrow_up:

cmd/cli/operations/deploy.go
76.31% <ø> (ø)
:arrow_up:

cmd/cli/flink/run_jar.go
73.91% <100%> (ø)
:arrow_up:

cmd/cli/main.go
27.75% <50%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Hi @kerinin
Thank you for your contribution. It would be nice if you could add a bit more information in the CLI Usage so that it's clear to users that they can supply the --program-args multiple times.

@mrooding Good point - updated and pushed, let me know if you can think of better wording.

@kerinin bit later than expected but thanks again for contributing.


The versioned printer should be initialized with the mapping apiversion

VersionedPrinter handles fallback when multiple different APIVersions
are present if multiple arguments are passed (for instance, both Kube
resources at v1beta3 and a third party's API objects which are only
at v1). The cmd PrinterForMapping should always include the current
object's "mapping version" as a fallback in the event the preferred
API version does not map to the actual object.

Miss some files?

Oh, I see, it's a variadic function...

LGTM


Produce consistent code generation in Java 8 and Java 7

The order in which methods are generated changes between Java 7 and Java 8. If Java 8 is used, several unit tests in BuilderGeneratorIT fail because of the ordering of generated methods. For example with Java 8 BuilderGeneratorIT#beanWithNonGenericCollectionsProperty fails.
Its because of WithMethodList's use of org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(targetClass). The order of fields returned changes between Java 7 and Java 8.
Under Java 7, the order of the fields returned by org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors( BeanWithNonGenericCollections.class) is

beans
things
class
stuff

But under Java 8 it is:

stuff
beans
class
things

I suggest that the fields should be ordered in some consistent way so that methods are generated in a consistent order.
package uk.co.buildergenerator.integrationtest;

import java.beans.PropertyDescriptor;

import org.apache.commons.beanutils.PropertyUtils;

import uk.co.buildergenerator.testmodel.BeanWithNonGenericCollections;

public class Main {

	public static void main(String[] args) {
		for (PropertyDescriptor propertyDescriptor : PropertyUtils
				.getPropertyDescriptors(BeanWithNonGenericCollections.class)) {

			System.out.println(propertyDescriptor.getDisplayName());
		}
	}
}

Hi Tim,
Fork it (which you already have!), fix it, then send me a pull request.
If we can make it order agnostic that would be even better I think?
Cheers,Matt
On Thursday, 2 June 2016, 8:37, Tim Azzopardi<EMAIL_ADDRESS>wrote:

The order in which methods are generated changes between Java 7 and Java 8. If Java 8 is used, several unit tests in BuilderGeneratorIT fail because of the ordering of generated methods. For example with Java 8 BuilderGeneratorIT#beanWithNonGenericCollectionsProperty fails.Its because of WithMethodList's use of org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(targetClass). The order of fields returned changes between Java 7 and Java 8.Under Java 7, the order of the fields returned by org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors( BeanWithNonGenericCollections.class) is

beans
things
class
stuff
But under Java 8 it is:
stuff
beans
class
things
I suggest that the fields should be ordered in some consistent way so that methods are generated in a consistent order.package uk.co.buildergenerator.integrationtest;

import java.beans.PropertyDescriptor;
import org.apache.commons.beanutils.PropertyUtils;
import uk.co.buildergenerator.testmodel.BeanWithNonGenericCollections;
public class Main {
public static void main(String[] args) {
    for (PropertyDescriptor propertyDescriptor : PropertyUtils
            .getPropertyDescriptors(BeanWithNonGenericCollections.class)) {

        System.out.println(propertyDescriptor.getDisplayName());
    }
}

}—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Re: "If we can make it order agnostic that would be even better I think?"
s/agnostic/independent/?
But even then...

If you mean make the integration tests pass in a way that is independent
of the order of the methods in the generated code, then that would be hard.
The integration tests are currently written to use a simple file compare,
so at least the failing (and to be safe all the) IT tests would need to
change substantially.

If you mean make BG generate the methods in a predictable order that
is *independent
*of the order of the return PropertyUtils#getPropertyDescriptors then that
would be easy: the properties could be ordered alphabetically by name.

IMO a predictable order of generated methods would be best. IMO It should
NOT be OK for BG generated methods to jump around in the source file if the
version of the JRE or Apache beanutils changes.
On Thu, 2 Jun 2016 at 17:27 uglycustard<EMAIL_ADDRESS>wrote:

Hi Tim,
Fork it (which you already have!), fix it, then send me a pull request.
If we can make it order agnostic that would be even better I think?
Cheers,Matt
On Thursday, 2 June 2016, 8:37, Tim Azzopardi<EMAIL_ADDRESS>wrote:
The order in which methods are generated changes between Java 7 and Java
8. If Java 8 is used, several unit tests in BuilderGeneratorIT fail because
of the ordering of generated methods. For example with Java 8
BuilderGeneratorIT#beanWithNonGenericCollectionsProperty fails.Its because
of WithMethodList's use of
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(targetClass).
The order of fields returned changes between Java 7 and Java 8.Under Java
7, the order of the fields returned by
org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptors(
BeanWithNonGenericCollections.class) is

beans
things
class
stuff
But under Java 8 it is:
stuff
beans
class
things
I suggest that the fields should be ordered in some consistent way so that
methods are generated in a consistent order.package
uk.co.buildergenerator.integrationtest;

import java.beans.PropertyDescriptor;
import org.apache.commons.beanutils.PropertyUtils;
import uk.co.buildergenerator.testmodel.BeanWithNonGenericCollections;
public class Main {
public static void main(String[] args) {
for (PropertyDescriptor propertyDescriptor : PropertyUtils
.getPropertyDescriptors(BeanWithNonGenericCollections.class)) {
System.out.println(propertyDescriptor.getDisplayName());
}
}
}—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/uglycustard/buildergenerator/issues/42#issuecomment-223345787,
or mute the thread
https://github.com/notifications/unsubscribe/AAJH_o6JGUjbjmLToltqGBzFlPV6q4prks5qHwRqgaJpZM4IsSBh
.

Yeah, good point. Want to give it a go?

Sure!

Release 1.0.1


User not displayed in free tradebacks/redeem list

When entering a free tradeback/redemption, it asks you to fill in the user, but the user doesn't get displayed on the reference.

Check this one as well?

The user is not displayed here, but it is displayed here.

Oh yeah, that display is totally messed up. Leaving this one open then. Will get to it.


chore(main): print help text without the err message

Signed-off-by: Sunil Shivanand<EMAIL_ADDRESS>

Isn't this a "fix" - i.e. user-facing? Not sure....


Add not_null_proportion schema test and related integration tests

This is a:

[ ] bug fix PR with no breaking changes — please ensure the base branch is master
[x] new functionality — please ensure the base branch is the latest dev/ branch
[ ] a breaking change — please ensure the base branch is the latest dev/ branch

Description & motivation

Quite often real-world data sources have columns that should be non-null but for one reason or another there are a couple of NULL values. This PR implements a not_null_proportion test that allows the user to specify the minimum (at_least) tolerated proportion (e.g., 0.95) of non-null values. There's also an optional at_most argument for which I can't think of a use case but added it anyway as it was trivial to implement.
Checklist

[ ] I have verified that these changes work locally on the following warehouses (Note: it's okay if you do not have access to all warehouses, this helps us understand what has been covered)

[x] BigQuery
[x] Postgres
[ ] Redshift
[x] Snowflake

[x] I have updated the README.md (if applicable)
[x] I have added tests & descriptions to my models (and macros if applicable)
[x] I have added an entry to CHANGELOG.md

Closing this out as it got merged in https://github.com/dbt-labs/dbt-utils/pull/411


Upgrade protagonist version

protagonist 0.17.1 is not being installed on latest node version (0.12.2) so I upgraded this dependency to their latest stable version

Shouldn't it be tested from v0.10?

Coverage remained the same at 100.0% when pulling af2ade951db5a001e49d335d6b3ec4f2ac1666a2 on rafaelmenta:master into 698898d405213a32842cef144ba8845ffcc59c5a on localmed:master.

+1

Thanks for updating, and for working out the node dependency. Back when I wrote this protagonist was supporting back to v0.8!

Thank you for the quickness! Are the changes already published on npm?


LinuxWatchService fails when running clojure boot

When running clojure boot, the LinuxWatchService throws an exception.
bill@T540P:/mnt/c/Users/Bill/Documents/rolonicArk/simpleArk$ boot.sh test-it
sun.nio.fs.UnixException: Bad file descriptor
at sun.nio.fs.UnixNativeDispatcher.read(Native Method)
at sun.nio.fs.LinuxWatchService$Poller.run(LinuxWatchService.java:318)
at java.lang.Thread.run(Thread.java:745)
Windows 10 version 1607 (OS Build 14393.693)
The boot development environment monitors the file system for changes. So this is a critical API when using clojure boot.

Forgot to mention the java version...
bill@T540P:~$ java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
bill@T540P:~$

Boot version info:
BOOT_CLOJURE_VERSION=1.9.0-alpha10
BOOT_VERSION=2.6.0
BOOT_EMIT_TARGET=no

I believe this is a duplicate of some of the problems highlighted in #277 and is fixed in later Windows 10 builds. In particular, see my comment https://github.com/Microsoft/BashOnWindows/issues/277#issuecomment-241632789 which shows the same Bad file descriptor error.


portfolio text need not centeralized

use {: .list-inline .text-align: start} at the end of the block


Question on Forecast_Observations

When using the "forecast_observations" how would you show that in the config?
forecast_observations: 7
or
forecast_observations:
7
or something else?

Hi,
the right assignment is forecast_observations: 7, but for a bug this one didn't work.
I have fixed the bug and released a new version.
Thanks for your report.
Renato

Thanks


Stop logger from trying to chmod on each event

... to safe i/o and prevent error messages popping up when the user is different then the webserver.
We run cron jobs from the command line as user Foo, while the webserver runs as user Bar. We now get a race condition whichever user executes first has the right to chmod the file. Every additional chmod() by the other user results in an error:
ERROR - 2011-11-30 15:12:58 --> Severity: Warning  --> chmod(): Operation not permitted /var/websites/superawesomeproject/codeigniter/libraries/Log.php 106
This fix only sets chmod on the first write when the file is created. Since it sets permissions to 666, every other user can write to the file.
Is there a specific reason why chmod() is called on each write to the Log class?

Oh yeah, changelog. Sorry forgot...

No worries. :-)


refactor: organize structure of components

BREAKING CHANGE: react dependencies are now peer dependencies, imports have changed

Codecov Report

Merging #201 (ea2134d) into master (c6c621e) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #201   +/-   ##
=======================================
  Coverage   62.44%   62.44%
=======================================
  Files          58       58
  Lines        2868     2868
  Branches      595      595
=======================================
  Hits         1791     1791
  Misses        942      942
  Partials      135      135

Impacted Files
Coverage Δ

core/AMTDesktop.ts
100.00% <ø> (ø)

core/AMTKvmDataRedirector.ts
100.00% <ø> (ø)

core/AMTRedirector.ts
59.77% <ø> (ø)

core/AMTTerminal.ts
100.00% <ø> (ø)

core/ConsoleLogger.ts
93.93% <ø> (ø)

core/Converter.ts
94.25% <ø> (ø)

core/Desktop.ts
20.00% <ø> (ø)

core/ImageData/DataProcessor.ts
91.30% <ø> (ø)

core/ImageData/RLEDecoder.ts
9.09% <ø> (ø)

core/ImageData/index.ts
100.00% <ø> (ø)

... and 48 more

Continue to review full report at Codecov.

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


No scrollbar for folder list?

A long list of files in the file pane will create a scrollbar on the right, but the same doesn't seem to happen for the folder list so if I have a long directory tree I can't get to the ones at the bottom.
Is this a bug or have I screwed up something here?

Probably a CSS bug on our end, i will poke the person responsible.

Great, thanks!

Hi @eggfriedrice,
Thank you for reporting this CSS issue. I have updated the bundle. You will now get a scrollbar when you have a long directory tree.
Can you confirm it if its fixed?

closed for inactivity.


Extremely slow response times for Ecto call generating 700+ obs

Environment

Elixir & Erlang versions (elixir --version):

elixir --version
Erlang/OTP 22 [erts-10.5] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1]
Elixir 1.9.4 (compiled with Erlang/OTP 20)

Operating system:
Windows 10

Editor or IDE name (e.g. Emacs/VSCode):

VSCode

LSP Client name:

ElixirLS Fork: Elixir support and debugger
Problem
I have one api call that uses this function in my app:
  def list(org_id, app_id, cr_id, filters \\ %{}) do
    from(c in Change,
      join: cr in assoc(c, :change_request),
      where: cr.id == ^cr_id,
      where: cr.application_id == ^app_id,
      where: cr.organization_id == ^org_id
    )
    |> add_filters(filters)
    |> preload()
    |> Repo.all()
  end

It grabs some records using Ecto and returns in about a half second with 767 objects that are rendered into JSON and passed back in the response payload.
However, if I run my application via VSCode, I actually cannot get that function to return (I've waited 5mins, can't seem to figure out how to keep the connection open longer than that). Resource usage on erl.exe goes as high as 4GB and 50% CPU while it's chugging along.  I have removed all breakpoints and am still experiencing this problem.
If there is a way to provide you with any extra information that could help, please let me know.

However, if I run my application via VSCode

How are you running the application exactly? Is that via the debugger?

@axelson I am using the following launch configuration with VSCode:
{
    "configurations": [
        {
            "type": "mix_task",
            "name": "Run API",
            "request": "launch",
            "task": "phx.server",
            "projectDir": "${workspaceRoot}"
        }
    ]
}

Hmm, maybe that's just overhead from the erlang interpreter interpreting all the files in your project. Does it complete if you reduce the number of objects rendered?

@axelson I'll try to put together a repo that demonstrates the issue, I'll post back here when I'm done.

That would be very helpful, thanks!

@axelson just an FYI I still have this on my radar. I spent a bunch of time creating a test project, I just need to get the data straightened out.
I was wondering, is there any way I can examine what the plugin is doing myself? Set breakpoints, step through code, make alterations?

@ctataryn in order to debug you'd generally make changes, then run mix elixir_ls.release -o ~/.vscode-oss/extensions/elixir-lsp.elixir-ls-0.3.2/elixir-ls-release/ (you will have to update that path for your system). I don't use breakpoints since stopping a process in a multi-process system results in lots of errors. Instead I would add require Logger; Logger.info("client capabilities: #{inspect(state.client_capabilities)}") type log messages and then view the ElixirLS output (from view -> output.

Actually you should use IO.puts for debugging when debugging a live server (but if you're debugging in the tests you should use Logger.info).

@ctataryn ping

@lukaszsamson Thank you for the reminder. I don't think I'll have the time right now to further investigate this issue, if you'd like to close it, I can bookmark it and re-open when I have some more time in the future.


1.19.2 mob bugs and etc.

1.19.2, forge 43.2.4, mod ver 4.0.6
-mobs arent naturally spawning. only ones spawning are sunken skeletons, necromancers, drowned necromancers
-spiders having trouble shooting webs. currently they stare into ur soul for abt 6 seconds and shoot a projectile
-when stuck in a spiders simple_trap/web and snarelings glob the camera is messed up while trying to move out of it, like being stuck inside a block i guess
-mountaineer AI messed up. has trouble attacking and just swings its pickaxe, while climbing has trouble finding a target, it just climbs to the highest point and stays there. doesn't move or anything just sits there.
-windcaller and wildfire is taking fall damage
geckolib bugs (i think):
-royal guards are walking funny/wobbling really fast
-skeleton vanguard are wrongfully holding their shield and glaive, attack anim is also messed up
-sunken skeletons missing the coral sticking out their head
-sunken skeletons arent spawning in their 4 variants. only the purple one is spawning
misc:
glow layers are messed up for the wildfire and restone golem while using shaders see https://github.com/Infamous-Misadventures/Dungeons-Mobs/issues/169
fixed bugs:
-blasting projectiles firing the same projectiles as necromancers which are blue ones, instead of purle ones
an excessive amount of enderlings (should probably tune the weight down a bit)

Blastling, Watchling & Snareling spawn weights have been nerfed by 50% in 4.0.7.

Blastings now fire their own projectiles in 4.0.7.

Natural mob spawns have been fixed in 4.0.8.
Spiders having a delayed ranged attack have been fixed in 4.0.8.
Web Traps and Snareling Globs constantly teleporting trapped victims have been fixed in 4.0.8.
Mountaineers not being able to attack has been fixed in 4.0.8.
Windcaller and Wildfire taking fall damage has been fixed in 4.0.8.


Use wrapProgram make ob supply its own runtime deps

The test can build everything is failing and I haven't looked into why yet. If you happen to have an idea why, let me know.
Also, installing this makes obelisk show up as ob instead of obelisk-command in nix-env -q. I can change this if we liked obelisk-command as the CLI package name. I thought ob was a bit more obvious.
For devs, you now should use nix-shell -A commandEnv instead of nix-shell -A command.env to get into dev shell for command.
Fixes #78

Because hub is in this list, we should probably also run hub ourselves to ensure that the auth is configured with the version of hub we are using. Or we should not bring hub with us and rely on the user already having it (but this assumes that the way hub stores auth is compatible with how we expect, which may not be true for various combinations of versions of hub and ob).

Thanks!

@3noch How does this affect the use of nix-shell ....env commands (there are two of them) in the README? cf. https://github.com/obsidiansystems/obelisk#contributing-to-obelisk

Actually this PR doesn't affect it. n/m.


⚠ Avatar API Endpoint has degraded performance

In 0822c6f, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) experienced degraded performance:

HTTP code: 200
Response time: 5104 ms

Resolved: Avatar API Endpoint performance has improved in b116b53 after 13 minutes.


sensor_connections boolean default false -> sensor int references sensor(id) default null

It is currently convoluted to retrieve the sensor of a transfo_tree that is not a sensor_connection.
I propose to have instead a sensor field which would be :

null when sensor_connections was true
the id of the common sensor of the referentials linked by the transfos of the transfo_tree if it was false.

How do you determine the "common" sensor? Is it the one associated with the source referential of the first transfo in the transfo tree?
SELECT r.sensor as sensor_id
FROM li3ds.transfo_tree tt
JOIN li3ds.transfo t on t.id == tt.transfos[1]
JOIN li3ds.referential r on r.id = t.source
WHERE tt.id = 1;

To rephrase my proposal : If all sources and targets of all transfos of the transfo_tree agree on a common sensor, then this is the sensor of the transfo_tree, otherwise, set it to null.

Ok so not necessarily the source of the the first transfo.
What about the case where the transfo tree is a chain of transfos? Is there a "common sensor" in that case?

It depends whether its a transfo tree linking referentials of a single sensor or one that links referentials of multiple sensors.


cant change fonts?

+1

Any news on this one? This feature would be highly welcome!

I improved and will improve this library with multiple nice features.
link: react-native-steps
this above feature is added

@ramneekhanda @teddysantya @jan-happy  I have released v0.0.11 which includes functionality to render custom labels. I have updated the examples to showcase the functionality


TypeError: Cannot read properties of undefined (reading 'visibilityState')

Bug report
The following error sometimes occurs under jest environment. But not always happens
TypeError: Cannot read properties of undefined (reading 'visibilityState')
    at Object.isVisible (/Users/project/app/node_modules/swr/_internal/dist/index.js:140:59)
    at isActive (/Users/project/app/node_modules/swr/core/dist/index.js:55:38)
    at /Users/project/app/node_modules/swr/core/dist/index.js:330:29
    at processTicksAndRejections (node:internal/process/task_queues:95:5)

Description / Observed Behavior
Same to Bug report
Expected Behavior
no error
Repro Steps / Code Example
  export const SWRNoCacheConfig = ({ children }: { children: ReactNode }) => (
    <SWRConfig value={{ provider: () => new Map() }}>{children}</SWRConfig>
  );

  const { result } = renderHook(
    () => useMyHook(),
    {
      wrapper: SWRNoCacheConfig,
    },
  );

Additional Context
swr version is 2.2.2 plus using react
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "swr": "^2.2.2",

duplicated of #2373


Make design system for Stats

Make and awesome design system for Stats Component.
See the Stats and make one.
Refer to : Button Design System for any reference or ask me in any confusion.
Tip :
You can use Tailwind Playground

Assign this to me

Same for this as well. But I am giving points as this a valid issue and we will work on this in future.


Feature/colors

initial implementation for new color palette, per #42

review on render
review on percy

changes in this PR

all colors are defined as scss variables
using new foreground and background colors (body, nav, text)
coloring leaves according to the branch they belong to
updated panel color and tag color/layout
tweaked the provisional selected leaf style so I'm not reusing a branch color as a highlight color

notes:

I'm using the leaf label color from the designs, but at a lower opacity for now, because of the overlapping text labels
I was doing something wrong with the body max size calculation; I've corrected the logic but I'm not sure the layout is correct
would it be useful to set a minimum height for the percy mobile captures? I think that's feasible, they look really long now
The colors look better in Figma than they do in my browser! Is it the same for you? If so, any ideas why?

@rlskoeser thank you for sharing!! regarding the colors of the leaves looking different, based on my inspection you're not just changing the opacity of the labels you're also changing the opacity of the leaves, that's why they look dull, they're all 0.6 opacity

@gissoo found it. The css reset I'm using somehow (by applying an unset all) was resulting in a default fill-opacity of 0.6. I've corrected that so default fill-opacity is 1. Would you confirm on the updated render site for this PR?

@rlskoeser thank you, yes, I saw that in the CSS browser panel. thank you, they look good now!

we could address the layout issues once you share a version with me to play with, and also once I place the spacing/margins for review.
I think a minimum height for the percy mobile capture would be useful, can we try 960px?
Other than that the colors look right!


Fix #4849: Add start-index and stop-index assertion for ParameterMarkerExpression

Fixes #4849.
Changes proposed in this pull request:

Removed 6 insert cases in SQLParserParameterizedTest class
Add start-index and stop-index attributes for several insert cases in insert.xml

Pull Request Test Coverage Report for Build 10411

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.005%) to 59.636%

Files with Coverage Reduction
New Missed Lines
%

sharding-orchestration/sharding-orchestration-core/sharding-orchestration-core-registrycenter/src/main/java/org/apache/shardingsphere/orchestration/core/registrycenter/util/IpUtils.java
3
76.0%

Totals

Change from base Build 1121:
-0.005%

Covered Lines:
12464

Relevant Lines:
20900

💛  - Coveralls


[tlse] internal TLS support for placement

Creates certs for k8s service of the service operator when spec.tls.endpoint.internal.enabled: true
For a service like nova which talks to multiple service internal endpoints, this has to be set for each of them for, like:
  customServiceConfig: |
    [keystone_authtoken]
    insecure = true
    [placement]
    insecure = true
    [neutron]
    insecure = true
    [glance]
    insecure = true
    [cinder]
    insecure = true

Depends-On: https://github.com/openstack-k8s-operators/lib-common/pull/428
Depends-On: https://github.com/openstack-k8s-operators/openstack-operator/pull/620
Depends-On: https://github.com/openstack-k8s-operators/placement-operator/pull/92
Jira: OSPRH-2368

needs to be rebased when https://github.com/openstack-k8s-operators/openstack-operator/pull/620 landed. only last commit is relevant for this PR

recheck

/retest


llama3 on prem benchmarks

🚀 The feature, motivation and pitch
Documentation and examples are for llama2 benchmarks.   We would like to run llama3 on prem benchmarks.
Alternatives
No response
Additional context
No response

Hi! I will update the code soon, meanwhile you can change the MODEL_PATH to meta-llama/Meta-Llama-3-70B, then launch two vllm servers that host meta-llama/Meta-Llama-3-70B by CUDA_VISIBLE_DEVICES=0,1,2,3 python -m vllm.entrypoints.openai.api_server  --model meta-llama/Meta-Llama-3-70B --tensor-parallel-size 4 --disable-log-requests --port 8000  CUDA_VISIBLE_DEVICES=4,5,6,7 python -m vllm.entrypoints.openai.api_server  --model meta-llama/Meta-Llama-3-70B --tensor-parallel-size 4 --disable-log-requests --port 8001 . You can still use the chat_vllm_benchmark.py to benchmark.

PR merged, please try the latest example. Let me know if there is any problem.

Closing this issue as the PR has been merged. Let me know if there is any problem!


updated virtioFS

updated virtioFS section

Hey! @christophermclellan can you share the link to the blog post and I'll add it in this PR

@jerae-duffin Here's the link to the blog - https://www.docker.com/blog/speed-boost-achievement-unlocked-on-docker-desktop-4-6-for-mac/

Thanks! @usha-mandya Updated link


Multitrack cursor not going back to beginning after finish playing and trying to play again

Hey, thank you for testing and contributing to wavesurfer.js!
Please make sure you can check all of these points below before opening an issue:
(You don't have to post this section)

[x] I have checked the FAQ and it doesn't solve my problem.
[x] I have checked the documentation and it doesn't solve my problem
[x] I have searched for already open issues which desribe my problem.
[x] The issue I'm having is related to and caused by wavesurfer.js, not by other software (which maybe packages and uses wavesurfer incorrectly) – In that case you should open the issue on the respective project pages.

Please make sure you provide the following information (if applicable):
Wavesurfer.js version(s):
7.0.0-beta.6
Browser and operating system version(s):
Chrome, Windows 11
Code needed to reproduce the issue:
https://wavesurfer.pages.dev/examples/#multitrack.js
(Please reduce your code as much as possible and only post the minimum code needed to reproduce the issue. A Code pen is an excellent way to share such code)
Use behaviour needed to reproduce the issue:

Drag the cursor toward near the end of the player.
Click "Play" and wait until it finishes playing.
Click "Pause"

I expected the cursor to go back to the beginning and play all the tracks simultaneously, but it seems that the cursor is not going back, and only track id 1 is playing.
https://github.com/katspaugh/wavesurfer.js/assets/38929720/16898637-699e-48de-a969-897d794f5637

It’s not expected to go back. You gotta code it yourself. There’s a “finish” event on media elements that you can listen to and jump back to 0.


About train.py

Thanks for sharing this great work. Hey, just wondering under what conditions you might consider open sourcing the train.py file? I'm really looking forward to being able to train the model on my own dataset.

Thanks for sharing this great work. Hey, just wondering under what conditions you might consider open sourcing the train.py file? I'm really looking forward to being able to train the model on my own dataset.

Thank you for your continued attention!
We will release train.py after the review of this job is completed. If you encounter any related questions, you are welcome to contact me via email or issues.

Thanks!

Thank you for your great work and look forward to the release of the training code.


Mono source process as stereo

For some reason mono source changing to stereo after processing.
At lest on HP2_4BAND_44100_2.pth model
In cli beta version mono source processed as mono.

AI only works in stereo. We can add auto-convert to mono if the input file is mono.

I only work with mono input files, so it would be great to have the output as mono also.


[Feature] support more mysql data type for Mysql CDC Sync Action

Search before asking

[X] I searched in the issues and found nothing similar.

Motivation
Now, flink mysql cdc connector support all mysql data type ,
https://ververica.github.io/flink-cdc-connectors/master/content/connectors/mysql-cdc.html#data-type-mapping
we should also support them in the mysql cdc action.
Solution
No response
Anything else?
No response
Are you willing to submit a PR?

[X] I'm willing to submit a PR!

@zhangjun0x01 Are we done with all the types?

the set type has not done ,I am doing some test.

Thanks @zhangjun0x01 !


ginkgo: 2.13.0 -> 2.13.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/go:ginkgo/versions.
meta.description for ginkgo is: A Modern Testing Framework for Go
meta.homepage for ginkgo is: https://onsi.github.io/ginkgo/
meta.changelog for ginkgo is: https://github.com/onsi/ginkgo/blob/master/CHANGELOG.md
Updates performed

Golang update

To inspect upstream changes

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.13.1 with grep in /nix/store/cbcfzzbf62j9rvwrgq1nffh49jixakdb-ginkgo-2.13.1
found 2.13.1 in filename of file in /nix/store/cbcfzzbf62j9rvwrgq1nffh49jixakdb-ginkgo-2.13.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ginkgo

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/cbcfzzbf62j9rvwrgq1nffh49jixakdb-ginkgo-2.13.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ginkgo https://github.com/r-ryantm/nixpkgs/archive/cbfcf708229b7458d78dcef420c4cdc1447b0720.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/cbfcf708229b7458d78dcef420c4cdc1447b0720#ginkgo

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/cbcfzzbf62j9rvwrgq1nffh49jixakdb-ginkgo-2.13.1
ls -la /nix/store/cbcfzzbf62j9rvwrgq1nffh49jixakdb-ginkgo-2.13.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ginkgo

Maintainer pings
cc @saschagrunert @06kellyjac for testing.

Result of nixpkgs-review pr 267730 run on x86_64-linux 1

1 package built:

ginkgo


System-level notifications for workflows.

I don't even know if this is possible with VS Code extensions, but would be great to have a system notification that a workflow has completed. That way, I can kick off a build, go do something in another app and then macOS would ping me and say "Hey! Your workflow is done!" or "Sad news, your workflow failed."

I was just about to file this issue too. This would be a very valuable feature. This way I wouldn't have to open the run in my browser (using up screen estate), just to know when the run has completed.
Bonus points for an option to automatically "subscribe" for notifications on runs that are initiated from pushes to the current branch only.

Unfortunately this is not a feature we are ready to commit to or to put on our road map at this time. We appreciate the suggestion, and will re-open if that changes!

I'm left wondering the same as on my other comment:
Is it mostly the implementation and would you be interested in merging a PR for this or is it also the eventual maintenance that you're not interested in?


Handle ZWNJ properly

We currently map the ZWNJ character to a glyph struct with no index.
Instead, we should map it just like we would other glyphs, and work out an appropriate fallback strategy in the event of the glyph's absence.

This has been addressed in 02c5f60.


cmd/go: no newline after note about old Go version

What version of Go are you using (go version)?

$ go version
go version devel +ffd096db2b Wed Feb 13 05:35:45 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?
Yes
What did you do?

$ go mod init go1.13mod
$ go mod edit -go 1.13
$ cat main.go
package main

func main() {
	Compile error
}
$ go run .
# go113mod
./main.go:4:10: syntax error: unexpected error at end of statement
note: module requires Go 1.13$ # note that there is no newline after this last line.

What did you expect to see?
A newline after the "note: module requires Go 1.13".
What did you see instead?


gulp-sass 执行gulp 任务时候出现

Error: dlopen(/XXX/XXXX/XXXX/XXXX/study/node_modules/node-sass/vendor/darwin-x64-47/binding.node, 1): no suitable image found.  Did find:
/Users/XXX/XXX/XXX/study/node_modules/node-sass/vendor/darwin-x64-47/binding.node: truncated mach-o error: seXXXgment __TEXT extends to 1212416 which is past end of file 225840
at Error (native)
gulp version

npm rebuild node-sass


Add authentication to frontend

Add authentication to frontend. This implies:

Adding login screen for user (simple user/pass for now, with OAuth2 form names)
Obtaining token from /api/token endpoint when executing login
Maintaining token in browser and using it when sending api requests
Maybe redirecting to login screen when getting an Not Authenticated message

Details:

Token requests:

POST request should be made to the /api/token endpoint
Proper headers to include: "Content-Type": "application/x-www-form-urlencoded" and "Accept": "application/json"
Payload: a form with three fields: "grant_type": "password" , "username": [theusername], "password": [thepassword]
In JSON reply, token is a string contained in "access_token" field
There is also info about when the token expires, but we can kinda ignore that for now, for a bit at least

In every request to other endpoints, the token should be sent as a header in the following way:

"Authorization": "Bearer [token]"

Not sending a token to an endpoint should get you a 401 Unauthorized result, which is when you should redirect to the login page.
Branch currently in development of this is, in sebastian-echeverria's fork, "feature/identity"

Addressed by #388


digester: keep the singleAtIdentifier in normalize (#1128)

cherry-pick https://github.com/pingcap/parser/pull/1128

LGTM


fix: missing value on dbms attribute makes Oracle paylods be executed on other dbms

Hello!
While testing for some SQL Injections on my Postgresql environment I noticed that Oracle payloads are being executed because there is no value for the dbms attribute.

Best regards,
oppsec.

it is fixed in the up coming updates including few other fixes plus a single additional request to the target url won't bother that much i guess. so closing this PR and once update is pushed this will be fixed already.


Update semanticdb-scalac to 4.4.26

Updates org.scalameta:semanticdb-scalac from 4.4.0 to 4.4.26.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "semanticdb-scalac" } ]

labels: library-update, semver-patch

Superseded by #143.


feat: Add LinkTarget to IFileSystemInfo

In https://github.com/TestableIO/System.IO.Abstractions/pull/790 we added LinkTarget to FileSystemInfoBase, but I forgot to also add it to the interface (which was the whole point in the first place).
So this is embarrassing, but also it will allow LinkTarget to be used and mocked.

@fgreinacher I missed this during my last PR. Sorry!

On a related note, I do not think the tests are testing using .net6, or else they would have blown up (I think). Taking a look.

Thanks @BrianMcBrayer!
The tests are indeed running against .NET 6, but they don't assert anything the the interfaces and base classes are equivalent. Might be something to improve 🤔


Guarded session refactor

move session to db, change utils to use guarded session and/or clean up
sessions properly.

Looks like tests fail because flake8:
src/iris/db.py:47:14: W292 no newline at end of file


Use proxy authentication during install

Fetching the esbuild executable during install through a http proxy that requires authentication didn't work.
This PR extends the installation by picking up and applying HTTP Basic Authentication credentials from the proxy environment variables HTTPS_PROXY, https_proxy, HTTP_PROXY or http_proxy, depending on the scheme of the fetch URL.
eg. export<EMAIL_ADDRESS>See #54 for further motivation.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


@material-ui/x-grid-data-generator not working

I've installed the XGrid and the x-grid-data-generator to test it following the example from the documentation, however, after implementing it, it breaks the application completely.

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
ERROR in<EMAIL_ADDRESS>Module not found: Error: Can't resolve '@material-ui/lab/Rating' in 'C:\www\<app>\node_modules\@material-ui\x-grid-data-generator\dist\esm'

Expected Behavior 🤔
The application should render and show something like this

Steps to Reproduce 🕹
Steps:

Install dependencies:
"@material-ui/data-grid": "4.0.0-alpha.24",
"@material-ui/icons": "~4.11.2",
"@material-ui/x-grid": "4.0.0-alpha.24",
"@material-ui/x-grid-data-generator": "4.0.0-alpha.24",
Implement the code from the documentation
Observe the error

The code from the documentation
import * as React from 'react';
import { XGrid } from '@material-ui/x-grid';
import { useDemoData } from '@material-ui/x-grid-data-generator';

export default function XGridDemo() {
  const { data } = useDemoData({
    dataSet: 'Commodity',
    rowLength: 100000,
  });

  return (
    <div style={{ height: 520, width: '100%' }}>
      <XGrid
        {...data}
        loading={data.rows.length === 0}
        rowHeight={38}
        checkboxSelection
      />
    </div>
  );
}

Context 🔦
I am evaluating the XGrid for the project in my company.
Your Environment 🌎

`npx @material-ui/envinfo`
System:
    OS: Windows 10 10.0.17763
  Binaries:
    Node: 14.16.0 - ~\AppData\Local\Volta\tools\image\node\14.16.0\node.EXE
    Yarn: 1.22.10 - ~\AppData\Local\Volta\tools\image\yarn\1.22.10\bin\yarn.CMD
    npm: 6.14.11 - ~\AppData\Local\Volta\tools\image\node\14.16.0\npm.CMD
  Browsers:
    Chrome: 89.0.4389.114
    Edge: Not Found
  npmPackages:
    @emotion/styled:  10.0.27
    @material-ui/core: 4.11.3 => 4.11.3
    @material-ui/data-grid: 4.0.0-alpha.24 => 4.0.0-alpha.24
    @material-ui/icons: ~4.11.2 => 4.11.2
    @material-ui/styles:  4.11.3
    @material-ui/system:  4.11.3
    @material-ui/types:  5.1.0
    @material-ui/utils:  4.11.2
    @material-ui/x-grid: 4.0.0-alpha.24 => 4.0.0-alpha.24
    @material-ui/x-grid-data-generator: 4.0.0-alpha.24 => 4.0.0-alpha.24
    @material-ui/x-license:  4.0.0-alpha.21
    @types/react: 17.0.2 => 17.0.2
    react: 17.0.1 => 17.0.1
    react-dom: 17.0.1 => 17.0.1
    styled-components: 5.2.1 => 5.2.1
    typescript: 4.2.3 => 4.2.3

Browser: Chrome

I have just realized that there's a separate space for the material-ui-x.
I've moved this issue there.


Fix typo

Signed-off-by: Tomoya Usami<EMAIL_ADDRESS>correct the word. s/SPIFFEE/SPIFFE/
[ ] Configuration Infrastructure
[x] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[x] Does not have any changes that may affect Istio users.

Hi @hiyosi. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/ok-to-test

@hiyosi: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
fc5bc33306c5b05e245cc7d1f0a5fd82b6f5e48c
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@hiyosi: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-telemetry-mc-k8s-tests_istio
fc5bc33306c5b05e245cc7d1f0a5fd82b6f5e48c
link
/test integ-telemetry-mc-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I'm not sure. It seems not to be related to this change.

/retest


ecPairing contract call returns 0

Smart contract reverts here: https://github.com/eigen-trust/protocol/blob/e51f43281fa87341cc5ecdb4a72a524af5c861d1/data/et_verifier.yul#L1738
How we generate code: https://github.com/eigen-trust/protocol/blob/e51f43281fa87341cc5ecdb4a72a524af5c861d1/circuit/src/verifier/mod.rs#L85-L114
The verification passes if we call evm directly with this function: https://github.com/eigen-trust/protocol/blob/e51f43281fa87341cc5ecdb4a72a524af5c861d1/circuit/src/verifier/mod.rs#L116-L134

Is the revertion happens to TestCircuitPi? If that's true, is there any test that I could run to reproduce this failure? That might provide more clue for me to find the bug, since TestCircuitPi looks okay for snark-verifier.

After doing more research, I realised that the problem is somewhere in our verifier wrapper: https://github.com/eigen-trust/protocol/blob/e51f43281fa87341cc5ecdb4a72a524af5c861d1/data/EtVerifierWrapper.sol
Sorry about this, will close the issue for now


mummerplot error message: "Inappropriate ioctl for device"

Hi all,
I am trying to run mummerplot on the command line to generate a png that shows how my two fasta sequences align. I am getting the following error message:
mummerplot -p atcc_vs_wt --png atcc_vs_wt.delta
gnuplot 4.6 patchlevel 6
Reading delta file atcc_vs_wt.delta
Writing plot files atcc_vs_wt.fplot, atcc_vs_wt.rplot
Writing gnuplot script atcc_vs_wt.gp
Rendering plot atcc_vs_wt.png
WARNING: Unable to run 'false atcc_vs_wt.gp', Inappropriate ioctl for device

Some other information
$ mummerplot --version
mummerplot 3.5

$ gnuplot --version
gnuplot 4.6 patchlevel 6

Any advice is appreciated!

I get the same error message as above:
[ljcohen@dev-intel14 mummer]$ mummerplot --fat --filter --png --large -p F_olivaceus F_oli_ONT_Fhet.delta
gnuplot 4.6 patchlevel 3
Writing filtered delta file F_olivaceus.filter
Reading delta file F_olivaceus.filter
Writing plot files F_olivaceus.fplot, F_olivaceus.rplot
Writing gnuplot script F_olivaceus.gp
Rendering plot F_olivaceus.png
WARNING: Unable to run 'false F_olivaceus.gp', Inappropriate ioctl for device

Version info:
[ljcohen@dev-intel14 mummer]$ mummerplot --version
mummerplot 3.5
[ljcohen@dev-intel14 mummer]$ gnuplot --version
gnuplot 4.6 patchlevel 3

Tried a previous version of gnuplot, same thing:
[ljcohen@dev-intel14 mummer]$ mummerplot --fat --filter --png --large -p F_olivaceus F_oli_ONT_Fhet.delta
gnuplot 4.4 patchlevel 4
Writing filtered delta file F_olivaceus.filter
Reading delta file F_olivaceus.filter
Writing plot files F_olivaceus.fplot, F_olivaceus.rplot
Writing gnuplot script F_olivaceus.gp
Rendering plot F_olivaceus.png
WARNING: Unable to run 'false F_olivaceus.gp', Inappropriate ioctl for device

Installed stable version of gnuplot (5.2.0):
cd ~/bin
wget wget https://downloads.sourceforge.net/project/gnuplot/gnuplot/5.2.0/gnuplot-5.2.0.tar.gz
tar -xvzf gnuplot-5.2.0.tar.gz
cd gnuplot-5.2.0
make install
cd src
./gnuplot --version # confirms the version installed
echo export PATH=$(pwd):$PATH >> ~/.bashrc
source ~/.bashrc

Same problem:
[ljcohen@dev-intel14 mummer]$ mummerplot --fat --filter --png --large -p F_olivaceus F_oli_ONT_Fhet.delta
gnuplot 5.2 patchlevel 0
Writing filtered delta file F_olivaceus.filter
Reading delta file F_olivaceus.filter
Writing plot files F_olivaceus.fplot, F_olivaceus.rplot
Writing gnuplot script F_olivaceus.gp
Rendering plot F_olivaceus.png
WARNING: Unable to run 'false F_olivaceus.gp', Inappropriate ioctl for device

This seems to be a recurring issue with mummerplot. Per a suggestion on this forum page, I was able to fix before by commenting out 3 lines of code that have the word 'mouse' (search for clipboardformat). But that didn't fix the problem this time. Would appreciate any advice.

Installing the previous version of mummer, 3.9.4alpha worked!
[ljcohen@dev-intel14 mummer]$ mummerplot --fat --filter --png --large -p F_olivaceus F_oli_ONT_Fhet.delta
gnuplot 5.2 patchlevel 0
Writing filtered delta file F_olivaceus.filter
Reading delta file F_olivaceus.filter
Writing plot files F_olivaceus.fplot, F_olivaceus.rplot
Writing gnuplot script F_olivaceus.gp
Rendering plot F_olivaceus.png

Although, it does say that the mummerplot version is the same as before, which is odd:
[ljcohen@dev-intel14 mummer]$ mummerplot --version
mummerplot 3.5

for me,it has been solved by installing gnuplot v. 4.6

When I was troubleshooting this issue, I realized that gnuplot was actually what was failing, not so much mummer, the error was indicating that I was using the wrong terminal for this output but no matter whether I specified x11, postscript, or png I was still getting the same error. Turns out, if you installed this software out of a docker container it is failing because this software is still trying to find gnuplot in the docker container, which is causing it to fail.

After a few hours test, I solved this issue. I think the people who got
WARNING: Unable to run 'false out.gp', Inappropriate ioctl for device
is that when they installed mummer, the gnuplot was NOT in the environment path. The solution is simply, change the line 27 in mummerplot
my $GNUPLOT_EXE = "false";

to
my $GNUPLOT_EXE = "gnuplot";

If your gnuplot is in your environment path, just set "gnuplot", if not, put the path there, like what "$LIB_DIR" and "$BIN_DIR" did.
The point why mummer 3x worked but not mummer 4x is that in mummer 3x, they did not have the "$GNUPLOT_EXE" variable, they directly used "gnuplot". But in mummer 4x, they use "$GNUPLOT_EXE" to try to hardcode the path of gnuplot (I guess).

Actually it's the problem of gnuplot, whereas it's the problem of libgd.
when installing gnuplot, you can check the config.log,such as gnuplot-4.4.0/config.log and search png and it may be as follows:
configure:12420: result:   jpeg terminal: no (requires libgd with jpeg support)
configure:12433: result:   gif terminal: no (requires libgd with gif support)
configure:12442: result:   png terminal: no (requires libgd with png support)
configure:12450: result:     (jpeg, gif and png terminals cannot use TTF fonts, requires libgd support)
configure:12466: result:   pdf terminal: no (requires libpdf)
this means that the libgd is not installed and you can download and install it.
however, in some systems, it may encounter problems when you make it, you can test it as follows:
gcc -lgd --verbose
and you can fix it using
export LD_LIBRARY_PATH="/som/place/to/libgd-2.2.5/lib:$LD_LIBRARY_PATH"
and if it don't work, just use
export LIBRARY_PATH="/som/place/to/libgd-2.2.5/lib:$LIBRARY_PATH"

I use mummer v4.x and have not this error, you can try it.

I also had this error.
I followed asdcid's instruction above. The "false xxx.gp" clearly should be "gnplot xxx.gp".
It took me a whole day to solve this. Another thing to realize is the mummer4 only works with gnuplot 4.6, NOT 5.0 or higher.
Here is what I did from the beginning:

Install Anaconda3
sudo wget https://repo.anaconda.com/archive/Anaconda3-2019.07-Linux-x86_64.sh
Anaconda3-2019.07-Linux-x86_64.sh
conda init
source ~/.bashrc
conda config --add channels bioconda    # add channel
unset PYTHONPATH    # this solve an error:  AttributeError: module 'enum' has no attribute 'IntFlag'

Install Gnuplot 4.6,    I had error with the most recent version of gnuplot
sudo  conda install -c bioconda gnuplot=4.6.0

Install mummer4
sudo ./conda install -c bioconda mummer4

Solve an error:  "Can't find PostScript prologue file prologue.ps"

export GNUPLOT_PS_DIR=/home/YOURNAME/anaconda3/share/gnuplot/4.6/

gnuplot need set term with png. If you can not find term with png in your gnuplot, you have to install libgd or more packages. It is up to your system, for example graph-tools.

I had this problem****
gnuplot 5.2 patchlevel 2
Reading mummer file mummer.mums (use mummer -c)
Writing plot files mummer.fplot, mummer.rplot
Writing gnuplot script mummer.gp
Rendering plot mummer.ps
set mouse clipboardformat "[%.0f, %.0f]"
^
"mummer.gp", line 18: wrong option
WARNING: Unable to run 'gnuplot mummer.gp', Inappropriate ioctl for device

Problem gone after removing the "$P_FORMAT .= "\nset mouse clipboardformat "$MFORMAT"";" in line 1154 of mummerplot

I had the similar problem
I realized that i had installed gnuplot (using sudo apt-get install gnuplot)  after mummer installation.
So i uninstalled mummer and re-installed it. and it worked perfectly for me

I had the similar problem
I realized that i had installed gnuplot (using sudo apt-get install gnuplot)  after mummer installation.
So i uninstalled mummer and re-installed it. and it worked perfectly for me

In my case commenting out the single line of the code mentioned by girum89 was not enough. I had to comment out the 3 lines of "$P_FORMAT" (lines 1153, 1154, 1155 of mummerplot file). In the last version of mummer the problem persists:
mummer, 4.0.0rc1
GnuPlot, gnuplot 5.2 patchlevel 8

I tried commenting on all these lines and it still won't work.
mummer 4.0.0rc1
gnuplot 5.0 patchlevel 3

Using mummer3 instead of mummer4 works for me.

This problem seemed to be caused by deletion of function "set mouse clipboard" in gnuplot 5

I had similar issues with mummer/4.0.0rc1 and gnuplot/5.2.8.
I tried many things and, finally, what worked was:

Use mummer4 for whatever purposes to create .delta file (I needed mummer4 specifically, but one could already use mummer3 here)

Use gnuplot/4.6 and mummer/3.23

This gave me the same error as gexijin with  "Can't find PostScript prologue file prologue.ps" and this was resolved as suggested

Hi, I had the trouble with:
WARNING: Unable to run 'false out.gp', Inappropriate ioctl for device
I tried solving it in different ways (as mentioned in some comments here), but it did not work for me. I removed MUMer and gnuplot installed before and started again with this:
Installing the following tools to visualize:
conda install -c conda-forge fig2dev
conda install -c conda-forge xfig
conda install -c conda-forge gnuplot
sudo apt install build-essential

After this I installed MUMer4, but it showed me the same WARNING message. So I uninstalled the MUMer4 and installer the MUMer3 with:
conda install -c bioconda mummer
I hope it works for you.

I had the similar problem I realized that i had installed gnuplot (using sudo apt-get install gnuplot) after mummer installation. So i uninstalled mummer and re-installed it. and it worked perfectly for me

It worked for me!

I followed all the steps above. Definitely check for my $GNUPLOT_EXE = "gnuplot"; as mentioned above. For me, removing "= X11" as the default terminal set in the line $OPT_terminal  = X11;  # -t option worked.

Install the dependencies first:
conda install -c conda-forge fig2dev xfig gnuplot -y
Then install mummer4 from bioconda:
conda install -c bioconda mummer4
Finally, editing the mummerplot script as suggested above, form my $GNUPLOT_EXE = "false" to my $GNUPLOT_EXE = "gnuplot"
These works for me.

Perhaps not the most elegant workaround:
I ran all the mummer4 commands in one environment except for mummerplot.
I created a second environment with mummer3 to call mummerplot (on the mummer4-generated delta file), and I managed to generate plots without any issues from gnuplot.
Just another alternative!

[like]  Stéphane Plaisance reacted to your message:

From: johnstonmj @.>
Sent: Saturday, January 20, 2024 5:36:26 AM
To: mummer4/mummer @.>
Cc: Stéphane Plaisance @.>; Comment @.>
Subject: Re: [mummer4/mummer] mummerplot error message: "Inappropriate ioctl for device" (#36)
Perhaps not the most elegant workaround:
I ran all the mummer4 commands in one environment except for mummerplot.
I created a second environment with mummer3 to call mummerplot (on the mummer4-generated delta file), and I managed to generate plots without any issues from gnuplot.
Just another alternative!
—
Reply to this email directly, view it on GitHubhttps://github.com/mummer4/mummer/issues/36#issuecomment-1901767888, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAGRTFHXW7EIZWZHFALVZSDYPNJVVAVCNFSM4DXVXCZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJQGE3TMNZYHA4A.
You are receiving this because you commented.Message ID: @.***>


Fix dom-repeat-once incorrectly stamping

Fixes #307

Travis failed because of WCT 4.3.0. This is fixed in #309

Confirmed working!
Have reruned the tests after merging 309, I'll see if the pr now gives a green light to merge this pr.

@eanker Make sure to run with wct 4.2.2. The tests should now be fixed.


Rotation of ARWorld

This is a very nice proof of concept. I've learned a lot from it.
However, I think there's a small "unplanned feature" in there: The portal camera rotates along with the main camera, which is good, but also in the rolling rotations (as opposed to just the yaw and pitch), making the entire ARWorld seem to roll when the device is rotated.
I've been trying to solve this by simply ignoring one of the euler angles when setting the portal camera's rotation (in the Update() member of Portal) but I have not yet been successful. Probably because the rotation is hidden somewhere in the quaternion, and a simple euler angle doesn't necessarily refer to it.
Do you perhaps know how to solve this?
Thanks for the lovely POC so far!

All that needs to change is in the update function in Portal.cs:
portalCam.transform.rotation = Quaternion.LookRotation(mainCam.transform.forward, mainCam.transform.up);


createOptions should not be empty string

 "createOptions": "" should be replaced with  "createOptions": "{}" to make the manifest valid.
Otherwise the build task throws a warning Warning: createOptions of module edgeAgent should be an object

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ad3731a8-f0df-f1a1-d1a1-e89a769a0908
Version Independent ID: 50a5190e-eafa-7dde-c18f-be9505b00a0a
Content: Deploy module & routes with deployment manifests - Azure IoT Edge
Content Source: articles/iot-edge/module-composition.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

Hello @algattik
Could you please provide us any screenshot for this build task-Warning?

See also https://github.com/toolboc/IoTEdge-DevOps/pull/13

Hello @algattik Thanks for the confirmation.
Our SME will review the documentation and will update it accordingly.

@algattik Thank you for bringing this to our attention. Most of our documentation uses an empty object for createOptions, but I did a global search and fixed four articles that had examples using an empty string. I'll close this issue as resolved once my changes get merged.


808 fab menu component

Follow up on #809 , remove the error that was triggered by window.console.log in the template code of the test component

Coverage remained the same at 96.28% when pulling 792acc289429879c832b515bf63c8e335d8f06d4 on surstrosti:808-fab-menu-component into 7270040ec8706a8a4c462747dd271af11393992a on mseemann:master.

@leojpod thx a lot!

published :)

@mseemann nice! Thanks!


Version bump to 2.184.0

Auto-generated by fastlane 🤖
Changes since release '2.183.2':

[app store connect] cleanup token creation code across entire project (#18186) via Josh Holtz
[deliver][spaceship] migrate AgeRatingDeclaration from AppStoreVersion to AppInfo for App Store Connect API 1.3 update (#18732) via Josh Holtz
[pilot] introducing timeout feature for Apple build-processing waiting-time (#18660) via Manish Rathi
[action][swiftlint] Added support for --fix mode option (#18695) via Manish Rathi
[resign] fix incorrectly typoed variable name (#18715) via Nick Silvestro
[Fastlane.Swift] fix OptionalConfigValue for Any-based types. (#18664) via Jorge Revuelta
[deliver] remove all instances of is_string in options and use type (#18617) via Josh Holtz
[resign] fix entitlements merging when changing team while resigning (#18713) via Nick Silvestro
[fastlane_core][configuration] suggestion message improvement when fetching value with non symbol key (#18696) via Manish Rathi
[spaceship] update AppStoreConnect SandboxTester doc (#18708) via Yasuharu Yanamura

          1 Warning

:warning:
Big PR

  Generated by :no_entry_sign: Danger

[ ]


fix buffer overflow

Scope & Purpose
Fix a potential buffer overflow when stringfying arbitrary vpack objects

[x] Bug-Fix for devel-branch (i.e. no need for backports?)
[x] The behavior in this PR can be (and was) manually tested (support / qa / customers can test it)
[x] The behavior change can be verified via automatic tests

Testing & Verification
This change is already covered by existing tests, such as scripts/unittest shell_server_aql --test tests/js/common/aql/aql-view-arangosearch-feature.js.
Additionally:

[x] I ensured this code runs with ASan / TSan or other static verification tools

https://<IP_ADDRESS>/view/PR/job/arangodb-matrix-pr/7521/

Obsolete, as Jenkins cannot handle the branch name.


feat: rewrite the linter for spaces before semicolons in Lean

[ ] depends on: #16334

Actually, this reveals a bug in the suggested auto-fix: while lake exe lint-style respects the linter exclusions, the auto-fix doesn't. Marking as awaiting-author.

bors d+


javadoc and sources jar task names should be configurable

Hi folks,
Gradle 6 introduced Built-in javadoc and sources packaging and publishing via
java {
    withJavadocJar()
    withSourcesJar()
}

While this is fantastic, we have found ourselves in the need for changing the default task name for one of them.
Historically we leveraged our own sources jar task under sourceJar which is not populated across several projects and there are specific configurations like archiveBaseName
it would be phenomenal if we could have a way to set the task name for these new tasks.
Something like the following could be great for our use case:
java {
  withJavadocJar('myJavaDocJar')
  withSourcesJar('sourceJar')
}

This is a naive search for usage of sourceJar -> https://github.com/search?l=Gradle&q=sourceJar&type=Code

The whole reason we made these two features an opt-in was that we knew existing builds had to do it on their own, with potentially colliding task names.
So the idea is that you opt-in when you are ready to replace the custom tasks with those provided by these entry points. Note that you can still configure the tasks, they are registered immediately.
So I fail to see what the name change would give you. Keep two different ways of producing a source jar in a single project?

Hi @ljacomet ,
So the current use case for us is the following: https://github.com/nebula-plugins/nebula-publishing-plugin/blob/master/src/main/groovy/nebula/plugin/publishing/publications/SourceJarPlugin.groovy#L37
We created a sourceJar task years ago and we have found several projects where folks configure the task to modify things like the archiveBaseName, ex.
sourceJar.baseName = 'my-shadow-artifact'

I believe our goal is to stay the closest to Gradle OSS offerings so removing custom code for a source jar task and use the new Gradle features is something we would love to do.
With that said, we could try to migrate people to refactor their build files although it isn't a nice experience for them
That's why I was thinking that providing a way to set the task name would be great as it would ease migration for many other folks. Don't know if that makes sense.
Unfortunately, we can't go and include the new one and keep the old one because we would have colliding artifacts for the same module/classifier.
At some point, we would have to see also how shadow plugin adds its own variants for the sources

As mentioned on the PR, closing this for now. Thanks for the input @rpalcolea