JoinAudio is Not working

From yesterday in my app Audio only room is not been working, I tried the example app joinchannelaudio also it's not working, but I can hear audio if I joinwithvideo.
Steps to reproduce the behavior:

Run the sample app in examples folder
Click on JoinChannelAudio
Use a second device to connect to JoinChannelAudio
No Audio can be heard
If I use JoinChannelVideo u can hear audio

I'm getting this log these calls are not made by me
I/agora.io(15219): local audio publish timeout 5005 I/agora.io(15219): [RS]: **report stats: seq: 26, report list size 1, tx/rx: 3926/1200, cache size: 0 I/agora.io(15219): [ATW]: Audio statistics - play count: playout count = 1800 signal level: far_in = 0 I/agora.io(15219): [ATW]: Audio statistics - rec count: record count = 1800 signal level: near_in = 102, near_out = 102 I/agora.io(15219): **CALL STATS: duration 31s cpu app/total 17.62/0.0 battery 255 tx/rx: 2/1 kbps 31.810K/25.960K bytes I/agora.io(15219): [ATW]: Audio statistics - play count: playout count = 3600 signal level: far_in = 0 I/agora.io(15219): [ATW]: Audio statistics - rec count: record count = 3600 signal level: near_in = 108, near_out = 108 I/agora.io(15219): [RS]: **report stats: seq: 58, report list size 1, tx/rx: 12089/2736, cache size: 0

I think it's better to submit a ticket to agora support, you may need to share some sensitive data for further investigation.


FileBackend changed from RandomAccessFile to regular FileWriter due…

fixes #217

Thanks, @schnaker85, much appreciate it.


docs: add local_environment_setup.md

:tada: This PR is included in version 2.118.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Feature Request: keepdims option for tf.boolean_mask()

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): N/A
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): N/A
TensorFlow installed from (source or binary): N/A
TensorFlow version (use command below): ('v1.6.0-0-gd2e24b6039', '1.6.0')
Python version: Python 2.7.14
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce: N/A

Describe the problem
tf.boolean_mask() currently grabs individual elements from the input tensor according to the shape and content of the boolean mask argument (see https://www.tensorflow.org/api_docs/python/tf/boolean_mask). The returning tensor's dimensionality is always lower than or equal to the input tensor. It would be very useful if tf.boolean_mask() included an additional, optional boolean argument keepdims. If keepdims=False, the behavior of the method is unchanged. If keepdims=True, the output tensor would have the same dimensionality as the input tensor. This would allow 'filtering out' of certain values from the input, while keeping its overall shape as much as possible (see example below).
Source code / logs
tensor = [[1, 2], [3, 4], [5, 6]]
mask = np.array([[True, False],[False, True],[False, True]])
boolean_mask(tensor, mask, keepdims=False)  # [1, 4, 6]
boolean_mask(tensor, mask, keepdims=True) # [[1],[4],[6]]

mask = np.array([[True, False],[False, True],[False, False]])
boolean_mask(tensor, mask, keepdims=False)  # [1, 4]
boolean_mask(tensor, mask, keepdims=True) # [[1],[4]]

@langmore can you please take a look?
I think boolean_mask(tensor, mask) is designed to implement the numpy tensor[mask] function. And you can work around this by using cond_vars.

I run into the same problem, and need keepdims feature for tf.boolean_mask().

Nagging Assignee @bignamehyp: It has been 15 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @bignamehyp: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @bignamehyp: It has been 45 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @bignamehyp: It has been 60 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

I am wondering after tf.boolean_mask, how to recover the predicted results as a 2D tensor from pred (1D tensor) and mask (2D array with elements of 'True' or 'False'), where False corresponds to 0.
mask = labels > 0
labels = tf.boolean_mask(labels, mask)
heatmaps = tf.boolean_mask(heatmaps, mask)

scores = tf.nn.softmax(logits=heatmaps, labels=labels)
pred = tf.argmax(scores)

@langmore
Thanks!

I think this is still not a well-defined feature request. There aren't even some examples of (input, output) pairs at all. The input, output pairs given by in the original issue are already proven unsound by @burglarhobbit.
If one just wants to replace False entries by another element (which seems to be what @panfengli needs) then you should use tf.where.

For example,
img = tf.constant(([1,2,3], [4,5,6], [7,8,9]))
mask = tf.where(img>5)
new_img = tf.zeros_like(img)

I would like new_img to be
[[0, 0, 0],
[0, 5, 6],
[7, 8, 9]]

@panfengli  tf.where(img>5, img, tf.zeros_like(img)) does what you need.

Okay, I got it. Thanks!

Nagging Assignee @bignamehyp: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @bignamehyp: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @bignamehyp: It has been 44 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @bignamehyp: It has been 59 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

then expected output according to you should be [[1, 3], [6], [7, 8, 9]] but this will give ShapeError since TensorFlow doesn't allow flexible shapes like Python lists do. So what I suggest is along with keepdims argument, there should be a pad_val argument where you mention the value of the padding that is going to happen at the end.

Is this still the case now that Ragged tensors have been released?

In PR 1366762 we added a new "tf.ragged.boolean_mask" op which preserves mask dimensions.

Hi @edloper, what if I want to keepdim but also need a valid tensor by adding padding, like what @burglarhobbit said:
tensor = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
mask = np.array([[True, False, True], [False, False, True], [True, True, True]])
boolean_mask(tensor, mask, keepdims=False) # [1, 3, 6, 7, 8, 9]
boolean_mask(tensor, mask, keepdims=True, pad_val=0) # [[1, 3, 0], [6, 0, 0], [7, 8, 9]]


CRC mismatch at 256 nodes in C++ Pennant

I'm seeing the following failure in C++ Pennant starting at 256 nodes:
[6 -<PHONE_NUMBER>40]    5.450854 {6}{gex}: CRC MISMATCH: arg0=1610612737 header_size=36 payload_size=16 exp=300a8000 act=68e03e37

It happens about 80% of the time, so it's going to be pretty painful to work around (if it's possible at all—considering I need longer runs for the replay test).
The backtrace looks useless, but here it is:
  [0] = /lib64/libpthread.so.0(+0x13310) [0x155550cfd310]
  [1] = /lib64/libc.so.6(gsignal+0x110) [0x15554f786360]
  [2] = /lib64/libc.so.6(abort+0x151) [0x15554f787941]
  [3] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x437336) [0x155551a17336]
  [4] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x43a045) [0x155551a1a045]
  [5] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x44b7b0) [0x155551a2b7b0]
  [6] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x44bbc0) [0x155551a2bbc0]
  [7] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(gasnetc_recv_am_unlocked+0x830) [0x155551f14440]
  [8] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x93555d) [0x155551f1555d]
  [9] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(gasnetc_poll+0x9) [0x155551f15649]
  [10] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(gasnetc_AMPoll+0x10) [0x155551f0c2f0]
  [11] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x442c64) [0x155551a22c64]
  [12] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x311d91) [0x1555518f1d91]
  [13] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x3125b9) [0x1555518f25b9]
  [14] = /users/eslaught/resilience/cpp_pennant.run22_exit_crash/librealm.so.1(+0x3f639f) [0x1555519d639f]
  [15] = /lib64/libpthread.so.0(+0x8539) [0x155550cf2539]
  [16] = /lib64/libc.so.6(clone+0x3f) [0x15554f848e0f]

If there are workarounds or solutions to this, they'd be appreciated.

Documenting what I already told @elliottslaughter. This is a memory corruption of an active message payload. The most likely causes are realm cleaning up or stomping on a buffer before an active message send is complete, gasnet corrupting the payload in flight, or a hardware bug. None of them are likely to be very easy to try down.

@elliottslaughter :

which system is this happening on?  is it possible to try it on another system, ideally one using another gasnet conduit?
can you try running with a debug build of gasnet and see if gasnet's checks flag anything?
if you run with -gex;cksum 0, do things run correctly or do you get hangs/bad results/other things indicative of realm packets getting corrupted?

This is on Piz Daint.
I am currently trying a run with REALM_NETWORKS=gasnet1. After that I'll try the things you suggest.

Using REALM_NETWORKS=gasnet1 is sufficient to work around this for now.

-gex:immediate 0 does not fix the issue.

