What's a valid meeting Id?

When using the join meeting and providing the data below in the post body, whats the valid meeting id? I've tried various combinations from the join meeting URL, but no joy.
{
"name": "",
"time": "",
"tenantId": "{TenantId}",
"objectIds": [
"{UserObjectId-1}",
"{UserObjectId-2}"
],
"meetingId": "{MeetingId}",
"joinURL": "https://teams.microsoft.com/l/meetup-join/...",
"removeFromDefaultRoutingGroup": true,
"allowConversationWithoutHost": true
}

I found that just leaving it empty is the way to go, it works fine that way.


Use the #[diagnostic::on_unimplemented] attribute to improve ECS (system and query) error messages

What problem does this solve or what need does it fill?
Bevy's error messages for invalid inputs for systems and queries that take SystemParam,  QueryData or QueryFilter are terrible: users get a terrible error message saying that the trait isn't implemented for the whole tuple and suggesting a bunch of irrelevant tuples with generic types.
For upstream reports of what these errors look like, please see:

https://github.com/rust-lang/rust/issues/89681
https://github.com/rust-lang/rust/issues/89680
https://github.com/rust-lang/rust/issues/89679
https://github.com/rust-lang/rust/issues/114247

What solution would you like?
Use the soon-to-be-stabilized diagnostic attribute on our key traits, and manually provide more helpful error messages.
#[diagnostic::on_unimplemented(
    message = "My Message for `ImportantTrait<{A}>` is not implemented for `{Self}`",
    label = "My Label",
    note = "Note 1",
    note = "Note 2"
)]
trait ImportantTrait<A> {}

https://github.com/rust-lang/rust/pull/119888 is the stabilization PR which goes over more details of how this works: this will not be available until Rust 1.78.
What alternative(s) have you considered?

Add variadic generics to upstream Rust (one day).
Use a macro to determine these things that needs to be added to every system. bevy_check by @jakobhellermann does this, and is essential prior art.

Additional context
This was brought to my attention by George Semmler on Mastodon.

Really good to see that the error message has improved already.
I think that the main thing I would like to do is change the error message to include some Bevy-specific guidance, and to cull the tuple pyramids from the tips around "the following other types" text.

https://github.com/rust-lang/rust/issues/51992 appears to be the tracking issue for do_not_recommend, which should let us hide the tuple pyramid impls.

https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html
No longer blocked!


How can I obtain and organize the correct directory in fitting?

I downloaded smplx-1.1 and flame2020, and placed all the downloaded files into fitting/common/utils. However, I couldn't find MANO_SMPLX_vertex_ids.pkl, SMPL-X__FLAME_vertex_ids.npy, and smplx_flip_correspondences.npz in the smplx folder. The number of files in the flame folder also doesn’t match.

Did I miss downloading some files?

Thank you for your quick response. I've completed the missing files in the smplx folder and downloaded the relevant compressed files from the FLAME website. I guess I should rename female_model.pkl from flame2020 to FLAME_FEMALE.pkl, male_model.pkl to FLAME_MALE.pkl, and generic_model.pkl to FLAME_NEUTRAL.pkl. Is that correct? Also, I couldn't find the files flame_static_embedding.pkl and flame_dynamic_embedding.npy.

For the FLAME files, yes you're correct.
For others, see https://github.com/mks0601/ExAvatar_RELEASE/issues/3

Thanks！


Replace consensus Encodable/Decodable Psbt Serialization

fix https://github.com/rust-bitcoin/rust-bitcoin/issues/934
Instead of using consensus {de,en}code, serialize high-level structures (PartiallySignedTransaciton, Output, Input) borrow the signature from Serialize, Deserialize traits and implement them on Psbt:
impl Psbt {
    /// Serialize a value as raw data.
    fn serialize(&self) -> Vec<u8>;

    /// Deserialize a value from raw data.
    fn deserialize(bytes: &[u8]) -> Result<Self, encode::Error>;
}

Side note: If you use one of the nine keywords defined by github the issue will be automatically closed when a PR merges. 'Addresses' isn't on the list, or was that intentional?

@tcharding as you note the Serialize Deserialize Psbt Traits are for the key value pairs. I propose we continue to use the consensus_encoding signature with the io::Read and io::Write signature but in non-consensus-related methods. It's more convenient to use a decoder with a pointer than raw byte streams.

I've taken a few attempts to solve this after the draft. I think the original reason Carl used consensus encoding is because that module contains convenient, generalized, and now well reviewed serialization patterns. The PSBT-pr reviewers knew the patterns and so ignored their repurpose. We should separate these patterns from the consensus module for their utility across the library. Then the consensus mod will contain consensus layer bitcoin p2p network implementation and a clean serialize mod will contain familiar utilities available for clean application level support for psbt and beyond.

Isn't the problem we are trying to solve that implementing Encodable for PSBT is a strange thing to do. It does not matter how we serialize stuff in the psbt module, if we choose to use consensus_encode under the hood thats fine (as we do for all the other implementations) since the exact method of serialization is up to us (no spec), right? The issue that consensus_encode accepts a writer may be a better API than psbt::serialize::Serialize is a separate issue as is the fact that we have our own Serialize trait as well as deriving serde::Serialize.

Ah I think you cracked it. The simple solution wins again.
Makes sense to take advantage of consensus_encode consensus_decode under the hood without exposing the Encodable Decodable Traits.

One note, either the traits Serialize and Deserialize have to have there docs changed or else PSBT shouldn't implement them because doing so conflicts with their documentation. I kind of prefer to just implement two methods on PSBT, not sure how others feel about this. Also its all a bit of a tangle so there is probable more than one way to go forward and I do not have a picture in mind of the final destination :)

What's wrong with the doc:
//! PSBT serialization.
//!
//! Defines traits used for (de)serializing PSBT values into/from raw
//! bytes from/as PSBT key-value pairs.

The spec includes the whole <psbt> as a key-value pair itself
We can implement two methods on PSBT but should also implement them for every non-Consensus PSBT related data that implements consensus de/encode now to fix the kernel of the issue

The bip 174 <keypair> is defined as <keypair> := <key> <valuedata> such that
 <keypair> := <key> <value>
 <key> := <keylen> <keytype> <keydata>
 <value> := <valuelen> <valuedata>

Our Pair struct forgoes  because  is saved as Vec, which manages len itself.
https://github.com/rust-bitcoin/rust-bitcoin/blob/5b707069e570bb087d768808d5ea724d67e448c6/src/util/psbt/raw.rs#L31-L41
Instead Pair depends consensus impl Encodable for Vec<u8> which defines consensus_encode as consensus_encode_with_size, serializing the length as defined in spec.
Is this desirable since Vec already manages len? Or should our internal representation be a 1:1 map of the spec struct to memory? What mental model makes the most sense?
This snagged me when I took buf.extend(Pair.value: Vec<u8>) granted for  and not as just .

Another major question I have is whether we want to keep the serialize(&self) -> Vec<u8> signatuer, great for in memory operations, or consensus_encode(&self, &mut w) -> Result<usize, io::Error>  with results. The serialize is nice because we don't have to account for whole categories of errors, while the latter is nice to write to other mediums and return errors from things like the file system if a disk were ejected.

If we impl consensus_encode then we get serialize() for free.

If we impl consensus_encode then we get serialize() for free.

@apoelstra now I'm confused. Isn't this issue trying to fix that all these application layer messages use impl Encodable/impl Encodable but should not? re: #934

I'd love to have a genio-style trait with associated Error. If this is considered too much then probably impl for writer and unwrap the result in fn serialize.

If we impl consensus_encode then we get serialize() for free.

@apoelstra now I'm confused. Isn't this issue trying to fix that all these application layer messages use impl Encodable/impl Decodable but should not? re: #934

Ah, yeah, I see. That's pretty annoying. To answer your original question yes, I woud like to keep the serialize(&self) -> Vec<u8> siganture.

This should work end to end now. I welcome feedback on the design. I'm not sure why the fuzz test fails yet.
@Kixunil I agree this Pr is prerequisite to fixing #837, but I think the fix another Pr. The consensus / psbt untangling looks more involved than it appears on the surface in my brief attempt. One thing would be to bring over an io::Error  psbt::Error which is somewhat involved since io::Error breaks #[derive(Eq)] which is required in tests. My attempt building on this pr is on this branch

@DanGould I believe that the best error untangling would be to make decodable error associated.
Regarding fuzzing, weird I don't see the reproducer in the output.

I believe that the best error untangling would be to make decodable error associated. -- @Kixunil

I took a stab keeping the io::Error as associated encode::Error in this commit. It works.
I wonder however, is a problem to instantiate consensus::encode::Error in this module for io::Error? This instance does not come from consensus module behavior? I would not consider this solution a regression since we were already using encode::Error in this case before, but it rhymes with the design problem this PR intends to fix.

I meant having associated Error type at Decodable trait. Encoding should only fail if the writer fails so we should have io::Error there (at least until we have something like genio).

is a problem to instantiate consensus::encode::Error in this module for io::Error?

It certainly does look strange. Maybe we should have this shared type:
/// Error used when reading or decoding fails.
pub enum ReadError<Io, Decode> {
    /// Reading failed
    Io(Io),
    /// Decoding failed
    Decode(Decode), // consensus and PSBT error here
}

However this one will be annoying to use with ? :( We could have ResultExt to provide decode() and io() methods to make it easier.
If that's not acceptable then I think deduplicated IO error is better.

@tcharding @sanket1729 would you please take a look at this? This should be a complete, working replacement.

I don't think the error stuff is perfect but this PR looks like progress to me. Thanks @DanGould!

I plan to fix error stuff in the next PR. Now we have a way for it to be fixed 🫡

I believe your fuzz CI fail is because there are a bunch of funny files in hfuzz_workspace/deserialize_psbt.

@tcharding are you implying this is an issue with the code, the test, or the test environment with hfuzz_workspace? I'm guessing this a caching CI environment issue. hfuzz_workspace does not look like a source file.

@sanket1729 Thank you for clarifying. I didn't realize "62" was the fuzz input sitting by its lonesome in console output there.
I made one more ammendment in this recent push, using crate::io::Cursor instead of finding the right Cursor switching  based on cfg features:
https://github.com/rust-bitcoin/rust-bitcoin/blob/27362c10f51682ad2a64312413c787195f3346a0/bitcoin/src/psbt/macros.rs#L55-L60

Guess I was wrong :)

