duplicate identifier issue

The es6-promise folder in @types folder in node modules created by you package is creating duplicate identifier issues. If we remove it ,then i get "cannot resolve all paramters for AngularIndexedDb" in metadata resolver while running the application.

Hi,
This is a duplicate of #4.


[DOC] Download page Cuda version issue

There is a nit in #8682, we should target the Cuda version change in the download page to 2308 rather than 2306.
If we want to update the doc for the 23.08 branch, we need to first achieve the 23.06 branch’s download page into the archive page. And then put the 23.08 download page there with the modification.
Currently https://github.com/NVIDIA/spark-rapids/blob/branch-23.08/docs/download.md shows 23.06 support 470+ while https://nvidia.github.io/spark-rapids/docs/download.html shows v450.80.02+
We will address this issue in the v2308 release document pr.

Couple of action items for this doc updates:

Change "CUDA & NVIDIA Drivers*: 11.x & v470+" to "NVIDIA Drivers*: 11.x"
remove below sentence: "Users will need to ensure the minimum driver (450.80.02) and CUDA toolkit are installed on each Spark node."
Add "L4 and H100" in the "GPU Models:" section.

@SurajAralihalli

Couple of action items for this doc updates:
1. Change "CUDA & NVIDIA Drivers*: 11.x & v470+" to "NVIDIA Drivers*: 11.x"

Since we statically compile the toolkit, I do not think we need to mention that.  I believe this should be:
NVIDIA Driver*: 470+

Correct @sameerz  i corrected that typo in the previous comment.

This package is built against CUDA 11.8, all CUDA 11.x and 12.x versions are supported through [CUDA forward
compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/index.html). It is tested
on V100, T4, A2, A10, A30, A100, L4 and H100  GPUs with CUDA 11.8-12.0.  For those using other types of GPUs
which do not have CUDA forward compatibility (for example, GeForce), CUDA 11.8 or later is required.

yes we can keep those