When I run with -gex:cksum 0, I get (probably unsurprisingly):
[44 - 15550717e840]    5.733568 {6}{realm}: invalid subgraph handle: id=7a30027000
pennant: /users/eslaught/resilience/legion/runtime/realm/runtime_impl.cc:2593: Realm::SubgraphImpl* Realm::RuntimeImpl::get_subgraph_impl(Realm::ID): Assertion `0 && "invalid subgraph handle"' failed.

Running with a debug GASNet produces:
[6 -<PHONE_NUMBER>80]    5.862988 {6}{gexxpair}: medium payload too large!  src=6/0 tgt=11/0 max=4072 act=6224

Do you have a backtrace to go with that last one?  And does it fail reliably in that way?

Yes, this failure mode appears to be deterministic.
Backtrace:
#4  0x000015554cb59360 in raise () from /lib64/libc.so.6
#5  0x000015554cb5a941 in abort () from /lib64/libc.so.6
#6  0x000015554efd2286 in Realm::XmitSrcDestPair::reserve_pbuf_inline (this=0x1838d70, hdr_bytes=20, payload_bytes=6224, overflow_ok=true, pktbuf=@0x1849698: 0x0, pktidx=@0x18496a0: -1,
    hdr_base=@0x155504c4be08: 0x155504c4be80, payload_base=@0x155504c4be10: 0x0) at /users/eslaught/resilience/legion/runtime/realm/gasnetex/gasnetex_internal.cc:1189
#7  0x000015554efdb594 in Realm::GASNetEXInternal::prepare_message (this=0x7fb6c0, target=13, target_ep_index=0, msgid=99, header_base=@0x155504c4be08: 0x155504c4be80, header_size=20,
    payload_base=@0x155504c4be10: 0x0, payload_size=6224, dest_payload_addr=0) at /users/eslaught/resilience/legion/runtime/realm/gasnetex/gasnetex_internal.cc:3853
#8  0x000015554efc036a in Realm::GASNetEXMessageImpl::GASNetEXMessageImpl (this=0x155504c4be00, _internal=0x7fb6c0, _target=13, _msgid=99, _header_size=20, _max_payload_size=6224, _src_payload_addr=0x0,
    _src_payload_lines=0, _src_payload_line_stride=0, _dest_payload_addr=0, _dest_ep_index=0) at /users/eslaught/resilience/legion/runtime/realm/gasnetex/gasnetex_module.cc:234
#9  0x000015554efc1fcc in Realm::GASNetEXModule::create_active_message_impl (this=0x7bdff0, target=13, msgid=99, header_size=20, max_payload_size=6224, src_payload_addr=0x0, src_payload_lines=0,
    src_payload_line_stride=0, storage_base=0x155504c4be00, storage_size=256) at /users/eslaught/resilience/legion/runtime/realm/gasnetex/gasnetex_module.cc:676
#10 0x000015554eb16819 in Realm::Network::create_active_message_impl (target=13, msgid=99, header_size=16, max_payload_size=6224, src_payload_addr=0x0, src_payload_lines=0, src_payload_line_stride=0,
    storage_base=0x155504c4be00, storage_size=256) at /users/eslaught/resilience/legion/runtime/realm/network.inl:100
#11 0x000015554f0a885f in Realm::ActiveMessage<Realm::RemoteMicroOpMessage<Realm::ByFieldMicroOp<1, long long, Realm::Point<1, long long> > >, 256ul>::init (this=0x155504c4bde0, _target=13,
    _max_payload_size=6224) at /users/eslaught/resilience/legion/runtime/realm/activemsg.inl:53
#12 0x000015554f09fece in Realm::ActiveMessage<Realm::RemoteMicroOpMessage<Realm::ByFieldMicroOp<1, long long, Realm::Point<1, long long> > >, 256ul>::ActiveMessage (this=0x155504c4bde0, _target=13,
    _max_payload_size=6224) at /users/eslaught/resilience/legion/runtime/realm/activemsg.inl:44
#13 0x000015554f099bd8 in Realm::PartitioningMicroOp::forward_microop<Realm::ByFieldMicroOp<1, long long, Realm::Point<1, long long> > > (target=13, op=0x1545604027c0, microop=0x15457c172180)
    at /users/eslaught/resilience/legion/runtime/realm/deppart/partitions.inl:46
#14 0x000015554f092d18 in Realm::ByFieldMicroOp<1, long long, Realm::Point<1, long long> >::dispatch (this=0x15457c172180, op=0x1545604027c0, inline_ok=true)
    at /users/eslaught/resilience/legion/runtime/realm/deppart/./byfield.cc:208
#15 0x000015554f0932aa in Realm::ByFieldOperation<1, long long, Realm::Point<1, long long> >::execute (this=0x1545604027c0) at /users/eslaught/resilience/legion/runtime/realm/deppart/./byfield.cc:320
#16 0x000015554eca3d7f in Realm::PartitioningOpQueue::do_work (this=0x16a7280, work_until=...) at /users/eslaught/resilience/legion/runtime/realm/deppart/partitions.cc:978
#17 0x000015554edd92b1 in Realm::BackgroundWorkManager::Worker::do_work (this=0x155504c4d0e0, max_time_in_ns=-1, interrupt_flag=0x0) at /users/eslaught/resilience/legion/runtime/realm/bgwork.cc:621
#18 0x000015554edd6fe7 in Realm::BackgroundWorkThread::main_loop (this=0x144a770) at /users/eslaught/resilience/legion/runtime/realm/bgwork.cc:125
#19 0x000015554edda6a6 in Realm::Thread::thread_entry_wrapper<Realm::BackgroundWorkThread, &Realm::BackgroundWorkThread::main_loop> (obj=0x144a770)
    at /users/eslaught/resilience/legion/runtime/realm/threads.inl:97
#20 0x000015554ef5b331 in Realm::KernelThread::pthread_entry (data=0x8e3920) at /users/eslaught/resilience/legion/runtime/realm/threads.cc:781

I've got my job for a little bit if you want me to test anything else.

@streichler suggested that this may be a duplicate of #1229. As a workaround I am testing building GASNet with:
--with-aries-max-medium=8192

With this, running DEBUG=1 with a debug GASNet, I'm able to get to the end of execution and then fail with the error message at https://github.com/StanfordLegion/legion/issues/1415#issuecomment-1450541920 (which is expected and an unrelated issue).
I guess my one question is whether this is really a solution, since presumably the required max medium size will scale as $\mathcal{O}(N)$.

As I suspected, when I go to 512 nodes I start hitting:
[6 - 155501ae1880]   11.069872 {6}{gexxpair}: medium payload too large!  src=6/0 tgt=10/0 max=8168 act=12368

So I'd need a max medium size of 16K for 512 nodes, 32K for 1024 nodes, etc. I can work around this for now, but it doesn't seem sustainable.

I agree this isn't sustainable, but I can renew the work on #1229 for a proper fix.

I'm also hitting this issue for a 128-node run of a modified version of Stencil on Perlmutter:
[9 - 7fb002856000]   50.335033 {6}{gex}: CRC MISMATCH: batch_size=16 payload_size=16 exp=815730 act=7020ff50

The backtraces don't appear to have anything useful. I'm on commit 92afef of Legion. Some GASNet info:
*** Details for bug reporting (proc 5): config=RELEASE=2023.9.0,SPEC=1.20,PTR=64bit,nodebug,PAR,timers_native,membars_native,atomics_native,atomic32_native,atomic64_native compiler=GNU/12.3.0 sys=x86_64-pc-linux-gnu

Can you try increasing the maximum size of GASNet's medium message as directed above and see if that fixes the problem?

I increased it to 2**15, quadruple the default value, but I'm still hitting the same error.

I think what we're looking for with Rupanshu's issue is a way to either confirm the root cause in a release build of Legion/GASNet, or to force the issue to reproduce somehow in debug mode GASNet so we can see what's really going on.
Any ideas?

Well you definitely don't need to do anything with a debug version of Legion as there should be nothing that Legion can do to cause a CRC mismatch. Realm assertions are on by default even in release mode so there's no benefit in building a debug Realm. I'm not sure if there are any checks in GASNet or Realm that confirm that all active messages that are sent are within the maximum size for that kind of active message. I would bet a heavily on Realm sending an active message beyond the maximum allowed size for a particular kind. I have no good suggestions for you other than to go in and annotate all the active message sends in Realm so that they check that they are within the bounds of the appropriate size.

I believe that GASNet refuses to compile when it thinks it's being included into a non-debug application (if it is itself built in debug mode).
I told @rupanshusoi to try commenting that check out. In theory it should just be a #error line somewhere in one of the GASNet header files.

Is there a reason why Realm doesn't check maximum lengths? In debug mode in particular, that seems like an eminently reasonable thing to do....

Ok, I got an assertion failure with a debug GASNet and release Legion:
*** FATAL ERROR: Assertion failure (proc 103): in gasnetc_ofi_handle_am() at anguage/gasnet/GASNet-2023.9.0/ofi-conduit/gasnet_ofi.c:1725: isreq == header->isreq
   op1 :           1 (0x00000001) == isreq
   op2 :           0 (0x00000000) == header->isreq

Full log here.

I'm moving discussion of @rupanshusoi 's issue to #1660 because this appears to be a different underlying root cause, even though the initial symptoms looked similar.


[WIP] Support MongoDB 4.0

Don't merge

We have to wait until the problem in https://github.com/mongodb/mongo-php-library/issues/562 is solved and to work together with the event store, because the event store will open the transaction first.

@prolic @codeliner This is a crucial issue.

The snapshotter doesn't use MongoDB 4.0 transactions, because it is not needed here. Sharing the MongoDB transaction from the event store is also not possible. So even if you use transaction in the event store or via the event-store-bus-bridge TransactionManager the snapshot will not be part of the transaction.

Maybe we expose the MongoDB session object from the event store and use an event store plugin to get the snapshot working in a transaction. Do you have any ideas?

Your issue should be fixed in 1.5.2, so you can increase the requirements?

Oh, it looks like transaction support is not possible with GridFS. So how can we remove snapshots if a transaction is roll backed? At the moment, there is no validation if an aggregate exists for the aggregate snapshot.

@codeliner Any ideas?

Removed the transaction notice, because snapshots are not part of event store transactions. So it's ready for review @prolic :tada:


Add Serialise instances

This adds instances from the serialise package, making it suitable in more places that ByteStrings are.

@vmchale may you updated tested-with and regenerate .travis.yml with https://github.com/haskell-ci/haskell-ci; you'll need to change --branch to --branches.

@vmchale the Generic Serialise instance does
gencode (K1 a) = encodeListLen2 <> encodeWord 0 <> encode a

i.e. adds a tag. I guess for this case we'd like to avoid adding tag and just serialise wrapped ByteString as is (i.e. write manual instances?)

Done in #17

released in https://hackage.haskell.org/package/base64-bytestring-type-1.0.1


Removed 'olevhalf' from CMIP6_coordinate.json

#237

@taylor13 This branch has been updated with the latest changes from xml-cmor3-database.


Acro dynamic form

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.63%. Comparing base (245fea8) to head (4cbdfe8).
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #89      +/-   ##
==========================================
- Coverage   99.36%   96.63%   -2.74%
==========================================
  Files          36       36
  Lines        2374     2374
  Branches      252      236      -16
==========================================
- Hits         2359     2294      -65
- Misses         15       80      +65

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


database extension: drop Bootstrap and Pure #5548

Fixes #5548
This drops Pure and Bootstrap from the database extension as those libs leak into the rest of the UI.
Side effects:

It changes the overall look and feel of the connection UI (smaller buttons, no colors, etc)

Post-changes screenshot:

I think it's worth it for the over all maintainability of OpenRefine.

I am very supportive of this but it might be worth tweaking the new styling a bit more to make the whole thing more inviting and more similar to the rest of OpenRefine, no?
As a user, there is a clear degradation of the appearance and I think we can avoid it.
Here is how the same screen looks before the change:

I would be happy to spend time on restoring the layout and enlarging headers. Beyond that I think it would be better if someone actually using the extension would make additional improvements(I usually uninstall this extension).

I have been restoring the basic layout as well as some padding/alignment. In the best of one would probably like to adopt the Dialog system but I feel like that's beyond scope.

Also the connections area in 'Saved connections' doesn't show a scrollbar past the current size:
Before:

After:

The overflow issues are taken care off but the spacing still looks kinda off, it's hard to get rights without starting to refactor things or going overboard with hard-coded pixel values.


Fix PG13 DockerHub build warnings

Fixed PG13 DockerHub build warnings by converting an Assert to an error message.
This PR is the PG14 PR as they both have the same warnings.
No regression tests needed adjusting.

Builds correctly, looks good


combineCandidates will sometimes fail and cause assertion failure during network unit tests

Occasionally when a network test executes it fails with an assertion in the combineCandidates function in the Nominator with error similar to
FATAL ERROR: [source/agora/consensus/protocol/Nominator.d:705] combineCandidates: no valid candidate for slot 16.
Maybe this indicates a potential problem in production.

`SHOULD NOT BE HERE!!!! candidates=
consesusData=ConsensusData([Transaction(Payment, [Input(0x4b87e702b639bf31ed9fc87fa2812eb4cbf2d945eacf84eee5175a3690a730dff427bbc7baa284f9e061ec79c0e493eab70fc51cd3ed15d7030bfe15cd0296a1, 0, 0x06386763e000d70df43b7751b5b9d4c5d7c5e70e0a0e3ff1232c63d55f574fef58c10cdf140ec6ab3b3074f362c321eeeeb3c8e5985c1dca82005f6dd513fbde)], [Output(610000000000000, GCOQEOHAUFYUAC6G22FJ3GZRNLGVCCLESEJ2AXBIJ5BJNUVTAERPLRIJ)])], [])
FATAL ERROR: [source/agora/consensus/protocol/Nominator.d:714] combineCandidates: no valid candidate for slot 13. Candidates:const(set!(xvector!(ubyte,<PHONE_NUMBER>u)))([7F9BF58B3660, 7F9BF58B3660, 1])
This node was started at source/agora/test/ValidatorCleanRestart.d:39
This most likely means that the node crashed due to an uncaught exception
If not, please file a bug at https://github.com/Geod24/localrest/
Full error: core.exception.AssertError@source/agora/consensus/protocol/Nominator.d(713): [source/agora/consensus/protocol/Nominator.d:714] combineCandidates: no valid candidate for slot 13. Candidates:const(set!(xvector!(ubyte,<PHONE_NUMBER>u)))([7F9BF58B3660, 7F9BF58B3660, 1])
??:? onAssertErrorMsg [0x10a8f1394]
??:? _d_assert_msg [0x10a8f17c5]
??:? _ZN9Nominator17combineCandidatesEyRKSt3setIN3xdr7xvectorIhLj4294967292EEEE [0x109db4555]
??:? _ZN7stellar18NominationProtocol15processEnvelopeERKNS_11SCPEnvelopeE [0x10a33701e]
??:? _ZN7stellar4Slot15processEnvelopeERKNS_11SCPEnvelopeEb [0x10a38b783]
??:? _ZN7stellar18NominationProtocol14emitNominationEv [0x10a33512f]
??:? _ZN7stellar18NominationProtocol8nominateERKN3xdr7xvectorIhLj4294967292EEES5_b [0x10a337e4d]
??:? _ZN7stellar4Slot8nominateERKN3xdr7xvectorIhLj4294967292EEES5_b [0x10a38c51c]
??:? ZN7stellar3SCP8nominateEyRKN3xdr7xvectorIhLj4294967292EEES5 [0x10a37b06c]
??:? @trusted void agora.consensus.protocol.Nominator.Nominator.nominate(ulong, agora.consensus.data.ConsensusData.ConsensusData) [0x109db5169]
??:? @safe void agora.consensus.protocol.Nominator.Nominator.checkNominate() [0x109e66288]
??:? void geod24.LocalRest.Timer.run() [0x10a42ff36]
??:? void geod24.concurrency.FiberScheduler.create(void delegate()).wrap() [0x10a431ed8]
??:? void core.thread.context.Callable.opCall() [0x10a8fe9ce]
??:? void core.thread.fiber.Fiber.run() [0x10a8feb5d]
??:? fiber_entryPoint [0x10a8fea92]`

The question is: is that code path reached because the candidate set was empty, or because it failed validation?
If it failed validation it would be good to have some extra information. For example, what is the current ledger block height, and also what is the slot index we are currently nominating.

Can you reliably replicate the bug? Can you narrow it down to a specific test? E.g. test=agora.test.Quorum dub test

Unfortunately it does not happen all the time. On the same test it can occur at different heights and then run fine.

I'm guessing this only happens with your new changes? Not in v0.x.x? I haven't seen this bug yet in v0.x.x.

I did just catch it again and it is due to validateConsensusData returning something. However the reason is not logged as the assert throws too early for this to happen.

I will add some more temporary logging to see the reason for it being invalid.

I can think of two reasons why validateConsensusData could fail in combineCandidates:

Memory corruption. The passed in candidate set is somehow corrupted
The candidate set is stale. Perhaps there is a race condition where externalize was called but a fiber switched and then the ballot timer fired again in the meantime

I suspect it could be the second case..

Sorry I meant the Nominating timer, not balloting. It's the nominating timer which calls combineCandidates.

combineCandidates: Invalid consensus data: Transaction: Input ref not in UTXO
Seems that this is the reason. However I don't think that should cause an assertion failure in the node? It should be rejected.

No this is definitely a real bug somewhere. combineCandidates takes a series of validated candidates and creates a single composite candidate. We currently just pick the first one, but this part is left to be done later once we implement transaction filtering.
All of the candidate values should be valid.

combineCandidates: Invalid consensus data: Transaction: Input ref not in UTXO

Can you also print out the current block height, and the slot_idx?

combineCandidates: Invalid consensus data: Transaction: Input ref not in UTXO
SHOULD NOT BE HERE!!!! candidates=
consesusData=ConsensusData([Transaction(Payment, [Input(0xf5947c767253f1312422a7dafbaba9c0469fd3f8fb3b760d2c0c849f11fcec326144d82168496369f2c221072b5bd079b2408f8a566f0659696589189729a8fe, 0, 0x0eea252a8e34a180b134aca58108cf46e4b32e477129e8a51bedfdd149eb7c7dda6528174928703dea8a333f4de3dbd12b7c320537ce65811c10489171686089)], [Output(610000000000000, GCOQEOHAUFYUAC6G22FJ3GZRNLGVCCLESEJ2AXBIJ5BJNUVTAERPLRIJ)])], [])
FATAL ERROR: [source/agora/consensus/protocol/Nominator.d:716] combineCandidates: no valid candidate for slot 5. Candidates:const(set!(xvector!(ubyte,<PHONE_NUMBER>u)))([7FB9CEC454B0, 7FB9CEC454B0, 1])
This node was started at source/agora/test/ValidatorCleanRestart.d:39
This most likely means that the node crashed due to an uncaught exception
If not, please file a bug at https://github.com/Geod24/localrest/
Full error: core.exception.AssertError@source/agora/consensus/protocol/Nominator.d(715): [source/agora/consensus/protocol/Nominator.d:716] combineCandidates: no valid candidate for slot 5. Candidates:const(set!(xvector!(ubyte,<PHONE_NUMBER>u)))([7FB9CEC454B0, 7FB9CEC454B0, 1])
??:? onAssertErrorMsg [0x1109ee354]
??:? _d_assert_msg [0x1109ee785]
??:? _ZN9Nominator17combineCandidatesEyRKSt3setIN3xdr7xvectorIhLj4294967292EEEE [0x10feb1505]
??:? _ZN7stellar18NominationProtocol15processEnvelopeERKNS_11SCPEnvelopeE [0x1104340fe]
??:? _ZN7stellar4Slot15processEnvelopeERKNS_11SCPEnvelopeEb [0x110488863]
??:? _ZN7stellar18NominationProtocol14emitNominationEv [0x11043220f]
??:? _ZN7stellar18NominationProtocol8nominateERKN3xdr7xvectorIhLj4294967292EEES5_b [0x110434f2d]
??:? _ZN7stellar4Slot8nominateERKN3xdr7xvectorIhLj4294967292EEES5_b [0x1104895fc]
??:? ZN7stellar3SCP8nominateEyRKN3xdr7xvectorIhLj4294967292EEES5 [0x11047814c]
??:? @trusted void agora.consensus.protocol.Nominator.Nominator.nominate(ulong, agora.consensus.data.ConsensusData.ConsensusData) [0x10feb2119]
??:? @safe void agora.consensus.protocol.Nominator.Nominator.checkNominate() [0x10ff63238]
??:? void geod24.LocalRest.Timer.run() [0x11052d016]
??:? void geod24.concurrency.FiberScheduler.create(void delegate()).wrap() [0x11052efb8]
??:? void core.thread.context.Callable.opCall() [0x1109fb98e]
??:? void core.thread.fiber.Fiber.run() [0x1109fbb1d]
??:? fiber_entryPoint [0x1109fba52]
source/agora/test/ValidatorCleanRestart.d(42): Node logs:

Can you check the block height too? It should be this.ledger.getBlockHeight()

Can you check the block height too? It should be this.ledger.getBlockHeight()

Next time it occurs I will have it logged also.

combineCandidates: Invalid consensus data: Transaction: Input ref not in UTXO
SHOULD NOT BE HERE!!!! candidates=
Block Height=5
consesusData=ConsensusData([Transaction(Payment, [Input(0xf5947c767253f1312422a7dafbaba9c0469fd3f8fb3b760d2c0c849f11fcec326144d82168496369f2c221072b5bd079b2408f8a566f0659696589189729a8fe, 0, 0x0eea252a8e34a180b134aca58108cf46e4b32e477129e8a51bedfdd149eb7c7dda6528174928703dea8a333f4de3dbd12b7c320537ce65811c10489171686089)], [Output(610000000000000, GCOQEOHAUFYUAC6G22FJ3GZRNLGVCCLESEJ2AXBIJ5BJNUVTAERPLRIJ)])], [])
FATAL ERROR: [source/agora/consensus/protocol/Nominator.d:717] combineCandidates: no valid candidate for slot 5. Candidates:const(set!(xvector!(ubyte,<PHONE_NUMBER>u)))([7FDF31828B10, 7FDF31828B10, 1])

Looks like it was for last block.

Yes this is what I feared. It looks like the nomination protocol has continued for the same slot after externalization. I'll look at the code to see what could trigger this.

I'll push my current code to a different branch as it is quite easy to reproduce to the moment.

This is branch https://github.com/hewison-chris/agora/tree/combineCandidatesBug
Test to trigger quite often is dtest=agora.test.ValidatorCleanRestart dub test

I thought I already covered this case though:
https://github.com/hewison-chris/agora/blob/c1d52be671b0cbdb9b4c01f17321b1d3341595b3/source/agora/node/Validator.d#L341-L343
But maybe the race condition is more subtle..

I wonder if there is just a missing call to stopNominationRound inside of the valueExternalized routine..

Hmm no, wrong assumption. It is eventually called in https://github.com/hewison-chris/agora/blob/c1d52be671b0cbdb9b4c01f17321b1d3341595b3/source/agora/node/Validator.d#L341-L343.

I can no longer reproduce it when I add a check that we are not externalizing a block during prep of consensusData:-
 public void prepareNominatingSet (ref ConsensusData data, ulong max_txs)
        @safe
    {
        if (externalizingBlock) return;

and
public bool onExternalized (ConsensusData data)
        @trusted
    {
        scope(exit) externalizingBlock = false;
        externalizingBlock = true;
        auto block = makeNewBlock(this.last_block, data.tx_set, data.enrolls);
        return this.acceptBlock(block);
    }

Hmm.. that would mean that checkNominate is called before onExternalized finished running. I think that means there is a context switch somewhere.

I can see another source of a context switch:
https://github.com/bpfkorea/agora/blob/d3b05dcea8414882180e5b73014f468c346974af/source/scpp/src/scp/NominationProtocol.cpp#L426-L435
emitNomination() ultimately calls Nominator.emitEnvelope(), which calls sendEnvelope on each client via runTask. And runTask yields the calling fiber.
The problem with yielding the fiber is that the ledger state can change in the meantime.
We really need a schedule() primitive here.

This diff essentially uses schedule under the hood (at least in LocalRest):
diff --git a/source/agora/network/NetworkClient.d b/source/agora/network/NetworkClient.d
index 45cbc4935..22d7bb399 100644
--- a/source/agora/network/NetworkClient.d
+++ b/source/agora/network/NetworkClient.d
@@ -239,7 +239,7 @@ class NetworkClient

     public void sendEnvelope (SCPEnvelope envelope) nothrow
     {
-        this.taskman.runTask(
+        this.taskman.setTimer(0.seconds,
         {
             this.attemptRequest!(API.receiveEnvelope, Throw.No)(this.api,
                 envelope);

I think it fixes the combineCandidates bug. But there might be other bugs there still because the tests in your branch still don't succeed for me.

This diff essentially uses schedule under the hood (at least in LocalRest):
diff --git a/source/agora/network/NetworkClient.d b/source/agora/network/NetworkClient.d
index 45cbc4935..22d7bb399 100644
--- a/source/agora/network/NetworkClient.d
+++ b/source/agora/network/NetworkClient.d
@@ -239,7 +239,7 @@ class NetworkClient

     public void sendEnvelope (SCPEnvelope envelope) nothrow
     {
-        this.taskman.runTask(
+        this.taskman.setTimer(0.seconds,
         {
             this.attemptRequest!(API.receiveEnvelope, Throw.No)(this.api,
                 envelope);

I think it fixes the combineCandidates bug. But there might be other bugs there still because the tests in your branch still don't succeed for me.

Thanks @AndrejMitrovic I'll try this out. The tests are still being refactored so I would not expect them to pass yet.

Fixed by #1256


Loading external data

A method for loading external data needs to be in place so that the following events can happen in order:

load external assets
load 1-year data #382
load all data (what we have now)

70036a9e4816f4b7918e65be7855ed3ef06bc816
Instructions: https://github.com/Gapminder/vizabi/wiki/FAQ---Data-loading#how-do-i-preload-external-data-to-my-component-or-tool


Cannot copy sequence with size... even with correct observation space dim.

I'm using the correct observation space dim, calculated by:
Shape = [Current Balance]+[prices 1-30]+[owned shares 1-30] +[macd 1-30]+ [rsi 1-30] + [cci 1-30] + [adx 1-30]
But, as soon as the program starts, I get the ValueError: cannot copy sequence with size 17 to array axis with dimension 19. When I change it to 17, the program runs, but when the DDPG validation starts I get the error again (this time with the correct dim, as calculated above) ValueError: cannot copy sequence with size 19 to array axis with dimension 17.
It seems my dimension is not constant through the iterations. What could be the possible reasons for this?

Ok. So I think I found the culprit of my case. It seems some of the tickers from my data didn't have values for some dates, thus changing the dimension of the vector during these periods. After properly parsing the data so that all tickers have the same number of data points, everything worked as expected.


AtomicArc::clone() is not consistent in behaviour

If the AtomicArc is null, cloning it effectively makes a new, independent AtomicArc, which is counter-intuitive. However, if the AtomicArc instance is non-null, reference counting works as expected.
This is a tricky behaviour, because on one hand, I understand why this happens, on the other hand, now I need to use an Arc<AtomicArc<T>> or AtomicArc<Option<T>> for nullable struct members, eg. in a LinkedList implementation, neither of which seem very clean.

Your understanding it correct, and that is actually my intent. Thanks for your opinion on the semantics. Honestly, I haven't found it problematic before - I just thought that AtomicArc was like a pointer with ownership (e.g., crossbeam_epoch::Atomic<T> in + std::sync::Arc), and therefore cloning an AtomicArc = cloning a crossbeam_epoch::Atomic<T> + reference counting, so I guess, it was more like Option<Arc<T>> rather than Arc<Option<T>>.
However, implementing something like AtomicArc<Option<T>> will be trickier than it looks, since,

Constructing an instance of T while there are multiple pointers requires synchronization. Constructing should only be allowed to one thread. Something like AtomicOption has to be implemented.
Dereferencing the instance requires additional memory barriers. Say, we have AtomicOption, constructing T has to release the instance - release-store memory barrier -, and reading the instance also has to acquire it - load-acquire memory barrier. Of course release-acquire is free on X86, but still, PPC is a major player in the enterprise hardware world, and ARM is also a rising star; optimizing memory operations is very, very important in enterprise software development.

So, my suggestion here is, you implement something like AtomicOption, and use AtomicArc<AtomicOption<T>>.
For this issue, I'll add more comments and documentation about the semantics.

However, considering your points, I increasingly think that a  AtomicOption is basically equivalent to AtomicArc. An AtomicArc<AtomicOption<T>> is simply initialized with AtomicArc::new(AtomicArc::null()), and you get the desired semantics.
Is there something I'm missing with this comparison?

Let me explain AtomicArc a little bit further.
AtomicArc<T> points to an instance of T where the instance is garbage collected later after the AtomicArc<T> is dropped.

AtomicArc = AtomicPtr<T> --> T, where T is heap-allocated.
It is analogous to Arc, since Arc = ptr --> T.

AtomicOption is different. It can be allocated in stack and the instance is dropped when the AtomicOption is destroyed.

AtomicOption = (T, AtomicBool ).
It is analogous to Option, since Option = (T, bool).
Since it can reside in stack, it cannot be protected by EBR.

Furthermore, AtomicArc<AtomicArc<T>> is different from AtomicArc<AtomicOption<T>>.

AtomicArc<AtomicArc<T>>: AtomicArc --> AtomicArc --> T.
AtomicArc<AtomicOption<T>>: AtomicArc --> (T, AtomicBool), thus one less indirections.

So, semantically, yes, you're right, AtomicArc<AtomicOption<T>> and AtomicArc<AtomicArc<T>> are the same, but in practice, they are different in terms of performance as the former requires users to dereference two pointers to read the instance.

Thanks for your thoughts.
It seems to me that specifically for use in a LinkedList, I'm better off using an Arc<AtomicArc<T>>, since this way everything can track the same AtomicArc instance, simplifying memory management, since the Node references can use the same ref counted pointer.
Overall, however, it comes out as Arc -> AtomicArc -> Arc -> T to reach the value.


Add pass to annotate ops with on_device for non-BYOC heterogeneous

Added pass AnnotateDevicePlacement which allows for per-Call op placement using on_device. This allows for heterogeneous execution of non-external compilers such as CPU and GPU.
Added unit test for AnnotateDevicePlacement.
Moved the on_device definition from an anonymous lambda to a c++ function so that it can be called directly from c++ instead of forcing the use of PackedFunction calls.

Thanks for the PR. Regard to the current AnnotateTarget pass for BYOC, I have some questions/comments:

From the use case, it looks like very similar to the compiler_begin and compiler_end, but limits to per node. Could you ellaborate the reason why not using compiler_begin and compiler_end directly?

This PR doesn't include a pass to annotate nodes but relies on manual annotation. Could you ellaborate how would you expect users to use them?

If we use compiler_begin and compiler_end, it seems possible to extend existing AnnotateTarget to annotate non-external compilers. The current AnnotateTarget annotates rest nodes to CPU. We could refactor that pass and make CPU and GPU as two "external" compilers as well so that AnnotateTarget could also take care of them. I feel that we should only maintain one annotation mechanism at the end, so whatever which approach we finally agree on, we could also refactor BYOC AnnotateTarget pass in that way.

Also cc @zhiics

I also have the same concern as @comaniac. Maybe we should slowly stop using the word "BYOC", it makes it sound "external".
I think we can have a unified infra to dispatch IRModule --> runtime.Module compilation flows. I don't see an immediate concern why we cant use the current "BYOC" partitioning infra to generate the cpu, gpu targets as well.
Love to hear thoughts on this and see the roadblocks of unifying these approaches. I guess that helps to have a unfied TargetRegistry as well.
cc : @tqchen

Thanks for the comments and input everyone, @zhiics any feedback on the annotation pass? Thanks!

@comaniac and @manupa-arm to your questions
This PR is to provide a simple demo of heterogeneous execution on CPU and Vulkan which are both tvm internal compilers.

I started with compiler_begin and compiler_end and was able to annotate my simple example model. These attributes worked great until up until calling the compilers. In my use case I need to compile code to use the CPU and Vulkan backends, both of which are built into tvm. With the compiler_begin/end annotation it really looks like it only works with external compilers, with no way to use tvm's built in compilers for the second device. For a quick demo I used the older on_device annotation which does directly work with both backends built into tvm.
There is a pass to annotate nodes, AnnotateDevicePlacement in src/relay/transforms/annotate_device_placement.cc. The pass simply call a callback for each CallNode and then annotates the nodes with the returned on_device. This pass is sufficient for the demo I had put together. What the user specifically wants to do is still under investigation.
As a more long-term goal I agree with you that consolidating the two heterogeneous approaches into a single approach is desired and hope to do that. AnnotateTarget looks to be complete. I though about wrapping CPU and GPU as "external" compilers but that seems like a more roundabout solution to the problem, better would be to unify the "external" and "internal" compilers so that either could be used with the compile_begin/end annotation.

@rkimball Exactly. We should eliminate "external" and "internal" but just treat every target evenly. Meanwhile, the corresponding changes in compile engine have to be made to deal with built in targets, as you pointed out.
While I still feel we should not have two mechanisms doing similar things, I'd suggest having an RFC to improve the BYOC flow so that it could be even more general.
cc @zhiics

This PR appears to be out of date, please feel free to reopen it if this is not the case.
As part of the new year we are attempting to triage the project's open pull requests to ensure that code which
is ready for review and/or merging receives adequate attention.
Thanks again for your contribution, and feel free to reach out to discuss these changes.


[php][openssl][cert] openssl.cafile

There is a problem with openssl.cafile and the ca-bundle.crt
It's not possible to download

https://github.com/WPN-XM/server-control-panel/releases/download/0.8.4/wpnxm-scp-x86.zip

but this URL for instance works: http://download.documentfoundation.org/libreoffice/stable/4.3.7/win/x86/LibreOffice_4.3.7_Win_x86_helppack_de.msi

Found this: When you receive this error, it likely means that your CA is out-of-date and needs to be updated.

No, it's not out of date...

The cert for github or s3 is not included in the ca-bundle.crt?

Which cert is missing?

openssl s_client -connect github.com:443 -showcerts

php.ini:
[curl]
curl.cainfo =C:\server\bin\openssl\ca-bundle.crt

[openssl]
openssl.cafile=C:\server\bin\openssl\ca-bundle.crt

Cert Bundle Sources

We include ca-bundle.crt from our repo configs/ssl/ca-bundle.crt
http://curl.haxx.se/ca/cacert.pem
https://github.com/bagder/ca-bundle/blob/master/ca-bundle.crt

php -r var_dump(openssl_get_cert_locations());:
array(8) {
  ["default_cert_file"]=>
  string(54) "D:/php_core_deps/pack/vc14/x64/openssl-1.0.2a/cert.pem"
  ["default_cert_file_env"]=>
  string(13) "SSL_CERT_FILE"
  ["default_cert_dir"]=>
  string(51) "D:/php_core_deps/pack/vc14/x64/openssl-1.0.2a/certs"
  ["default_cert_dir_env"]=>
  string(12) "SSL_CERT_DIR"
  ["default_private_dir"]=>
  string(53) "D:/php_core_deps/pack/vc14/x64/openssl-1.0.2a/private"
  ["default_default_cert_area"]=>
  string(45) "D:/php_core_deps/pack/vc14/x64/openssl-1.0.2a"
  ["ini_cafile"]=>
  string(35) "C:\server\bin\openssl\ca-bundle.crt"
  ["ini_capath"]=>
  string(0) ""
}

The default configuration looks a bit strange.
PHP Errors
PHP Warning:  fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in C:\server\openssl.php on line 40

Warning: fopen(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in C:\server\openssl.php on line 40
PHP Warning:  fopen(): Failed to enable crypto in C:\server\openssl.php on line 40

Warning: fopen(): Failed to enable crypto in C:\server\openssl.php on line 40
PHP Warning:  fopen(https://github.com/WPN-XM/server-control-panel/releases/download/0.8.4/wpnxm-scp-x86.zip): failed to
ver\openssl.php on line 40

PHP Script for reproduction:
#$url = 'https://github.com/WPN-XM/server-control-panel/releases/download/0.8.4/wpnxm-scp-x86.zip';
$url = 'http://download.documentfoundation.org/libreoffice/stable/4.3.7/win/x86/LibreOffice_4.3.7_Win_x86_helppack_de.msi';
download($url, __DIR__ . '/scp.zip');
function download($url, $path)
{
	$file = fopen($url, "rb");
	if ($file) {
		$newf = fopen($path, "wb");
		if ($newf) {
			while(!feof($file)) {
				fwrite($newf, fread($file, 1024 * 8), 1024 * 8);
		}}}
	if ($file) {fclose($file);}
	if ($newf) {fclose($newf);}
 }
 var_dump(openssl_get_cert_locations());

this is a ca-bundle.crt problem


Offset text for buttons

Please add the ability to make multi-line text on buttons . I used '\n' but got an odd looking character instead. Multi-line text is useful when creating a custom toooltips.

I had to make the Reddit image 2.5x the height that it appears to achieve this result.

Added in 2.0.4


Why does it keep loading when switching rooms?

Describe the bug
A clear and concise description of what the bug is.
Steps to reproduce
Describe us how we could reproduce the bug you're trying to report
You can also use https://github.com/advanced-chat/vue-advanced-chat-sandbox and share the source code to reproduce the bug.
Example:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen when you encounter the bug.
Screenshots
If applicable, add screenshots to help explain your problem.
Device (please complete the following information)

OS: [e.g. iOS, Windows 10, ...]
Browser: [e.g. Chrome 75, Safari 9]
Package version: [e.g. 2.2.0]

Additional context
Add any other context about the problem here.

the same problem

did anyone solved? how do you manage modify this module in your  proj?


Fix helm.values field to support mutiple values

helm.values field type used to be map[string]interface{}. Looping through the map to generate a env variable leads to a inconsistent env variable issue. Since we change the helm.values field type to JSON already, we can pass it through env variable directly, and process it later in helm-sync.

/retest

/retest


links to non-existing external URLs in chirpy

Checklist

[x] I have read the tutorials and know the correct effect of the functional design.
[x] There are no similar reports on existing issues (including closed ones).
[x] I found the bug on the latest code of the master branch.

Describe the bug
I'm using link checker lychee to validate links on the page created by Jekyll + Chirpy.
Currently it seems like pages generated chirpy contains links to non-existing web pages like:

https://fonts.googleapis.com/
https://www.googletagmanager.com/
https://fonts.gstatic.com/

To Reproduce
Steps to reproduce the behavior:
❯ lychee  --no-progress https://chirpy.cotes.page/
✗ [400] https://www.googletagmanager.com/ | Failed: Network error: Bad Request
✗ [404] https://fonts.googleapis.com/ | Failed: Network error: Not Found
✗ [404] https://fonts.gstatic.com/ | Failed: Network error: Not Found
Issues found in 1 input. Find details below.

[https://chirpy.cotes.page/]:
✗ [404] https://fonts.gstatic.com/ | Failed: Network error: Not Found
✗ [400] https://www.googletagmanager.com/ | Failed: Network error: Bad Request
✗ [404] https://fonts.googleapis.com/ | Failed: Network error: Not Found

🔍 51 Total ✅ 48 OK 🚫 3 Errors (HTTP:3)

or
curl -s https://chirpy.cotes.page/ | grep -E '(https://fonts.googleapis.com|https://www.googletagmanager.com|https://fonts.gstatic.com)'

curl -s https://chirpy.cotes.page/ | less --pattern='https://fonts.googleapis.com|https://www.googletagmanager.com|https://fonts.gstatic.com/'

Expected behavior
When running link checker against chirpy generated web page (like https://chirpy.cotes.page/) there should be no links to non-existing web pages (404).
Environment

Command
Version

ruby -v

gem -v

bundle -v

bundle exec jekyll -v

bundle info jekyll-theme-chirpy

I used https://chirpy.cotes.page as the reference...

Desktop

macOS latest
Chrome latest
Smartphone

n/a
Additional context

Hi @ruzickap, these links are used for preconnect and dns-prefetch, so no 404 detection is required.
See also:
https://github.com/cotes2020/jekyll-theme-chirpy/blob/782a930fdf298739cd205de7708598ba96b3d276/_includes/head.html#L60-L63
https://github.com/cotes2020/jekyll-theme-chirpy/blob/782a930fdf298739cd205de7708598ba96b3d276/_includes/head.html#L78-L83

Ok...
Looks like it is common to just "ignore" it: https://github.com/filiph/linkcheck/issues/49
Another answer: https://generatepress.com/forums/topic/https-fonts-gstatic-com/
Maybe it be possible to use some "existing" URLs in this case:

https://fonts.googleapis.com/css2?family=Lato
https://www.googletagmanager.com/gtag/js

Anyway...
I'm going to close it and configure the "link checker" to ignore these URLs.
Thank you

My understanding is that the values specified by preconnect  and dns-prefetch are usually domain names (not including the file path), and these domain names are used by the browser to communicate with the resource server at the Transport Layer(TCP), and the detection of 404 is performed at the Application Layer (HTTP).
Checking the validity of HTTP resource links is already done with Html-Proofer, I'm not sure why you would use an additional test action like the linkcheck.


[RFC] Add command in bin for clearing cache even if environment is broken

Follows the discussion at https://github.com/symfony/symfony/issues/23592
This command allows one to run bin/clear-cache or bin/clear-cache <envName> in any situation. It's consciously implemented als Plain Ole PHP since it is most commonly used to fix a temporary broken environment, in which the vendor directory or its packages may also well be (temporarily) broken. So no use in depending on symfony/console or 'symfony/process`.
If we do this the clearCache command in SensioDistributionBundle will also need to be patched afterwards, and some documentation changed.
Based on 3.3 as it deprecated clear:cache without --no-warmup, no use in adding it to older versions.