In  1b64e702aa838a54f83f5a2267657d2c41d8e8e9
cargo +nightly build --features=base64 fails with

error[E0277]: the trait bound `PartiallySignedTransaction: Encodable` is not satisfied
   --> bitcoin/src/psbt/mod.rs:793:75
    |
793 |             write!(f, "{}", Base64Display::with_config(&encode::serialize(self), base64::STANDARD))
    |                                                         ----------------- ^^^^ the trait `Encodable` is not implemented for `PartiallySignedTransaction`
    |                                                         |
    |                                                         required by a bound introduced by this call
    |
    = help: the following other types implement trait `Encodable`:
              &'a T
              &'a mut T
              (T0, T1)
              (T0, T1, T2)
              (T0, T1, T2, T3)
              (T0, T1, T2, T3, T4)
              (T0, T1, T2, T3, T4, T5)
              (T0, T1, T2, T3, T4, T5, T6)
            and 107 others
note: required by a bound in `serialize`
   --> bitcoin/src/consensus/encode.rs:118:21
    |
118 | pub fn serialize<T: Encodable + ?Sized>(data: &T) -> Vec<u8> {
    |                     ^^^^^^^^^ required by this bound in `serialize`

error[E0277]: the trait bound `PartiallySignedTransaction: Decodable` is not satisfied
   --> bitcoin/src/psbt/mod.rs:803:13
    |
803 |             encode::deserialize(&data).map_err(PsbtParseError::PsbtEncoding)
    |             ^^^^^^^^^^^^^^^^^^^ the trait `Decodable` is not implemented for `PartiallySignedTransaction`
    |
    = help: the following other types implement trait `Decodable`:
              (T0, T1)
              (T0, T1, T2)
              (T0, T1, T2, T3)
              (T0, T1, T2, T3, T4)
              (T0, T1, T2, T3, T4, T5)
              (T0, T1, T2, T3, T4, T5, T6)
              (T0, T1, T2, T3, T4, T5, T6, T7)
              AddrV2
            and 101 others
note: required by a bound in `deserialize`
   --> bitcoin/src/consensus/encode.rs:132:23
    |
132 | pub fn deserialize<T: Decodable>(data: &[u8]) -> Result<T, Error> {
    |                       ^^^^^^^^^ required by this bound in `deserialize`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `bitcoin` due to 2 previous errors

I combed over each commit ensuring they contain only my best work. Thank you very much for the thorough reviews.

Thanks for sticking with it @DanGould!

@Kixunil it looks like you're still blocking this merge -- should we remove the Psbt variant from consensus::encode::Error in this PR or can it wait for a later one?

I have that drafted Psbt error variant removal for the next PR. Hoping it can wait

Sounds good to me -- but I'll wait for Kix to comment before merging.

Sorry, didn't have much time. I'll look into this soon.

@DanGould let me know if you'd like to address @Kixunil's nits, otherwise we can merge this.

please merge


Update concepts-connectivity-architecture.md

@code-sidd
Thanks for approving the PR. For future PRs, please note that a #sign-off comment is the best way to signal to the review team that a PR is ready to merge.

#sign-off


Skip SSLEngineTests that depend on KeyManagerFactory when this is not…

… supported by the openssl version.
Motivation:
Some version of openssl dont support the needed APIs to use a KeyManagerFactory. In this case we should skip the tests.
Modifications:

Use assumeTrue(...) to skip tests that need a KeyManagerFactory and its not supported.

Result:
Tests pass on all openssl versions we support.

@Scottmitch PTAL... we either need to do this or just use "normal files" to construct the SslContextBuilder. WDYT ?

@Scottmitch we run the build with netty-tcnative-boringssl-static and netty-tcnative. With netty-tcnative this is needed.

Cherry-picked into 4.1 (43a2315372a8d642ce4df14db2ebfd001b9538e0) and 4.0 (02d5739)

@Scottmitch thanks for the review buddy


Is there a way to ensure the lengths of two list arguments match?

Foo :: {
l1: [...string]
l2: [...string]
}
I want to make sure that instances of Foo have equal numbers of strings specified for l1 and l2. Is this possible to express in cuelang?

We generally answer questions in Slack. You can join from this link: https://cuelang.org/community
You can with an extra field:
ex: {
  l1: [...string]
  l2: [...string]
  sameLength: len(l1) == len(l2)
}

@verdverm the check field should really be a definition to avoid it being emitted:
ex: {
	l1: [...string]
	l1: ["test"]
	l2: [...string]
	l2: ["test"]
	sameLength :: len(l1) == len(l2)
	sameLength :: true
}

I'll close this issue because we've address the direct question. There is also plans for a constrain() built-in as part of the evaluator redesign in #338

@myitcv would hidden fields work equally as well?

This issue has been migrated to https://github.com/cue-lang/cue/issues/381.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


feature: Added an option to disable endpoint translation

After my pull request gets merged on leetcode-cli (which provides the -T option to disable endpoint translation), this pull requests will give user an option to toggle in settings whether or not they want to use endpoint's translation for the problems.

@jdneo Thank you for bumping leetcode-cli to 2.8.0! Do you mind publish that change to npmjs as well? So I can specify the new version in package.json. Or do you prefer to specify the commit hash in package.json?

@dzz007 you can first use the latest bit of the cli and link it to the vs code extension locally. Let me know if everything works fine. After that I'll release it to the registry.

@jdneo thank you for responding! I just tested with locally installing with master branch of leetcode-cli in vscode-leetcode. Everything works fine, I checked both the leetcode.com and leetcode-cn.com endpoints.
The only problem I found is that changing Endpoint in vscode-leetcode's setting page actually doesn't work. But that is a separate bug which is not related to this leetcode-cli upgrade at all, and I verified that because it exists in the current version as well.

Just published 2.8.0.

@jdneo Thanks, just finished changing package.json & package-lock.json. I tested again and it works well.

The content of package-lock.json looks strange, why the entries have node_modules prefix?

I believe it's because I am currently using NPM v7 which introduced some changes to the lock file as specified in "lockfileVersion": 2. I can downgrade to NPM v6 and regenerate the lock file if you want.

Just a sidenote, IIRC v2 version of the lock-file is backward compatible with older version of NPM. So it should be able to work fine with NPMv6 for example.

ok, thanks for the information

@jdneo no problem! Do you want me to keep the lock file as-is or do you want or to use the old version?

If it's backward compatible, then it's fine I think.

Thank you for your review! I just added the application scope.

Coule you add a tsdoc for the showSolution function notifying the param needTranslation will not take effect?

@jdneo That's a good point! I will add it in couple hours. Do you want me to put it in leetCodeExecutor?

Thanks!

Apologize for lazy merge. I just get the permission to merge the PRs. 😃


Add code to make the reference catalog.

We should include code to make a reference catalog when we generate the phosim input catalogs.  I need a suggestion for where to put it.  In the old version this was in the same file as the code to generate inputs.
This is the code I use to do it:
import os
import numpy
from lsst.sims.catalogs.measures.instance import InstanceCatalog
from lsst.sims.catalogs.generation.db import CatalogDBObject
from lsst.sims.catUtils.utils import ObservationMetaDataGenerator
from lsst.sims.catUtils.mixins import AstrometryStars, PhotometryStars

class TwinklesReference(InstanceCatalog, AstrometryStars, PhotometryStars):
    catalog_type = 'twinkles_ref_star'
    column_outputs = ['uniqueId', 'raJ2000', 'decJ2000', 'lsst_g',
                      'lsst_r', 'lsst_i', 'starnotgal',
                      'isvariable']
    default_columns = [('isresolved', 0, int), ('isvariable', 0, int)]
    default_formats = {'S': '%s', 'f': '%.8f', 'i': '%i'}
    transformations = {'raJ2000': numpy.degrees, 'decJ2000': numpy.degrees}

opsimDB = os.path.join('.', 'enigma_1189_sqlite.db')

# you need to provide ObservationMetaDataGenerator with the connection
# string to an OpSim output database.  This is the connection string
# to a test database that comes when you install CatSim.
generator = ObservationMetaDataGenerator(database=opsimDB, driver='sqlite')
obsMetaDataResults = generator.getObservationMetaData(fieldRA=(53, 54), fieldDec=(-29, -27), boundLength=0.3)

# First get the reference catalog
stars = CatalogDBObject.from_objid('allstars')
while True:
    try:
        ref_stars = TwinklesReference(stars, obs_metadata=obsMetaDataResults[0])
        ref_file_name = 'twinkles_ref.txt'
        break
    except RuntimeError:
        continue
ref_stars.write_catalog(ref_file_name, write_mode='w', write_header=True, chunk_size=20000)

If this is intended as a standalone script that would take an opsim db file as input, I would argparse it and put it in the bin folder.  If this code should be packaged as a function that could be imported and used elsewhere, I would do that, then put it in python/desc/twinkles.
Note that I wrote bin/build_index_files.py based on the cookbook back when we only had r-band simulations, and that build_index_files.py script does some similar things.  So we should try to identify the desired functionality, omit the redundant stuff, and repackage things accordingly.

code added at 98085bc162b1


Laser measure

Leica Disto D2
The Leica Disto D2 uses Bluetooth technology to conveniently transfer its collected data to your devices. It also features an end piece that flips out and extends into hard-to-reach corners, and it can store up to 10 readings in its internal memory.

Features

Bluetooth 4.0 for transferring measurements into desired software
Pythagoras function for indirect height or width measurements
Last 10 measurement memory
IP 54, dust & splash protected
Intelligent automatic end piece for hard to reach corners

Specs.

Brand
Leica Geosystems

Environment
Internal & External

Line Axis
Horizontal & Vertical

Working Range
0.05-100 m

Measuring Accuracy
1 mm

Dimensions
116 x 44 x 26 mm

Total Product Weight
0.1 kg

Links

Product page
Buy on [Amazon.com] for $150


RB-1.0 on Lion - 8 of 37 tests fail

This is my report on the RB-1.0 testsuite.  I ran all them all I think.  I got 8 of 37 fails. Here is the platform and software I'm using:
Core i5 8GB
OSX Lion 10.7.3
oiio RB-1.0
boost: 1.48.0
cfitsio: 3.29
cmake: 2.8.7
doxygen: <IP_ADDRESS>
field3d: 1.3.2
gdbm: 1.10
glew: 1.7.0
hdf5: 1.8.8
ilmbase: 1.0.2
jasper: 1.900.1
jpeg: 8d
libtiff: 3.9.5
little-cms2: 2.3
opencolorio: 1.0.5
openexr: 1.7.0
openjpeg: 1.5.0
pkg-config: 0.25
python: 2.7.2
qt: 4.8.0
scons: 2.1.0
sqlite: 3.7.10
szip: 2.1
webp: 0.1.3
The tests ran the same compiling with clang or llvm-gcc.  So that is good news.
I don't want to bore you XFAILS, but some output is useful I suppose.
So I made a gist of some out.txt diffs
78% tests passed, 8 tests failed out of 37

Total Test time (real) =  42.27 sec

The following tests FAILED:
	  3 - oiiotool (Failed)
	 12 - texture-overscan (Failed)
	 16 - texture-fat (Failed)
	 17 - imagecache-files (Failed)
	 19 - bmp (Failed)
	 22 - openexr-suite (Failed)
	 26 - targa-tgautils (Failed)
	 27 - fits (Failed)

Fixed in head.  Many thanks.


[feat] Can wix be replaced?

Describe the problem
Wix for windows installer is almost a big huge monster which made me very very  unhappy.
(1) use wix to install for the old style windows (e.g win7 ), need webview2.109 to be installed offline.
(2) use wix to install with other app ( vc_redist bundle) is almost impossible mission.
Describe the solution you'd like
Remove wix from tauri installer
or
Get a substitute.
wix is a disaster for me.
Alternatives considered
No response
Additional context
No response

OK.
Currently my solution is:

use wix to package tauri bundle
use nsis to package tauri bundle AND vc_redist!
OH!MY!


Thoughts on just in time authorization

Paper supporting just in time authorization:
https://www.usenix.org/conference/hotsec12/workshop-program/presentation/felt

Very interesting paper, tough the use of the terms "satisfising" and "optimizing" seem pretty werid to me.

i think this is a duplicate of #3


Add recycling of intermediate result vectors

Adds a thread level pool for intermediate result vectors.

Allow use of recycled vectors in Expr::evalAll, ensureWritable and
selected special forms.

ToDO: Use EvalCtx::ensureWritable in more functions.

@oerling Orri, would you update the PR description to explain the motivation for this change.
One of the benchmark shows a regression. Would you take a look?

✗ Fail: VectorCompare.cpp/compareSimilarSimpleFlatNoDispatch          (2.27ns vs 5.46ns) -58.41%

Hi @oerling, I'm going to close this PR since it has been inactive for 90 days. Please feel free to reopen it if needed.


Cannot install cucim by using conda or pip

As described in the screenshot when trying to install the cucim package through conda-install or by using pip it is showing that the package is not available in the necessary channels.

Unfortunately Windows is not supported
WSL could be used though
More details in this comment: https://github.com/rapidsai/cucim/issues/454#issuecomment-1331244039

Closing this. Windows support-relased questions are discussed in https://github.com/rapidsai/cucim/issues/454#issuecomment-1331244039


[Feature Request]: Make CombineFns used in Python Combiners part of the public API

What would you like to happen?
Currently the CombineFn implementations in combiners.py are not included in __all__ which makes them look like implementation details. I think we should expose these in a way that makes it clear they can be used directly (e.g. in GroupBy with aggregate_fields). Two possibilities:

Just add the CombineFn implementations to __all__
Add a combineFn method on the corresponding combiners - this would be analogous to the Java SDK. see Count.combineFn.

Issue Priority
Priority: 2
Issue Component
Component: sdk-py-core

I think there is no concern adding public CombineFn implementations to __all__. Re second approach - there may be some ambiguity here for composite combiners. For example: would there be an expectation for defining "Top.SmallestPerKey.combineFn" or just Top.combineFn ?


Can't apply managementApiAuth to existing datacenter

What happened?
When I added
    managementApiAuth:
      manual:
        clientSecretName: cass-management-api-client
        serverSecretName: cass-management-api-server

to existing datacenter it failed to update sts because API is still running on http, but operator sends https requests:
2023-10-20T06:52:06.234Z	ERROR	controllers.CassandraDatacenter	calculateReconciliationActions returned an error	{"cassandradatacenter": "cass-db/dc2", "requestNamespace": "cass-db", "requestName": "dc2", "loopID": "14a47b0d-9f66-45c4-a330-9ef440c8754a", "error": "Post \"https://<IP_ADDRESS>:8080/api/v0/ops/seeds/reload\": http: server gave HTTP response to HTTPS client"}
github.com/k8ssandra/cass-operator/internal/controllers/cassandra.(*CassandraDatacenterReconciler).Reconcile
	/workspace/internal/controllers/cassandra/cassandradatacenter_controller.go:149
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:122
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:323
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:274
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.14.6/pkg/internal/controller/controller.go:235

What did you expect to happen?
I expected operator to communicate with pods and update configuration to enable mTLS on both operator and mgmt api sides.
How can we reproduce it (as minimally and precisely as possible)?

Bring up a basic datacenter with

    managementApiAuth:
      insecure: {}

Once datacenter is up and running create certificates chain

### MGMT API Auth
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: cass-management-api-ca
spec:
  isCA: true
  commonName: cass-management-api
  secretName: cass-management-api-ca
  duration: 87600h0m0s # 10y
  privateKey:
    encoding: PKCS8
  issuerRef:
    name: cassandra-ca-issuer
    kind: Issuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: cass-management-api-issuer
spec:
  ca:
    secretName: cass-management-api-ca
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: cass-management-api-server
spec:
  secretName: cass-management-api-server
  duration: 8760h0m0s # 1y
  issuerRef:
    name: cass-management-api-issuer
  dnsNames:
    - cass-management-api-server
  commonName: cass-management-api
  privateKey:
    encoding: PKCS8
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: cass-management-api-client
spec:
  secretName: cass-management-api-client
  duration: 720h0m0s # 30d
  issuerRef:
    name: cass-management-api-issuer
  commonName: cass-management-api-user
  privateKey:
    encoding: PKCS8

Update datacenter configuration:
    managementApiAuth:
      manual:
        clientSecretName: cass-management-api-client
        serverSecretName: cass-management-api-server

cass-operator version
1.17.2
Kubernetes version
1.27.4
Method of installation
Argo
Anything else we need to know?
No response

Similar issue happens if I build a datacenter with manual managementApiAuth and then disable it: it sends an http request to the https api endpoint

Actions to take here:

Instead of checking CassandraDatacenter's status of the HTTPS, we need to check if ObservedGeneration < Generation of CassandraDatacenter and if the target Pod has HTTPS enabled or not and build the client security based on that information.
The above can be checked from running configs by inspecting the Pod and/or if the target server secret is mounted there. Can be found from Pod's ENV variables: MGMT_API_TLS_CERT_FILE is set (or a volume called "management-api-server-certs-volume" is mounted to the pod)

@burmanm is this ticket still current? It is from last year so I'm confirming before I start work on it.
Also, can you clarify what you mean by check if ObservedGeneration < Generation of CassandraDatacenter? What ObserverGeneration are we checking? Why would the ObservedGeneration and "Generation" be different if you're referring to the CassandraDatacenter in both cases?

| @burmanm is this ticket still current? It is from last year so I'm confirming before I start work on it.
Yes, it is.
| Also, can you clarify what you mean by check if ObservedGeneration < Generation of CassandraDatacenter? What ObserverGeneration are we checking? Why would the ObservedGeneration and "Generation" be different if you're referring to the CassandraDatacenter in both cases?
Whenever you update the CassandraDatacenter, the ObservedGeneration is less than Generation until the reconciliation has finished. In this case, it wouldn't since it fails midway. However, I think you can just skip that check for now and simply verify if the target pod has https enabled or not for mgmt-api.
Currently, the syntax is func BuildManagementApiSecurityProvider(dc *api.CassandraDatacenter), yet this isn't sufficient. On the other hand, be careful that the SecurityProvider is the HTTPS one when constructing the PodTemplateSpec and other required modifications as enabling auth would require the https one to provide those curl commands and other properties. So it's not just the httphelper client.


Can't see git diff for staged files

Description
After staging a file in git, Telescope is unable to show diff for the file in git_status window.
Neovim version
NVIM v0.9.0-dev-867+gf9826e1df
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

Operating system and version
Debian Bullseye
Steps to reproduce
mkdir test
bash
cd test
git init .
echo "test" > test.txt
git add test.txt
git commit -m test
echo "test edited" > test.txt
git add test.txt
nvim

In nvim

:Telescope git_status
select test.txt

Expected behavior
There is diff in "Git File Diff Preview"
Actual behavior
Git File Diff Preview is empty
Minimal config
vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
  require('packer').startup {
    {
      'wbthomason/packer.nvim',
      {
        'nvim-telescope/telescope.nvim',
        requires = {
          'nvim-lua/plenary.nvim',
          'nvim-telescope/telescope-file-browser.nvim',
        },
      },
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
      display = { non_interactive = true },
    },
  }
end
_G.load_config = function()
  require('telescope').setup()
  require('telescope').load_extension('file_browser')
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing Telescope and dependencies.")
  vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]

If the issue is with :Telescope git_status, it would be an upstream issue. But while we're here this issue should be solved if you update Telescope.
https://github.com/nvim-telescope/telescope.nvim/pull/2421

I was looking for string git_status in this org and, found it in this repo, so thought that this was responsible for the bug. Sorry for the confusion.
Updated Telescope to master branch and that fixed the problem. Thanks @jamestrew.


remove cover_print_enabled and cover_data_dir config options and replace with cover_opts

{cover_print_enabled, true} dropped in favour of {ct_opts, [verbose]}
{cover_data_dir, "..."} dropped for now. can be replaced with something in ct_opts if anyone complains it was dropped
addresses #576

Updated docs to match the change.


Use git grep as opposed to system grep

When running on a system where BSD grep is on the PATH the check fails because bsd-grep follows symlinks on grep -r. This causes the check to find all the transitive dependencies that are using git on the bazel-envoy symbolic link directory.
Note this is also a better option because we only care about greping the files that are included in the repo and nothing else
Risk Level: Low
Testing: Done locally, added a bzl file with remote = strings and it correctly failed.

@mattklein123 just for your mental sanity: this -does- happen upstream on osx environments that don’t have gnu-grep first on the PATH. I repro’ed with a fresh clone

@Reflejo I see. Is it something about the mobile dev environment that switches this?

@mattklein123 No, bsd grep is just the default on vanilla macos environments (aka any macos that didn't brew install grep nor added /usr/local/opt/grep/libexec/gnubin to the PATH before /usr/bin).
I assume most devs compiling envoy have gnu utils though and the ones that don't are just passing --no-verify


Create Red Flash Hit Effect

Create and implement a red flash on hit effect. When a runner gets hit, the model should be tinted red for a second and then return to normal. There will be a quick fade in and a quick fade out.

I setup an implementation that will change all the materials in the runner to a transparent red for 0.4 seconds then return to the original material when hit. This implementation was setup using a blueprint. I'll be looking into it further to see if there's a non-ugly way to implement it using C++. UE4 provides blueprint functions that make this process very simple so I'm leaning toward the use of the blueprint.

I went through and converted the blueprint I made yesterday to a function in C++. This new code creation allowed me to easily change the material and to easily apply the hit effect to the AI as well. This took about an hour and a half.


Regressions in Reader branch

Just to track them so we don't forget fixing:

annotations are not properly rendered in Editor (bold, ext-link etc.), in Reader it works
References are broken in Editor (we may refactor that anyways)
tbc...

I fixed the problem with missing annotation components. Was just missing registrations.
Found some other things:

IsolatedNodes are no longer rendered in Editor
Seems Footnotes and References are mixed up in EditXrefComponent (some change must have caused this)

@oliver---- can you confirm and comment on the issues.

For annotations we need to register components explicitly. This has changed in Texture, because it overrides the fall-back component for unsupported inline nodes.

Yeah I saw the comment and it's fixed now. Also provided an ExtLinkComponent with a proper link. I've also just fixed the confusion of referenceManager with footnoteManager, that was my mistake.
If you have time, could you look into those two things:

IsolatedNodes are no longer rendered in Editor
Adding a new citation breaks: try adding a new xref for a reference (think this is related to the new context setup;)

Will do

I have fixed the two mentioned issues.

Two things I'd like to make you aware of @michael @Integral

please use export default with the class name. Since ES6 it is not necessary to have that at the bottom. Without the line at the bottom the code is less redundant.
as mentioned above, be aware that Commands must pass context through to the rest of the api. This is particularly important for higher-level command implementations, i.e. those which are sub-classed.

Thank you! Works perfectly. One question: When in the reader, clicking on an isolated node highlights it, do we want that, or somehow disable these selections? I mean such a selection would be fine, but you should be able to clear it by clicking somewhere else.
Thanks for the hints regarding export and context.

Can we just not render the isolated node if this.props.disabled === true? Guess that would feel best, in terms of a reader. Currently you can't make a selection inside a caption.

You can try, by changing TextureContainerEditor.getNodeComponent()

We are good here. Closing.


Adding urlencoded querystring parameter with Request Transformer plugin

I use Kong latest version 0.5.x.
I prepared simple API that uses only Request Transformer and File Log plugins.
I try to add urlencoded querystring parameter with this plugin.
For example:
--data "config.add.querystring=where:%7B%22foo%22%3A%22bar%22%7D"
In log file from File Log plugin I see that request query string is empty: "querystring":{}
Could you please explain what am I doing wrong? How to pass urlencoded querystring parameter through Request Transformer plugin?
Thanks in advance

I was not able to reproduce under Kong 0.5.4.
API:
{
    "created_at":<PHONE_NUMBER>000,
    "id": "e5e66dd3-774b-46aa-c6a8-294f0413ae4c",
    "name": "mockbin",
    "request_path": "/mockbin",
    "strip_request_path": true,
    "upstream_url": "http://mockbin.com"
}

Plugins:
{
    "data": [
        {
            "api_id": "e5e66dd3-774b-46aa-c6a8-294f0413ae4c",
            "config": {
                "add": {
                    "querystring": [
                        "hello:world",
                        "where:%7B%22foo%22%3A%22bar%22%7D"
                    ]
                }
            },
            "created_at":<PHONE_NUMBER>000,
            "enabled": true,
            "id": "3d37be6d-0994-46df-c612-383964e12fcd",
            "name": "request-transformer"
        },
        {
            "api_id": "e5e66dd3-774b-46aa-c6a8-294f0413ae4c",
            "config": {
                "path": "/path/to/kong/log.log"
            },
            "created_at":<PHONE_NUMBER>000,
            "enabled": true,
            "id": "f518d475-b0a5-41bd-c1c1-e9dc9321dd64",
            "name": "file-log"
        }
    ]
}

In the request going to upstream and in the log file, I clearly see:
"querystring":{"hello":"world","where":"%7B%22foo%22%3A%22bar%22%7D"}
``

Steps to reproduce at kong 0.5.4:

curl -i -X POST --url http://localhost:8001/apis/ --data 'name=test' --data 'upstream_url=http://helloworld.com/' --data 'request_host=test'
curl -X POST http://localhost:8001/apis/test/plugins --data "name=request-transformer" --data "config.add.querystring=where:%7B%22foo%22%3A%22bar%22%7D"
Postman api plugins request (as you can see ":" is not escaped inside parameter value )
And as from the Request Transformer Plugin source code:

local parts = stringy.split(entry, ":")
for _, entry in ipairs(val) do
      local parts = stringy.split(entry, ":")
      cb(parts[1], utils.table_size(parts) == 2 and parts[2] or nil)
end

Not escaped ":" inside parameter brakes request because of keys/values split by ":".
But as I see, it is fixed in kong 0.6.0


why using "v-repeat" instead of "v-for"?

I tried v-for but failed before I found that I should use 'v-repeat'..

Ok, I found why this happened: the jsfiddle demos use 0.12 which doesn't support v-for.


Add some tests for windows

This adds run-fail tests for https://github.com/taiki-e/cargo-hack/pull/6#discussion_r341265709 and https://github.com/taiki-e/cargo-hack/runs/285686743.
cc #3

bors r+


Change queryTimeout to be infinite by default

Current implementation is using 5 seconds by default. This change can pose backward compatibility issues for existing usages

@lifey I think removing this completely is better for now as there are no tests for this funcionality and it did bite me as well. We might include a new timeout implementation in the future.


Bluemaxima.Kahvibreak version 1.6

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/110295&drop=dogfoodAlpha

How do we deal with self extracting ZIP files with no shortcuts?

Automatic Validation ended with:

##[error] Installer https://bluemaxima.org/kahvibreak/Kahvibreak 1.6.zip
Scan request id: '10d7c987-f484-4dc3-ad73-b47022a87ad8'
Error information: RequestContainsTooManyFlaggedFiles
##[error] Result: Failed


Incorrect behavior when changing opacity for a separate pocket

In React code I display array of pockets on 3d model in scene (with opacity: 0,3). Then, after I check pocket on array of checkbox components in app, this checked pocket must change its opacity to 1. But instead of this smth happens with opacity of all pockets and all array of files are redownloading. Below u can see screen record:
https://github.com/nglviewer/ngl/assets/48678379/5a3589c4-0ad4-46ec-8503-f3be69bd0dde
This is my code:

import React, { useState, useEffect, useRef, useContext, useMemo } from "react";
import * as NGL from "ngl";
import { useResizeDetector } from "react-resize-detector";
import { FilesService } from "services";

import { SiteRadarContext } from "pages/site-radar/SiteRadarContext";
import "./style.scss";

interface PocketsViewProps {
  pdbUrl: string;
}

interface PocketData {
  url: string;
  color: string;
}

const PocketsView: React.FC<PocketsViewProps> = ({ pdbUrl }) => {
  const { pockets } = useContext(SiteRadarContext);
  const [pocketData, setPocketData] = useState<PocketData[]>([]);

  const containerRef = useRef();
  const stageRef = useRef();
  const representation = useRef(null);
  const pocketReps = useRef([]);
  const pocketRepMap = useRef(new Map());

  // Function to handle resizing of the container
  const handleResize = () => {
    const stage = stageRef.current;
    if (stage) {
      stage.handleResize();
    }
  };

  // Use the resize detector to trigger resize handling
  const { ref: resizeRef } = useResizeDetector({ onResize: handleResize });

  // Set file IDs of checked pockets
  useEffect(() => {
    const fetchPocketData = async () => {
      const fetchedData = await Promise.all(
        pockets.map(async (pocket) => {
          try {
            const response = await FilesService.getFileLink(pocket.fileId);
            return { url: response.pre_signed_url, color: pocket.color };
          } catch (e) {
            console.error("Error fetching file:", e);
            return null;
          }
        })
      );

      setPocketData(fetchedData.filter((p) => p));
    };

    fetchPocketData();
  }, [pockets]);

  console.log(pockets);

  useEffect(() => {
    const stage = new NGL.Stage(containerRef.current, {
      backgroundColor: "#ededed",
    });
    stageRef.current = stage;

    // Load the main PDB file
    stage
      .loadFile(pdbUrl, { defaultRepresentation: true })
      .then((o) => {
        representation.current = o.addRepresentation("ribbon", {
          defaultRepresentation: true,
        });
        o.autoView();
      })
      .catch((error) => console.error("Error loading file:", error));

    // Cleanup function
    return () => {
      if (stage) {
        stage.viewer.wrapper.remove();
        stage.viewer.renderer.forceContextLoss();
        stage.dispose();
        stage.removeAllComponents()
      }
    };
  }, [pdbUrl]);

  const memoizedPocketData = useMemo(() => pocketData, [pocketData]);

  useEffect(() => {
    const stage = stageRef.current;
    if (stage) {
      // Clear old representations
      pocketReps.current.forEach((rep) => {
        rep.dispose();
      });
      pocketRepMap.current.clear();
      // pocketReps.current = [];

      // Load new pocket data
      memoizedPocketData.forEach((pocket) => {
        if (pocket && !pocketRepMap.current.has(pocket.url)) {
          stage
            .loadFile(pocket.url)
            .then((o) => {
              const rep = o.addRepresentation("surface", {
                color: pocket.color,
                opacity: 0.3,
              });
              pocketRepMap.current.set(pocket.url, rep); // Store representation in the map
            })
            .catch((error) =>
              console.error("Error loading pocket file:", error)
            );
        }
      });

    }

  }, [memoizedPocketData]);

  useEffect(() => {
    pockets.forEach((pocket) => {
      const rep = pocketRepMap.current.get(pocket.fileId);
      if (rep) {
        rep.setParameters({ opacity: pocket.checked ? 1 : 0.3 });
      }
    });
  }, [pockets]);

  return (

  );
};

export default PocketsView;

It seems that the opacity is controlled by the property checked of each pocket object in the pockets array.
When this value changes, I suspect that the pockets array changes as well.
pockets is reactive dependency of 2 different useEffect: one that sets the opacity, and the other one that loads the pocket data.
When pockets changes both useEffect are executed: the second one changes the opacity of representations, and the first one reloads data from server. When the data from server is fetched, setPocketData is executed.
This changes pocketData so memoizedPocketData gets a new value (because it has pocketData as a dependency; note that this memoization is never effective there)
Next, the useEffect that depends on memoizedPocketData is executed as well, pocket representations are removed and recreated with an opacity of 0.3.
IMO, this bug is not related to NGL, but is related to React intricacies. Cascades of useEffect make the execution of the code difficult to reason about.
To circumvent this, I would suggest 2 options:

regarding the pocket objects: split the data part from the controls part. Like that a change in the cheched property would not cause the refetch of data and re-creation of the pockets
second option would be to keep the same data structure, but to control the whole pocket management in a single useEffect. To avoid refetch/rerenders, you can use the name property for the representation and check wether they have already been created or not. You'd have to manage the internal state of the NGL stage by yourself to avoid unneeded recomputations. I personally prefer doing that, rather than let React logics take care of the NGL state because React philosophy is to re-render components multiple times to sync with state which is acceptable for the DOM, but not suitable for 3D rendering and scientific computation

How can I display the qualitative characteristics of a model in the console? For example, color, transparency, etc.

I created a separate component without any additional logic to try to implement the desired behavior. The screen recording shows that with all attempts to trigger only one mutable pocket object, I have a loading file on both pocket files:
https://github.com/nglviewer/ngl/assets/48678379/d6f44777-2c42-4fd2-a1b3-3d2f7e36cd82
Code:

import { useState, useEffect, useRef } from "react";
import * as NGL from "ngl";
import pdbUrl from "../../assets/test-pockets/3hi7.pdb";
import pocket1Url from "../../assets/test-pockets/pocket1.sdf";
import pocket2Url from "../../assets/test-pockets/pocket2.sdf";

const TestOpacity = () => {
  const containerRef = useRef();
  const stageRef = useRef();
  const pocketReps = useRef([]); // To store pocket representations

  const [pocketsArray, setPocketsArray] = useState([
    { url: pocket1Url, checked: false, color: "red", name: 'red' },
    { url: pocket2Url, checked: false, color: 'blue', name: 'blue' },
  ]);

  const prevPocketsRef = useRef();

  // Initialize NGL Stage
  useEffect(() => {
    const stage = new NGL.Stage(containerRef.current, {
      backgroundColor: "#ededed",
    });
    stageRef.current = stage;

    // Cleanup function
    return () => {
      if (stage) {
        stage.viewer.wrapper.remove();
        stage.viewer.renderer.forceContextLoss();
        stage.dispose();
      }
    };
  }, []);

  // Load main PDB file
  useEffect(() => {
    if (pdbUrl && stageRef.current) {
      stageRef.current
        .loadFile(pdbUrl, {
          defaultRepresentation: true,
        })
        .then((o) => {
          console.log("Loaded object:", o);
          o.addRepresentation("cartoon");
          o.autoView();
        })
        .catch((error) => {
          console.error("Error loading file:", error);
        });
    }
  }, [pdbUrl]);

 // Load pockets only once or when URLs change
  useEffect(() => {
    if (stageRef.current) {
      pocketsArray.forEach((pocket, index) => {
        stageRef.current
          .loadFile(pocket.url)
          .then((o) => {
            const rep = o.addRepresentation("surface", {
              color: pocket.color,
              opacity: pocket.checked ? 1 : 0.3,
            });
            pocketReps.current[index] = rep;
          })
          .catch((error) => {
            console.error("Error loading pocket:", error);
          });
      });
    }

    const currentPocketReps = pocketReps.current;

    // Cleanup function
    return () => {
        currentPocketReps.forEach(rep => rep && rep.dispose());
    };
  }, [pocketsArray.map(pocket => pocket.url)]);

  // Update opacity when checked state changes
  useEffect(() => {
    pocketsArray.forEach((pocket, index) => {
      const rep = pocketReps.current[index];
      if (rep && prevPocketsRef.current && prevPocketsRef.current[index].checked !== pocket.checked) {
        rep.setParameters({ opacity: pocket.checked ? 1 : 0.3 });
      }
    });

    prevPocketsRef.current = pocketsArray;
  }, [pocketsArray.map(pocket => pocket.checked)]);

  // Toggle checked state
  const toggleChecked = (index) => {
    setPocketsArray((currentPockets) =>
      currentPockets.map((pocket, idx) =>
        idx === index ? { ...pocket, checked: !pocket.checked } : pocket
      )
    );
  };

  return (

        {pocketsArray.map((pocket, index) => (

            <input
              type="checkbox"
              checked={pocket.checked}
              onChange={() => toggleChecked(index)}
            />
            Pocket {pocket.name}

        ))}

  );
};

export default TestOpacity;

This line of code in the dependency list of the useEffect creates a new reference at each rerender because it always returns a new array:
pocketsArray.map(pocket => pocket.url)
These questions have nothing to do with bugs or features in NGL. I can't dedicate time to reviewing third party code


Automatically refresh invoice payment

Currently it seems like the invoice page has to be reloaded manually after payment. A simple
<meta http-equiv="refresh" content="5;url=/invoice/sdfjklsdfjskldfjlsk" />

might do the trick. The invoice page seems lightweight enough to do that. Later it could be replaced with e.g. websockets. Alternatively long-polling might also work (without JS).

Thanks for opening the issue!
We thought about this and think it'd be confusing if the invoice page just disappeared and switched over to the paid file. For example imagine a user has the invoice page open in a browser in some background tab when paying the invoice. They won't even notice that the file will be displayed, which -- depending on file type -- could be weird.
The current behavior is still really bad, since the invoice doesn't even give users any indication what to do after paying the invoice. We put up #173 to make it a bit better, with a button that reloads the page and instructions at the bottom.
We think in the future a better version would have a button that is greyed out as long as the invoice isn't paid and activates (without user interaction) once the invoice is paid.


Enable coveralls for the library

It seems that coveralls is not enabled for the library:
https://coveralls.io/github/zendframework/zend-diagnostics?branch=master
but in travis we try upload the coverage and the whole coveralls configuration is present in the library.
Can we please enable it to see the proper coverage badge on the main page, please?

Done!


fix: only count users own actions for heatmap contributions

Problem / Current Behaviour
The current query used to count contributions includes notifications sent to watchers of the repository.
Imagine following setup:

Two users with ids 0 and 1
User 0 has a repository with id 0
User 1 watches the repository
User 0 creates a new issue "Test" (or any other action) in the repo
The action table now contains following entries:sqlite> SELECT * FROM action ORDER BY id DESC LIMIT 10;
id          user_id     op_type     act_user_id  act_user_name  repo_id     repo_user_name  repo_name   ref_name    is_private  content     created_unix  comment_id  is_deleted
----------  ----------  ----------  -----------  -------------  ----------  --------------  ----------  ----------  ----------  ----------  ------------  ----------  ----------
19766       0           6           0                           0                                                  0           43|Test<PHONE_NUMBER>    0           0
19765       1           6           0                           0                                                  0           43|Test<PHONE_NUMBER>    0           0

The current query only checks that the user_id matches, this means that the issue created by user 0 will show up as 1 contribution for both users.
Proposed Fix
By also checking for act_user_id we can assure that only actions that the user did himself are counted as a contribution.
We can not drop the check for user_id, assuming the scenario from above, the one issue created would show up as 2 (1 + number of watchers) contributions for the user who created the issue.
Drawback
The organization's heatmap will now only contain meta-actions like ActionCreateRepo, previously all contributions made by users in this repository were also counted, resulting in a nice summary heatmap for all activity.

Codecov Report

Merging #5647 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #5647      +/-   ##
==========================================
+ Coverage   37.81%   37.81%   +<.01%
==========================================
  Files         322      322
  Lines       47489    47490       +1
==========================================
+ Hits        17957    17960       +3
+ Misses      26943    26941       -2
  Partials     2589     2589

Impacted Files
Coverage Δ

models/user_heatmap.go
78.26% <100%> (+0.98%)
:arrow_up:

models/repo_list.go
64.55% <0%> (+1.26%)
:arrow_up:

Continue to review full report at Codecov.

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


Add com.snowplowanalytics.snowplow.storage/bigquery_config/jsonschema/1-0-1

With optional dead-end topic.

Descheduling as its not ready yet.


[SR-628][Sema] Mixing lvalues and rvalues in tuple exprs is very unhappy.

In SR-628 in particular, the problem was an assert that an AccessKind was being set on a non-lvalue, but there were lots of asserts here in various scenarios, the most common other ones being an AccessKind not being set assertion by the ASTVerifier or lvalue-ness not matching between tuple expr and tuple element expr.
This patch checks that a tuple is all rvalues when a tuple element expr is built, and if there are any lvalues, inserts load exprs into the lvalue elements to make all rvalues.
When the tuple exprs have consistent lvalue-ness everything works as expected, although the diagnosis for assigning to an rvalue tuple could be better.
Tests added, all tests pass.

Added this last thing last night, should've added more reasoning/justification for putting the fix where I did, and also I found one more error case this morning (committing and squashing):
Many/most TupleExprs end up being used for function application, where a mix of lvalue and rvalue args can be valid, so checking this when creating the TupleExpr is a no go. When tuples get assigned or passed around, type checking / casting the tuple type does the necessary lvalue-ness work. Adding a TupleElementExpr, here, is the only place where an individual piece of a tuple can be "dereferenced" and the expr AST is being modified here already.
It is difficult to find a place elsewhere in the type checker where the same work could be done. In an expression like let _ = (x,3).0, we get an opportunity to convert the x lvalue into an rvalue and the HEAD inserts a load expr to do so, but asserts while recursively setting AccessKind on the 3. We could make the conversion smarter and/or make setting AccessKind on TupleExpr conditional to fix that. But in the similar expression let _= (x,3).1, there is no type mismatch, and the type checker finishes work, only for the ASTVerifier to complain that the x expr never has its AccessKind set at all.
The only other alternative to munging the tuple into rvalues up front here that I can see would be to make a separate cleanup pass of some sort over all TupleExprs.
This does make the following illegal (cannot assign to immutable expression of type 'Int'):
var x: Int
var y: Int
(x,y).1 = 7

... but there is no real reason to write this code, and there's no good reason for the compiler to worry about allowing absurdities like (x,3).0 = 7. Maybe when/if subscripting gets added to tuples someone will want to do (x,y)[i] = 7, but that's a problem for another day.

I've merged this, but I have a couple of speculative suggestions for further investigation

If instead the constraint system was set up so that the input to a TupleElementExpr had to be an rvalue, would existing logic in CSApply insert the appropriate LoadExprs?

I keep on sidling up close to the constraint system, but I have yet to really understand it, so I honestly don't know. :-) I think you'd have to add type variables for each tuple element and then constrain them to the rvalue type of that tuple element, but that seems like a lot of indirection and setup for -- in this situation -- something that's always a fairly straightforward transformation.


feat: inherit Version for Bond contracts and add check to workflow script

Purpose for this PR
As per
https://github.com/windranger-io/windranger-treasury/issues/184
Inherit the Version contract where applicable and run the check to ensure the bytecode matches the git tag in the github workflow.
Todo:

where else does Version need to be inherited?

closes https://github.com/windranger-io/windranger-treasury/issues/184


accessibility linter warnings

I hooked up an a11y linter to the sinopia editor.  It gives us a bunch of errors, in a couple flavors.  I'm not sure if this is about how we implemented stuff in the UI, or if there's a design issue ...
...
sinopia_editor/src/components/CanvasMenu.jsx
 13:9   error    Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md                                                                                jsx-a11y/anchor-is-valid
...
  22:85  error    The href attribute requires a valid value to be accessible. Provide a valid, navigable address as the href value. If you cannot provide a valid href, but still need the element to resemble a link, use a button and change it with appropriate styles. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md
  27:85  error     The href attribute requires a valid value to be accessible. ...
  29:15  error     The href attribute requires a valid value to be accessible. ...
  34:85  error     The href attribute requires a valid value to be accessible. ...
  36:15  error     The href attribute requires a valid value to be accessible. ...
  37:15  error     The href attribute requires a valid value to be accessible. ...
  38:15  error     The href attribute requires a valid value to be accessible. ...
  42:85  error     The href attribute requires a valid value to be accessible. ...
  44:15  error     The href attribute requires a valid value to be accessible. ...
  45:15  error     The href attribute requires a valid value to be accessible. ...
  46:15  error     The href attribute requires a valid value to be accessible. ...
  50:85  error    The href attribute requires a valid value to be accessible. ...

sinopia_editor/src/components/EditorHeader.jsx
   20:15  error    Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md  jsx-a11y/anchor-is-valid

sinopia_editor/src/components/EditorHeader.jsx
  20:15  error    Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md  jsx-a11y/anchor-is-valid

/Users/ndushay/ld4p/sinopia_editor/src/components/Header.jsx
  24:13  error    Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md  jsx-a11y/anchor-is-valid

/Users/ndushay/ld4p/sinopia_editor/src/components/LoginPanel.jsx
  21:9  error    The href attribute requires a valid value to be accessible. ...
  23:9  error    The href attribute requires a valid value to be accessible. ...

@ndushay I don't know why it thinks certain links or subheaders are anchors. I am consulting with Jennifer.

@ndushay @SaravShah We put a "#" as a placeholder for the links we don't have URLs for yet. The category titles should not have  tags around it because we won't be linking those.

https://ucomm.stanford.edu/policies/accessibility-policy/

at the time of this comment, at least the following accessibility issues still exist (flagged as warnings by jsx-a11y):
sinopia_editor/src/components/editor/property/InputLang.jsx
  70:9  warning  Form label must have ALL of the following types of associated control: nesting, id  jsx-a11y/label-has-for

sinopia_editor/src/components/editor/property/OutlineHeader.jsx
  32:9  warning  Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md  jsx-a11y/anchor-is-valid

sinopia_editor/src/components/Header.jsx
  19:15  warning  Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md  jsx-a11y/anchor-is-valid

sinopia_editor/src/components/home/Header.jsx
  26:13  warning  Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md  jsx-a11y/anchor-is-valid

sinopia_editor/src/components/menu/CanvasMenu.jsx
  24:9  warning  Anchor used as a button. Anchors are primarily expected to navigate. Use the button element instead. Learn more: https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/anchor-is-valid.md  jsx-a11y/anchor-is-valid

so mostly <a> tags being as buttons, but also a couple missing attributes on a label

@jermnelson is this still an issue now that we do the Help page differently?

This is still an issue in our code base as we still are getting warnings from the linter. The Help page is unrelated to this problem.

https://github.com/LD4P/sinopia_editor/pull/1347 addressed the last of these.


Use conditional call to clearTimeout. Fixes #316

It sounds like #316 was caused by a beta version of Angular.


Fix babel-plugin-codegen crash when export init is null

Summary
It is possible that init is null when using the following code.
export var a;

The typescript compiler actually generates something like this for enums so a lot of third party libraries triggered this issue.
For example in expo-apple-authentication/build/AppleAuthentication.types.js
export var AppleAuthenticationScope;
(function (AppleAuthenticationScope) {
    AppleAuthenticationScope[AppleAuthenticationScope["FULL_NAME"] = 0] = "FULL_NAME";
    AppleAuthenticationScope[AppleAuthenticationScope["EMAIL"] = 1] = "EMAIL";
})(AppleAuthenticationScope || (AppleAuthenticationScope = {}));

This simply adds a null check.
Changelog
[General] [Fixed] - Fix babel-plugin-codegen crash when export init is null
Test Plan
Tested that this fixed the crash in an app.

hi @janicduplessis, can you rebase your changes? i will go for the land when possible. thanks for working on this!

@philIip done!


Chore/file upload

Made FileUpload component work and add it to Organization Registration.

Added a download component to ui-core + added docs download list for Organization View

LGTM, just not sure why the whitespace is 2 spaces instead of 4 spaces like elsewhere in the repo. Thought we had a linting rule for that?

I guess it happens, because NX has its own linting rules inside, which is not configured yet to match with the rest of repo.


Groups wont recognize entities with characters like ü or ß

Make sure you are running the latest version of Home Assistant before reporting an issue.
You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:
Home Assistant release (hass --version):
0.64.3
Python release (python3 --version):
3.6.3
Component/platform:
groups
Description of problem:
Lights with a name like "Küche" or "Groß" wont be taken into a group, they work everywhere else tho (customization, etc)
Problem-relevant configuration.yaml entries and steps to reproduce:

- platform: rfxtrx
  devices:
    0b1100cd0213c7f210010f70:
      name: Küche
    0b11000a02ef9ff210010f50:
      name: Wohnzimmer_klein
    0b1100000213b3f210010f70:
      name: Wohnzimmer_groß

group:
  div:
    name: Div
    entities:
      - switch.Küche
      - switch.Wohnzimmer_klein
      - switch.Wohnzimmer_groß

Just "Wohnzimmer_klein" appeares in group, other entries do not
(if "ß" gets removed in group and configuration it appears)
Additional info:
i have no troubles with those switches in customization or anything else, just groups wont work

First up, name: Wohnzimmer_klein specifies the friendly name of the entity. That is different from the entity id that needs to be specified in the group definition (- switch.Wohnzimmer_klein).
In order to always have entity ids with alphanumeric characters, special characters such as umlaute automatically get converted to their ASCII counterparts. For example, ü → u, ä → a, ... Additionally, everything in the friendly name gets converted to lower case and spaces are converted to _.
So ideally your config would look like this (ß is just removed apparently, can't do much about that):
- platform: rfxtrx
  devices:
    0b1100cd0213c7f210010f70:
      name: Küche
    0b11000a02ef9ff210010f50:
      name: Wohnzimmer Klein
    0b1100000213b3f210010f70:
      name: Wohnzimmer Groß

group:
  div:
    name: Div
    entities:
      - switch.kuche
      - switch.wohnzimmer_klein
      - switch.wohnzimmer_gro

You can use the states panel to verify the entity ids:

(States panel accessible from front end)

(Here you see the friendly name conversion (right) to the entity id conversion (left); and can check whether you're using the correct format)

Closing because this is expected behavior. If you believe that's incorrect please re-open it again.


作者您好，关于运行bash test.sh on MVTec-AD 的指标问题

Thank you for your excellent work.
When I tested the model you shared on OneDrive using the MVTec-AD dataset and ran the bash test_multi.sh, I obtained results of mean: [97.61266667 99.144 96.472 97.29266667 60.59066667 61.024 93.16533333], which are similar to the results reported in Table S7 of the paper. However, when I ran bash test.sh, the results were [98.744 99.41133333 97.52933333 98.52733333 69.76133333 67.39933333 94.88066667], which are lower than the results reported in Table 5 of the paper. Could this be due to random factors, or is this kind of variation normal?
many thanks!

If there are any important points I should pay attention to, could you please point it out, thanks

bash test.sh on MVTec-AD 各类别指标如下：
test:carpet, checkpoint_step:2000
len(val_dataloader) 59
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9755/0.9936/0.977/0.9856/0.7413/0.7152/0.9339-----
test:grid, checkpoint_step:3000
len(val_dataloader) 39
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:1.0/1.0/1.0/0.9889/0.3607/0.3396/0.959-----
test:leather, checkpoint_step:2500
len(val_dataloader) 62
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9997/0.9999/0.9946/0.9975/0.679/0.6466/0.9865-----
test:tile, checkpoint_step:500
len(val_dataloader) 59
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:1.0/1.0/1.0/0.9866/0.7766/0.7999/0.9702-----
test:wood, checkpoint_step:1000
len(val_dataloader) 40
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9912/0.9973/0.9752/0.9802/0.7839/0.7097/0.9573-----
test:bottle, checkpoint_step:2500
len(val_dataloader) 42
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9984/0.9995/0.992/0.9866/0.8556/0.7924/0.959-----
test:cable, checkpoint_step:1500
len(val_dataloader) 75
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9925/0.9961/0.9783/0.9813/0.706/0.6598/0.9344-----
test:capsule, checkpoint_step:2000
len(val_dataloader) 66
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.992/0.9984/0.9774/0.9851/0.5204/0.5335/0.939-----
test:hazelnut, checkpoint_step:3500
len(val_dataloader) 55
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9936/0.9961/0.9859/0.9947/0.8024/0.7322/0.9353-----
test:metal_nut, checkpoint_step:2500
len(val_dataloader) 58
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:1.0/1.0/1.0/0.9884/0.9227/0.8997/0.9685-----
test:pill, checkpoint_step:1500
len(val_dataloader) 84
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9828/0.9969/0.972/0.9783/0.7596/0.7081/0.9732-----
test:screw, checkpoint_step:3000
len(val_dataloader) 80
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9457/0.9821/0.9268/0.9902/0.5289/0.5596/0.9464-----
test:toothbrush, checkpoint_step:500
len(val_dataloader) 21
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:1.0/1.0/1.0/0.9934/0.5872/0.6684/0.9532-----
test:transistor, checkpoint_step:2500
len(val_dataloader) 50
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.9662/0.9587/0.8919/0.9635/0.7639/0.7/0.9076-----
test:zipper, checkpoint_step:1000
len(val_dataloader) 76
test-------- I-AUROC/I-AP/I-F1-max/P-AUROC/P-AP/P-F1-max/PRO:0.974/0.9931/0.9583/0.9788/0.676/0.6452/0.9086-----
[98.744      99.41133333 97.52933333 98.52733333 69.76133333 67.39933333
94.88066667]

I think there is a high probability that this problem is caused by randomness. Because of the randomness of the diffusion generation itself, we cannot guarantee that the result of the generation in different environments is exactly the same. We found the same problem with other diffusion-based algorithms. You can test VisA's results with tesh.sh. The fineturned DINO may alleviate this problem to some extent.

I think there is a high probability that this problem is caused by randomness. Because of the randomness of the diffusion generation itself, we cannot guarantee that the result of the generation in different environments is exactly the same. We found the same problem with other diffusion-based algorithms. You can test VisA's results with tesh.sh. The fineturned DINO may alleviate this problem to some extent.

thank you for your reply!

In fact, the results of the second run should be completely consistent to the first run in same machine and environment because I fixed random seeds. But the random environment is different for different machines, even if the same random seed is used. We tested on the 2080ti and A6000 and got different results.

Thank you very much
---- 回复的原邮件 ----
| 发件人 | Hang @.> |
| 发送日期 | 2024年10月16日 15:42 |
| 收件人 | hyao1/GLAD @.> |
| 抄送人 | zhang @.>,
Author @.> |
| 主题 | Re: [hyao1/GLAD] 作者您好，关于运行bash test.sh on MVTec-AD 的指标问题 (Issue #9) |
In fact, the results of the second run should be completely consistent to the first run in same machine and environment because I fixed random seeds. But the random environment is different for different machines, even if the same random seed is used. We tested on the 2080ti and A6000 and got different results.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


[feature request] axis caption in spatial editor

Issue description:
Maybe this is not a big issue for people with a lot of experience in 3d applications but when working
in the spatial editor, I still often get confused/disoriented about which axis is which and from what direction exactly I'm looking.
When working in blender, I find the little widget in the bottom left corner very helpful to quickly orient myself and know where in 3d space I am positioned and on which axes (an in what direction) i'm currently working.

I think something similar would be very nice to have in godot's viewport as well.

Usually it's R, G, B for X, Y, Z respectively, but I'd also like an arrow or something directional to tell which way is positive/negative.

This is probably a little too non-standard for most people, but how about a gradient on the axis color from light(positive) to dark(negative) color or something similar as a visual helper?

@Noshyaar I think the arrow is not necessary since it is already pretty obvious that positive is the direction where the axis is drawn to.

@toger5 From the screenshot, yes. But I meant currently in the engine.


eslint errors

There are only a couple of problems listed:

[ ] @typescript-eslint/ban-types
[ ] @typescript-eslint/no-unused-vars
[ ] @typescript-eslint/no-explicit-any

npm run lint:eslint

><EMAIL_ADDRESS>lint:eslint
> eslint .

/github_stuff/astrowind/src/components/blog/RelatedPosts.astro
  4:10  error  'fetchPosts' is defined but never used  @typescript-eslint/no-unused-vars

/github_stuff/astrowind/src/components/blog/SinglePost.astro
  19:9  error  'Content' is assigned a value but never used  @typescript-eslint/no-unused-vars

/github_stuff/astrowind/src/components/widgets/Content.astro
  85:33  error  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

/github_stuff/astrowind/src/components/widgets/Features.astro
  43:30  error  Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.
- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead  @typescript-eslint/ban-types

/github_stuff/astrowind/src/components/widgets/Features2.astro
  45:30  error  Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.
- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead  @typescript-eslint/ban-types

/github_stuff/astrowind/src/components/widgets/Features3.astro
  49:29  error  Unexpected any. Specify a different type                                                                                @typescript-eslint/no-explicit-any
  67:30  error  Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.
- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead  @typescript-eslint/ban-types

/github_stuff/astrowind/src/components/widgets/Hero.astro
  13:20  error  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

/github_stuff/astrowind/src/components/widgets/Hero2.astro
  12:20  error  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

/github_stuff/astrowind/src/components/widgets/Steps.astro
  33:37  error  Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.
- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead  @typescript-eslint/ban-types
  36:58  error  Don't use `{}` as a type. `{}` actually means "any non-nullish value".
- If you want a type meaning "any object", you probably want `object` instead.
- If you want a type meaning "any value", you probably want `unknown` instead.
- If you want a type meaning "empty object", you probably want `Record<string, never>` instead.
- If you really want a type meaning "any non-nullish value", you probably want `NonNullable<unknown>` instead  @typescript-eslint/ban-types

/github_stuff/astrowind/src/components/widgets/Testimonials.astro
  53:39  error  Unexpected any. Specify a different type  @typescript-eslint/no-explicit-any

/github_stuff/astrowind/src/utils/blog.ts
  4:21  error  'Taxonomy' is defined but never used  @typescript-eslint/no-unused-vars

/github_stuff/astrowind/src/utils/images-optimization.ts
  213:82  error  'width' is defined but never used. Allowed unused args must match /^_/u   @typescript-eslint/no-unused-vars
  213:89  error  'height' is defined but never used. Allowed unused args must match /^_/u  @typescript-eslint/no-unused-vars

/github_stuff/astrowind/src/utils/permalinks.ts
  112:14  error  'key' is never reassigned. Use 'const' instead  prefer-const

✖ 16 problems (16 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

I'll be submitting some pull requests to eliminate the easy ones.

Hi @ShoGinn
Thank you for this. It was corrected with your PR: https://github.com/onwidget/astrowind/pull/429


Bump the depended Jackson version to 2.15.3

A fix in Jackson 2.15.3 is needed to enable this fix https://github.com/embulk/embulk-util-json/pull/33#issuecomment-1727651903
https://github.com/FasterXML/jackson-core/pull/1111
It's time to upgrade the depended Jackson to the latest!

We may want to add a runtime check for the bundled Jackson version...?

Added the runtime version check. :)
ecf37c3ab5517ed717c2c3e21f8362f56611ed70

runtime version check. LGTM👍

Thanks!


Use the prefix for writing a commitment

In EVM, I think the key of the account corresponds to the prefix, so it is unnecessary in contract.


Adding FitsHandle and unit testing

Adding the class FitsHanlde in rail/core/data.py and unit test for it.

Done in #178

Thank you! Do I have to remove the issue branch as well?

You can if you want.    Otherwise I suspect it will stick around till someone clean those up at some point.
-e

On May 13, 2022, at 1:40 AM, Luca Tortorelli @.***> wrote:
Thank you! Do I have to remove the issue branch as well?
—
Reply to this email directly, view it on GitHub https://github.com/LSSTDESC/RAIL/issues/176#issuecomment-1125800588, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRIGITZNAAIFSBGJESOI53VJYIP7ANCNFSM5VO5CMUQ.
You are receiving this because you modified the open/close state.


Rails/UniqueValidationWithoutIndex should not fail when have index

Expected behavior
Rubocop should run  with no issue.
Actual behavior
app/models/meeting.rb:24:3: C: Rails/UniqueValidationWithoutIndex: Uniqueness validation should have a unique index on the database column.
  validates :meeting_uid, uniqueness: true

Steps to reproduce the problem
# create meeting migration
class CreateMeetings < ActiveRecord::Migration[7.1]
  def change
    create_table :meetings do |t|
      t.string :subject, null: false, default: ''
      t.string :meeting_uid, null: false
      t.index :meeting_uid, unique: true

      t.timestamps
    end
  end
end

Create a table name meetings with column meeting_uid and add unique index on meeting_uid
run rubocop

RuboCop version
$ bundle exec rubocop -V
1.60.2 (using Parser <IP_ADDRESS>, rubocop-ast 1.30.0, running on ruby 3.2.2) +server [x86_64-linux]
  - rubocop-factory_bot 2.25.1
  - rubocop-performance 1.20.2
  - rubocop-rails 2.23.1

closing this as it only happen on my local for some reason.


Resizable handles on other corners

Resizable handles on other corners ?

This is an issue for https://github.com/STRML/react-resizable. Accepting PRs.


fix: added retries to cypress integ tests

Description of changes
Cypress tests are failing with socket timeout error on first run : https://app.circleci.com/pipelines/github/aws-amplify/amplify-cli/8930/workflows/f09dd4b1-0b58-460b-8ab4-10978f7e9bdf/jobs/266106
This was happening due to default responseTimeout of 30s on cypress tests, thus failing on cy.visit()
Added retries solves this as successive runs takes less than 30s normally. So no need to increase default responseTimeout.
This test cofirms above statement : https://app.circleci.com/pipelines/github/aws-amplify/amplify-cli/8939/workflows/807f23c2-30d7-4617-999e-40a9969677a2/jobs/266349

Issue #, if available

Description of how you validated changes

tested Manually and links attached above

Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #10538 (66f2c87) into master (714f2fa) will increase coverage by 0.28%.
The diff coverage is 56.44%.

@@            Coverage Diff             @@
##           master   #10538      +/-   ##
==========================================
+ Coverage   46.57%   46.86%   +0.28%
==========================================
  Files         703      713      +10
  Lines       35246    35543     +297
  Branches     7134     7184      +50
==========================================
+ Hits        16417    16658     +241
- Misses      17042    17081      +39
- Partials     1787     1804      +17

Impacted Files
Coverage Δ

...ql-transformer/amplify-cli-feature-flag-adapter.ts
91.66% <ø> (ø)

...y-api/src/graphql-transformer/auth-mode-compare.ts
10.00% <ø> (ø)

...-api/src/graphql-transformer/user-defined-slots.ts
100.00% <ø> (ø)

...vider-utils/awscloudformation/apigw-input-state.ts
88.00% <0.00%> (ø)

...mation/service-walkthroughs/appSync-walkthrough.ts
15.36% <0.00%> (+0.06%)
:arrow_up:

...loudformation/utils/check-appsync-api-migration.ts
35.71% <0.00%> (ø)

packages/amplify-category-auth/src/index.js
16.04% <0.00%> (-0.23%)
:arrow_down:

...ls/awscloudformation/handlers/resource-handlers.ts
14.85% <0.00%> (ø)

...udformation/utils/attach-prev-params-to-context.ts
50.00% <0.00%> (ø)

...wscloudformation/utils/auth-sms-workflow-helper.ts
43.75% <0.00%> (ø)

... and 104 more

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Deployment target iOS 8.0, should be 7.0?

Hi artman,
Thanks for this awesome library. The documentation says this library requires iOS 7.0 but the podspec targets iOS 8.0. Is iOS 8.0 required and if not, can the target be lowered to 7.0?

iOS8 is required if you use it via pods, since embedded frameworks are only supported in iOS8. You can use it with iOS7 if you integrate manually.


Add a backwards-compatibility system for GDExtension

This adds a way to ensure that methods that were modified in the Godot API will continue working in older builds of GDExtension even if the new signature is different.
Usage:
// New version (changed)
ClassDB::bind_method(D_METHOD("add_sphere","radius","position"),&MyShapes::add_sphere);
// Compatibility version (still available to extensions).
ClassDB::bind_compatibility_method(D_METHOD("add_sphere","radius"),&MyShapes::_compat_add_sphere);

Compatibility testing:
It is also now possible to ask an engine build whether it breaks compatibility with a previous version by calling like this:
$ godot4.1 --validate-extension-api godot4.0-api.json
The following is output to the console right now:
Validate extension JSON: API was removed: classes/AnimationTrackEditPlugin
Validate extension JSON: Error: Hash mismatch for 'classes/AnimationNode/methods/blend_node'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/AnimationNode/methods/blend_input'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/Area2D/methods/set_priority'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/Area2D/methods/get_priority'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/Area3D/methods/set_priority'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/Area3D/methods/get_priority'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_selection'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_editor_settings'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_script_editor'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_base_control'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_edited_scene_root'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_resource_previewer'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_resource_filesystem'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_editor_main_screen'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_file_system_dock'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/EditorInterface/methods/get_editor_paths'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/MeshInstance3D/methods/create_multiple_convex_collisions'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/RichTextLabel/methods/push_list'. This means that the function has changed and no compatibility function was provided.
Validate extension JSON: Error: Hash mismatch for 'classes/SyntaxHighlighter/methods/get_text_edit'. This means that the function has changed and no compatibility function was provided.

If compatibility was broken, Godot will return with an exit code other than zero.
Which means it will need to be fixed by providing compatibility versions as described above.
The idea would be to eventually integrate this to the CI, by storing previous versions of the Godot stable APIs that will need to be tested.
FAQ:
Q: If I add an extra argument and provide a default value (hence can still be called the old way), do I still have to provide the compatibility version?
A: Yes, you must still provide a compatibility method. Most language bindings use the raw method pointer to do the call and process the default parameters in the binding language, hence if the actual method signature changes it will no longer work.
Q: If I removed a method, can I still bind a compatibility version even though the main method no longer exists?
A: Yes, for methods that were removed or renamed, compatibility versions can still be provided.

I think we should also warn extension devs when they are using a method that has been deprecated. I could imagine something similar to this:
// Compatibility version with information about the new method.
ClassDB::bind_compatibility_method(
	D_METHOD("add_sphere","radius"), &MyShapes::_compat_add_sphere, D_METHOD("add_sphere_mesh","radius","position"));

// Compatibility version with information about a completely new approach
ClassDB::bind_compatibility_method(
	D_METHOD("add_sphere","radius"), &MyShapes::_compat_add_sphere, "Please check out the new MeshBuilderObject instead. [docs link]");

This would result in the following warnings when the extension is used with a debug build of godot:
WARN: The method add_sphere(radius) is deprecated. Use add_sphere_mesh(radius, position) instead.
WARN: The method add_sphere(radius) is deprecated. Please check out the new MeshBuilderObject instead. [docs link]

This would (hopefully)) make it easier for plugin devs to update to new extension versions.

@Ansraer the problem with this warning is that it will be shown for users of the extension as well. If an extension isn't updated but it's working because of compatibility then the user will be stuck with this warning showing every time.
Unless this under DEV_ENABLED and we recommend extensions are developed with a dev_build.

Yeah, I was talking about dev builds only. Not sure what other people do, but most of my development happens with a dev build. I only use non-dev builds when I need to check performance.
My thought process was that players would always use a non-dev build, while extension developers (who are more likely to use a dev build) can get additional information that makes it easier to keep their code up to date with API changes.
The way I see it this is a stop-gap measure, sooner or later we will need to remove the backward compat methods anyways. If we have visible warnings for developers it should be easier for them to keep their extensions up to date with the latest changes.

@Ansraer:

I think we should also warn extension devs when they are using a method that has been deprecated.
[... snip ...]
This would (hopefully)) make it easier for plugin devs to update to new extension versions.

There are valid reasons that a plugin developer may want to keep using the older compatibility functions.
At the last GDExtension meeting we discussed making our "compatibility promise" be: GDExtensions built for older versions of Godot will work in newer versions of Godot, but not the other way around. So, a GDExtension built against the Godot 4.0 APIs should work (unless we mess something up ;-)) in Godot 4.2, but a GDExtension built against Godot 4.2 won't work in Godot 4.0 (because if you call a Godot 4.2 API that didn't exist back in Godot 4.0, what would it do?).
So, a plugin developer that doesn't actually need the latest Godot features/APIs, and wants a single build of their plugin to work on as many Godot versions as possible, will build their plugin against the earliest version of Godot that it'll work with, utilizing the compatibility methods.
I agree that it'd be good to have a way to communicate to developers that they using deprecated functions. But we'd need to make sure that it isn't a warning that's printed every time they are calling the function, or that it's easy to turn off (even in debug builds). Because if they are using a compatibility function on purpose, perhaps very often (like every frame), it's not useful to get loads of console SPAM telling them about it. :-)