I suggest we change to the following, removing A2 and A30.  They should work as we support Ampere.  We are no longer doing formal QA on those cards.
This package is built against CUDA 11.8, all CUDA 11.x and 12.x versions are supported through [CUDA forward
compatibility](https://docs.nvidia.com/deploy/cuda-compatibility/index.html). It is tested
on V100, T4, A10, A100, L4 and H100  GPUs with CUDA 11.8-12.0.  For those using other types of GPUs
which do not have CUDA forward compatibility (for example, GeForce), CUDA 11.8 or later is required.

Done by https://github.com/NVIDIA/spark-rapids/pull/8948 @SurajAralihalli


TF2 kills doesn't work

The kills for stranges require CMsgIncrementKillCountAttribute instead of CMsgIncrementKillCountAttribute_Multiple or batched.

It should work. A CMsgIncrementKillCountAttribute_Multiple is just multiple of CMsgIncrementKillCountAttribute. Try setting incrementValue to 1 (or null I don't remember, try both) and repeat to something like 1000.

Having it set to null did it, thanks.


[ja] Translate /docs/tasks/configure-pod-container/configure-persistent-volume-storage into Japanese

This is a Feature Request

What would you like to be added

Translate https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/ into Japanese
Why is this needed
Comments

/language ja
/assign

No PR has been raised yet (8+ month) + no interest from any other contributor in localizing this page
/close not-planned


collectionengine: fix sorting of relation columns by using seralize

serialize seems to work (already does in filtering) for relation columns (flattening the relation to array and accessing the column with dot notation)

thanks @smb! Released on v5.11.10


Total Difficulty in Header accumulator or not?

Currently, the EpochAccumulator holds HeaderRecord which holds the total_difficulty field that gets updated on each BlockHeader update.
This issue is about whether we should restructure this object and/or remove total_difficulty from it.
cons:
The inclusion of total_difficulty in a HeaderRecord means that to create an EpochAccumulator for a specific epoch, you need, next to the headers, access to the total difficulty from the last record of the previous EpochAccumulator.
This means no parallelization is possible when creating the MasterAccumulator and all EpochAccumulator. However, that is not really an issue as it is something that needs to be done once to inject into the Portal history network and it doesn't take that long when you already have all the headers downloaded & stored locally.
There might be other uses cases however where this is a an issue.
One such case is for the storage of historical data in (era) files per epoch (8192 blocks), a hash_tree_root of the EpochAccumulator can be provided, so that the blocks in the file can be verified. However, with the total_difficulty included this would be more difficult as access to the previous total difficulty would also be required. But perhaps the solution here is just adding the previous total difficulty in the file?  @lightclient
pros:
With the total_difficulty per block accessible, the totalDifficulty in the eth_getBlockByHash / eth_getBlockByNumber can be provided. For Portal specific, this does require a rather large object (EpochAccumulator) to be downloaded for just this value. This is not ideal in the first place.
There might be other use cases where the value is useful that I'm not aware of.
(Another, minor, benefit is that when building the MasterAccumulator, one can find the merge point, not just by some hard defined merge block number, but by comparing the total difficulty with TTD.)
There could be some hybrid options too, for example where the MasterAccumulator gets split in a list of block hashes and a list of total_difficulties, or similar.

Hi @kdeme. Yes seems like lot's of potential designs possible for this. Is there something specific you'd like to accomplish? The current format is sufficient for my needs, however it would be marginally simpler for me to remove the total difficulty altogether because it isn't necessary for my use case.

@lightclient can you describe our explain your use case? In an EIP4444 context of geth fetches a historical block, how would it return totaldifficulty for
Sent from Proton Mail mobile
-------- Original Message --------
On Mar 9, 2023, 8:14 AM, lightclient wrote:

Hi @.***(https://github.com/kdeme). Yes seems like lot's of potential designs possible for this. Is there something specific you'd like to accomplish? The current format is sufficient for my needs, however it would be marginally simpler for me to remove the total difficulty altogether because it isn't necessary for my use case.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

My use case is simply focused on exporting, sharing, and importing the full pre-merge chain. Being able to return historical block over JSON-RPC w/o any additional processing is a bonus, but not something I am looking into actively right now. The nimbus team might be more interested in that.
I'm trying to avoid boiling the ocean here and get an initial agreed upon format out there so data providers can start providing historical blocks in bulk (e.g. eras) and users can import them to their client. The import works similarly to having a blocks.rlp file. The client has to process the blocks and ingest them to their own database. Along the way, the client likely has its own mechanism for tracking the total difficulty. Therefore, for my use case today, it isn't necessary.

And you are onboard with using the format we are using that includes total difficulty? We'd very much like to use the same format/schema as you and we also would like to have total difficulty available to us.
@kdeme assuming lightclient says yes, if suggest you make an executive decision here on final
Sent from Proton Mail mobile
-------- Original Message --------
On Mar 9, 2023, 8:30 AM, lightclient wrote:

My use case is simply focused on exporting, sharing, and importing the full pre-merge chain. Being able to return historical block over JSON-RPC w/o any additional processing is a bonus, but not something I am looking into actively right now. The nimbus team might be more interested in that.
I'm trying to avoid boiling the ocean here and get an initial agreed upon format out there so data providers can start providing historical blocks in bulk (e.g. eras) and users can import them to their client. The import works similarly to having a blocks.rlp file. The client has to process the blocks and ingest them to their own database. Along the way, the client likely has its own mechanism for tracking the total difficulty. Therefore, for my use case today, it isn't necessary.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

Yes I am happy with the current format which has total difficulty. Definitely want to use the same format as you if possible!


Release v1.48.0

To pick up these 24 commits https://github.com/libuv/libuv/compare/v1.47.0...v1.x
and also probably the last release with Windows 8 support?
desired:

#4279
#4241

optional:

#4278
#3743

Desired item #4241 has been superseded by #4292.

I also just stumbled across comments in the dotnet repo that pointed to documentation that seem to suggest a function was being used improperly for ESRCH in libuv. Seemed like a pretty simple change so I went ahead and made a PR that I think should fix it: https://github.com/libuv/libuv/pull/4301. If that PR looks okay to others, should we slip that into this release?

Libuv in Node CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/231/
There are 2 concerning failures:

macos failures related to signal handling: https://ci.nodejs.org/job/node-test-commit-osx/56944/ and https://ci.nodejs.org/job/node-test-commit-osx-arm/15648/ which are caused by this: https://github.com/libuv/libuv/issues/4299.
Crash on multiple platforms of the test sequential.test-performance-eventloopdelay , sequential.test-performance-eventloopdelay, etc.

Looking into those before making the release.

Let's revert https://github.com/libuv/libuv/commit/b9421d70665352138557d2d2338656a38ac70691 for this release until there is time to look into that. It sounds like a kernel bug (since there is a C reproducer), and while it only impacts the tests, it seems inconvenient to have that be breaking for now. I am also not certain how nodejs detects this issue, since libuv should have been the only one to install signal handlers.

Let's revert b9421d7

Will do.

I am also not certain how nodejs detects this issue, since libuv should have been the only one to install signal handlers.

Node.js installs signal handlers both using libuv and using sigaction() directly.

For the exact same signals though? That sounds a bit unreliable (because of exactly this bug), though not entirely unreasonable. The next phase after b9421d7 though might be to implement full signal chaining, so as soon as the libuv handler finishes, it calls the next one in the chain, hiding the existence of the libuv sigaction call from the user (aside from if they or libuv tries to go unregister it later and unregisters libuv instead)
The output I could find for the other test seems fairly worthless. Is this all that nodejs gives for info when a test crashes?
not ok 4091 sequential/test-performance-eventloopdelay
  ---
  duration_ms: 7328.51100
  severity: crashed
  exitcode: -11
  stack: |-
  ...

For the exact same signals though?

Yes, it may happen for SIGINT and SIGTERM. Nodejs installs its own handlers on bootstrap using sigaction() directly, and later on a user can install their own handlers for those signals: in this case it uses the  uv_signal_t API.

Revert PR: https://github.com/libuv/libuv/pull/4302

Current status: bisecting, as the coredump I could get didn't provide much info.

Click to expand!
Core was generated by `out/Debug/node --expose-internals --expose-gc test/parallel/test-performance-ev'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007ffc1a86f420 in ?? ()
[Current thread is 1 (Thread 0x7f142dcc9880 (LWP 1167554))]
(gdb) bt
#0  0x00007ffc1a86f420 in ?? ()
#1  0x0000562c6e716710 in ?? ()
#2  0x0000562c6e6dfbf0 in ?? ()
#3  0x0000562c6e72bd10 in ?? ()
#4  0x0000562c6e72bd00 in ?? ()
#5  0x00007ffc1a86f470 in ?? ()
#6  0x3e54286becaeb000 in ?? ()
#7  0x000000011a86f470 in ?? ()
#8  0x0000562c6e766830 in ?? ()
#9  0x00007ffc1a86f530 in ?? ()
#10 0x0000562c65bd8080 in node::SpinEventLoopInternal (env=0x562c65ebcc58 <node::PerIsolatePlatformData::FlushForegroundTasksInternal()+614>) at ../src/api/embed_helpers.cc:44
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread apply all bt

Thread 10 (Thread 0x7f142d4c5640 (LWP 1167733)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x562c6e70c300) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x562c6e70c300) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x562c6e70c300, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x00007f142dd61a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x562c6e70c2b0, cond=0x562c6e70c2d8) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ./nptl/pthread_cond_wait.c:627
#5  0x0000562c676b9f57 in uv_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../deps/uv/src/unix/thread.c:814
#6  0x0000562c65d30db6 in node::LibuvMutexTraits::cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../src/node_mutex.h:175
#7  0x0000562c65d32671 in node::ConditionVariableBase<node::LibuvMutexTraits>::Wait (this=0x562c6e70c2d8, scoped_lock=...) at ../src/node_mutex.h:249
#8  0x0000562c65ec007d in node::TaskQueue<v8::Task>::BlockingPop (this=0x562c6e70c2b0) at ../src/node_platform.cc:605
#9  0x0000562c65ebadf0 in node::(anonymous namespace)::PlatformWorkerThread (data=0x562c6e70cab0) at ../src/node_platform.cc:42
#10 0x00007f142dd62ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#11 0x00007f142ddf4850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 9 (Thread 0x7f1427fff640 (LWP 1167735)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x562c6e70c300) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x562c6e70c300) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x562c6e70c300, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x00007f142dd61a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x562c6e70c2b0, cond=0x562c6e70c2d8) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ./nptl/pthread_cond_wait.c:627
#5  0x0000562c676b9f57 in uv_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../deps/uv/src/unix/thread.c:814
#6  0x0000562c65d30db6 in node::LibuvMutexTraits::cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../src/node_mutex.h:175
#7  0x0000562c65d32671 in node::ConditionVariableBase<node::LibuvMutexTraits>::Wait (this=0x562c6e70c2d8, scoped_lock=...) at ../src/node_mutex.h:249
#8  0x0000562c65ec007d in node::TaskQueue<v8::Task>::BlockingPop (this=0x562c6e70c2b0) at ../src/node_platform.cc:605
#9  0x0000562c65ebadf0 in node::(anonymous namespace)::PlatformWorkerThread (data=0x562c6e70ce00) at ../src/node_platform.cc:42
#10 0x00007f142dd62ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#11 0x00007f142ddf4850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 8 (Thread 0x7f142ccc4640 (LWP 1167734)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x562c6e70c300) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x562c6e70c300) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x562c6e70c300, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x00007f142dd61a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x562c6e70c2b0, cond=0x562c6e70c2d8) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ./nptl/pthread_cond_wait.c:627
#5  0x0000562c676b9f57 in uv_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../deps/uv/src/unix/thread.c:814
#6  0x0000562c65d30db6 in node::LibuvMutexTraits::cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../src/node_mutex.h:175
#7  0x0000562c65d32671 in node::ConditionVariableBase<node::LibuvMutexTraits>::Wait (this=0x562c6e70c2d8, scoped_lock=...) at ../src/node_mutex.h:249
#8  0x0000562c65ec007d in node::TaskQueue<v8::Task>::BlockingPop (this=0x562c6e70c2b0) at ../src/node_platform.cc:605
#9  0x0000562c65ebadf0 in node::(anonymous namespace)::PlatformWorkerThread (data=0x562c6e70cc60) at ../src/node_platform.cc:42
#10 0x00007f142dd62ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#11 0x00007f142ddf4850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 7 (Thread 0x7f142dcc6640 (LWP 1167691)):
#0  0x00007f142ddf3b68 in __GI_epoll_pwait (epfd=11, events=0x7f142dcc2c50, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
#1  0x0000562c676c15e7 in uv__io_poll (loop=0x562c6e70c4c8, timeout=-1) at ../deps/uv/src/unix/linux.c:1432
#2  0x0000562c676a4552 in uv_run (loop=0x562c6e70c4c8, mode=UV_RUN_DEFAULT) at ../deps/uv/src/unix/core.c:448
#3  0x0000562c65ebedd6 in node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Run (this=0x562c6e70c3c0) at ../src/node_platform.cc:95
#4  0x0000562c65ebe974 in node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start()::{lambda(void*)#1}::operator()(void*) const (__closure=0x0, data=0x562c6e70c3c0) at ../src/node_platform.cc:64
#5  0x0000562c65ebe998 in node::WorkerThreadsTaskRunner::DelayedTaskScheduler::Start()::{lambda(void*)#1}::_FUN(void*) () at ../src/node_platform.cc:65
#6  0x00007f142dd62ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#7  0x00007f142ddf4850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 6 (Thread 0x7f142c422640 (LWP 1168198)):
#0  __futex_abstimed_wait_common64 (private=<optimized out>, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x562c6c78e1a0 <node::inspector::(anonymous namespace)::start_io_thread_semaphore>) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=<optimized out>, abstime=0x0, clockid=0, expected=0, futex_word=0x562c6c78e1a0 <node::inspector::(anonymous namespace)::start_io_thread_semaphore>) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x562c6c78e1a0 <node::inspector::(anonymous namespace)::start_io_thread_semaphore>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=<optimized out>) at ./nptl/futex-internal.c:139
#3  0x00007f142dd6abdf in do_futex_wait (sem=sem@entry=0x562c6c78e1a0 <node::inspector::(anonymous namespace)::start_io_thread_semaphore>, abstime=0x0, clockid=0) at ./nptl/sem_waitcommon.c:111
#4  0x00007f142dd6ac78 in __new_sem_wait_slow64 (sem=0x562c6c78e1a0 <node::inspector::(anonymous namespace)::start_io_thread_semaphore>, abstime=0x0, clockid=0) at ./nptl/sem_waitcommon.c:183
#5  0x0000562c676b9c41 in uv__sem_wait (sem=0x562c6c78e1a0 <node::inspector::(anonymous namespace)::start_io_thread_semaphore>) at ../deps/uv/src/unix/thread.c:639
#6  0x0000562c676b9db8 in uv_sem_wait (sem=0x562c6c78e1a0 <node::inspector::(anonymous namespace)::start_io_thread_semaphore>) at ../deps/uv/src/unix/thread.c:695
#7  0x0000562c65feb3dc in node::inspector::(anonymous namespace)::StartIoThreadMain (unused=0x0) at ../src/inspector_agent.cc:82
#8  0x00007f142dd62ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#9  0x00007f142ddf4850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 5 (Thread 0x7f14277fe640 (LWP 1167736)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x562c6e70c304) at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x562c6e70c304) at ./nptl/futex-internal.c:87
#2  __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x562c6e70c304, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x00007f142dd61a41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x562c6e70c2b0, cond=0x562c6e70c2d8) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ./nptl/pthread_cond_wait.c:627
#5  0x0000562c676b9f57 in uv_cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../deps/uv/src/unix/thread.c:814
#6  0x0000562c65d30db6 in node::LibuvMutexTraits::cond_wait (cond=0x562c6e70c2d8, mutex=0x562c6e70c2b0) at ../src/node_mutex.h:175
#7  0x0000562c65d32671 in node::ConditionVariableBase<node::LibuvMutexTraits>::Wait (this=0x562c6e70c2d8, scoped_lock=...) at ../src/node_mutex.h:249
#8  0x0000562c65ec007d in node::TaskQueue<v8::Task>::BlockingPop (this=0x562c6e70c2b0) at ../src/node_platform.cc:605
#9  0x0000562c65ebadf0 in node::(anonymous namespace)::PlatformWorkerThread (data=0x562c6e70cf70) at ../src/node_platform.cc:42
#10 0x00007f142dd62ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#11 0x00007f142ddf4850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 4 (LWP 1167783):
#0  0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x0

Thread 3 (LWP 1167732):
#0  0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x0

Thread 2 (LWP 1167690):
#0  0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x0

Thread 1 (Thread 0x7f142dcc9880 (LWP 1167554)):
#0  0x00007ffc1a86f420 in ?? ()
#1  0x0000562c6e716710 in ?? ()
#2  0x0000562c6e6dfbf0 in ?? ()
#3  0x0000562c6e72bd10 in ?? ()
#4  0x0000562c6e72bd00 in ?? ()
#5  0x00007ffc1a86f470 in ?? ()
#6  0x3e54286becaeb000 in ?? ()
#7  0x000000011a86f470 in ?? ()
#8  0x0000562c6e766830 in ?? ()
#9  0x00007ffc1a86f530 in ?? ()
#10 0x0000562c65bd8080 in node::SpinEventLoopInternal (env=0x562c65ebcc58 <node::PerIsolatePlatformData::FlushForegroundTasksInternal()+614>) at ../src/api/embed_helpers.cc:44
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Frame 10 of thread 1 is a call to platform->DrainTasks() but it goes completely off the rails. I would've expected to see NodePlatform::DrainTasks() in the next frame.

It looks more like an unwinder bug to me (probably gdb to v8 integration is disabled so the unwinding cannot occur correctly). I suspect none of those frames are right, given:
#6  0x3e54286becaeb000 in ?? ()

That would've been my guess too but I don't think that code path calls into JS code. Disassembly of the top most frame will probably tell though; V8-generated machine code has a very specific vibe to it.

Is it possible to run nodejs with the v8 JIT configured with the equivalent of -fno-omit-frame-pointer? It seems that many distros are now starting to set that option by default, since it provides mostly negligible performance improvements but breaks debugging and slows down perf tools quite substantially (https://chromium.googlesource.com/v8/v8.git/+/branch-heads/5.9/Makefile#232 maybe?)

Is it possible to run nodejs with the v8 JIT configured with the equivalent of -fno-omit-frame-pointer?

No. V8 uses a completely different calling convention, it's not due to lack of frame pointers. There is gdb integration (the --gdb switch to configure) but it has a tendency to bitrot so YMMV.

In order to reproduce it locally on my linux x64 box I had to really push it:
# Debug build
$ ./configure --debug && make -j12

# Run 300 instances of the test in parallel a few times until some crashes happened
$ for i in $(seq 1 300); do out/Debug/node --expose-internals --expose-gc test/parallel/test-performance-eventloopdelay.js & done

Also, I'm at the moment building node in one of the ci instances where the issue seems to happen consistently.

Okay, I see segfaults with that too. That makes it really trival to throw rr in front of that and then replay the failing trace

It looks like the stack gets pretty badly smashed somewhere around, since we start the function call with a frame that looks like this
(rr) bt
#0  0x0000556ea22bc87c in node::NodePlatform::DrainTasks (this=0x556eaa5aeb40, isolate=0x556eaa5e4370) at ../src/node_platform.cc:462
#1  0x0000556ea1fd8080 in node::SpinEventLoopInternal (env=0x556eaa648260) at ../src/api/embed_helpers.cc:44
#2  0x0000556ea2257996 in node::NodeMainInstance::Run (this=0x7fff3cebff70, exit_code=0x7fff3cebfec4, env=0x556eaa648260) at ../src/node_main_instance.cc:124
#3  0x0000556ea2257824 in node::NodeMainInstance::Run (this=0x7fff3cebff70) at ../src/node_main_instance.cc:100
#4  0x0000556ea211e8c2 in node::StartInternal (argc=4, argv=0x556eaa5698a0) at ../src/node.cc:1434
#5  0x0000556ea211e994 in node::Start (argc=4, argv=0x7fff3cec01a8) at ../src/node.cc:1441
#6  0x0000556ea403a026 in main (argc=4, argv=0x7fff3cec01a8) at ../src/node_main.cc:97

and then we return from that DrainTasks into no-mans-land
rr says the stack corruption happened here:
(rr) bt
#0  uv__queue_remove (q=0x556eaa7c9bc8) at ../deps/uv/src/queue.h:87
#1  0x0000556ea3aab497 in uv_timer_stop (handle=0x556eaa7c9b60) at ../deps/uv/src/timer.c:110
#2  0x0000556ea3aab76b in uv__timer_close (handle=0x556eaa7c9b60) at ../deps/uv/src/timer.c:201
#3  0x0000556ea3ab0bf2 in uv_close (handle=0x556eaa7c9b60, close_cb=0x556ea20ded0e <node::HandleWrap::OnClose(uv_handle_s*)>) at ../deps/uv/src/unix/core.c:187
#4  0x0000556ea20de98d in node::HandleWrap::Close (this=0x556eaa7c9ad0, close_callback=...) at ../src/handle_wrap.cc:76
#5  0x0000556ea20deaf2 in node::HandleWrap::OnGCCollect (this=0x556eaa7c9ad0) at ../src/handle_wrap.cc:95
#6  0x0000556ea20145eb in operator() (__closure=0x0, data=...) at ../src/base_object.cc:69
#7  0x0000556ea201460f in _FUN () at ../src/base_object.cc:70
#8  0x0000556ea29a4ee8 in v8::internal::GlobalHandles::PendingPhantomCallback::Invoke (type=v8::internal::GlobalHandles::PendingPhantomCallback::kFirstPass,
    isolate=<optimized out>, this=0x556eaa7b44b0) at ../deps/v8/src/handles/global-handles.cc:866
#9  v8::internal::GlobalHandles::InvokeFirstPassWeakCallbacks (this=0x556eaa5fa6b0) at ../deps/v8/src/handles/global-handles.cc:840
#10 0x0000556ea2ae2809 in v8::internal::Heap::PerformGarbageCollection (this=0x556eaa5f1d20, collector=v8::internal::GarbageCollector::SCAVENGER, gc_reason=<optimized out>,
    collector_reason=<optimized out>) at ../deps/v8/src/execution/isolate.h:1326
#11 0x0000556ea2ae3a8d in operator() (__closure=__closure@entry=0x7fff3cebfaa0) at ../deps/v8/src/heap/heap.cc:1871
#12 0x0000556ea2ae6d14 in heap::base::Stack::SetMarkerAndCallbackImpl<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::<lambda()> >(heap::base::Stack *, void *, const void *) (stack=0x556eaa5f4888, argument=0x7fff3cebfaa0, stack_end=0x7fff3cebfa20)
    at ../deps/v8/src/heap/base/stack.h:95
#13 0x0000556ea3a22467 in PushAllRegistersAndIterateStack ()
#14 0x0000556ea2ae49d6 in heap::base::Stack::SetMarkerIfNeededAndCallback<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags)::<lambda()> > (callback=..., this=<optimized out>) at ../deps/v8/src/heap/base/stack.h:60
#15 v8::internal::Heap::CollectGarbage (this=this@entry=0x556eaa5f1d20, space=space@entry=v8::internal::NEW_SPACE,
    gc_reason=gc_reason@entry=v8::internal::GarbageCollectionReason::kTask, gc_callback_flags=gc_callback_flags@entry=v8::kNoGCCallbackFlags)
    at ../deps/v8/src/heap/heap.cc:1835
#16 0x0000556ea2b6412f in v8::internal::MinorGCJob::Task::RunInternal (this=0x556eaa7c9f80) at ../deps/v8/src/heap/minor-gc-job.cc:102
#17 0x0000556ea22bc5a8 in node::PerIsolatePlatformData::RunForegroundTask (this=0x556eaa5f9980, task=std::unique_ptr<v8::Task> = {...}) at ../src/node_platform.cc:425
#18 0x0000556ea22bcc13 in node::PerIsolatePlatformData::FlushForegroundTasksInternal (this=0x556eaa5f9980) at ../src/node_platform.cc:499
#19 0x0000556ea22bc881 in node::NodePlatform::DrainTasks (this=0x556eaa684600, isolate=0x556eaa684608) at ../src/node_platform.cc:462
Backtrace stopped: frame did not save the PC

That points to commit 51a22f60d6f41a92b68def1f048e53b593037d11, which btw is the bisect last step I'm currently running

It looks like uv__queue_remove might get called multiple times (from repeated uv_timer_stop calls) after that commit, despite not being idempotent (it removes itself from the queue, but doesn't reinitialize its own queue)?

Looks like https://github.com/libuv/libuv/pull/4250#pullrequestreview-1783629163 might have had the correct code, but it didn't get copied into the PR correctly?

So, are we talking about smthg like this?
diff --git a/src/timer.c b/src/timer.c
index b57d64277..7847a15c2 100644
--- a/src/timer.c
+++ b/src/timer.c
@@ -104,10 +104,12 @@ static void timer_stop(uv_timer_t* handle) {

 int uv_timer_stop(uv_timer_t* handle) {
-  if (uv__is_active(handle))
+  if (uv__is_active(handle)) {
     timer_stop(handle);
-  else
+  } else {
     uv__queue_remove(&handle->node.queue);
+    uv__queue_init(&handle->node.queue);
+  }
   return 0;
 }

I've tested locally and I couldn't reproduce the crash.

yes, that looks like what I was thinking, though it doesn't need to be conditional. I can also confirm that running Ben's while loop a few times doesn't crash anymore with that change.

I opened https://github.com/libuv/libuv/pull/4304. PTAL

CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/242/

This is done. Sorry I messed up with the last commits but the GH Security Advisory feature was broken and didn't allowed me to merge the advisory with branch protections (even though it said it would bypass them), so I manually merged it and after the fact I figured out that I had to disable the protections manually in order to merge the advisory.

I think it might because we don't allow admins to bypass branch protections? I usually briefly disable it around a release so that the script will work correctly to push the release and tag it

Yes I understand, but the SA UI had a tick to bypass the branch protections. It didn't work

Just a minor nit that release name for 1.48.0 still mentions 1.47.0:

Just a minor nit that release name for 1.48.0 still mentions 1.47.0

Fixed. Thanks!

Just a minor nit that release name for 1.48.0 still mentions 1.47.0:

FYI I just edited the date in the release name to "2024.02.07".


Android installer does not download the SDK, NDK and OpenJDK folders to PlaybackEngines/AndroidPlayer

Installing the Android module with Unity Hub and Install-UnitySetupInstance yield different results. Notably, the following folders are missing in Editor\Data\PlaybackEngines\AndroidPlayer with the latter:

NDK
OpenJDK
SDK

Repro:
Find-UnitySetupInstaller -Version '2020.3.37f1' -Components 'Windows','Android' | Install-UnitySetupInstance

UnitySetup predates UnityHub and discovers downloads by scanning the releases websites, downloads the components and invokes them itself. The Unity installer used to bundle the Android tools in with the component, but that was split at some point to avoid duplicates of the tools if you don't need them (you can set the paths for you Android build tools inside Unity).
I'd love to install the Android tools from UnitySetup, but installing Android requires accepting the license agreement and I'm not sure how best to go about that in an automated fashion that doesn't run afoul of some policy so I've avoided it so far.
Open to ideas though!

So I know UnitySetup predates the UnityHub, but can it use the UnityHub?
 I just got this in email when I complained to Unity that wasn't a way to headlessly install Android JDK/SDK/NDK tools:

The hub does support a command line to do the full installation, including Child Modules (Open JDK + Android SDK & NDK), this would be the command to install Android + the JDK & NDK to an existing Unity installation:

"Unity Hub.exe" -- --headless install-modules --version 2020.3.38f1 -m android --cm

To install it all from scratch then something like this should work:

"Unity Hub.exe" -- --headless install --version 2020.3.38f1 -m android --cm

Is the Hub installed with the Unity installation? Could Android be added on after the original install?

I think moving to UnityHub would be a great change, but also a large one that will need lots of testing for all the use cases included in UnitySetup, e.g. the DSC resources.
I'm not sure if the Hub comes along with Unity if it's installed with UnitySetup, we'd have to test that from a clean machine. I suspect Android could be installed after the original install, but it'd be another thing to test.

Same problem, my android build requires NDK and installing via following wont install NDK
 Install-UnitySetupInstance -Installers (Find-UnitySetupInstaller -Version '$(unitygetprojectversion.projectVersion)' -Components 'Windows', 'Android') -Verbose
@mandalorianbob did you test unity hub method with NDK?


ID modifications but with text input

Hello and congrats on your great work! Just to clarify something: Is it possible to generate new images for the same id but providing a text input to guide the modification? Eg change hair color or pose etc.
Thanks in advance.

Hi,
As mentioned above the models have been intentionally overfitted to the default prompt ("photo of an id person") to focus on ArcFace embeddings and maximize ID similarity. The fine-tuned encoder will, thus, not work with other prompts. A workaround would be to combine its output with the text embeddings from the original CLIP encoder or to integrate text via an external adapter (IP-Adapter, ControlNet). In both cases, you would likely need to fine-tune the model - either the UNet or the external module - for text-driven generation.


Tests for var args version of allFinite and anyFinite #18

Improving code coverage a little bit

👍 thanks!


🐛 Bug Report: 1.27 GitLab discovery regression when using fallbackBranch other than master

📜 Description
Since Backstage 1.27, gitlab discovery is failing to find multiple projects during discovery.
The following configuration in Backstage 1.26 will find GitLab projects that have their default branch set to 'develop'. The same configuration using Backstage 1.27 will only find projects that have a catalog-info.yaml file in the same repository as is set by fallbackBranch
catalog:
  providers:
    gitlab:
      gitlab-instance:
        host: gitlab.host
        fallbackBranch: main
        schedule:
          frequency: { minutes: 30 }
          timeout: { minutes: 10 }

The regression is introduced in https://github.com/backstage/backstage/commit/a70377d3e1902480cbae14b2c7a861514f0a61ff where
      const project_branch =
        this.config.branch ??
        project.default_branch ??
        this.config.fallbackBranch;

in plugins/catalog-backend-module-gitlab/src/providers/GitlabDiscoveryEntityProvider.ts was changed to
    const customFallbackBranch =
      this.config.fallbackBranch !== 'master'
        ? this.config.fallbackBranch
        : undefined;

    const project_branch =
      this.config.branch ??
      customFallbackBranch ??
      project.default_branch ??
      this.config.fallbackBranch;

Here, customFallbackBranch takes precedence over the default branch set in GitLab on project level.
👍 Expected behavior
Find all GitLab projects where a catalog-info.yaml file exists in the default branch of that repository
👎 Actual Behavior with Screenshots
catalog info Processed 0 from scanned 0 projects. target=GitlabDiscoveryEntityProvider:gitlab-instance class=GitlabDiscoveryEntityProvider taskId=GitlabDiscoveryEntityProvider:gitlab-instance:refresh taskInstanceId=ec82cb6d-4138-49d9-92f7-2d0e5ea8ffc4

👟 Reproduction steps
Using an on-prem GitLab, configure multiple repositories with different default branches. In addition, configure backstage so that fallbackBranch is set to another value than master, e.g. main
📃 Provide the context for the Bug.
On-prem GitLab instance
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

Thank you for reporting!
@elaine-mattos since you're probably the one most familiar with the new setup, I wanted to check whether you think there's a simple fix here?

Hi, I'll take a look at it soon, no later than tomorrow!

Hi @Rugvip ,
we were testing a very specific use case at our installation and I forgot to remove this piece of code, sorry!
I have fixed it by removing the custom fallback branch and improved the tests a little bit, so that such bugs won't happen again.
Here's the PR: https://github.com/backstage/backstage/pull/24838


Error installing mixpanel

I get the following error when I added mixpanel to my existing project. I installed the SDK and linked the appropriate files as documented.
Undefined symbols for architecture x86_64:
  "_utf8_nextCharSafeBody", referenced from:
      _validate_dispatch_data_partial_string in libMixpanel.a(MPWebSocket.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Solved it had to add -licucore to Other Linker Flags in the main Xcode Project Build Settings

I'm having the same issue. I added -licucore, but it didn't fix it. Was there anything else you had to do?

@faceyspacey are you seeing the same error after adding -licucore ?

I was, i had to manually add libMixPanel.a. Not sure it wasn't added by the coca pod build phase. But the combination of the two made it work.

Can we please update the installation instructions to include this?

@faceyspacey  where did u add libMixPanel .a from ?
I am getting this same issue , and i am not using cocoapods for installing the sdk .
@arunshan  please help .

Anyone having this issue, try installing mixpanel via podfile
sudo gem install -n /usr/local/bin cocoapods
cd ./ios
pod init
Open the "Podfile" and add the line pod 'Mixpanel' inside the main target
pod install
then probably react-native link again
This solved any missing dependencies, architecture issues and mach-o linker errors that I was having trying to install this package.


Correction for raw affiliation Laboratory of Molecular and Cellular Neurophysiology, School of Life Science, East China Normal University, Shanghai 200062, China ; Differentiation & Cell Cycle Group, Laboratory of Molecular and Cellular Science, UMR 5239 CNRS/ENS Lyon/University of Lyon 1, Ecole Normale Supérieure de Lyon, IFR128 "Biosciences Lyon-Gerland" Lyon, 69007, France.

Correction needed for raw affiliation Laboratory of Molecular and Cellular Neurophysiology, School of Life Science, East China Normal University, Shanghai 200062, China ; Differentiation & Cell Cycle Group, Laboratory of Molecular and Cellular Science, UMR 5239 CNRS/ENS Lyon/University of Lyon 1, Ecole Normale Supérieure de Lyon, IFR128 "Biosciences Lyon-Gerland" Lyon, 69007, France.
raw_affiliation_name: Laboratory of Molecular and Cellular Neurophysiology, School of Life Science, East China Normal University, Shanghai 200062, China ; Differentiation & Cell Cycle Group, Laboratory of Molecular and Cellular Science, UMR 5239 CNRS/ENS Lyon/University of Lyon 1, Ecole Normale Supérieure de Lyon, IFR128 "Biosciences Lyon-Gerland" Lyon, 69007, France.
new_rors: 04zmssz18;029brtt94;02feahw73;02n96ep67;01bj4fd12
previous_rors: 04zmssz18;029brtt94;02feahw73;02n96ep67
works_examples: W84945568
contact: ae19adc2dc372d53ad330d54d7dff9c3:bb08b555ffb607b57a7342d9540c @ ens-lyon.fr

This issue was accepted and ingested by the OpenAlex team on 2024-11-01. The new affiliations should be visible within the next 7 days.


Nuget Builds For Components

Not sure if this should be separated out into separate projects. I mean, do the core components get included but built separately? They need to reference the nuget project to be able to be pulled down...so.
This needs to be figured out BEFORE going live with the open source part.

Having said that, keeping them separate for now. It is only for ticket logging and making project management a little easier


quic: Fix QuicFilterManagerConnectionImpl::ConnectionInfoProviderSharedPtr

quic: Fix QuicFilterManagerConnectionImpl::ConnectionInfoProviderSharedPtr
If QuicFilterManagerConnectionImpl::ConnectionInfoProviderSharedPtr is
called after the connection is closed, return nullptr.
Risk Level: Low
Testing: New unit tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

/assign @danzh2010

/assign @alyssawilk

/retest


"run_static" - Documentation issues

The description in the documentation of the variables contained in the dictionary does not match with real ones. There are some mismatched capital letters. It would be nice to follow a standard.

Another suggestion is to include units in the dict.
Other possibility is to include all the data directly on the rotor object, without creating a dictionary. I did not understood the logic when an information became a dict or when is attribute to the rotor or to the results of the method.

force_data dictionary has been removed.
Now, the following items from force_data became Rotor's attributes:

shaft_weight - Shaft total weight
disk_forces - Weight forces of each disk
bearing_reaction_forces - The static reaction forces on each bearing

Rotor.run_static() docstring's been updated

Just to clarify: Shaft total weight is the sum of the shaft elements or is the rotor (shaft + lumped mass)?
A summary of the rotor is a helpful tool to ensure that are no errors in the model, to perform double checks if the node is the rigth one and so on.
See the example from ROMAC:

They provide also the global nodes summary (there is a feature to create a automatic discretization of the rotor):
This is the model:

This is the visualization of the final nodes:

XLTRC2 also provides the summary:

Information as Inertias, CG location, Total length are all useful. I think you can store all of them as attributes, but maybe a method called "summary" that plots something as the two examples above may be a good idea.

Just to clarify: Shaft total weight is the sum of the shaft elements or is the rotor (shaft + lumped mass)?
A summary of the rotor is a helpful tool to ensure that are no errors in the model, to perform double checks if the node is the rigth one and so on.

The attribute shaft_total_weight refers only to the shaft. Maybe it's better adding another attribute called rotor_total_weight considering the the shaft + lumped mass to avoid any missunderstanding about it.

Information as Inertias, CG location, Total length are all useful. I think you can store all of them as attributes, but maybe a method called "summary" that plots something as the two examples above may be a good idea.

It sounds a good idea. For now we have the dataframes built using Pandas. But I think I can organize it using Bokeh widgets and plot like the examples you've said. Thanks for the suggestion.
Soon, I'll come with a preview for what this Bokeh widget will be and we can discuss more about it.

This is a preview of what the summary table will become when it's done.

It's quite simple to use it (not implemented yet):
>>> import ross as rs
>>> rotor = rs.rotor_example()
>>> table = rotor.summary().plot()
>>> show(table)

We can also create multiples types of summary and organize them in different plot() methods.

I did some improvements to this table. Now we can alternate through tabs to get access to different information. Take a look:

I've been looking for some way to customize colors, background, fontsize, etc, but to do this, we need to use JavaScript.

PR #342 closes this issue.


Making pod with namespace but validation error appearing,what to do now?

error: error validating "myfirstpod1.yaml": error validating data: [ValidationError(Pod.spec.containers[0].ports[0]): unknown field "conatainerPort" in io.k8s.api.core.v1.ContainerPort, ValidationError(Pod.spec.containers[0].ports[0]): missing required field "containerPort" in io.k8s.api.core.v1.ContainerPort]; if you choose to ignore these errors, turn validation off with --validate=false

Hi @azeem2412, could you please ellaborate on what you are trying to do?
It looks like you are trying to do sth. with a custom pod specification, which does not seem very related to this project. Have you taken a look at the guide?

This is something completely unrelated. Closing.


How to change "in_channels" (input image channel) in config file?

Checklist

I have searched related issues but cannot get the expected help.
I have read related documents and don't know what to do.

Describe the question you meet
I have "images" with 5 channels (loader as numpy array), but model default using 3 channels image.
How to change "in_channels" (input image channel) in config file?
Post related information

The output of pip list | grep "mmcv\|mmcls\|^torch"
[here]
Your config file if you modified it or created a new one.

_base_ = [
    '../_base_/models/mobilenet_v2_1x.py',
    '../_base_/schedules/imagenet_bs256_epochstep.py',
    '../_base_/default_runtime.py'
]
# ---- Model configs ----
# Here we use init_cfg to load pre-trained model.
# In this way, only the weights of backbone will be loaded.
# And modify the num_classes to match our dataset.

model = dict(
    backbone=dict(
        init_cfg = dict(
            type='Pretrained',
            checkpoint='https://download.openmmlab.com/mmclassification/v0/mobilenet_v2/mobilenet_v2_batch256_imagenet_20200708-3b2dc3af.pth',
            prefix='backbone'),
        # pad_small_map=True
        in_channels=5
    ),
    head=dict(
        num_classes=2,
        topk = (1, )
    ),
)

# ---- Dataset configs ----
# We re-organized the dataset as ImageNet format.
dataset_type = 'CustomDataset'
img_norm_cfg = dict(
     mean=[132.5028, 97.4147, 115.2442, 24.6812, 143.6917],
     std=[40.315, 62.0412, 33.2143, 45.6525, 219.5267],
     to_rgb=False)

Your train log file if you meet the problem during training.

Traceback (most recent call last):
  File "/home/123/anaconda3/envs/mmc/lib/python3.8/site-packages/mmcv/utils/registry.py", line 66, in build_from_cfg
    return obj_cls(**args)
TypeError: __init__() got an unexpected keyword argument 'in_channels'

Other code you modified in the mmcls folder.
[here]

you need to modify this line in src code. We will refactor this place to make inputs dims modifiable.eg.
        self.conv1 = ConvModule(
            in_channels=5,
            out_channels=self.in_channels,
            kernel_size=3,
            stride=2,
            padding=1,
            conv_cfg=self.conv_cfg,
            norm_cfg=self.norm_cfg,
            act_cfg=self.act_cfg)

you need to modify this line in src code. We will refactor this place to make inputs dims modifiable.eg.
        self.conv1 = ConvModule(
            in_channels=5,
            out_channels=self.in_channels,
            kernel_size=3,
            stride=2,
            padding=1,
            conv_cfg=self.conv_cfg,
            norm_cfg=self.norm_cfg,
            act_cfg=self.act_cfg)

Thank you so much!!!


Consider removing manual crafting alltogether. And instead having all devices have shared recipes with varients

So maybe there is still the inventory crafting, just no crafting table things.

To start with, we can just convert all crafting recipes to be only in the mechanical crafting and not in the crafting table (or, easier, we just remove the crafting table and hide it in jei, although that might be an issue if we want to keep inv crafting, hm..)

To give more context. When we take into account our design and philosophy, crafting table doesn't fit into any of the categories. It's not a device, as it can't be a part of a buildable processing line, it's not a product, and it's not an ingredient. By all respects, it should be removed. The hard question is how we dont make managing and building many devices a frustrating hog in the process

Right now I made most devices craftable in the stone cutter instead of crafting table from their respective casing. Removed their old recipe and made the casing recipe slightly more involved

The path to no crafting table is gonna be finding alternatives to devices first, as they are the main issue. Then ingredients and products it's easy as it usually makes sense to assemble and process them in other machines


updated control and port file for latest version of sqlite-modern-cpp

move from version 2.4 to 3.2

Looks good, thanks!


Cannot read property 'type' of undefined - using type array in avro schema

Describe the bug
Based on the asvc file below, the generator throws a
Something went wrong:
Error: Cannot read property 'type' of undefined

How to Reproduce
Steps to reproduce the issue. Attach all resources that can help us understand the issue:
Here is the Gist with the asvc sample : https://gist.github.com/M3lkior/e282c8ebd3ac94759d4f58ebefdb8f49

Use the https://gist.github.com/M3lkior/e282c8ebd3ac94759d4f58ebefdb8f49#file-asyncapi-yaml file and replace the asvc $ref by https://gist.github.com/M3lkior/e282c8ebd3ac94759d4f58ebefdb8f49#file-test-array-avsc

Run ag asyncapi.yaml @asyncapi/html-template

See the error below :

Something went wrong:
Error: Cannot read property 'type' of undefined

Expected behavior

array type on avro schema, with "items": "string"  must be converted to the HTML element, for the file test-array.avsc definition

array type on avro schema, with "items": "record"  must be converted to the HTML element, for the file test-array-record.avsc definition

@M3lkior I transferred the issue as it is avro schema parser related.
I tried one of the examples (you have an error in one JSON in gist):
asyncapi: 2.0.0
info:
  title: Test Async API
  version: '0.1.0'

channels:
  example:
    publish:
      message:
        schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
        payload:
          type: record
          name: Type Array with Record items not working
          namespace: test
          version: 1
          fields:
          - name: MyArray
            type: array
            doc: Array docs
            items:
              name: ArrayContent
              type: record
              fields:
              - name: FIELD1
                type: string
                doc: doc 1
              - name: FIELD2
                type: string
                doc: doc 2
              - name: FIELD3
                type: string
                doc: doc 3
              - name: FIELD4
                type: boolean
                doc: doc 4

the problem is related to how record type is handled -> https://github.com/asyncapi/avro-schema-parser/blob/master/to-json-schema.js#L72. Type is passed to avroToJsonSchema function, instead of basically array items, so here https://github.com/asyncapi/avro-schema-parser/blob/master/to-json-schema.js#L64 undefined is passed.
I do not know much about avro, so don't know much about record type and what cases should we handle there. Need some support

@derberg , thanks for the reply.
Except for the record type, which is more complexe, the same issue occurs when using the simple string type. It could be a good start to solve the issue.
For avro, you need some support from who ? the avro-parser maintainers ?

I think the other example has the same issue, record with array
asyncapi: 2.0.0
info:
  title: Test Async API
  version: '0.1.0'

channels:
  example:
    publish:
      message:
        schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
        payload:
          type: record
          name: Type Array not working
          namespace: test
          version: 1
          fields:
          - name: MyArray
            type: array
            doc: Array Docs
            items: string

For avro, you need some support from who ? the avro-parser maintainers ?
I need one of:

my own education is needed, so support of time 😄
or maybe @fmvilas knows exactly how to approach it
or maybe you know exactly how that should work

@derberg , i know that the record structure i my Gist is correct and work with the Avro java tools like maven plugins or Kafka Schema Registry.
So i think that this structure :
 //<PHONE_NUMBER>4810
// https://gist.githubusercontent.com/M3lkior/e282c8ebd3ac94759d4f58ebefdb8f49/raw/b2857b3bb0ceb5ef36733f708051e2480318c5c6/test-array-record.avsc

{
  "type": "record",
  "name": "Type Array with Record items not working",
  "namespace": "test",
  "version": 1,
  "fields": [
    {
      "name": "MyArray",
      "type": {
        "type": "array",
        "doc": "Array docs",
        "items": {
          "name": "ArrayContent",
          "type": "record",
          "fields": [
            {
              "name": "FIELD1",
              "type": "string",
              "doc": "doc 1"
            },
            {
              "name": "FIELD2",
              "type": "string",
              "doc": "doc 2"
            },
            {
              "name": "FIELD3",
              "type": "string",
              "doc": "doc 3"
            },
            {
              "name": "FIELD4",
              "type": "boolean",
              "doc": "doc4"
            }
          ]
        }
      }
    }
  ]
}

Should be equals to this AsyncAPI definition :
Test2:
      type: object
      properties:
        MyArray:
          type: array
          items:
            type: "object"
            properties:
              FIELD1:
                type: "string"
                description: "doc 1"
              FIELD2:
                type: "string"
                description: "doc 2"
              FIELD3:
                type: "string"
                description: "doc 3"
              FIELD4:
                type: "string"
                description: "doc 4"

Maybe @fmvilas can validate this point

Very sorry @derberg; I came back to my specification after having deepened the avro spec and my avro schema was wrong,
After refactoring my schema, the generation for array type is good !


Remove typing dependency

We don't support python2 and it has difficulty in installing in python3.7.

/test


How will testers submit feedback?

Where shall they submit feedback and bug reports to? How will we guide them as to how to fill out the feedback and bug reports in a useful way?
In my opinion, there should at the very least be a button that leads to an immediate way to give feedback.

Can I clarify a few things?

feedback

What kind of feedback do you mean?  UI / UX / bugs?  Or more product-oriented ones, like "do you see this changing how you advise clients?  Would you use it?  Does this actually fit your needs?"

testers

There are two kinds of testers:  (1) ones that CfB will be demoing to, face-to-face, and (2) those that will encounter the tool through referral (they get the link somehow and aren't with a CfB member when they click through.)
I'm not worried about Group 1 because we'll be with them.  We are going to be speaking w/ testers to evaluate product need with each demo, so we can roll UI stuff in as well, and physically write things down.
Group 2 - how large do you think this group will be?  (cc: @anhase)  My hunch is that it'll be <20 people, and the feedback - both UI/UX and product - will be rather similar across both groups.  So why inundate ourselves with duplicate material?  The reality is the product team does not have enough people power to handle large volumes of information.

at the very least be a button

Like a text box where people just write what they encountered, and then hit 'submit'?  Or a complete instrumentation of every possible interaction that, when clicked, creates a flag for us?
I think the latter would be awesome but rather overkill.  I can see the former executed as a Google Form link in the disclaimer (would have to tweak disclaimer language accordingly).  For scaffolding to get something meaningful, I can't think of something short and sweet off the top of my head -- at which point I echo my sentiment about duplicate data being more of a burden than a boon.

feedback

I mean the smaller stuff - bugs, was an input unclear - small picture stuff. Bigger picture stuff is probably a face to face conversation. I'm not sure our users will differentiate, though.

at the very least be a button

I'm talking about one button - either a way to submit feedback right there, or a link to a way to submit feedback, like to a google form. It could go on the 'About' page (see Nick's description in #177).
I think it's good to have one-on-one conversations, but it's also good to have feedback about immediate impressions, especially when someone isn't there to observe the interaction. Maybe that won't ever be a situation, though.

We should fold feedback and contact onto the same line on the "About" page, using language like, "Find a bug? Want to learn more? Contact us at<EMAIL_ADDRESS>

Being dealt with through 'About' page content, #171


Volhouden exercise

30/7 22.01 Volhouden exercise was only 1 message and seemed incomplete, see screenshot . Only first paragraph is shown (of the 3)

For the Volhouden exercise the persuasion sentence did not seem to align very well, I had this: Het grootste deel van de mensen gelooft dat deze oefening zal helpen om ... om vol te houden, ook als veel mensen om je heen roken of niet veel bewegen
This should be 'om' instead of 'om... om'. I think it's useful to check this for all the persuasive messages

This looks again like a synchronization error in the app (already mentioned to NiceDay). This is wat I see in the web app:

Any idea when this issue will be fixed by Niceday?

Unfortunately not

The developers in NiceDay are now able to reproduce the error and they plan to fix this in around 4 weeks from now.
NiceDay ticket issue #6872


Add gbHours metrics

What does this PR do?
This PR adds gbHours metrics into the console, currently it only adds it for the function usage page. Need to discuss if we need to replace executions on the main project usage page with gbHours.
Related PRs and Issues
https://github.com/appwrite/appwrite/pull/8235
Have you read the Contributing Guidelines on issues?
Yes

Going to close this and merge it into https://github.com/appwrite/console/pull/1247


ng new fails due to @babel/traverse

🐞 Bug report
Command (mark with an x)

[x] new
[ ] build
[ ] serve
[ ] test
[ ] e2e
[ ] generate
[ ] add
[ ] update
[ ] lint
[ ] extract-i18n
[ ] run
[ ] config
[ ] help
[ ] version
[ ] doc

Is this a regression?

 Yes, it worked yesterday with 11.2.9 but today it does not using the same version.
Description
 A clear and concise description of the problem...
🔬 Minimal Reproduction

docker run --rm -it node:lts bash
npm install -g @angular/cli
ng new test --strict --routing --style scss

🔥 Exception or Error
npm ERR! code ETARGET
npm ERR! notarget No matching version found for<EMAIL_ADDRESS>npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.
npm ERR! notarget
npm ERR! notarget It was specified as a dependency of '@babel/helpers'
npm ERR! notarget

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2021-04-21T02_07_30_591Z-debug.log
✖ Package install failed, see above.
The Schematic workflow failed. See above.
The error would make you think maybe a version of this package was removed from the node repository. However, when I checked it still seems to be there, and if I try to install it alone, it works just fine:
npm install<EMAIL_ADDRESS>

+<EMAIL_ADDRESS>added 25 packages from 46 contributors and audited 25 packages in 2.078s
found 0 vulnerabilities

🌍 Your Environment

Anything else relevant?

I am having a hard time understanding why this is failing because the version does exist. I do see changes pushed to this project 3 hours ago, so I imagine those changes has to have something to do with this issue. I was wondering if maybe a version got removed from the NPM repo after it was already added but the version exists from 3 hours ago, maybe it's just a cache. I see the failure on my mac native node, as well as in Docker, but when I just ran ng new from my other machine (a Windows PC) it seems to have worked fine.
Changes for reference: https://github.com/babel/babel/commit/006e2c93936373935bf1602d6ae4006d290f2d7b

Okay, this problem seems to have resolved itself when I test in Docker. It's still failing on my Mac, but because it's working in Windows and Docker, I can only assume at this point my machine has some invalid cached state that is causing the issue to persist longer than it should. I'd still wager something was truly wrong here, perhaps a package was removed from NPM and re-added, but at this point I think it will clear itself up, so I will close this to reduce the noise.

For the record, without me making any changes on my machine, it now works on my Mac. Something definitely happened here that negatively impacted angular-cli, but it was fixed and seems to be clearing up with time.

same bug here...


New Device: EcoFlow Delta Pro 3

Device
Delta Pro 3
Characteristics
Basically the same as Delta Pro Ultra with total AC in and out wattage. Wondering if the Pro 3 is the same code as Pro. If so I can test it.

Are you ready to test beta version of plugin with added device support?
🟢 Yes
More Information
Currently waiting for EcoFlow developer approval. Should be soon, then I can test.

According to API description responses for Delta Pro3 and Delta Pro are different.
It is appreciated that you are ready to test

Ok, I'll let you know when I receive the developer approval.

Ok, I now have the access code and secret key for my Delta Pro 3.

Ok, can you?

install version 1.4.0-beta.1
activate Debug Mode in settings

configure your access key, secret, serial number and select Delta Pro model
open logs for the plugin

post the logs

Here are the 2 logs you requested.
@pietrolubini_homebridge-ecoflow.log.txt
homebridge.log.txt

Here are the 2 logs you requested. @pietrolubini_homebridge-ecoflow.log.txt homebridge.log.txt

Thanks. I will add support of reading initial data for Delta Pro 3 and will ask you to test switching on/off switchers (USB, AC, X-Boost) in EcoFlow app and HomeKit.


Increment version for search releases

Increment package version after release of Azure.ResourceManager.Search

API change check
API changes are not detected in this pull request.


Add IteratorAscTo and IteratorDescTo functions to gtree.RedBlackTree

1. What version of Go and system type/arch are you using?

go1.17.6 darwin/amd64
2. What version of GoFrame are you using?

v2.0.6
I'm using TreeMap intensively in my project. There is a common use case to search a key (like a timestamp key not more than 5 days ago before now), and then iterate from the largest key to it (iterate all timestamp keys within 5 days in desc order) .
This use case can be defined as IteratorDescTo func of gtree.RedBlackTree.
I have a temporarily workaround for this use case:
Firstly call IteratorAscFrom to collect all nodes whose key is larger than specified key into a list, which should be an ascending ordered list.
Then reverse the list to descending order.
There may also has an IteratorAscTo func vice versa.
Thanks in advance.

feature of very low priority.

I was looking for a first good issue, and it sees like this is done already. maybe it's better to close.


Things i had on the todo list i never got to doing

tiny crown on chat owner
"fix" terrible codebase (More specifically Modals)
add to chat button on profiles
add users to gc via search
Theme modal (for oobe and settings)
OOBE
image button (simpler way to upload images)
BGM
BGM + SFX modal
basic modal
authors for music in bgm
disable bgm by default

issue: bgm isnt working. idk why

good, the reason i didnt want it as json was because it felt too storage intensive.

the issue is that cf pages seems to be failing

list of complaints i guess:

why no more crown meowy?
the reason the custom theme wasnt json was because i thought json was too storage intensive, but i guess that doesnt matter
cf pages wont build

why no more crown meowy?

in light mode, the crown is less visible (because it's bright yellow), and i think having just a crown icon would be clearer

the reason the custom theme wasnt json was because i thought json was too storage intensive

it's only a few bytes

cf pages wont build (fix needed)

idk why, i don't have access to the cloudflare (cc @tnix100)

Is this able to be merged into 1.6 now?


Fix: tests failure due to new boto3 release

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 80.497%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1329

Relevant Lines:
1651

💛  - Coveralls


Q: mixing modelForm and model, problem with Images

(noob warning)
I wanted to use summernote within a model but without using the default modelForm.
I ended up mixing the two like this (can't have widgets on model field...):
# In models I have
class Article(models.Model):
  """Represents a wiki article"""
  title = models.CharField(max_length=100)
  slug = models.SlugField(max_length=50, unique=True)
  text = models.TextField()
  author = models.ForeignKey(User)
  created_on = models.DateTimeField(auto_now_add=True)
  objects = models.Manager()
  tags = TaggableManager(through=TaggedArticle)

class ArticleForm(forms.ModelForm):
  class Meta:
    model = Article
    fields = ['text']
    widgets = {
            'text': SummernoteWidget(),
          }

After having the right display while serving the template, I attempt to save the Article like this:
# in views, a part of the saving method:
    form = ArticleForm(request.POST or None)
    if form.is_valid():
        #import pdb; pdb.set_trace()
        article = Article()
        article.text = form.cleaned_data['text'] # THIS IS MY HACKISH WAY OF FETCHING THE CONTENT
        article.author = request.user
        article.title = request.POST['title']
        if request.POST.has_key('tags'): #add relevant ones
          article_tags = request.POST.getlist('tags')
          article_tags = [tag for tag in user_tags]
          article.tags.add(*article_tags)
        article.save()
        return HttpResponse("Article saved successfully")

I have everything configured (MEDIA_ROOT, MEDIA_URL, summernote url as described in the setup)
The widget is displayed well within iframe
When uploading an image I get the "mime interpreted text blah blah blah" error
After saving, when displaying the article, the text is displayed well with all the markup but no image is displayed

Finally, how would you suggest me to solve the problem and having the images uploaded and displayed correctly in the resulted article text?
cheers and thanks for this great app.

Quick update, while reviewing changes in git, I've noticed that the uploaded images appear in django-summernote/"date-of-upload"/"some-hash-string"."image-extension"
Perhaps this information will help in identifying/resolving the problem.

Yet another update on the situation:
URLs works well. Local files not. Similar to that question.
 Above is a screenshot of the network tab after loading a local file to the iframe widget
 As you can see, the image is accessible on the server while browsing through the media url.
What am I doing wrong?

I overwrote next things in my settings.py:
SUMMERNOTE_CONFIG = {
....
'attachment_upload_to': upload_to,
....
}
def upload_to(instance,filename):
.... return os.path.join('django-summernote', filename)
and my MEDIA_ROOT and MEDIA_URL variables are:
MEDIA_ROOT = 'mine/static/mysite/media'
MEDIA_URL = '/media/'
next step I made was adding one string to urlpattern:
urlpatterns = patterns('',
....
) +  static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
and now everything works fine for me.

Thank you very much. It worked.

Sorry for late replying. Thank you @andyfuse and @hemulin.


CIP-???? | Maybe Datum

A CIP that looks to address the concerns of #364, #423, #309, #418, #310, and #321 in one go.
See proposal here.

I approve this CIP. The issue of accidentally locking UTxOs for good is widespread and problematic and the use cases for multipurpose scripts are clear enough to make them easy to achieve by design.

Note that the motivation/problem 3 is not accurate. A solution to this problem and the corresponding drawback is outlined here: https://github.com/ImperatorLang/eopsin/blob/master/ARCHITECTURE.md#minting-policy---spending-validator-double-function

@nielstron I updated the problem 3 section to acknowledge eopsin's workaround. My apologies for not doing it sooner.

Thanks!

PR #309 has a related discussion to this.
https://github.com/cardano-foundation/CIPs/pull/309#discussion_r939157351

@ch1bo What are your thoughts about this CIP? It is meant to address the concerns of 309 as well. Do you agree that it does?

@fallen-icarus In this model, can there be a situation when there's one script address, and:

one transaction would spend from it running the script as a tx-level script,
another transaction would spend from it running the script per-UTxO?

Another question: can a transaction run several tx-level scripts? (Perhaps, when spending outputs from M addresses, created from N scripts, where M > N) How would this work?

@imikushin The same script can be used in either context. You can think of all scripts as having logic like
if maybe_datum == Just datum
then utxo_level_logic
else tx_level_logic

can a transaction run several tx-level scripts? ... How would this work?

You can use as many tx-level scripts as will fit into the tx. The following table shows some valid usages:

Tx 1
Tx 2
Tx 3
Tx 4

Script A as tx-level
Script A as tx-level
Script A as utxo-level
Script A as utxo-level

Script B as tx-level
Script B as utxo-level
Script B as tx-level
Script B as utxo-level

The only restriction is that, within the same tx, script A cannot be used as BOTH a tx-level script and a utxo-level script. As far as how this would work, the ledger is already capable of detecting if all the relevant scripts are present. Currently, every utxo needs an accompanying script to execute at the utxo-level. This detection tooling will need to be slightly altered to also allow using tx-level scripts to witness all utxos from that script's address in the same way that a pubkey can witness all utxos from the user's address.

Perhaps, when spending outputs from M addresses, created from N scripts, where M > N

This is an interesting use case: If Address AA and Address AB are protected by Script A, can script A be used at the tx-level for Address AA's utxos while being used at the utxo-level for Address AB's utxos in the same tx? I would have to say no simply because this would likely dramatically complicate the ledger-script interface and I don't think this use case is ubiquitous enough to warrant adding such complexity. For most use cases, the script is probably meant to be used as only one level or the other, regardless of the address being spent from. If this usage is necessary, you can always break it up over multiple txs. Somebody on the plutus or ledger team will know better how complicated allowing this niche use case would be. The proposal, as it is now, does not allow for this use case.

@fallen-icarus, thanks for your reply. With clarifications about multiple tx-level scripts, I can definitely get behind this proposal.
Tx-level validation (as opposed to per-UTxO) basically gives more scalability for free (besides, of course, implementation cost), i.e. we're not paying for it by sacrificing security or decentralization.

@fallen-icarus Just a thought: maybe a better name for this CIP could be Transaction Level Validation Scripts.
I think it communicates the solution much better. Sure, script re-usability is an issue. But a much bigger concern is scalability, which this proposal addresses.
I mean, just think of a transaction dealing with multiple outputs that has to perform a ZK proof verification (a pretty intensive computation). How much easier it gets with per-transaction script execution vs per-output.

@imikushin I had thought about that before but tx level scripts aren't the main focus of this CIP. While I personally agree with the tx level scripts being the most important consequence of this CIP (since you can't fully utilize the eUTxO model without it), the main focus is on changing things to use the Maybe Datum. @rphair Do you have an opinion on this?

@fallen-icarus I agree the "Transaction" oriented name would be eye-catching for implementations, but the goal of any standard is to be applied as generally as possible.  Therefore if the current name "Maybe Datum" is the most generally applicable I'd be in favour of keeping it in the title unless there's a more explicit title that means the same thing (as a non Plutus programmer it means nothing to me except what people have said about this & related CIPs).
@imikushin's highlighted use case is a great one to keep focusing on, but from my (not technically expert on this subject) point of view you have to read deeply into the text to find how this phrase applies to the subject.  So maybe that use case could be included under a heading like "Use cases for Transaction Level Validation Scripts" in the Motivation or Rationale section.

@michaelpj thanks for the review. I'll need to think about the rest of your comments here.

@oversize @KtorZ @katomm adding you in this discussion as well. Is there a way to get this CIP approved and merged? It will improve scalability for multi output tx CC: @imikushin

@ShariffL I agree with @michaelpj that this CIP should be broken up into a few composable CIPs. Currently, I am considering breaking it up into two CIPs:

Using Maybe Datum for when a utxo is missing one. This would also enable universal scripts (one that can mint, spend, or manage rewards). It is mutually exclusive to #321.
Adding a new tx input type for grouped inputs. See here. This would address the redundant executions and enable "ignoring" datums even if utxos have them (they will still be present in the ScriptContext).

The others can correct me if I am wrong, but as the author of this CIP, I do not think this is being implemented in Conway. CIP-69 (#784) uses a Maybe Datum in a different way than this CIP was proposing. IMO, CIP-69 obsoletes the need for this one.

@fallen-icarus Yes, you are right in that CIP-0069 takes a different approach to solve the same problem. In that sense, it does make this CIP obsolete.

Thanks everybody especially @fallen-icarus for all the prior work on this.  Based on the last comments by @lehins @fallen-icarus @Ryun1 I'm closing this as superseded, but please feel free to reopen if that turns out not to be true.


(BKR-440) host_preserved.yml file should disable the pre_suite

instead of just removing the pre_suite/post_suite/tests from
the options, explicitly set it to be []
this means that you don't end up accidentally running a pre-suite
defined in a secondary options file

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1441/
Test FAILed.

Failure unrelated to patch.

:+1:

@anodelman it seems like there should probably be a test validating this behavior to prevent regressions and accidental behavior incompatibilities between major versions of Beaker. Actually, this PR does introduce a backwards incompatibility (anyone who relied on setting pre_suite in an options file when using preserved hosts will not be able to do so anymore...i know that seems unlikely, just saying.)

Added spec coverage.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1449/
Test FAILed.

Failure unrelated to change, :+1: from me!


Added identity hash

One question about the use case: do you want a Merkle tree where the leaf is a field element? From the test example, it seems to be the case.
There is an issue related to soundness. Note that the number of input bits in the code is F::BigInt::NUM_LIMBS * 64, but the field element cannot indeed represent this number of bits (e.g., a field of 260 bits have 5 limbs, but it cannot represent 320 bits). We may need to bound this number.

As for the former, I think it is a problem that currently Merkle tree is taking ToBytes as leaves and the developers have no other choices, and this is a restriction because one using Poseidon would prefer Merkle tree that takes field elements directly as leaves, rather than being forced to bypass this conversion. I will need to think about what is the best way to handle this...

@weikengchen It would def have been easier if we could have Poseidon itself take field elements and return field elements, as well as the leaf being the field element

Let me @tsunrise. I think the difficult part is to design an interface that is general enough as well as not prohibiting optimization.

@filiplazovic I've updated merkle tree API in #60, which can support leaf as field element (given a CRH whose Input is field element). Is identity hash still needed?


[Docs/GIE] Add doc for getting started with GIE

This doc provide getting started docs with GIE. Together with this doc, we also plan the tutorial
that including loading an ldbc graph and solving complex interactive queries.

It is a commit for #2522
BTW, if you have any further plan for GIE docs, you may want to fulfill the TBF in #2522, @longbinlai

#2522

I see. Already add the plan.


Allow PrivateNetworkOnlyFlag option

Allow PrivateNetworkOnlyFlag option
This commit adds the option in softlayer packer
plugin to set up an instance with private only
network.
Allows to specify private_network_only_flag parameter,
when set to true, the instance spun up will only
have a private ip. And it will try to ssh and run the
scripts using this private ip.

@arunsure Can you resubmit this PR on https://github.com/watson-platform/packer-builder-softlayer? Be sure to include the information from this PR https://github.com/watson-platform/packer-builder-softlayer/pull/3

Fixed here https://github.com/watson-platform/packer-builder-softlayer


Missing AssistEdit

Where are the AssistEdit button in Visual Studio Code?

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

ID: babe9dc8-8278-49b7-3f8a-0bc75dd8307b
Version Independent ID: 7cf185fd-3e0e-6d5f-7ed4-8a3773534357
Content: SubPageView Property - Business Central
Content Source: dev-itpro/developer/properties/devenv-subpageview-property.md
Service: dynamics365-business-central
GitHub Login: @jswymer
Microsoft Alias: solsen

Hello, sorry, this is referring to the old development environment (CSIDE).  It is not relevant in Visual Studio Code. We have fixed the articles accordingly and updates will be published soon. Thanks for the feedback!


Build failure on Centos 6

Trying to build on a pristine build of centos 6.  Installed Development Tools group.   Followed by running of download_prerequisites.sh  placing all of the downloads into /root/bulld.
I then set all of the enviroment variables per the Bulding.txt document.
Run of make testLocations yielded:
akefile:50: Sanity checking for required environment variables
Makefile:50: Envvar YES : NAME = oslockdown
Makefile:50: Envvar YES : SB_VERSION = 5.0.0
Makefile:50: Envvar YES : SB_RELEASE = opensource
Makefile:50: IsDir  YES : SB_HOME = /root/repos/OSLockdown
Makefile:50: IsDir  YES : JAVA_HOME = /usr/lib/jvm/java-1.7.0-openjdk-<IP_ADDRESS>.x86_64
Makefile:50: IsExec YES : $JAVA_HOME/bin/java = /usr/lib/jvm/java-1.7.0-openjdk-<IP_ADDRESS>.x86_64/bin/java
Makefile:50: IsExec YES : $JAVA_HOME/bin/javac = /usr/lib/jvm/java-1.7.0-openjdk-<IP_ADDRESS>.x86_64/bin/javac
Makefile:50: IsDir  NO  : (optional)JAVA_HOME2
Makefile:50: IsExec NO  : (optional)$JAVA_HOME2/bin/java
Makefile:50: IsExec NO  : (optional)$JAVA_HOME2/bin/javac
Makefile:50: IsDir  YES : GSOAP_HOME = /usr/local
Makefile:50: IsExec YES : $GSOAP_HOME/bin/wsdl2h = /usr/local/bin/wsdl2h
Makefile:50: IsDir  YES : GRAILS_HOME = /root/build/grails-2.3.7
Makefile:50: IsExec YES : $GRAILS_HOME/bin/grails = /root/build/grails-2.3.7/bin/grails
Makefile:50: IsDir  YES : SAXON_HOME = /root/build/saxon-6.5.5
Makefile:50: IsExec YES : $SAXON_HOME/saxon.jar = /root/build/saxon-6.5.5/saxon.jar
Makefile:50: IsDir  YES : FOP_HOME = /root/build/fop-1.0
Makefile:50: IsExec YES : $FOP_HOME/fop = /root/build/fop-1.0/fop
Makefile:50: IsDir  YES : JAXWSRI_HOME = /root/build/jaxws-ri
Makefile:50: IsDir  YES : DOCBOOK_STYLESHEETS = /root/build/docbook-xsl-1.74.0
Makefile:50: IsDir  YES : $DOCBOOK_STYLESHEETS/fo = /root/build/docbook-xsl-1.74.0/fo
Makefile:50: IsDir  YES : ANT_HOME = /root/build/apache-ant-1.9.2
Makefile:50: IsExec YES : ANT = /root/build/apache-ant-1.9.2/bin/ant
Makefile:50: IsExec YES : TOMCAT_ARCHIVE = /root/build/apache-tomcat-7.0.82.tar.gz
Makefile:50: IsDir  NO  : (optional)GRAILS_DEP_HOME
make: `testLocations' is up to date.
Running of make build ends with:
BUILD SUCCESSFUL
Total time: 41 seconds
echo "Making PDFs"
Making PDFs
make[1]: Leaving directory /root/repos/OSLockdown/docs' mkdir -p /root/repos/OSLockdown/build/dist make -e -C /root/repos/OSLockdown/src/core build  make[1]: Entering directory /root/repos/OSLockdown/src/core'
mkdir -p /root/repos/OSLockdown/src/core/rpmbuilddir/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
/usr/bin/test -f build/oslockdown.spec
echo "Creating tarball to build RPM using build/oslockdown.spec";
/bin/tar -C ../../.. --exclude=oslockdown/src/console --exclude=oslockdown/src/dispatcher --exclude=oslockdown/src/security_modules --exclude=oslockdown/src/selinux --exclude=oslockdown/cfg/docs --exclude=oslockdown/docs --exclude=.rpm --exclude=.log --exclude=*.pkg --exclude='.svn' --exclude=rpmbuilddir --exclude=externals -czf /root/repos/OSLockdown/src/core/rpmbuilddir/SOURCES/oslockdown.tar.gz oslockdown ;
Creating tarball to build RPM using build/oslockdown.spec
/bin/tar: oslockdown: Cannot stat: No such file or directory
/bin/tar: Exiting with failure status due to previous errors
make[1]: *** [build-linux] Error 2
make[1]: Leaving directory `/root/repos/OSLockdown/src/core'
make: *** [build] Error 2
Not quite sure where to head from here.  All of the parts necessary to build RPM's appear to be installed.

Michael,
I think you missed one of the notes in the readme - the 'root' of the OS Lockdown directory needs to be named 'oslockdown'.  By default the download from Git will call it either OSLockdown or OSLockdown-master, depending on whether you checked out the Master branch or did a zip download.  This is a legacy from our old build/devel procedures that we've never taken the time to fix.  It is on my personal list to fix here (as I dig up time to do so).
So the simple fix is to make sure the top level directory where you issue the 'make build' is named 'oslockdown'.  We're explicitly referencing that directory name when we tar up the source code in preparation for passing control to rpmbuild.

Right you are.    That's the problem with constant interruptions at my desk.   It's building now with no issues.   Thanks.


Better document and enforce contract for the parameter type of parametrized model builders

When running a build action, users have an ability to request models built by parameterized model builders.
These provided by the BuildController methods like:
https://github.com/gradle/gradle/blob/1d110f2ab92a44a92b36f2cfcbb4dea68c17e0a5/platforms/ide/tooling-api/src/main/java/org/gradle/tooling/BuildController.java#L131
The current javadoc does not specify any restrictions on the parameter type, and also does not explain how it is related to the type that the parameterized model builder has actually declared.
In a recent attempt to document something, we've put the contract on the ParameterizedToolingModelBuilder's getParameterType method. While it's better than nothing, it is not strictly accurate.
The facts about the current implementation:

Enforcement of the contract only happens at the request time, when calling getModel(..., paramType, paramAction) or a similar method
The contract checks for the parameter to be an interface, but only validates its declared methods to be getters/setters, and not the methods of any super-interfaces
There is no enforcement or any checks on the parameter type provided by the model builder
The model builder parameter type and the parameter type in the request are connected only structurally via proxying methods with the same name

The current implementation seems to suffer from a potential loophole, escaping the contract.
The request parameter interface can extend other interfaces with arbitrary methods (not checked by validation).
The model builder parameter type can have the same-named methods on its interfaces (not checked by validation).
The builder then can access these arbitrary methods as long as they look like getter and setters.
Overall, the current contract and the implementation seem fragile and unsound.
Though, fixing this properly may require a technically-breaking change.
However, the chance that there are users of this is very small.
Even if we keep the enforcement of getter/setter methods, I think the following approach should be idiomatic:
interface MyBuilderParameter {
    String getMyValue()
}

class MyBuilder implements ParameterizedToolingModelBuilder<MyBuilderParameter> {
// ...
}

// At registration time we enforce the parameter interface to only have getters
toolingModelBuilderRegistry.register(new MyBuilder())

interface MutableMyBuilderParameter extends MyBuilderParameter {
    void setMyValue(String value);
}

// At request time we enforce the parameter interface (and its super interfaces) to only have getters/setters
buildController.getModel(modelType, MutableMyBuilderParameter.class, parameterInitializerAction)

Which ever option we go with, it should be properly documented in the javadocs of the relevant methods.

I would consider simplify the contract instead of adding more validation, possibly after first documenting it a little better.
Specifically, I would use the same contract for a client passing a value to the builder as the builder uses to pass a value to the client. That is, allow the client to just create a parameter object and pass it directly to the getModel() method instead of the client providing a class literal and a configuration function.


Add table lineage model

Summary of Changes
Currently we don't have table lineage extractor. Provide a data model is the first step towards this goal.
User could build a generic / specific . lineage extractor with this model.
Tests
Yes
Documentation
What documentation did you add or modify and why? Add any relevant links then remove this line
CheckList
Make sure you have checked all steps below to ensure a timely review.

[x] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[x] PR includes a summary of changes.
[x] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[x] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does

[x] PR passes make test
[x] I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message"

Codecov Report

Merging #126 into master will decrease coverage by 0.11%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master     #126      +/-   ##
==========================================
- Coverage   83.16%   83.05%   -0.12%
==========================================
  Files          55       56       +1
  Lines        2745     2785      +40
  Branches      283      285       +2
==========================================
+ Hits         2283     2313      +30
- Misses        372      381       +9
- Partials       90       91       +1

Impacted Files
Coverage Δ

databuilder/models/table_lineage.py
75% <75%> (ø)

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 2a73a9a...a9dffdf. Read the comment docs.


Oracle: query couldn't be exported

System information:

Operating system (distribution) and version win 10 x64
DBeaver version 6.3.4

Connection specification:

Database name and version oracle

Describe the problem you're observing:
Export from simple query like select * from [table] fails with next message

In case it is saved as task - export ends successfully
Steps to reproduce, if exist:

Open SQL editor with query select * from [table]
Execute Export from query
dbeaver-debug.log

verified


Code showing blank

Hi - Sentiment score for Sentence is blank. Can it be fixed in the code and also the output?
Sentence score:

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

ID: 8f57e416-a37f-e719-4a3e-58a4e6390818
Version Independent ID: dbb3821b-5793-b41b-9601-559b00e4096a
Content: Quickstart: Text Analytics client library v3 - Azure Cognitive Services
Content Source: articles/cognitive-services/text-analytics/quickstarts/text-analytics-sdk.md
Service: cognitive-services
Sub-service: text-analytics
GitHub Login: @aahill
Microsoft Alias: aahi

@parasharshah
Thanks for the feedback! We are currently investigating and will update you shortly.

@parasharshah
Hi, I haven't seen any issue when I reproduced.

Please try again and let me more details.
Please make sure you did the following:
Install the client library by right-clicking on the solution in the Solution Explorer and selecting Manage NuGet Packages. In the package manager that opens select Browse and search for Azure.AI.TextAnalytics. Select version 5.0.0, and then Install. You can also use the Package Manager Console.
We will now proceed to close this thread. If there are further questions regarding this matter, please respond here and @YutongTie-MSFT and we will gladly continue the discussion.


Fix issues #178, #174, #170 - [closed]

In GitLab by @wknet123 on Sep 12, 2017, 04:23
Merges fix-remaining-issues -> dev

In GitLab by @wknet123 on Nov 13, 2019, 09:57
closed


Support MergeOperator

To use SlateDB as a fully-featured state backend for a stream processor, we need to support three main types of state:

Value (Latest Value, Aggregating State)
List / Bag / Buffering
Map

Traditionally, state-of-the-art implementations built on top of RocksDB have leveraged the MergeOperator [1] to efficiently handle types 1 and 2.
A key example is List state, where we append elements continuously until it's time to trigger a computation—like when a window fires.
For Value state, the MergeOperator can also be useful for efficiently managing aggregating states. It allows us to defer computations until we actually need the result—such as calculating a maximum value when a large window closes. This approach can be quite effective, particularly for operations where we only need the final outcome.
While this isn't always the absolute optimal method, it's a solid foundation for future iterations and improvements.
[1] RocksDB Merge Operator

@dmvk I'm +1 on this. I think it'd be good to  have an RFC to work off of, so we're all on the same page. I'll assign to you, but LMK if you'd prefer to leave it unassigned.

Rough Task List

[x] MergeOperator RFC
[ ] Add ValueDeletable#Merge (https://github.com/slatedb/slatedb/pull/336)
[ ] Add RowCodec ValueDeletable#Merge (https://github.com/slatedb/slatedb/pull/336)
[ ] Introduce a KeyValueIterator wrapper (MergeOperatorIterator [MOI]) that properly handles merges
[ ] get_with_options uses MOI and handles merges that are spread across different levels (depends on https://github.com/slatedb/slatedb/issues/274)
[ ] scan_with_options uses MOI and handles merges that are spread across different levels (depends on https://github.com/slatedb/slatedb/issues/274 and https://github.com/slatedb/slatedb/pull/342)
[ ] Compactor uses MOI and only merges entries with the same expire_ts
[ ] Public facing APIs
[ ] Benchmarks
[ ] Documentation / Examples

Dependencies:

[ ] https://github.com/slatedb/slatedb/issues/274
[ ] https://github.com/slatedb/slatedb/pull/342

Awesome. Added this issue to the README.md feature list as WIP.


object/minio: remove unused error

err is always nil here
close #2008

Codecov Report

Merging #2023 (9acc51e) into main (c361878) will increase coverage by 0.12%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main    #2023      +/-   ##
==========================================
+ Coverage   61.52%   61.64%   +0.12%
==========================================
  Files         137      137
  Lines       23837    23837
==========================================
+ Hits        14665    14694      +29
+ Misses       7452     7429      -23
+ Partials     1720     1714       -6

Impacted Files
Coverage Δ

pkg/object/minio.go
76.47% <0.00%> (ø)

pkg/meta/redis.go
71.88% <0.00%> (+0.04%)
:arrow_up:

pkg/meta/tkv.go
76.78% <0.00%> (+0.43%)
:arrow_up:

pkg/vfs/writer.go
79.66% <0.00%> (+1.01%)
:arrow_up:

pkg/vfs/reader.go
80.29% <0.00%> (+3.10%)
: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 c361878...9acc51e. Read the comment docs.


why i can't use command  sudo rm -rf "C:\"

because not have rm command
or i'm not update my windows?
（It's just a joke, the joke comes from the following picture）

Because it's still not linux / unix ? . It's just an elevation command for windows.

Because it's still not linux / unix ? . It's just an evelation command for windows.

Because it's still not linux / unix ?

that's a bug with windows then

lol

Because it's still not linux / unix ? . It's just an elevation command for windows.

Agree. The sudo command is just an elevation command, prompting for the highest privileges in Windows.
The sudo is just asking for UAC for further permissions, but does not replace the rem and rd commands in Windows.

This issue should be closed, right? Because it seems to be the misunderstanding of the "new features" that the Microsoft team brings to Windows 11.
It also appears not to be an actual issue, nor a recommendation/enhancement.

Oh, and, by the way, please don't run this command inside your work machine:
sudo rm C:\ /s /q

I won't take any responsibility for your losing files in C:\ after doing that.

An elevated operation isn't necessary to be executed with the highest privilege.
On Windows you are still executing the command under the current user, except it's elevated.
The user that has highest privilege is TrustedInstaller, if you really want to do things like removing all files in the system directory, you would need to first switch the user to TrustedInstaller.

An elevated operation isn't necessary to be executed with the highest privilege. On Windows you are still executing the command under the current user, except it's elevated.  The user that has the highest privilege is TrustedInstaller, if you really want to do things like removing all files in the system directory, you would need to run the elevated command as TrustedInstaller.

Yeah true. Hope this sudo thing won't be implemented into Windows Server 2025 or Windows 11 Pro for Workstation (or higher privileges in Active Directory/Workspace/Workgroup). It only raises even more problems with security in Windows.

is anyone going to fix this

is anyone going to fix this

Fix what?

windows not being unix


Single navbar

Summary

Drop section specific navigation bar — freeing up vertical space
Show (if options are set) search bar, language switch dropdown, and version switch dropdown on ALL pages  — making navigation more direct
Make navigation bar sticky (if option is set, default true) on large + mobile screens — making navigation more direct (no need to scroll to top)
Make "On this page" section collapse on smaller screens  — freeing up vertical space

Basic example
https://deploy-preview-782--doks.netlify.app/

Motivation

Making navigation easier /more direct
Back to original design
Preparing for global search
Preparing for scroll to top button (option)

Checks

[x] Read Create a Pull Request
[x] Supports all screen sizes (if relevant)
[x] Supports both light and dark mode (if relevant)
[x] Passes npm run test

Looking good!


Add default.tensor to setup.py

As name says.

default.tensor is the updated name of the tensor network device with the quimb backend. The new change installs it along with lightning.qubit as there are no non-python dependencies to get the device to work.
Updated the device's name attribute to return default.tensor instead of lightning.tensor.
Updated the errors raised by the device to use default.tensor instead of LightningTensor or lightning.tensor.

[sc-61741]

This is obviously a statistical fluctuation. Codecov keeps complaining, but at this point I am not surprised

Do we want to replace the following too?
pennylane_lightning/lightning_tensor/backends/quimb/_mps.py:    """A function that determines if an operation is supported by ``lightning.tensor`` for this interface."""
pennylane_lightning/lightning_tensor/backends/quimb/_mps.py:    """A function that determines if an observable is supported by ``lightning.tensor`` for this interface."""
pennylane_lightning/lightning_tensor/lightning_tensor.py:    """A function that determines whether or not a backend is supported by ``lightning.tensor``."""
pennylane_lightning/lightning_tensor/lightning_tensor.py:    """A function that determines whether or not a method is supported by ``lightning.tensor``."""

Where is this from?

Where is this from?

I was looking for the lightning.tensor string in files with grep -r "lightning\.tensor" pennylane_lightning/.