I think this can be done in the Makefile if not already done tbh

@ostrolucky most of those comments are intentional of course.

There is no assumption about the location of the composer.json. It is used if you have a "normal" install. Otherwise we can find nor use it.
The use case for the script is being able to restore broken installs. No external dependencies, so no AppKernel loading. If you have a "normal" install, it works. If you don't, it won't. But the same goes for bin/console and we keep that in there in the default installl.
The use of system commands is intentional, as it provides much more reasonable output than recursive unlink will ever give (think read-only filesystems etc.). Admittedly I don't think that output is currently being piped correctly, and you're right about the exit codes.
The path and newline separators do not matter. PHP is well documented since somewhere in the 4.x era to be agnostic to them. Using DIRECTORY_SEPARATOR in paths and PHP_EOL in console output has no added value therefore, they're only useful for example in parsing local paths and writing platform-specific file formats.
The bin/console script is just as (un)testable.

Adding such script just for one uncommon use-case is a total mess. There are workarounds for symfony/symfony#23592, and implementing this kind of logic rough and tough like that just lacks understanding of how Symfony works... 😕

The workaround appears to be rm -rf according to https://github.com/symfony/symfony/issues/23592#issuecomment-318627886. I know it's rough and tough, but it's a PR in Symfony Standard Edition, not Symfony core. It doesn't matter that you can break it by going power-user in Symfony, as that will break more scripts, including potentially bin/console itself.
Anyway, if the discussion is going to the level of implying I don't understand how Symfony works I'll just close and we'll keep advising people to rm -rf.