This also leaks the compatibility binds: https://github.com/godotengine/godot/actions/runs/4838476687/jobs/8622970764#step:11:400
Needs to delete them in class_db.cpp:1668 and class_db.cpp:1711

This looks great! :-)
I tested using the compatibility version of RichTextLabel::push_list() being added in PR #76577 and it worked perfectly. I also tested calling a function with an old hash that didn't have a compatibility function, and got the expected errors.
I didn't notice any additional issues in skimming the code

Discussed at the GDExtension meeting, and this looks good to us!

Thanks!


ROD-100 Record number error message

What?
ROD-100 - Record number error message
Why?
Error message for max and min length has been updated
How?
Testing?
Screenshots (optional)
Before

After

Anything Else? (optional)
Check list

[x] I have reviewed my own pull request for linting issues (e.g. adding new lines)
[ ] I have written tests (if relevant)
[x] I have created a JIRA number for my branch
[x] I have created a JIRA number for my commit
[x] I have followed the chris beams method for my commit https://cbea.ms/git-commit/
here is an example commit
[x] Ensure drone builds are green especially tests
[ ] I will squash the commits before merging

Change is tested and signed off.


Autocompletion for ::: should contain all of the functions from the package namespace environment, not just the exported ones.

I know it's not very common to use ::: for calling not exported functions but it still would be nice to show proper intellisense for it. RBox for Sublime "supports it" (on the other hand the autocomplete for :: is wrong in the RBox).
I have found relevant issue #2507, but it seems to me, that it got fixed only for the rtvs "special package".
RBox:

RTVS:

We currently use
package.functions.names <- function(packageName) {
    as.list(union(
		tryCatch({
			getNamespaceExports(packageName)
		}, error = function(e) {
			return(c())
		}),
		tryCatch({
			ls(paste0('package:', packageName))
		}, error = function(e) {
			return(c())
		})
	))
}

located in packages.R in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\R Tools....\rtvs
We could try
ls(getNamespace("testthat"), all.names = TRUE)
instead. You can change it directly in the RTVS package and try :-)

https://github.com/Microsoft/RTVS/commit/eab57cd565512d22dce04fa67733bdc386591dd0