feat(rust): worker address as output of tcp-connection create

Closes https://github.com/build-trust/ockam/issues/4600

@sergey-melnychuk Thank you for spending time on this, while we review and before we can merge please

[ ] Accept the Ockam Contributor License Agreement by adding your Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam-contributors repository.

The easiest way to do this is to edit the CONTRIBUTORS.csv file in the github web UI and create a PR, this will make the commit as verified.

https://github.com/build-trust/ockam-contributors/pull/202


Headlamp crashes if one clusters certificate authority path is misconfigured or ca file is not found.

Description
When multiple clusters are configured and one of the clusters certificate authority is misconfigured Headlamp crashes. Instead it should skip that particular cluster and work for the other clusters.
Environment and steps to reproduce

minikube start
rm ~/.minikube/ca.crt
Run headlamp

Expected behavior
Additional information
logs:
2022/09/05 16:38:18 plugins-dir: /Users/santhoshnagarajs/Library/Application Support/Headlamp/plugins
*** Headlamp Server ***
  API Routers:
	localhost:4466/clusters/docker-desktop/{api...} -> https://kubernetes.docker.internal:6443
2022/09/05 16:38:18 Failed to add certificate:open /Users/santhoshnagarajs/.minikube/ca.crt: no such file or directory
exit status 1

This log should be non-fatal
https://github.com/kinvolk/headlamp/blob/058fffb65ac2d7e5c35a84e9546beb39db715171/backend/cmd/cluster.go#L51

This is a blocker for https://github.com/kinvolk/headlamp/pull/692


[Enhancement] Add BigGAN's README link to the homepage

Add BigGAN's README link to the homepage.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@e0a9378). Click here to learn what that means.
The diff coverage is n/a.

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

@@            Coverage Diff            @@
##             master      #82   +/-   ##
=========================================
  Coverage          ?   76.05%
=========================================
  Files             ?      118
  Lines             ?     8031
  Branches          ?     1494
=========================================
  Hits              ?     6108
  Misses            ?     1541
  Partials          ?      382

Flag
Coverage Δ

unittests
76.05% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

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


Fix tgt_mask

fix #139
I confirmed that the issue #139 is resolved with this change.

This is really unsupported. Please see my comment: https://github.com/baudm/parseq/issues/139#issuecomment-2136848401
For number of decoder layers > 1, the correct usage is to set refine_iters to zero.


TemplateExpression with differential operator

This makes it so you can put derivative operators in the template structure when doing structured searches. This works with a derivative operator D that computes the derivative with respect to the i-th argument, and can be nested arbitrarily to get higher-order derivatives. However, note that nesting it multiple times could be take a while to compile though, since it will compile n^d operators for d-th order derivatives. (Runtime performance should be unaffected)
Here's an example:
using SymbolicRegression
using SymbolicRegression: D

structure = TemplateStructure{(:f, :g)}(
    ((; f, g), (x, y)) -> f(x, y) - D(f, 1)(x, y) + g(y)
)

This imposes a structure that for some symbolic $f$ and $g$, the evaluation would use $f(x, y) - \frac{\partial f(x, y)}{\partial x} + g(y)$.
Also helps support feature request from @gm89uk + @DeaglanBartlett. Interested to hear whether you run into any issues for it before I merge it!

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

44 of 44 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.06%) to 95.563%

Totals

Change from base Build<PHONE_NUMBER>3:
0.06%

Covered Lines:
3166

Relevant Lines:
3313

💛  - Coveralls

Turns out Zygote.jl is awful at second-order differentiation, even for tiny operators like cos. So I will switch things to ForwardDiff.jl

is there any reason to use Enzyme or Mooncake for this?

It is probably overkill as all I'm doing is:

Generating a derivative operator for each current operator
Creating a new operator enum with those derivative operators (inferrable, even with runtime-generated expressions)
Applying the chain rule and "shifting" the operator indices in the tree when we need to call the derivatives
Running regular eval_tree_array with that new operator enum

So all I'm using ForwardDiff for is this:
function (d::OperatorDerivative{F,1,1})(x) where {F}
    return ForwardDiff.derivative(d.op, x)
end
function (d::OperatorDerivative{F,2,1})(x, y) where {F}
    return ForwardDiff.derivative(Fix{2}(d.op, y), x)
end
function (d::OperatorDerivative{F,2,2})(x, y) where {F}
    return ForwardDiff.derivative(Fix{1}(d.op, x), y)
end

I've had a lot of issues in getting Enzyme into SR (https://github.com/EnzymeAD/Enzyme.jl/issues?q=is:issue author:MilesCranmer – though have appreciated the support from the authors) so want to avoid making it a direct dependencies until it is more stable. Mooncake I haven't tried yet but the README says it is still under development so probably want to avoid.
On the other hand, ForwardDiff.jl is already an indirect dependency via Optim.jl so I feel pretty safe about using it. What do you think?

On the other hand, ForwardDiff.jl is already an indirect dependency via Optim.jl so I feel pretty safe about using it. What do you think?

that's totally true, yea

Update: since the derivatives are general to any DynamicExpressions.jl expression, I'm going to register a separate package DynamicAutodiff.jl, then import that to SymbolicRegression.jl


[DOCS] Developer's guide

Write a general description on how the cashflower package works.

Done in cf1b91742756e5280c300b9b0b3ff5aaf98f7b2f


host-gen-js: Output optimization

This is based to https://github.com/bytecodealliance/wit-bindgen/pull/415, which is in turn based to https://github.com/bytecodealliance/wit-bindgen/pull/414, so should land after those.
Updates the output to be more friendly to minifiers resulting in a smaller total JS file size - arrow functions are used for intrinsics, and the dataView(memory) pattern is replaced with a dedicated dataView{n} binding per memory, which should be able to be optimized out if not used for a particular memory.

This looks reasonable, but the dataView optimization I don't think will work because memory.grow can invalidate the prior ArrayBuffer so JS needs to always check to see if the ArrayBuffers match to get the most up-to-date view of memory.

Ah, ok I can't come up with a better alternative, will close this then.


Notebook is not working anymore

Hello,
https://github.com/tensorflow/docs/blob/940d94cb568bcdd4e82402eff3403ddcf5f874f2/site/en/tutorials/understanding/sngp.ipynb
Running this notebook, currently is leading to some errors at particular cells. Could you please update the notebook so that no error occurs? Thank you.
Best regards,
Anil

@anilkumarvvss,
Thank you for the issue.
Here you are trying to install the Tensorflow v2.16 which by default uses the Keras3.0 version. There are changes that happened in the keras3.0 which might be the reason for the error you are facing.
!pip install -U -q --use-deprecated=legacy-resolver tf-models-official tensorflow

https://keras.io/api/
When I tried to execute the same code with tensorflow v2.15, it was executed without any issue/error. Kindly find the gist of it here. Thank you!

could you adapt it to newer versions if possible? because we tried running it with minor modifications(to bypass errors) with new versions, but it's giving significantly different results with our workarounds. Please have a look at our workarounds in the attached notebook. Thanks :)


[Gekidou MM-48006] Show keyboard when select a modifier

Summary
This PR makes a change so that when a user clicks a modifier in the search screen, they search input gets focussed and the keyboard show.
Ticket Link
https://mattermost.atlassian.net/browse/MM-48006
Checklist

[ ] Added or updated unit tests (required for all new features)
[ ] Has UI changes
[ ] Includes text changes and localization file updates
[ ] Have tested against the 5 core themes to ensure consistency between them.

Device Information
This PR was tested on:
Screenshots

Release Note

@matthewbirtch, this does not currently have the cursor position placed between the "" when that modifier is tapped. It is not necessarily hard to implement, but would prefer to tackle that in another ticket and hopefully get to beta.  I'll continue working on it, but that might have to get in next week.


Request type DEPOSIT_NFT missing from docs

The request type DEPOSIT_NFT is missing from this documentation:
https://developer.build5.com/docs/api-otr/interfaces/NftDepositTangleRequest

Will be fixed as part of the https://github.com/build-5/core/issues/2549


Implement CoreBot unit tests for JS

JavaScript task for https://github.com/microsoft/botframework-sdk/issues/5347

Refactored core-bot with unit tests for JS have been merged into the corebot-updates branch.


Migration Failed on 2.1.1 - On Inserting __EFMigrationsHistory

When I attempt to create a new database migration via the following command:
dotnet ef migrations add Initial
It works just fine and successfully too, but after running dotnet ef database update, I get this error:
INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion")
VALUES<PHONE_NUMBER>0022_Initial, 2.1.1-rtm-30846);
Npgsql.PostgresException (0x80004005): 42601: syntax error at or near "_Initial"

I am assuming that the insert command either wasn't parameterized or someone forget to add double quotation marks around the values?
When I rolled it back from version 2.1.1 to version 2.1.0, it worked just fine by recreating a migration seed and applying it to database.

I took a quick look around, but the default type mapper and our override of it look normal.
@BlackCentipede Could you provide a minimal reproduction (preferably a repo that we can clone) that demonstrates this issue?

Related sources
https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/blob/196b94c0760f495d96cdf01858211f00dd583e66/src/EFCore.PG/Update/Internal/NpgsqlUpdateSqlGenerator.cs#L41-L61
EF Core: UpdateSqlGenerator.AppendValues(...)
/// <summary>
///     Appends values after a <see cref="AppendValuesHeader" /> call.
/// </summary>
/// <param name="commandStringBuilder"> The builder to which the SQL should be appended. </param>
/// <param name="operations"> The operations for which there are values. </param>
protected virtual void AppendValues(
    [NotNull] StringBuilder commandStringBuilder,
    [NotNull] IReadOnlyList<ColumnModification> operations)
{
    Check.NotNull(commandStringBuilder, nameof(commandStringBuilder));
    Check.NotNull(operations, nameof(operations));

    if (operations.Count > 0)
    {
        commandStringBuilder
            .Append("(")
            .AppendJoin(
                operations,
                SqlGenerationHelper,
                (sb, o, helper) =>
                {
                    if (o.IsWrite)
                    {
                        if (!o.UseCurrentValueParameter)
                        {
                            AppendSqlLiteral(sb, o.Value, o.Property);
                        }
                        else
                        {
                            helper.GenerateParameterNamePlaceholder(sb, o.ParameterName);
                        }
                    }
                    else
                    {
                        sb.Append("DEFAULT");
                    }
                })
            .Append(")");
    }
}

EF Core: UpdateSqlGenerator.AppendSqlLiteral(...)
private void AppendSqlLiteral(StringBuilder commandStringBuilder, object value, IProperty property)
{
    var mapping = property != null
        ? Dependencies.TypeMappingSource.FindMapping(property)
        : null;
    mapping = mapping ?? Dependencies.TypeMappingSource.GetMappingForValue(value);
    commandStringBuilder.Append(mapping.GenerateProviderValueSqlLiteral(value));
}

Note: there was an issue a bit back where we had missing quotes, which was a result of mixing dependencies. I don't have time to search for it at the moment, but it was a result of mixing dependencies (e.g. Microsoft.EntityFramework from one minor version, Npgsql.EntityFrameworkCore.PostgreSQL from another). Please make sure your csproj references correspond and do dotnet restore. If the issue persists, please post a repro (including your csproj) as @austindrenski requested above.

Sorry for delayed response, anyway, I am not able to reproduce the issue anymore when I have updated all of the packages to the latest version: 2.1.1. So I'll close this issue, as @roji said, this could be why it failed for me when I am updating existing project. Thank you for taking the time to look into it.
Have a good evening.

Thanks for posting back, glad the issue disappeared.


[docs] Typo in overloading-guide.rst

Trivial typo. Used these docs for a test at work, thanks a lot!

Thanks for the patch. Closing/Reopening to get a build without release-notes requirement.


cant make it work

Hi non experienced user here, followed your github procedure but the camera does not show up in prusa connect, tried these combinations /dev/video0 and v4l2:/dev/video0
it shows like this: HD Web Camera: HD Web Camera (usb-3f980000.usb-1.1.3): /dev/video0
rebooted after every change, no luck yet
do I need to start something previous to reboot?
btw, camera works perfect via octoprint, can be this be a conflict or the same stream can be used for both?
Thanks
CAMERA_NAMES=("Prusacam")
CAMERA_DEVICES=("v4l2:/dev/video0")
CAMERA_RESOLUTIONS=("1920x1080")
CAMERA_OPTIONS=("--jpeg 95 -S 20")
TOKENS=("mytoken")

Hello - sorry for the inconvenience,
could you run the webcam_to_prusa_connect.sh in the terminal and post some logs?

./webcam_to_prusa_connect.sh
Input variables:
Camera 1, Name: Prusacam, XXXXXXXX
Processing camera: 1
Name: Prusacam
Token: XXXXXXXXXXX
Fingerprint: camera0000000001
--- Opening v4l2:/dev/video0...
/dev/video0 opened.
No input was specified, using the first.
Error selecting input 0
VIDIOC_S_INPUT: Device or resource busy

400 Bad Request

400 Bad Request
nginx

#######

I think your first idea was right: this device seems blocked by octoprint.
To fully prove this, you maybe could remove the cam from octoprint and test it again.
Octoprint seems to provide a rtsp stream. The propose of this script was to not use such a stream, because pusa connect uses single pictures only.
I think the upload.sh from here should work.
https://www.reddit.com/r/prusa3d/comments/1971673/streaming_a_webcam_via_rtsp_to_prusa_connect/
This was the starting point for my script and I removed the need for a rtsp stream.

Thanks!! Maybe the solution is easier, I just remembered that the Octoprint install of the camera streamer allows to take snapshots, you just need to change a parameter in the address:
http://<IP_ADDRESS>/webcam/?action=snapshot
this provides a static image that could be feed to Prusa connect, but I don't know how to implement this, maybe you can help, the solution will also help all current octoprint users.
If you don't have the time, any pointer on how to do it will help, I "programmed" some solutions with the help of Claude and ChatGPT
Thanks again!

Thanks!! Maybe the solution is easier, I just remembered that the Octoprint install of the camera streamer allows to take snapshots, you just need to change a parameter in the address:
http://<IP_ADDRESS>/webcam/?action=snapshot
this provides a static image that could be feed to Prusa connect, but I don't know how to implement this, maybe you can help, the solution will also help all current octoprint users.
If you don't have the time, any pointer on how to do it will help, I "programmed" some solutions with the help of Claude and chatgpt
Thanks again!

Never mind, kept looking and found an octoprint plugin that does exactly this. It requests the camera token and then does the api call and everything else: https://github.com/rizz360/prusa_connect_uploader
Thanks for the help, I'm closing this issue.


"istioctl validate" IstioOperator YAML

Resolves https://github.com/istio/istio/issues/21473
Motivation: https://github.com/istio/istio/issues/21642

Adding additional request for Environments review, to make sure that we should be validating IstioOperator for users who ask.

In response to a cherrypick label: #21644 failed to apply on top of branch "release-1.5":
Applying: Additional test case and refactor to expose validation of top-level IstioOperator
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
A	operator/pkg/apis/istio/common.go
M	operator/pkg/validate/validate.go
Falling back to patching base and 3-way merge...
Auto-merging operator/pkg/validate/validate.go
CONFLICT (modify/delete): operator/pkg/apis/istio/common.go deleted in HEAD and modified in Additional test case and refactor to expose validation of top-level IstioOperator. Version Additional test case and refactor to expose validation of top-level IstioOperator of operator/pkg/apis/istio/common.go left in tree.
Patch failed at 0002 Additional test case and refactor to expose validation of top-level IstioOperator


Implement backend for tagging system

Implement a tagging system that allows users to categorize resources with relevant tags. This component facilitates easier search and filtering of resources based on specific topics or subjects.

i want to work on this issue!


plus signs are incorrectly interpreted as project references (only in drawer)

Steps to reproduce

Hit Ctrl+N to open the new todo dialog
type A+B = C +test_project and save the todo

Actual result
In the drawer, the +B part is interpreted as a non-existent B project
Expected result
T +B part should be treated as part of the todo text
Attached GIF

Hey @andrei-a-papou . Although the gifs are of course very helpful, can I kindly ask you to use the issue-templates? It really help keeping this backlog tidy and I would like to avoid that other users see issues without the template and also start creating those like this.
If the templates don't make sense to you, please let me know how they should be re-structured and I will take care of it. Thanks a lot :)

@ransome1 I think the templates are a bit verbose but this is totally fine if one can trim them down to only keep the necessary information when reporting a bug. I agree templates are helpful in many ways, of course.
I've corrected the bug report above, is this good enough? Would you add more info to it, if yes, could you give me an example of what's missing?

@andrei-a-papou its perfect like that. This is so much.

@andrei-a-papou this could be a duplicate of https://github.com/ransome1/sleek/issues/617.

@ransome1 It looks that way, yes. I missed that other bug report.

Is this really what it looks like on your system? Definitely something wrong with the formatting here. This is some Linux distro you're using, right?

This is a Debian box, yes. What exactly do you mean by wrong formatting? I noticed recently that little numbers inside circles are no longer centered properly, I don't think sleek had this issue before.

 I missed that other bug report.

Closing here, will be handled in https://github.com/ransome1/sleek/issues/617

Yes, this is v.2.0.8, AppImage. On Ubuntu, do you use AppImage or native package format?

The screenshot you took was from a GIF, which had been downsampled by the screencasting app. Here's a normal PNG image:


Fix broken link to NSA/CISA technical security report

Checklist

[x] Issue(s) linked

Fixes #77

Thanks @aniketh-varma ! We'll include this fix with an upcoming version of this mod later this week.


Resetpass

Coverage decreased (-4.5%) to 45.339% when pulling 0f55446cfb20b6aeeb72af0be18fa5df746d44dc on resetpass into b86b3a577f2e403d2377bab363d0c6769bfc091f on master.

Coverage decreased (-2.1%) to 47.696% when pulling 654776fbc079e8dab786724f74ba7cf8c3bcca26 on resetpass into b86b3a577f2e403d2377bab363d0c6769bfc091f on master.


Godot 3.5 Support

Hey,
I wanted to check in and see if there was support for 3.5 planned. I was looking at the 4.x branch and it seems like godot 3.5 is going to take a bit of effort to port to from either side. Likely easier to take the 4.x branch and remove the 4.x bits. Has there been any work towards this?
Thanks,
Michael Brune

@MJBrune
Hello and sorry for the late response.
Yes, I am working on a new and improved version of the jumplink addon that works with the new NavigationServer in Godot 4.x that was now ported to Godot 3.x. Unfortunately there are a lot of issues currently with the new navigation implementation in Godot that slows down progress and the 3.x port is botched with a lot of issues and missing exposed functions required for this addon. I am currently waiting until official Godot navigation sorts out all the main issues.

Hey, No worries, we all work on our own time. What are the issues that
you've seen? Maybe I can try to make a pull request to the engine to fix or
address these things. If I can get an idea of what's going on with how 3.5
broke the nav link behavior maybe I can work on solving the overall issue.
From my limited time with it, it was seeming like there wasn't a good way
to get the navmesh instance from the nav system anymore. Is this the case?
On Sun, Feb 6, 2022, 6:10 AM smix8 @.***> wrote:

@MJBrune https://github.com/MJBrune
Hello and sorry for the late response.
Yes, I am working on a new and improved version of the jumplink addon that
works with the new NavigationServer in Godot 4.x that was now ported to
Godot 3.x. Unfortunately there are a lot of issues currently with the new
navigation implementation in Godot that slows down progress and the 3.x
port is botched with a lot of issues and missing exposed functions required
for this addon. I am currently waiting until official Godot navigation
sorts out all the main issues.
—
Reply to this email directly, view it on GitHub
https://github.com/smix8/Godot_3D_Navigation_Jump_Links/issues/3#issuecomment-1030840170,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADGR2C2URY377FYEUWTP3LUZZ6L5ANCNFSM5ND5WPVQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@MJBrune
A few issues like missing exposed RID functions have been fixed.
One main issue is that the NavigationServer get_closest_point_owner() now returns Map RID's instead of References to SceneTree NavigationMeshInstances like before. Since Map's are already merged information of all NavigationMeshInstances the critical information for this addon which SceneTree Node contributed which part of the navmesh seems to be no longer available.

Yeah, that's exactly what I ran into trying to port to 3.5 too. Is there
any open issue with this on Godot's end? If not I'd be happy to get the
ball rolling and perhaps even write the bits that are needed. Although it
highly depends on the new system and if that information is even available
anymore.
On Sun, Feb 20, 2022 at 3:17 PM smix8 @.***> wrote:

@MJBrune https://github.com/MJBrune
A few issues like missing exposed RID functions have been fixed.
One main issue is that the NavigationServer get_closest_point_owner() now
returns Map RID's instead of References to SceneTree
NavigationMeshInstances like before. Since Map's are already merged
information of all NavigationMeshInstances the critical information for
this addon which SceneTree Node contributed which part of the navmesh seems
to be no longer available.
—
Reply to this email directly, view it on GitHub
https://github.com/smix8/Godot_3D_Navigation_Jump_Links/issues/3#issuecomment-1046343451,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADGR2FGMIC3EF2M4RJDGX3U4FZCHANCNFSM5ND5WPVQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@MJBrune
As far as I know there is no specific issue open yet.
The current order in Godot 4.x and Godot 3.x how the merged navmesh is created is like this:
GodotNavigationServer::region_bake_navmesh(Ref<NavigationMesh> r_mesh, Node *p_node)
-->Entry point with both references to meshresource and region node.
NavigationMeshGenerator::bake(Ref<NavigationMesh> p_nav_mesh, Node *p_node)
--> Starts the parse of the navigationmesh from the NavigationRegion Node NavigationMesh Resource.
This is als the point where the region node information is dropped and only the mesh resource is used.
NavigationMeshGenerator::_build_recast_navigation_mesh()
--> creates the final merged mesh result with the ReCast navigation module.
NavigationMeshGenerator::_convert_detail_mesh_to_native_navigation_mesh(const rcPolyMeshDetail *p_detail_mesh, Ref<NavigationMesh> p_nav_mesh)
--> This has still the Reference to the NavigationMesh but no longer to the Node in the SceneTree.

With https://github.com/godotengine/godot/pull/60661 merged among some other fixes the main obstacles for Godot 3.5 support are now removed.
I don't think I will be ready with a new addon version when Godot 3.5 is released but should follow soon after.

Fixed with 4c04cb555bbe71ab1dcc6d36a717b59e736355a3

Wonderful work. I'm very excited for it
On Sat, Jun 18, 2022, 6:07 PM smix8 @.***> wrote:

Fixed with 4c04cb5
https://github.com/smix8/Godot_3D_Navigation_Jump_Links/commit/4c04cb555bbe71ab1dcc6d36a717b59e736355a3
—
Reply to this email directly, view it on GitHub
https://github.com/smix8/Godot_3D_Navigation_Jump_Links/issues/3#issuecomment-1159592248,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADGR2HSBFG5N2UGQ5RLBHTVPZXDRANCNFSM5ND5WPVQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Add user interface to send commands easily

Add an async method that can send a command_long and await for the answer with it


[TEST ONLY] - Fix release crash

Fixes #4117

@yaichenbaum this is just for test. Anyway after "WinUI 2.6 Preview (#4090)" I can't even start the app in Debug mode. Is it just me?

@yaichenbaum this is just for test, not ready to review it yet. Anyway after "WinUI 2.6 Preview (#4090)" I can't even start the app in Debug mode. Is it just me?

For me, it works in debug, but not in release.

Noope with WinUI 2.5 everything is fine but with 2.6 it crashes in Release Mode when setting the FontIcon foreground.
You can revert #4091 (ideaaly you should only revert changes to StatusBarControl.xaml, the rest should be kept)

@gave92 Do you think we are missing something in the default.rd.xml file?

@yaichenbaum i do not know. we need to test release mode a bit with 2.6 since what I was doing in #4091 looks pretty ordinary.


Fixed attribute error with new unit_of_measurement changes

Minor fix for issue that cropped up after upstream merge.  It was a variable naming clash with the unit_of_measurement field.

You can actually remove both friendly name and unit of measurement from the state attributes. I have upgraded Entity (what used to be Device) to auto add it to the attributes if they exist: source

Ok, I have removed them, I'll make sure I go back and update any other components too.

Sorry, should have communicated it better. We can merge this if tests pass.

Looks like you forgot to remove some imports.

Sorry, forgot to flake8 it after the changes, it should be all good now

Made you a contributor so you can merge yourself :+1:

Coverage increased (+0.02%) to 65.25% when pulling 470096047b8a9979655823d964fad15c7518d1dc on jamespcole:nzb-dev into e8724358708da1fc1c51844ad0b510db3570d60a on balloob:dev.

Coverage decreased (-0.52%) to 64.7% when pulling 470096047b8a9979655823d964fad15c7518d1dc on jamespcole:nzb-dev into e8724358708da1fc1c51844ad0b510db3570d60a on balloob:dev.


Backup Reveal Words Verification

Add verify, dont trust spot check with three random numbered seed words to current flow.
Remove first, and third checks: "I wrote down the words".


[Bug]: history is lost when using BlobsStorage

Describe the bug
I'm extending the 04.ai.a.teamsChefBot sample, and I've replaced the MemoryStorage with the BlobsStorage implementation from the botbuilder-azure-blobs package. Which is working as expected, and I can save the converstation history to blob storage most of the cases.
However when the user does not wait enough and types in two messages in quick succession, it throws an error:

[onTurnError] unhandled error: RestError: The condition specified using HTTP conditional header(s) is not met.

I think this is happening because the DefaultTrunStateManger tries to save the two histories using the same ETAG which fails on the blob storage side.
e.g., the starting history is look like this:
ETAG: 1
Human: first message
Bot: response to first message
in teams the user types in two messages, in this case the history is not updated in between and I end up with two histories where non of them containing all the messages, but having the same etag
ETAG: 2
Human: first message
Bot: response to first message
Human: second message
Bot: response to second message
ETAG: 2
Human: first message
Bot: response to first message
Human: third message
Bot: response to third message
I've tried to use the LastWriterWinsStore implementation from the example: 04.q.questBot which resolves this error, however in this case part history is lost because it loses some of the messages, because of the list writer semantic. However in this case because there is only writer it should somehow keep track the whole history and should not lose any of the messages.
Is there any solution this problem? To use BlobsStorage and keep all the history even when the user sends multiple messages quickly?

@corinagum thank you for looking into this, I'm afraid that this might be a larger problem to fix.
I've forked the pushed the repro here: https://github.com/nemesv/teams-ai/tree/history_repro
I've only modified the 04.ai.a.teamsChefBot. To run the code you need to setup and configure the blob storage in the .env.local.user file
SECRET_STORAGE_CONNECTION_STRING=
STORAGE_CONTAINER=

This is how it looks in the teams when using the BlobStorage:

I've logged the messages before sending to the blobstorage:
{
  "msteams/28:09446dad-bb7b-42f4-ab24-97f9c0410280/conversations/a:1hz5yXATMKzoEyZ675s29Fi2vxzW9T8yWUZKeZ4niHa3e9DU6nrkseqekztS_t2snH8o_HutlmU4esr9cmHlcickwADl2rV8MvJn6jTHsvmu7IGwNIc7AH26qU_B4Y1et": {
    "__history__": [
      "User: 1",
      "Assistant: Hello there! Welcome to Teams Chef, your expert guide in Microsoft Teams app development. May I know your name, please?",
      "User: test1",
      "Assistant: Great to meet you, test1! As a junior developer learning Microsoft Teams development for the first time, I'm here to help you build new apps for Microsoft Teams. Are you ready to get started?"
    ],
    "eTag": "\"0x8DB6BD2FE0EBA2B\""
  }
}

{
  "msteams/28:09446dad-bb7b-42f4-ab24-97f9c0410280/conversations/a:1hz5yXATMKzoEyZ675s29Fi2vxzW9T8yWUZKeZ4niHa3e9DU6nrkseqekztS_t2snH8o_HutlmU4esr9cmHlcickwADl2rV8MvJn6jTHsvmu7IGwNIc7AH26qU_B4Y1et": {
    "__history__": [
      "User: 1",
      "Assistant: Hello there! Welcome to Teams Chef, your expert guide in Microsoft Teams app development. May I know your name, please?",
      "User: test2",
      "Assistant: Great to meet you, test2! As a junior developer learning Microsoft Teams development for the first time, I'm here to guide you in your journey to build new apps for Microsoft Teams. Are you ready to get started?"
    ],
    "eTag": "\"0x8DB6BD2FE0EBA2B\""
  }
}

 [onTurnError] unhandled error: RestError: The condition specified using HTTP conditional header(s) is not met.
RequestId:61900150-f01e-0096-06bd-9d94e7000000
Time:2023-06-13T06:09:05.5851489Z

If I replace it with the LastWriterWinsStore there is no more RestError but the history does not contain both messages, only the second one

{
  "msteams/28:09446dad-bb7b-42f4-ab24-97f9c0410280/conversations/a:1hz5yXATMKzoEyZ675s29Fi2vxzW9T8yWUZKeZ4niHa3e9DU6nrkseqekztS_t2snH8o_HutlmU4esr9cmHlcickwADl2rV8MvJn6jTHsvmu7IGwNIc7AH26qU_B4Y1et": {
    "__history__": [
      "User: test",
      "Assistant: Hello there! My name is Teams Chef. What's your name? And how can I assist you in your journey to build new apps for Microsoft Teams?",
      "User: first",
      "Assistant: Nice to meet you, First! As a junior developer learning Microsoft Teams development for the first time, I'm here to guide you in your journey to build new apps for Teams. Do you have any specific questions or areas you'd like to focus on?"
    ]
  }
}
{
  "msteams/28:09446dad-bb7b-42f4-ab24-97f9c0410280/conversations/a:1hz5yXATMKzoEyZ675s29Fi2vxzW9T8yWUZKeZ4niHa3e9DU6nrkseqekztS_t2snH8o_HutlmU4esr9cmHlcickwADl2rV8MvJn6jTHsvmu7IGwNIc7AH26qU_B4Y1et": {
    "__history__": [
      "User: test",
      "Assistant: Hello there! My name is Teams Chef. What's your name? And how can I assist you in your journey to build new apps for Microsoft Teams?",
      "User: second",
      "Assistant: Nice to meet you, Second! As a junior developer learning Microsoft Teams development for the first time, I'm here to guide you in your journey to build new apps for Teams. Do you have any specific questions or areas you'd like to focus on?"
    ]
  }
}

Let me know if you need any further info to reproduce this issue!

AH I see! Thanks so much for the detailed repro steps -- I will be looking into this today and report back asap.


Add SDK 2.0 Bigframes Sklearn sample notebook

REQUIRED: Add a summary of your PR here, typically including why the change is needed and what was changed. Include any design alternatives for discussion purposes.

Official sample notebook for SDK2.0 Bigframes Sklearn Integration

REQUIRED: Fill out the below checklists or remove if irrelevant

If you are opening a PR for Official Notebooks under the notebooks/official folder, follow this mandatory checklist:

[ ] Use the notebook template as a starting point.
[ ] Follow the style and grammar rules outlined in the above notebook template.
[ ] Verify the notebook runs successfully in Colab since the automated tests cannot guarantee this even when it passes.
[ ] Passes all the required automated checks. You can locally test for formatting and linting with these instructions.
[ ] You have consulted with a tech writer to see if tech writer review is necessary. If so, the notebook has been reviewed by a tech writer, and they have approved it.
[ ] This notebook has been added to the CODEOWNERS file under the Official Notebooks section, pointing to the author or the author's team.
[ ] The Jupyter notebook cleans up any artifacts it has created (datasets, ML models, endpoints, etc) so as not to eat up unnecessary resources.

If you are opening a PR for Community Notebooks under the notebooks/community folder:

[ ] This notebook has been added to the CODEOWNERS file under the Community Notebooks section, pointing to the author or the author's team.
[ ] Passes all the required formatting and linting checks. You can locally test with these instructions.

If you are opening a PR for Community Content under the community-content folder:

[ ] Make sure your main Content Directory Name is descriptive, informative, and includes some of the key products and attributes of your content, so that it is differentiable from other content
[ ] The main content directory has been added to the CODEOWNERS file under the Community Content section, pointing to the author or the author's team.
[ ] Passes all the required formatting and linting checks. You can locally test with these instructions.

@matthew29tang can this notebook run on Python 3.9 instead of 3.10? If so can you try?
There seems to be an issue with the test framework on 3.10:
Step #1: /bin/sh: 1: python3.1: not found
We will get it fixed. @ivanmkc @andrewferlitsch

Thanks for the pointer, I've unpinned the python version.

Thanks for the review! I've addressed all the other comments.

@matthew29tang thank you for addressing the comments. I see the notebook failing on:
Step #5: notebooks/official/sdk/sdk2_bigframes_sklearn.ipynb FAILED in 22:59:57: Operation did not complete within the designated timeout of 82792 seconds.
I will rerun the test to see if the error is still persistent.

I realized it was timing out since I forgot to remove my code block of overrides for local testing. Looks like all tests are passing now.


emacs: Use wrapGAppsHook always when on GTK

Motivation for this change
The GTK theme is not recognized (e.g., the mouse pointer is different when inside an Emacs window).
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

/cc @chaoflow @lovek323 @peti

I've been using that for some time now and it seems to work. Can I merge it?

I have the impression that this patch triggers a lot of warning messages in the terminal:
Warning: arch-dependent data dir '/nix/store/cr388ab8l3lxxdixxbiwg0cc4nixhw84-emacs-25.1/libexec/emacs/25.1/x86_64-unknown-linux-gnu/': Not a directory

this seem harmless but are still anoying.

I have the impression that this patch triggers a lot of warning messages in the terminal:

Could we alter the hook so it doesn't point GTK to non-existent directories?

This seems to be done in master now, albeit in a slightly different way.


Windows: New env variable (KEYBASE_BIN_PATH) to store the CLI exe path

Reasoning: See #22039
If for some reason this variable is not set, fallback to %localappdata%\Keybase.
(If the installer supports such a thing, you can also set $env:KEYBASE_BIN_PATH to %localappdata%\Keybase)

Closing to bring up a cross-platform solution/update commits


Smoke test download can hang for 2 minutes

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=150544&view=results
Log output:
[2022-01-18T07:35:51.438Z] Running desktop smoke tests against D:\a\1\VSCode-win32-x64\Code - Insiders.exe
[2022-01-18T07:35:51.486Z] Test data path: C:\Users\VSSADM~1\AppData\Local\Temp\vscsmoke
[2022-01-18T07:35:51.486Z] Preparing smoketest setup...
[2022-01-18T07:35:51.506Z] Starting operation 'versionReq...
[2022-01-18T07:35:51.506Z] Starting operation 'ensureStableCode...
[2022-01-18T07:35:51.723Z] Finished operation 'versionReq' successfully after 217ms
[2022-01-18T07:35:51.723Z] Starting operation 'versionReq.json()...
[2022-01-18T07:35:51.726Z] Finished operation 'versionReq.json()' successfully after 3ms
[2022-01-18T07:35:51.727Z] Found VS Code v1.64.0-insider, downloading previous VS Code version 1.63.2...
[2022-01-18T07:35:51.729Z] Starting operation 'download stable code...
[2022-01-18T07:35:51.920Z] download stable code progress: resolvedVersion
[2022-01-18T07:35:51.921Z] download stable code progress: resolvingCDNLocation
[2022-01-18T07:35:52.173Z] download stable code progress: downloading
[2022-01-18T07:37:51.517Z] Starting operation 'rimraf(testDataPath)...
[2022-01-18T07:37:51.523Z] Finished operation 'rimraf(testDataPath)' successfully after 6ms

So it looks like the download can just take 2 minutes for whatever reason. Maybe the progress could be improved further to log the amount of bytes transfered? And then maybe we have to accept that the smoke test needs a higher timeout.
Besides, could we just cache the stable code across multiple builds? Is that even possible?

Maybe the progress could be improved further to log the amount of bytes transfered?

Or rather, the error should report how far along the download was, when it timed out.

Another one happened, adding the trace here so I can easily find via search in the future:
  1) "before all" hook in "{root}"

  0 passing (2m)
  1 failing

  1) "before all" hook in "{root}":
     Error: Timeout of 120000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
      at listOnTimeout (internal/timers.js:557:17)
      at processTimers (internal/timers.js:500:7)

Progressed will now be logged every 10s. Let me know if you need anything more from the vscode-test side.

Thanks!

Will tackle/reopen when I see this again and we have more data available.

That was fast: https://dev.azure.com/monacotools/Monaco/_build/results?buildId=151114&view=logs&j=672276a2-8d3a-5fab-615d-090c51352f92&t=0699ae84-7245-5a45-5eee-80b086af2725&l=21
[2022-01-20T15:37:34.823Z] Running desktop smoke tests against D:\a\1\VSCode-win32-x64\Code - Insiders.exe
[2022-01-20T15:37:34.873Z] Test data path: C:\Users\VSSADM~1\AppData\Local\Temp\vscsmoke
[2022-01-20T15:37:34.873Z] Preparing smoketest setup...
[2022-01-20T15:37:34.897Z] Starting operation 'versionReq...
[2022-01-20T15:37:34.899Z] Starting operation 'ensureStableCode...
[2022-01-20T15:37:35.222Z] Finished operation 'versionReq' successfully after 325ms
[2022-01-20T15:37:35.223Z] Starting operation 'versionReq.json()...
[2022-01-20T15:37:35.225Z] Finished operation 'versionReq.json()' successfully after 2ms
[2022-01-20T15:37:35.226Z] Found VS Code v1.64.0-insider, downloading previous VS Code version 1.63.2...
[2022-01-20T15:37:35.229Z] Starting operation 'download stable code...
[2022-01-20T15:37:35.495Z] download stable code progress: resolvedVersion
[2022-01-20T15:37:35.495Z] download stable code progress: resolvingCDNLocation
[2022-01-20T15:37:35.809Z] download stable code progress: downloading (0/106120839)
[2022-01-20T15:37:45.811Z] download stable code progress: downloading (79708156/106120839)
[2022-01-20T15:42:34.922Z] Starting operation 'rimraf(testDataPath)...
[2022-01-20T15:42:34.926Z] Finished operation 'rimraf(testDataPath)' successfully after 4ms

@connor4312 any clues?

Interestingly this always seems to be on Windows.

Hm, so it looks like the data stream probably stopped receiving data. The logs are triggered every 10s, and no more logs means that there was no more data events coming from the download stream.
Either that, or the unzip process (which is run asynchronously to download) stalled for some reason. We did move to a new zip library in 1.6.0 which is faster but might be causing issues. In order to rule that out, I've added an option to use the old synchronous unzipping code path, and have toggled that on in this repo.

ok thanks.