proposal: allow more flexible account hierarchies

hw allows multiple keyrings, but there is no facility for managing this with the current client commands
I believe the following commands should have a keyring parameter, and possibly also a derivation path parameter, if we are allowing complicated wallets. otherwise derivation path is always going to be some default
Account commands:
newacc    name                          Create a new account
newread   name pubkey                   Create a new read-only account
newms     name M N [pubkey...]          Create a new multisig account
newreadms name M N [pubkey...]          Create a new read-only ms account
accounts                                List all accounts in a keyring
There is a potential name spacing issue if two keyrings can have accounts with same name.  If name conflicts are not allowed, the following commands are unchanged, I think.
setgap    acc gap                       Set the address gap for an account
account   acc                           Display an account by name
addkeys   acc  {pubkey...}              Add pubkeys to a multisig account
If conflicts are allowed, there needs to be a way to resolve this, eg fully qualified account name becomes keyring name + account name.
This brings up an interesting question about how hw client should be used in the wild.
I see these possiblities
-- single user
-- trusted cabal of users
-- public utility model with hundreds or thousands of users who are unknown to each other.
The single user or trusted cabal case is currently well supported, I think.
The public utility, name space conflicts become a thing.
I think we are going to be in a single user or small cabal world for hw client, but just throwing this out in case anyone sees an issue with this.

I was mulling above
"possibly also a derivation path parameter, if we are allowing complicated wallets. otherwise derivation path is always going to be some default"
bip32 has the interesting property that you can branch off accounts from any level.  So, one way of managing this complexity would be to create a default account, named "head" or '' (empty string) or something like that, on keyring creation.
Or make it explicit by changing
newkeyring  [mnemonic] [-k name]        Create a new keyring
to
newkeyring  [mnemonic] [-k name]  rootaccountname      Create a new keyring with a named root account
Then,
newacc name Create a new account
becomes
newacc keyringname parentaccountname name Create a new account
and you can create bip32 hierarchies of arbitrary complexity
Maybe this is just giving the user freedom to shoot himself in the foot... I kind of like it though.
Thoughts?

never mind, this is controlled with
--keyring
flag.
I'm leaving this open for now, in case my proposal for having more flexible hierarchies is liked.
If so, that should be its own feature request and this should be closed.
Otherwise this should just be closed.

According to #5, we should move away from holding keyring information at all on the “server”, and we could probably even move away from labeled accounts as well. If the client should handle private keys, outputs, etc, it is its responsibility to label things, knowing that we can always have a facility to store encrypted account/address/etc. labels on the server, eventually.
I don’t think it is a good idea to do arbitrary hierarchy support at the server side, but to move that complexity to the client. Since the client will be able to register an extended public key with the server and have the server track its addresses and transactions (according to discussion in #5), it makes sense that the client may decide which arbitrary derivations the server must track.

I agree.  Maybe I wasn't clear.
All of what I wrote was meant to apply to the hw client only. I begin to consider the server in #122

changed title to reflect the only possibly relevant novelty in this thread.

Cool, yes, maybe we should have a way for the client to create an account by specifying:

if account is multisig (m of n):

how many keys (m)
how many signatures (n)

key(s), which are either:

plain extended public key(s)
derivation path from a master key
a combination of both (only multisig)

number of addresses to pre-generate (optional)
date of key creation
gap of addresses that should have not been used

This information can be relayed to a Haskoin server, then the server will generate addresses, and then scan the blockchain from the specified date for transactions, generating more addresses if required to honour gap. The rescan can be substituted for a full blockchain index in the future, for increased performance.
Optionally, to help in establishing multisig accounts, an account may be created on the server with an incomplete set of keys, in which case whoever knows one of the extended public keys used can add its own public key to the account, until all keys have been added. Linking each of these extended public keys with encrypted metadata that resides in the server and is accessible to all parties in the multisig account could be a good idea, and perhaps there are ways to do so by creative use of the elliptic curve public keys keys already available.
This preserves the KISS principle.

I'm starting to agree that storing some metadata on server, such as account names, derivation hierarchies and the like, is a reasonable thing to do. Particularly it makes communicating about shared keys a lot more straightforward, as you say.
This raises the question, do you you have granular access on the metadata, or everyone can see everything, as long as they have auth on the server?
Everyone sees everything makes sense if this is shared viewing wallet for a small business, but not so much if it is "public utility" for caching mpubkeys, or a viewing wallet for an exchange or similar service.
So, you are considering the harder case, and what to encrypt and how to do it.
I think I agree with everything except
" an account may be created on the server with an incomplete set of keys, in which case whoever knows one of the extended public keys used can add its own public key to the account, until all keys have been added."
There's an easier way to do this.
Assume we have named accounts, with names mapped to xpubkey, as in my initial comment.
Creating a multisig account is then just instead of
newreadms name M N [pubkey...]

we do
newreadms name M N [accountname1, accountname2...]

the server creates the account using fresh addresses derived from the various mpubkeys.  The derivations are included in the metadata when queried by
account acc Display an account by name

I think we can do all of this and keep mpubkeys secret by hiding them on queries, but I'm not sure if it's worth going through the effort of hiding mpubkeys from other users.

So, to be clear, I am disagreeing with
"we could probably even move away from labeled accounts as well"

because I am hoping to convince you that account name labels on server make multisig account coordination much easier to wrangle.
Once we have have labeled accounts on server it seems we have paid most of the cost of having more elaborate account hierarchies, but I don't care so much about that, as a one layer deep hierarchy covers most important use cases.

Sorry, I changed my mind again about storing metadata on server.
If haskoin adopts bip45, hw clients can become deterministic multisig wallets simply by importing their cosigners extended purpose' public keys, once.

This information can be relayed to a Haskoin server, then the server will generate addresses

Clients can generate addresses to watch deterministically and send this to the server, and then we don't need to be caching mpubkeys+gap limits either.  Just addresses.

Besides serving as a basic spv client, the haskoin server could also serve as a rendezvous point for partially signed transactions.  It might be instructive to study how bip45-supporting
https://github.com/bitpay/bitcore-wallet-service
accomplishes this.
Bitcore wallet service would be analogous hw server here, and the copay wallet would be analogous to the hw client.
It's interesting to note, from Security Considerationsi n the above link, "Extended public keys are stored on BWS. This allows BWS to easily check wallet balance, send offline notifications to copayers, etc."
This is a design choice, not a requirement.
As I said in previous comment, we can move all logic to client, and keep xpubkeys completely off server.

@xenoj, your last comment on this thread amounts to basically copying the bitcore wallet service model. (Are there any differences?)
That's not a bad thing, and I wouldn't argue too much if that's the direction you want to go.
I'm just pointing out that it's possible to go with a zero metadata on server model and still have deterministic multisig keys client side, which is a little bit more secure.
It's also possible that it's a common use case that clients want to share metadata, and aren't too concerned about leaking it in the event of a hack.

Hey @tphyahoo,
Then the Bitcore wallet service model is good and we should aim to go in that direction.
The thing about the metadata is that I love the cloud, I want you to tag an address here, and see it in your mobile wallet.
Therefore a model in which you keep metadata encrypted and stored in the server is good. It makes clients more stateless.
I believe we are witnessing a fork moment. We are departing so much from the existing haskoin-wallet that we may just start a separate project using haskoin and haskoin-node libraries, and simplifying storage. I would tend to prefer memory-based blockchain headers, and LevelDB for transactions and addresses.

I'm not so certain it's time to fork, but if you spin something up I'll probably go with the flow.
OK, so back to metadata on server.  I think this is a can of worms, so I will share some design considerations that will either scare you away from the worms, or otherwise clarify direction.
Design considerations...
1 -- Zero Knowledge or server gets hacked means metadata gets leaked?
Bitpay has gone non-zero-knowledge with bws.  I'm assuming that is your model model as well.
Nice things about zero knowledge
-- it gets you granular permissioning for free.
-- one else seems to be doing it, so it would be a real differentiator if achieved
Bad thing about zero nowledge
-- it's harder.
2 -- Is metadata (and historical transaction data) available offline?  I guess we want some offline cache so this works ok.
3 -- CRUD, or WORM? I guess CRUD. I don't really see why user would want to delete a label, but since it's a deterministic wallet at least no value is lost this way.
4 -- do users want to share metadata (like account names for multisig accounts) with each other?
OK, but now we need granular permissions with acls. Maybe each account gets an acl for who is allowed to read from it (or even know it exists).
5 -- What if two authed user (or same user in different places) make conflicting updates?

@xenog: this is either total overkill, or "cloud wallet done right."
proposal: zero knowledge account-pegged meta data storage with acls.
The basic idea is borrowed from the alt.anonymous.messages usenet community. On a.a.m, messages are world viewable, but postable/decryptable only if you have been accepted into the group (your pubkey is on the a.a.m ACL, which is a list of pgp pub keys).  Posters are responsible for encrypting data for every pub key.  Only messages with valid signatures are posted.
In our zero knowledge metadata wallet, metadata is updated by appending encrypted data to sqlite table. It is the client’s responsibility to encrypt the data for everyone on the acl list (just as with a.a.m.), since server doesn’t have priv keys.  To keep the appended encrypted data from growing forever, we implement a fixed size fifo buffer and drop old metadata updates after a while. Of course, we use signatures too, just like a.a.m.
(quasi humorous side note: maybe we should use a.a.m. for storing metadata. Or bitmessage! But we’re boring and we’re already using sqlite and this is fine too.)
We want to decouple metadata encrypting keys, from bitcoin controlling keys.
I’m not sure the best way to do this, but two ideas are
— use a completely different mechanism from bitcoin, like pgp or openssl
— use bitcoin E.C. keys, but take care these don’t control any bitcoin (for instance, by reserving a deriv path that should ONLY be used for this purposes
I’ll defer further consideration of precise key mechanism for now. We’ll call these keys metadata keys, to differentiate them from bitcoin keys.
hw accounts have at least one acl, which controls who can read and write all metadata.  This can be made more granular by having separate acls depending on the metadata. EG, account metadata, versus multisig transaction proposal metadata. It’s easy to add more acls as use cases arise. For version one, I think one acl for everything suffices.
The acls are lists of pub keys.
modifying acl requires the xprivkey tied to the account. keys can be added or deleted.
If you’re on the acl list, you can both read and write the channel, as with alt.messages.anonymous.
the metadata that is stored is a json object containing account name, address labels for the account, and account history, with derived address and account labels where possible. This is stored encrypted with every pub key, in sqlite.
We also store pending multisig transaction proposals here, for use as a convenient but protected rendezvous point for communicating multisig transactions.
If a user’s wallet is destroyed, he can
— recover funds with seed (but without any labeling information)
— recover metadata from any pgp priv key associated to the ACL
— start writing metadata again by generating a new priv key and associating it to the acl
— if there is no priv key for the stored encrypted data, he loses all the labels, but of course still has the coins
BTW, iiuc, bitcore wallet service does not keep metadata like labels on server.  There is an option to make backups in copay client.
So if implemented this feature would be unique to haskoin wallet.

Hey @tphyahoo,
Your ideas are not crazy at all, I have been thinking about using the blockchain itself to store account metadata.  We should use privacy-enhanced BIP-45 as I proposed on bitcoin-dev recently.
Cheers

Hi @tphyahoo,
Actually, I was thinking of a much simpler model, which requires no (proper) authentication, but that goes more or less in the same direction as you are heading there.
Regular (Non-Multisig) Accounts
For this type of account, the solution would be trivial: metadata is encrypted with a hardened derivation from the master key that isn’t used for any other purpose.   The client stores this encryption key itself encrypted with a password using a symmetric encryption algorithm.  Clients store metadata against a particular extended public key and an optional derivation path.  Anyone that knows the extended public key can download the encrypted metadata.  To upload or delete metadata, it must be signed with the private key corresponding to the extended public key to which the metadata belongs.  No other type of authentication is required.
Good for:

labeling accounts (xpubs)
labeling addresses
attaching arbitrary metadata to either

Multisig Accounts
The scheme described for regular accounts is used, with the addition of a multisig encryption key.  This key is calculated using ECDH among all account root keys from cosigners.  Metadata is encrypted with this key and signed with the private key of the user that uploads it.  Only the original uploader can delete a piece of encrypted metadata.  Anyone with knowledge of any of the extended public keys that compose an account can download the encrypted account metadata.
Good for:

sharing transaction propositions
messaging cosigners
shared labels for cosigner public keys
shared labels for addresses

Since the regular scheme is also implemented, you can override a label for an extended public key or address in your own private view of the multisig account.
Unencrypted Data
The server will store some data unencrypted for performance and account recovery:

extended public keys
a set of addresses generated from these keys
basic multi-signature account data: extended public key set and number of required signatures

This data is indexed by extended public key, and knowledge of any of any of the extended public keys involved should allow retrieval of the rest of associated data.  This will allow a user to easily retrieve all information concerning multisig accounts, for example.
Multi-Signature Oracles
An automated entity known as an oracle can become a participant on a multi-signature account for security purposes.  Its job is to sign transaction proposals automatically on behalf of the account owner after doing additional identity verification or velocity checks, for example.

very nice. wish I had thought of that myself.
As a quick observation, I think it would be good to register a new bip purpose scheme following
https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
for a new kind of wallet.  That is, a wallet containing keys for encrypting wallet metadata, but expressly not for storing bitcoin value.
So the derivation you propose would be
m / wallet_metadata_encryption_purpose_id / 0
if we think we will only ever need a single key for encrypting metadata, or if we need more keys that should be explained in the bip for "wallet metadata encryption" and we can bounce this around further.
Then
-- we're guaranteed  we don't conflict with the main wallet, which iiuc is under m/44 and maybe m/45 if bip45 gets incorporated.
-- we're one step closer to some kind of unified format for wallet metadata which would make wallets interoperable... maybe we should also do a bip for that?
-- of course your main objective of having cloud wallets with nice privacy properties
question about
"The client stores this encryption key itself encrypted with a password using a symmetric encryption algorithm."
why?  And who stores it?
If it's the original client, and he has the seed, and we're not talking about encrypting the seed, why are we worried about encrypting just the metadata viewing key?
And if it's someone with viewing privileges but without the privkey seed, sort of the same issue.
I guess what I'm getting at is I thought we're moving away from specifically encrypting anything and instead focusing on physical security (with multisig and/or hardware wallets for high value) so I'm not sure if there's anything special about this particular key that we are treating it differently by caring about encrypting it even symmetrically with a password.

another sticking point for me, from the section on multisig accounts
"This key is calculated using ECDH among all account root keys from cosigners. "
Can you say more about this mechanism?
I had a glimpse at
https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman
and it seems ECDH is good for establishing a shared key given two public keys, but I didn't see any mechanism for establishing a shared key among more than two participants.
Also the mechanism you propose uses xpub keys for authentication and xpriv keys for uploading and modifying data.
So the end goal of the shared key would be an xpubkey derived from a number of others in a deterministic way.
But I don't see that ECDH actually accomplishes that, that is, I don't think ECDH gets you something that actually looks like an xpubkey, does it?
Maybe just sort the multiple xpub keys and xor them in sorted order?
Don't know enough about cryptography to say if that's a good or safe idea or not, but at least it yields an xpub key.

Metadata Encryption Key
Metadata is encrypted with using an extended private key derived from the wallet’s master key.  On the server, associated with the corresponding extended public key is a bunch of encrypted metadata, including all extended public subkeys (accounts) belonging to the wallet, which themselves may be associated to additional encrypted metadata pertaining to each individual account and address under the wallet.
Metadata Key Management Options
No Local Metadata Key
The Metadata key is not stored locally at all. Since the key used to encrypt the metadata is derived from the seed, not storing this key is acceptable as long as the user still has the seed.
Unencrypted Metadata Key
The metadata encryption extended key may be stored unencrypted.  This exposes wallet data to potential attackers that may gain access to the device where the metadata key is stored, provided this device is not already encrypted by other means.
Metadata Passphrase
The metadata passphrase encrypts a local copy of the encryption extended private key.  The presence of this passphrase, assuming it is secure, makes it harder for an attacker with access to the user’s disk to learn anything about the wallet.
Seed Encryption Options
No Seed
The user may decide not to store the wallet seed locally at all.
Seed Passphrase
The seed of the wallet itself may be stored encrypted with a chosen passphrase locally on the client.  This passphrase would be required to send funds.
Seed Encrypted by Hardware
A hardware encryption device may be used and the encrypted seed then stored locally.  In order to load the key in memory and use it to sign transactions, the hardware encryption device must be inserted.  Smart cards or possibly USB tokens can be used for this purpose.
Seed Stored in Hardware
The seed can be stored in hardware that can calculate BIP-32 derivations and sign transactions. The device should be capable of exposing the encryption extended private key, or this key must be derived and stored locally at some point before uploading the seed or master key to the hardware device and erasing it from memory.
I will respond to your other queries tomorrow.

from the oracle section
"Its job is to sign transaction proposals automatically on behalf of the account owner after doing additional identity verification or velocity checks, for example."
There are many potential cosigning scenarios. I don't see any reason to particularly elevate this one over many others.
Also oracle seems like the wrong word to me, unless you want to generically call almost any cosigner an oracle.
The right word here would be "banker" if retail banks provided such a service for bitcoin holders, or "crypto security nanny" perhaps.  (Maybe we need to invent a word.  Wallet buddy?)
I would either leave this section off the proposed bip entirely, or stick it in an appendix or a section "example applications" or something like that.

I'd now like to rant a bit about
Metadata Key Management Options / Seed Encryption Options
This gets a bit opinionated.  But it's an opinion based on having done consulting for "civilians" with high value wallets, helping them get their brains around wallet security implications.  It's hard, because it's an unfamiliar and hostile domain -- by some counts, 10% of bitcoin is lost or stolen.   So it's tricky.
I've found the following basic prescriptions to be invaluable in orienting users to a reality based mindset
1 -- physical access equals root
2 -- computer was ever connected to the internet, almost equals root
It's not about being draconian.  It's about making simplifying assumptions so that you can make good choices with confidence, and not bog down in paranoia about zero day attacks.
So rather than think about whether the password can be sniffed (it can), you focus on physical security, because that's easy to understand.
Hardware wallets represent physical security.  They're a little portable zone of safety that doesn't leak privkeys.  "cold" computers, locked in a safe, are a kludge to accomplish the same thing.  (My view is that we basically should be shifting to ubiquitous hardware wallets, and hopefully this will happen soon.)
Anyway, with this view, the three "Metadata Key Management Options" presented boil down to the same thing.  All three leak metadata privkeys in the event that an attacker has bugged the computer.
-- No Local Metadata Key: leaked when the user enters the seed at the prompt
-- Unencrypted Metadata Key: self explanatory
-- Metadata Passphrase: sniffed from ram after the user enters the passphrase
Passing on to the four seed encryption options
-- No seed: leaked at prompt
-- Passphrase: leaked after user enters passphrase
-- Encrypted by Hardware: leaked decryption
-- Stored in Hardware: the only actually safe option, if the computer is bugged!
So far, we have the usual solution for securing the seed (hardware wallet), but funny enough we actually have no solution that does not leak the metadata privkey in the event of an attack!
I believe we can fix this by adding option 4 to Metadata Key Management Options
-- Stored in Hardware.  A trezor/ledger/etc.
People normally use trezor for signing transactions, but you can also use trezor to sign/decrypt arbitrary data.
See
https://github.com/hiviah/TrezorPass/
for an example of this in action.
My recommendation is to deprecate passpharase and seed encrypted by hardware options, and direct user either to
-- be cavalier about security for low value wallets, and keep the seed phrase in a config file or entered at the prompt
-- use hardware wallet or cold computer if the metadata is high value.  (Just like if the bitcoin is high value.)
I think passphrase and hardware element solutions, that leak privkeys to ram, are just going to give users a false sense of security and/or confuse them about where privkeys actually live.
The principle that privkeys never cross a certain boundary is VERY important, and symmetric encryption and vanilla hardware encryption (but not trezor) violate this.

re
-- labeling addresses
I think it's in poor taste to label individual bitcoin addresses in the wallet metadata.
I think it will be easier to build, maintain, and (hopefully someday) interoperate an ecosystem of metadata compatible wallets if we always label the xpubkey, and pretty much treat addresses as derived data.

Hey @tphyahoo,
Oracle refers to an automated signer, as opposed to a human being.  Therefore in an escrow arrangement between a buyer and seller there will usually not be any oracles, but in a security provider arrangement where a machine is validating one-time-passwords and velocity checks, there will.  I think the term may have been coined by Nick Szabo.  I read it first here.
Labeling addresses is useful to monitor incoming payments.  If you are meant to use an address only once, then labeling addresses is like labeling expected transactions, which is useful.  Most users will have a single account.  By the way, transactions should also be able to get labels, keyed to the extended public key public and transaction id (or better: transaction hash excluding signatures).  For multisig, they should be keyed by all xpubs and transaction id.
About your rant.  I agree with your security assessment, but I prefer to have practical security instead of extreme security that may or may not be practical for everybody.
Although Trezor seems to be selling for about US$ 130 in some places, many users only have that much in Bitcoin.  They will not pay US$ 130 to protect that amount or less.  It is unreasonable, so a solution without Trezor is necessary.
Defending against a compromised client system is nigh impossible.  Assume you have Trezor, and you have a bugged computer, and you’re buying something online and doing a payment, malware can alter the bitcoin address of your payee on screen, and that means that the Trezor will get the wrong address too.  Both will match, you’ll accept to pay on the Trezor, and you’ll have been robbed.  Working with the assumption of an attacker having full control of the client system is hard.  One possible solution for this scenario by the way involves multisig and MePIN, which pops a notification on your smartphone showing the actual address and amount that the transaction goes to for signing on another system.  Of course we can always say that the smartphone may be compromised too, and that is not trustworthy anymore.  It is turtles all the way down.
For advanced users we should offer choice.  For novices we should have default security settings.  Something like multisig oracle + MePIN can work.  Something like Trezor can work (although payments won’t be possible from a mobile phone.  Other choices can work too.  I want to set the basis of multiple security arrangements that we can experiment with.
Do not forget that the most popular Bitcoin wallet out there is Blockchain.info.  Their security model assumes that the client is not compromised, and so far that has worked, with some reported cases of lost funds, but most users managing to hold on to their coins.  Security is important, and operating system writers, web browser writers, and application writers are understanding this.  Things have improved from the days of Blaster.  But we still need to constantly manage tradeoffs between security and convenience.  Forcing everyone to use a Trezor or similar device will harm the convenience side of things (no mobile), and as I demonstrated it does not completely guarantee that it will resist all possible attacks.  So, security is improving, but there are still no silver bullets.  There is more than one way to do it.
Cheers!

This discussion should be started again in the repository if necessary.


@itwin/grouping-mapping-widget: Support iTwin.js and AppUI 4.0

@arnobmallickbsw any update on getting gm updated?

Hey @aruniverse, we are figuring out a timeline for this.

as per @arnobmallickbsw this pkgs is only for "Reference", therefore it will not be required for DR to upgrade.


Pseudo Papilledema Detection

Deep Learning Simplified Repository (Proposing new issue)
:red_circle: Project Title : Pseudo Papilledema Detection
:red_circle: Aim : Create a DL model which will identify the Pseudo Papilledema from the given set of input images.
:red_circle: Dataset : https://www.kaggle.com/datasets/shashwatwork/identification-of-pseudopapilledema
:red_circle: Approach : Try to use 3-4 algorithms to implement the models and compare all the algorithms to find out the best fitted algorithm for the model by checking the accuracy scores. Also do not forget to do a exploratory data analysis before creating any model.

📍 Follow the Guidelines to Contribute in the Project :

You need to create a separate folder named as the Project Title.
Inside that folder, there will be four main components.

Images - To store the required images.
Dataset - To store the dataset or, information/source about the dataset.
Model - To store the machine learning model you've created using the dataset.
requirements.txt - This file will contain the required packages/libraries to run the project in other machines.

Inside the Model folder, the README.md file must be filled up properly, with proper visualizations and conclusions.

:red_circle::yellow_circle: Points to Note :

The issues will be assigned on a first come first serve basis, 1 Issue == 1 PR.
"Issue Title" and "PR Title should be the same. Include issue number along with it.
Follow Contributing Guidelines & Code of Conduct before start Contributing.

:white_check_mark: To be Mentioned while taking the issue :

Full name :
GitHub Profile Link :
Email ID :
Participant ID (if applicable):
Approach for this Project :
What is your participant role? (Mention the Open Source program)

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

Kshitij Kumar
Github link-https://github.com/kshitij192
Email-<EMAIL_ADDRESS>Participant id- None
Approach- Using Transfer learning

Issue assigned to you @kshitij192


Contradiction in RFC1192 (Inclusive Ranges)

The "Detailed design" section mentions

Writing ...b in an expression desugars to std::ops::RangeToInclusive { end: b }.

However, the "Alternatives" sections states

This RFC doesn't propose non-double-ended syntax, like a..., ...b or ... since it isn't clear that this is so useful. Maybe it is.

From what I have gathered, the specified design has been implemented.

Hmm, you're right. I did implement a...b and ...b. My understanding is a... is reserved for possible variadic generic syntax In The Future.
There was discussion in the RFC about ...b, and the text was updated but some parts missed as you noticed.
cc @aturon


Modify frontend codes of ping email server

Coverage remained the same at 54.564% when pulling 3ed8b44c8698e47f82921a8eafa00b899f642297 on ywk253100:170324_ping_email_server_ui into ed1cad0ba88f752949a72b9a6b841ac5f7e97ea7 on vmware:dev.

Code change is already merge into harbor-clarity branch,so close this PR


Client Allocation Request for: Blockinpress

Client Allocation Questions
Core Information

Name: Blockinpress
Website / Social Media: https://blockinpress.com/
Region: Asia excl. Greater China
DataCap Requested: 15TiB
Addresses to be Notarized: f1egqrp5gjqsivj6j3o6gj7gskdi2qh6uladnxlta
Notary Requested: steven004

@Blockinpress Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Hey @Blockinpress , the region you set is Asia excl. Greater China, which is not covered by me.
You could either send this to one who is focusing on the region you defined, or you submit a new one to region Greater China.


Custom Processes

I can't see a similar discussion point but apologies if it has already been covered elsewhere.
Can we add support for custom processes? I have a use case for iterative processing of certain tasks (e.g. take output from TASK A, split it, feed chunks to TASK B, aggregate TASK B outputs, continue chain) but I can see this being a piece of logic that users may want to customise to their needs.
Currently inheriting Crew and rewriting kickoff() to handle custom process logic works but it's not very elegant and forks some of the Crew logic into a separate implementation.

Probably an integration with LangFuse?


Spring cloud config add symmetric encryption key by manually reading from a file

Guys , posting here because need urgent help.
https://stackoverflow.com/questions/48760231/spring-cloud-config-add-symmetric-encryption-key-by-manually-reading-from-a-file

No need to cross post. Closing in favor of stack overflow.


Bump json dependencies

@ottonascarella released as https://pub.dev/packages/artemis/versions/2.1.2


Throw clear exception when WOQLClient is initialized without DB

When a WOQLClient is initialized and a query is executed without a database, the following error appears:
woqlclient.errors.InvalidURIError: Invalid argument to Undefined, TerminusDB Id is not a valid Terminus DB API endpoint

It should probably be clearer that a DB should be passed to WOQLClient before a proper query can be executed.

Now (version 0.1.1) a database is required to initialize a WOQLClient object.


explore alternative solutions to ioctl module for dirsync

ioctl requires C++ compiler to be installed in the environment which may/may not be available by default. Current solution skips the dependency if npm install encounters an error, making the file backend solution less reliable on some environments.

Hey Rahul, do you have any idea about this one?
How does dirsync affect platforms like OSX?

I don't have the critical knowledge about it but from what I have learned so far from @RachedBenMustapha and everyone else is that all platforms have this issue and the implementation of the ioctl module supports only linux platforms (virtual filesystems like aufs not included). To circumvent this for OSX, we could consider @NicolasT 's suggestion to fsync after every write, which I am not sure how it would play out with nodejs FS calls(it could be queued like any other fd calls and data loss is not guaranteed in that case as well). Alternatively, we could explore if OSX exposes any ioctl flags that we could use and write our own implementation for dirsync.

To be clear, my suggestion is not to fsync after every write. That's not what dirsync does either.
The idea is to do what dirsync does on EXT4 (and not necessarily on other even non-virtual filesystems like XFS) through basic POSIX calls, i.e. (f)sync modified objects after ack'ing said modification.
What does this mean? E.g. when creating a file, before handling back the file handle to the application code, fsyncing the parent directory of said file. The same for unlink calls (though one may argue this should be 'configurable' by the caller: often one may not really care about such dangling links). Similar when using rename: even though rename is atomic, an application may assume the new path is stable after the call returns and take actions based on this (e.g. update some location field in a database), which is not correct: the rename is only stable after fsyncing the target directory.
In many projects, you'll find utility procedures to do this transparently, e.g. safe_rename, safe_creat or whatever.

Was there any update to this issue?

@NicolasT, to bring this closer to the code, is the suggestion to add an fs.fsync(parentFd) before this line https://github.com/scality/S3/blob/master/lib/data/file/backend.js#L76 where parentFd is the file descriptor for ${STORAGE_PATH}/${folderHashPath}?
Per the man for fsync:
Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
Do you think this call should be synchronous fs.syncSync()?  See this thread: https://github.com/nodejs/node-v0.x-archive/issues/6438
Thanks

No activity since Jul 23rd so I am closing. Re-open if you feel this can be taken care off in the short term.


Default classes for each HTML element improvement

DESCRIPTION:
The example to add default classes to the output as discussed on the wiki pages (https://github.com/showdownjs/showdown/wiki/Add-default-classes-for-each-HTML-element) uses a regular expression that will need you to set noHeaderId option to false. If this option is set to false, you are no longer able to use reference tags like a href="#titlename" to access the title from a table of contents.
CURRENT EXAMPLE CODE:
const bindings = Object.keys(classMap)
  .map(key => ({
    type: 'output',
    regex: new RegExp(`<${key}>`, 'g'),
    replace: `<${key} class="${classMap[key]}">`
  }));

const conv = new showdown.Converter({
  extensions: [...bindings],
  noHeaderId: true // important to add this, else regex match doesn't work
});

SOLUTION PROPOSAL:
If the regular expression is updated to also match other attributes in the tag (.*). The replace string can be updated to print those attributes to the output using $1.
regex: new RegExp('<${key}(.*)>', 'g'),

replace: '<${key} class="${classMap[key]}" $1>

If you change this, the noHeaderId option can be set to false again, allowing tables of contents to work again.

Thank you. Will update as soon as possible.

Updated. https://github.com/showdownjs/showdown/wiki/Add-default-classes-for-each-HTML-element
Thank you for your contribution

using replace: '<${key} class="${classMap[key]}" $1> you get an incorrect output, because $1 refers to the first group of the regular expression, which turns out to be the name of the html tag.
This is resolved by changing from $1 to $2, that is: <${key} class="${classMap[key]}" $2>


updated to wowchemy/v5 v5.6.1

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


ProductStateMachine create failed

Resource ManageProvisionedProductStateMachine failed to create and stack rolled back.
CloudFormation logs
Resource handler returned message: "Invalid Logging Configuration: The CloudWatch Logs Resource Policy size was exceeded. We suggest prefixing your CloudWatch log group name with /aws/vendedlogs/states/

Same issue with TerminateProvisionedProductStateMachine as well


Test Kubernetes 1.15 in CI

Will enable in postsubmit once/if this passes
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

/test all

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

Test name
Commit
Details
Rerun command

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

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

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

Test name
Commit
Details
Rerun command

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

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

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

Test name
Commit
Details
Rerun command

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

integ-pilot-k8s-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test integ-pilot-k8s-tests_istio

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

/retest

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

Test name
Commit
Details
Rerun command

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

integ-pilot-k8s-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test integ-pilot-k8s-tests_istio

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

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

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

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test integ-pilot-k8s-tests_istio

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

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

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

Test name
Commit
Details
Rerun command

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

integ-pilot-k8s-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test integ-pilot-k8s-tests_istio

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

/retest

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

Test name
Commit
Details
Rerun command

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

integ-pilot-k8s-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test integ-pilot-k8s-tests_istio

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

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

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

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test integ-pilot-k8s-tests_istio

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

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

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

Test name
Commit
Details
Rerun command

release-notes_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test release-notes_istio

unit-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test unit-tests_istio

integ-pilot-k8s-tests_istio
00ba76e9579f47624641a2e2b49fcd2a5dccf452
link
/test integ-pilot-k8s-tests_istio

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

/test all


scss not working

https://gohugo.io/hugo-pipes/introduction/#from-file-to-resource
not working
error calling toCSS: no Resource provided in transformation

What version of Hugo are you using (hugo version)?

$ hugo version
Hugo Static Site Generator v0.69.0/extended windows/amd64 BuildDate: unknown

Does this issue reproduce with the latest release?
yes

Thanks for getting in touch, but it feels like this is a question  that would be better suited to the Hugo Discussion Forum.  We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add some more details if you feel this is a genuine bug. You may also find the answers you search for in Hugo Documentation.


Fix setup.cfg using description-file instead of description_file

One other quick thing I noticed while working on MR #20 was that setuptools was producing a warning regarding the use of description-file in setup.cfg, this is visible in the deployment of 1.5.1 here.
This MR simply follows their advise and swaps out the description-file key to description_file to remove the warning.

Good to see the SNR of AI is still terrible, I've no idea how a newline causes it to think that it's a new change that "the Python tests will run in verbose mode". We'll be able to work on all this stuff for at least a bit longer before they take over.

Thanks @David-McKenna -- LGTM!
PS: I swear WTD has been getting worse 🤖


Snapshot policy support

As described in https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/224, there are resource types that support snapshotting outside of CloudFormation that are missing support for the Snapshot policy in DeletionPolicy and UpdateReplacePolicy; so it'd be great if providers could provide support themselves

I think we would want to implement a Snapshot handler alongside the current CRUDL handlers. Then CloudFormation can call those as needed. Need to think about what the contract for snapshot looks like, but it shouldn't be too hard.


[Fabric][React Native 0.68] Support the new architecture

Description
Hi !
Lottie doesn't currently support the new Fabric architecture. Are there any plans to ?

We will, but there are some major versions which need to be released in the meantime.

@emilioicai I would keen to pick up the work for that. Let me know what you think 😃

Hey @AlexanderEggers that would be great! Let me know if I can support you in any way.

Hey @AlexanderEggers and @emilioicai any update on supporting the new architecture? 🙏

@capezzbr I started with the work for that. I hope to have a PR up by the end of this month.

@AlexanderEggers does that means react-native-lottie does not work on RN 0.68?

@chenop No, react-native-lottie should work fine with any newer RN version (tested on 0.68 and 0.69 and no issues so far). But you won't be able to actually enable the new architecture.

Hey @AlexanderEggers any update about supporting new architecture?

@EmreDereli The relevant integration is currently stuck because of an issue with the new arch: https://github.com/facebook/react-native/issues/34372 I hope we will be able to resolve that problem soon.

@alfonsocj yes I already started with that a little bit but not much progress yet. The underlying new architecture issues are keeping me from progressing at the moment.

Is there a specific new arch issue on iOS or is it same issue you mentioned above (https://github.com/facebook/react-native/issues/34372)?.

@alfonsocj It would be unproductive to start working on the new arch for ios unless we get the android setup correct. That setup is still blocked by the mentioned issue.

I finally managed to get the lib working with fabric (working for both platforms). We will do some internal testing to verify that the most of the basic props are working but a release should happen soon. 🎉 If anyone wants to help the testing effort, feel free to checkout https://github.com/lottie-react-native/lottie-react-native/issues/931.


small fixes for mypi.ini

pr that fixes mypi.ini and adds type-protobuf

Codecov Report

Merging #760 (8901ff8) into main (b6d0179) will decrease coverage by 0.01%.
The diff coverage is 42.10%.

@@            Coverage Diff             @@
##             main     #760      +/-   ##
==========================================
- Coverage   40.55%   40.54%   -0.02%
==========================================
  Files         206      206
  Lines       10878    10883       +5
==========================================
  Hits         4412     4412
- Misses       6466     6471       +5

Impacted Files
Coverage Δ

lnbits/app.py
67.18% <ø> (+0.52%)
:arrow_up:

lnbits/core/crud.py
52.55% <0.00%> (ø)

lnbits/core/models.py
64.91% <0.00%> (-1.16%)
:arrow_down:

lnbits/core/views/generic.py
30.53% <0.00%> (-0.97%)
:arrow_down:

lnbits/wallets/fake.py
70.21% <0.00%> (ø)

lnbits/wallets/lnpay.py
21.68% <0.00%> (ø)

lnbits/wallets/opennode.py
24.05% <0.00%> (ø)

lnbits/utils/exchange_rates.py
25.00% <25.00%> (ø)

lnbits/core/views/api.py
41.13% <64.70%> (+0.19%)
:arrow_up:

lnbits/core/services.py
51.53% <66.66%> (+0.60%)
:arrow_up:

... and 3 more

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

What is the purpose of this PR ? Does it change anything? Please write more extensive descriptions so it can be properly reviewed.
It has 15 file changes but the description says that only an ini file changes.
Thanks :)

the purpose of this PR is the re-enable mypy checks, at the moment the status is Found 30 errors in 6 files (checked 41 source files)

Nice! Please get accustomed to writing descriptions in the top post and updating the top post as you go along. Otherwise it gets hard to follow the progress!
See here for an example of how to do it ideally.

ready :)?


[FLINK-18676] [FileSystem] Bump s3 aws version

What is the purpose of the change
This pull request bumps AWS SDK version to minimal version supported WebIdentityTokenCredentialsProvider in s3-fs-package, which is described in an issue.
Brief change log

flink-s3-fs-base - bumped aws dependency

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (don't know)
The runtime per-record code paths (performance sensitive): (don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (don't know)
The S3 file system connector: (yes)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

Thanks a lot for opening a pull request to address this. You need to update also the LICENSE files affected by this, as described here https://cwiki.apache.org/confluence/display/FLINK/Licensing (see "I'm changing a Flink dependency, what do I need to do with the LICENSE and NOTICE files?" section)

Hi! I am affected by this issue, any chance of getting this moving @batas?

Maybe I'll take over this pull request. Since the 1.12 release is coming up, it would be nice to address this issue.

Okay, I will indeed take over this PR. I'm closing this one in favor of a new one.


package not being published correctly

hello, if you install latest from npm, you'll see that the dist folder is not present, basically the compiled source code is missing.
the last version that can be used is 0.0.13

I experienced a similar issue as @vonoro
Using version 0.0.13

Same here:

any updates on this one?
latest version is still broken

got it, I am fixing it thanks

@dmytrotkk  @ChristianPerez34  @tomholford  please check out the latest version 0.0.17
somehow, the republish command does not trigger, so enforce it in the CI


⚠ API - Lens has degraded performance

In a8139e0, API - Lens ($LENS_API_URL) experienced degraded performance:

HTTP code: 503
Response time: 361 ms

Resolved: API - Lens performance has improved in cafab1f after 7 minutes.


Fix global window is not defined problem with Nuxt

fix #1
With this workaround so it can be imported directly right now.

Thanks!

@ivanvermeyen
Oops I realized that I forgot to run npm run prod, so dist/collapse-transition.js is still the old one.

Haha, I should have noticed that :)


Remove aurora / pgvector / ECS embeddings for V2

Issue #, if available:
Derived from #520 (Guardrail support)
Description of changes:

Remove followings:

Aurora Serverless
VPC (no longer needed)
Related documents

Add followings:
WIP

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

What is the advantage of using KnowledgeBase vs pgvector?
We are reluctant of upgrading to using KB since we have quite a lot of data on pgvetor but I'd like to see why this project is heading towards that route, if the advantages are big enough, we can follow.

@DTheunis Please refer: migration guide

Create PR again on #561


(Question) Build is always dirty for me

Should there be certain files excluded from consideration for "dirtiness"? I'm not sure how I can avoid ProjectSettings.asset being modified during the build since I am just using the default settings for the action. Although depending on the buildMethod specified, maybe other files like .meta files could change.
I can just keep using allowDirtyBuild for the moment either way though, but curious of your thoughts on how folks should avoid using the parameter

If the file that's always dirty is your project settings and the reason is a mismatch between your local unity editor version and the on used in CI, then you should see the dirty warning as a warranted one; There are only a few million things that could potentially go wrong and it'll be impossible to debug without first synchronising the versions. Goes to https://github.com/webbertakken/unity-builder/issues/95.
If it is dirty because the test runner just ran before the build and the test artifacts are the cause, then the quick fix would be to add the artifacts folder to gitignore, but we can't possibly ask everyone to do that. So for this we need to find a reasonable solution. Progress on this can be tracked in https://github.com/webbertakken/unity-test-runner/issues/58

The editor version I'm using locally and the one I'm specifying for the unity-builder are the same, but good point that it could be a legitimate problem that ProjectSettings changed.  I did ignore artifacts/ so ProjectSettings is the only file that's dirty for me.  From the diff, it seems like maybe the defaults for things like the android build version and things like that are modifying the ProjectSettings.

I don't think that is possible because these things aren't integrated in test-runner and the diff is checked before bootstrapping unity.
I'm closing this question.
Feel free to create a bug if you have reason to believe something is indeed broken. Also feel free to reopen if you have any further questions directly related to this question.

Hmm okay.
ProjectVersion.txt
m_EditorVersion: 2019.4.1f1
m_EditorVersionWithRevision: 2019.4.1f1 (e6c045e14e4e)

GitHub workflow
name: Continuous Build and Test

on:
  pull_request: {}
  push: { branches: [github_actions] }

env:
  UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
  UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
  UNITY_SERIAL: ${{ secrets.UNITY_SERIAL }}

jobs:
  build:
    name: Build and test the game
    runs-on: ubuntu-latest

    steps:

      # Checkout
      - name: Checkout repository
        uses<EMAIL_ADDRESS>        with:
          lfs: true

      # Cache
      - uses<EMAIL_ADDRESS>        with:
          path: Library
          key: Library

      # Test
      - name: Run tests
        uses<EMAIL_ADDRESS>        with:
          unityVersion: 2019.4.1f1

      # Build
      - name: Build project (Windows)
        uses: webbertakken/unity-builder@ec0cde0c85272dcbb5a143a77374830c173346d4 # use logDiff changes
        with:
          unityVersion: 2019.4.1f1
          targetPlatform: StandaloneWindows64 # Build a 64-bit Windows standalone

No custom build or test method.  Build project (Windows) fails due to dirtiness, various changes to my ProjectSettings such as:
-  serializedVersion: 18
+  serializedVersion: 20
 -  runInBackground: 0
+  runInBackground: 1
 -  displayResolutionDialog: 0
+  stadiaPresentMode: 0
+  stadiaTargetFramerate: 0

What could I be doing to change this file? It seems like maybe it's the actions changing the file somehow, but I'm not sure how at the moment.  I haven't tried saving the build artifacts yet to see what effect these changes have, but I really don't want things like "displayResolutionDialog" being changed because we plan to have custom resolution menu in-game.  Maybe I'm missing something. Sorry to spam your repo! I am really enjoying your actions.

@dogboydog Have you ran a build with 2019.4.1f1 on your local machine? Do you have any local changes after the build? (if so commit them)
The other way around you could try to commit these changes and see if a local build overwrites the values. I don't expect it to do it, but if it does, it must be a mismatch of something. In that case the only way to solve it is that people come up with exact steps to reproduce the issue.
It is true that builder runs in the background but it doesn't change any files for the test project or my private project and I haven't heard many people about this before either.
On top of that, why would a simple run of unity (using the same version) add stadioPresentMode? It doesn't look related to this repository.


Issue on Alerting WebHook since 0.24.0 alertmanager version

What did you do?
I noticed a issue or change of behavior on the latest Alertmanager tag: 0.24.0  on the Receiver Webhook
We are using webhook receiver with a proxy configuration.
This configuration was working fine with Alertmanager 0.23.0
We've upgraded to 0.24.0  and got this issue :
level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="webhook/webhook[0]: notify retry canceled after 2 attempts: Post "https://URL/\": Post "https://TOKEN": dial tcp 10.X.X.X:443: connect: connection timed out
Do we need to update the webhook configuration ?
Thanks in advance
regards
  - name: webhook
    webhook_configs:
    - send_resolved: true
      url: "https://URL"
      max_alerts: 4
      http_config:
        proxy_url: "http://PROXY"
        tls_config:
          insecure_skip_verify: true
        oauth2:
          client_id: CLIENT_ID
          client_secret: CLIENT_SECRET
          token_url: https://TOKEN_URL

What did you expect to see?

Alertmanager version:  0.24.0

Prometheus version: 2.35.0

Could you try adding enable_http2: false ?
On 16 May 02:39, sswieton wrote:

What did you do?
I noticed a issue or change of behavior on the latest Alertmanager tag: 0.24.0  on the Receiver Webhook
We are using webhook receiver with a proxy configuration.
This configuration was working fine with Alertmanager 0.23.0
We've upgraded to 0.24.0  and got this issue :
level=error component=dispatcher msg="Notify for alerts failed" num_alerts=1 err="webhook/webhook[0]: notify retry canceled after 2 attempts: Post "https://URL/\": Post "https://TOKEN": dial tcp 10.X.X.X:443: connect: connection timed out
Do we need to update the webhook configuration ?
Thanks in advance
regards
  - name: webhook
    webhook_configs:
    - send_resolved: true
      url: "https://URL"
      max_alerts: 4
      http_config:
        proxy_url: "http://PROXY"
        tls_config:
          insecure_skip_verify: true
        oauth2:
          client_id: CLIENT_ID
          client_secret: CLIENT_SECRET
          token_url: https://TOKEN_URL

What did you expect to see?

Alertmanager version:  0.24.0

Prometheus version: 2.35.0

--
Reply to this email directly or view it on GitHub:
https://github.com/prometheus/alertmanager/issues/2924
You are receiving this because you are subscribed to this thread.
Message ID: @.***>

--
Julien Pivotto
O11y - https://o11y.eu/

Hi,
The param "enable_http2" is defined in the scraping jobs, so, updating it could have a large impact on the solution...
My concern is just limited to the WebHook receiver.
is there an other way to set this param ? in the receiver for ex ?
thanks
Whether to enable HTTP2.
[ enable_http2:  | default: true ]

This should be settable in the webhook receiver, that's what I am talking about

ok.  this is not documented in Alertmanager receiver spec. I guess this is the correct schema to use
Thanks
regards
 - name: webhook
    webhook_configs:
    - send_resolved: true
      enable_http2: false
      url: "https://URL"
      http_config:
        proxy_url: "http://PROXY"
        tls_config:
          insecure_skip_verify: true
        oauth2:
          client_id: CLIENT_ID
          client_secret: CLIENT_SECRET
          token_url: https://TOKEN_URL

mmh indeed we would need to first update the alertmanager, it's not supported yet.
So you coul try setting the env variable:
PROMETHEUS_COMMON_DISABLE_HTTP2=1

We deploy in Production, so, not possible to integrate this fix.
Back to Alertmanager 0.23.0 waiting for the fix regarding this issue
Thanks


Restarting after changing the display language doesn't restart

Install a language pack
Change the display language
Get a modal dialog saying you have to restart
Choose the restart button.
VS Code closes, but doesn't reopen. It must be manually started.

This is on Windows with a system install.

I'm just calling the NativeHostService::restart() of whatever that abstraction is the restart vscode.
I'm gonna hand this off to maybe @bpasero for electron advice... but I wonder if it'll be good to know if:

there's a lingering process preventing the full restart
if a vscode update works fine
if change a setting that requires restart works fine

@alexr00 if you have log level set for an extension, ex: --log github.vscode-pull-request-github:debug in command args, remove them and it should address the issue.
Merging to https://github.com/microsoft/vscode/issues/188769

The log level is more important to me than the restart so I'll just live with the bug for now.


Rename the member functions of the EnrollmentManager

The names of add and remove functions were really confusing because the name didn't tell whether it's for the EnrollmentPool or the ValidatorSet. So I make the name clearer. As a result, we have three functions for the EnrollmentPool; hasEnrollment, addEnrollment, and removeEnrollment.

Ready for review.
It's a simple change for naming functions more properly.


<EMAIL_ADDRESS>All-Around results not generated

Trying to look up events in the v1.1.0 config using the v2.0.0 all-around abbreviation

fixed in 3daf0842be512faa8c4f2fd33f5b8b735065561c


Fail to create project- npx create react app laravel

Can't create project.. it says,
Could not create a project called "React" because of npm naming restrictions:
  *  name can no longer contain capital letters

I had a fairly similar issue too


fix minor typos

Very, very minor typos I noticed.

Thanks for catching them.

Thanks @fat-tire , nice to see you here again.


[SPARK-14783] Preserve full exception stacktrace in IsolatedClientLoader

In IsolatedClientLoader, we have acatch block which throws an exception without wrapping the original exception, causing the full exception stacktrace and any nested exceptions to be lost. This patch fixes this, improving the usefulness of classloading error messages.

Test build #56440 has started for PR 12548 at commit 7a850b6.

Test build #56440 has finished for PR 12548 at commit 7a850b6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/56440/
Test PASSed.

Merged build finished. Test PASSed.

Merging to master.

nice


Programmatic schema migration (cassandra)

Creating and updating the database schema (cassandra) manually is onerous and error prone.  Creating a programmatic method for schema migration would help significantly in reducing human error and improve interaction with continuous build and delivery systems.

code for this is on the same branch in progress as #5

openzipkin/zipkin#459


could update "aldeed:template-extension" to last version?

I clone, and update via PR to fix (https://github.com/shkomg/meteor-autoform-select2).
but when I update aldeed:template-extension to last version 4.0.0, It don't work.
Please helpme.

Will be fixed in next release


Pinned Github Actions dependencies

Main Changes
Pinned missing Github Actions dependencies
Context
Full Report

Changelog

159ba96 chore: pinned Github Actions dependencies by @UlisesGascon

I am not sure how this change affects the failing pipeline. Can you re-run it? 🤔


Option to create links to google documents instead of converting it

When syncing with Google Drive, would it be possible to add an option so that links to google documents are created instead of converting the files? Double clicking on the file should then open the browser with the relevant file. I believe this is how it works when using the official Drive client by Google. This should be similar to how "--drive-skip-gdocs" works.

How does that actually work?  What type of file is created and what is in it?  I suspect this intercepted by the google drive client somehow.

Yes, the Google Drive client creates a file called "WorkbookName.gsheet". Inside is simple json, something like this:
{"url": "https://docs.google.com/open?id=aaabbbccc",
"doc_id": "aaabbbccc",
"email"<EMAIL_ADDRESS>"resource_id": "document:aaabbbccc"}

My suggestion is to create a similar file that natively opens the link in the browser. It's not ideal to edit my Google documents in Libre office and uploading it back to Google Drive.
What do you think?

The solution/alternative that odeke-em/drive client does is to create a .desktop for all google docs with this fields:
Type=Link
URL=https://drive.google.com/...

I guess that it's the same idea, but for Linux.
This also works for other Drive but not Docs files like Zoho's ones, etc...
I'm movimng from odeke-em/drive to rclone and I'm missing this feature... so +1 to this feature!!
Thanks!

:+1:  for this, as this is how the official Google Drive Stream client behaves on Windows. Would be great if this client behaved the same way! I am now looking for some good working alternative to Google Drive Stream, but not yet successfully because of this :(

Does anyone want to work on this issue?
I'm happy to talk people through what needs to be done.

I have looked a bit into this issue while working on Google documents uploads.
It seems like there are different concepts of link files:
Windows and macOS have .url files.
[InternetShortcut]
URL=https://rclone.org/

Source: stackoverflow
macOS also has .webloc files.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>URL</key>
    <string>https://rclone.org/</string>
</dict>
</plist>

Source: stackoverflow
Linux has .desktop files.
[Desktop Entry]
Encoding=UTF-8
Name=rclone.org
URL=https://rclone.org/
Icon=text-html

Source: stackoverflow
A simple cross platform solution could use .html files:
<html>
<head>
<meta http-equiv="refresh" content="0; url=https://rclone.org/" />
</head>
</html>

Source: stackoverflow
To be cross platform compatible we should implement at least .html files and probably .url and .desktop files for native users.
I will try to integrate this into my current work at uploading documents.

Comment history:
Part 1: https://github.com/cjnaz/RCloneSync/issues/22
Part 2: https://github.com/cjnaz/rclonesync-V2/issues/1
Part 3: https://github.com/ncw/rclone/issues/2413
In short: Not having this option completely breaks Google Drive sync for me (which I need for other programs). RClone sees Google documents as having file size -1 and doesn't properly copy back and forth, that messes up RCloneSync, which fails to build a file index that is needed for two-way sync.

@Fabian42 there is always this flag
  --drive-skip-gdocs                      Skip google documents in all listings.

which will make syncs work properly just skipping the google docs.

There has been progress for this issue:
#2479 is a work in progress rewrite of the drive documents handling.
If anyone wants to help testing the new implementation, there is a beta branch containing the changes: https://beta.rclone.org/branch/v1.42-162-g6a66967c-drive-documents/
Keep in mind this is not tested thoroughly yet and therefore be considered experimental.
Please post any feedback in #2479. Updated releases will also be anounced there.

#2479 has been merged lately.
This feature can be used since https://beta.rclone.org/v1.43-112-ga20fae03-beta/, the latest beta and in v1.44


Convert multi-assignments to separate assignments

Most of our code uses separate assignment statements, such as:
String a = "something";
String b = "something else";

However, some of our code uses multi-assignments, like:
String a = "something", b = "something else";

This is less than ideal style, and these should be changed to separate assignments wherever it makes sense to do so, throughout the code. There may be some places, such as in for loop initialization, where we want to keep the multi-assignment, but most places we don't.

This should only be done in the main branch. It doesn't need to be done for earlier branches. It's also low-priority.


nr/androidTests-fixes

Proposed Changes

Update failing tests from android sources
Ignore one more focus test. ScrollableFocusableInteractionTest tests should be handled. There are a lot of ignored ones from previous merge.

Testing
Test: run tests in copyPasteAndroidTests
Issues Fixed
No issues related to this PR

I tried to investigate test in ScrollableFocusableInteractionTest. It works on application example, but test fails, so need deeper investigation. Maybe with other ignored tests here

Created an issues for 1.6:
https://github.com/JetBrains/compose-multiplatform/issues/2965


Proposal for preserving state of the experiment.

You want to make a PR to Talos
Thanks so much :) First, please take a moment to carefully check through
the below items:
Sanity

[ ] I'm aware of the implications of the proposed changes
[ ] Code is PEP8
[ ] I'm making the PR to master

Docs

[ ] Docs are updated
[ ] Docs version is correct (index.html and _coverpage.md)

Tests

[ ] Changes have gone through actual use testing
[ ] All local tests have passed (run ./test.sh in /talos)
[ ] Tests have been updated to reflect the changes

Hello @mikkokotila! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file talos/parameters/ParamSpace.py:

Line 216:31: E261 at least two spaces before inline comment
Line 291:1: W293 blank line contains whitespace
Line 291:1: W391 blank line at end of file

In the file talos/scan/scan_prepare.py:

Line 6:80: E501 line too long (80 > 79 characters)
Line 15:80: E501 line too long (84 > 79 characters)
Line 36:80: E501 line too long (93 > 79 characters)

In the file talos/scan/scan_run.py:

Line 17:25: E128 continuation line under-indented for visual indent
Line 21:33: E127 continuation line over-indented for visual indent
Line 22:33: E127 continuation line over-indented for visual indent
Line 42:80: E501 line too long (91 > 79 characters)
Line 46:80: E501 line too long (83 > 79 characters)

In the file talos/scan/scan_utils.py:

Line 18:16: E231 missing whitespace after ':'
Line 18:18: E251 unexpected spaces around keyword / parameter equals
Line 54:19: E231 missing whitespace after ':'
Line 54:21: E251 unexpected spaces around keyword / parameter equals
Line 64:80: E501 line too long (80 > 79 characters)
Line 91:19: E231 missing whitespace after ':'
Line 91:21: E251 unexpected spaces around keyword / parameter equals
Line 101:80: E501 line too long (82 > 79 characters)

What do you think, what is the simplest way in which we can achieve this same? Ideally, we would not have to add anything except a point at each round, on which a local file is updated.


Get Permission Status

Describe the solution you'd like
I think you should add the getPermissionStatus() function when denied to be able to check and show a dialog that navigates to app settings

What exactly should the function itself do, and what should the function enable developers to get done?
If the responsibility of the proposed function should be to only check whether permissions have been granted, and the logic of showing a dialog and navigating to system settings when denied will be outside the scope of this function, try the following instead:
hasPermissions returns a bool indicating if permissions have been granted.
In case the proposed function should also handle the dialog and navigation to system settings, how do you imagine handling different locales?


improve auth@edge error handling

Parameter existence check is executed after attempt to parse. I suggest to the parsing after the validation in order to provide the client a better error message
https://github.com/onicagroup/runway/blob/2b4274df5b7aa177180eb90cc8ae7a4c8f1c65ca/runway/hooks/staticsite/auth_at_edge/templates/parse_auth/__init__.py#L49

Staticsite auth capabilities to be removed.


Cannot access list elements

code:
[1, 2, 3]@[0];

error:
1: [1, 2, 3]@[0];

SyntaxError: Expected ';'

I know why this occurs. I will fix this ASAP!!


Question about config that allows villagers enter trains but not move them

BkCommonLib version: newest snapshot 1.14.4-v2
TrainCarts version: newest snapshot 1.14.4-v2
Spigot version: paper 332

Problem or bug:
DefaultTrainProperties.yml:
default:
  soundEnabled: true
  displayName: ''
  allowPlayerTake: true
  requirePoweredMinecart: false
  trainCollision: true
  collisionDamage: 1.0
  keepChunksLoaded: false
  speedLimit: 0.4
  waitDistance: 0.0
  suffocation: true
  killMessage: ''
  banking:
    strength: 0.0
    smoothness: 10.0
  slowDown: true
  allowManualMovement: true
  tickets: []
  collision:
    players: DEFAULT
    misc: ENTER
    train: LINK
    block: DEFAULT
  blockTypes: ''
  blockOffset: unset
  owners: []
  ownerPermissions: []
  tags: []
  allowPlayerEnter: true
  allowPlayerExit: true
  invincible: false
  isPublic: true
  pickUp: false
  exitOffset:
    ==: Vector
    x: 0.0
    y: 0.0
    z: 0.0
  exitYaw: 0.0
  exitPitch: 0.0
  driveSound: ''
  blockBreakTypes: []
  destination: ''
  enterMessage: ''
  spawnItemDrops: true
admin:
  soundEnabled: true
  displayName: ''
  allowPlayerTake: false
  requirePoweredMinecart: false
  trainCollision: true
  collisionDamage: 1.0
  keepChunksLoaded: false
  speedLimit: 0.4
  waitDistance: 0.0
  suffocation: true
  killMessage: ''
  banking:
    strength: 0.0
    smoothness: 10.0
  slowDown: true
  allowManualMovement: false
  tickets: []
  collision:
    players: DEFAULT
    misc: ENTER
    train: LINK
    block: DEFAULT
  blockTypes: ''
  blockOffset: unset
  owners: []
  ownerPermissions: []
  tags: []
  allowPlayerEnter: true
  allowPlayerExit: true
  invincible: false
  isPublic: true
  pickUp: false
  exitOffset:
    ==: Vector
    x: 0.0
    y: 0.0
    z: 0.0
  exitYaw: 0.0
  exitPitch: 0.0
  driveSound: ''
  blockBreakTypes: []
  destination: ''
  enterMessage: ''
  spawnItemDrops: true
spawner:
  soundEnabled: true
  displayName: ''
  allowPlayerTake: false
  requirePoweredMinecart: false
  trainCollision: true
  collisionDamage: 1.0
  keepChunksLoaded: false
  speedLimit: 0.4
  waitDistance: 0.0
  suffocation: true
  killMessage: ''
  banking:
    strength: 0.0
    smoothness: 10.0
  slowDown: true
  allowManualMovement: false
  tickets: []
  collision:
    players: DEFAULT
    misc: ENTER
    train: LINK
    block: DEFAULT
  blockTypes: ''
  blockOffset: unset
  owners: []
  ownerPermissions: []
  tags: []
  allowPlayerEnter: true
  allowPlayerExit: true
  invincible: false
  isPublic: true
  pickUp: false
  exitOffset:
    ==: Vector
    x: 0.0
    y: 0.0
    z: 0.0
  exitYaw: 0.0
  exitPitch: 0.0
  driveSound: ''
  blockBreakTypes: []
  destination: ''
  enterMessage: ''
  spawnItemDrops: true

config.yml
#> This is the configuration file of TrainCarts
#> In here you can tweak TrainCarts to what you want
#> For more information, you can visit the following websites:
#> http://www.minecraftwiki.net/wiki/Bukkit/TrainCarts
#> http://forums.bukkit.org/threads/traincarts.29491/

# Path or online download URL to the resource pack to use
# Using 'server' makes it use server.properties (default)
# Using 'default' or empty makes it use no resource pack at all
resourcePack: server

# Properties of the link between the carts of a train
linkProperties:
  # The distance between two carts in a train
  cartDistanceGap: 0.5
  # The distance between two carts above which they lose linkage and disconnect
  cartDistanceGapMax: 2.5
  # Factor at which the gap is maintained, based on train velocity
  cartDistanceForcer: 0.1
  # Factor at which the gap is maintained, always active
  # When set to nonzero, will cause carts to move at standstill
  cartDistanceForcerConstant: 0.0

# Whether or not the combined carts (powered/storage minecarts) break up into two items
breakCombinedCarts: false

# A performance boost to give to powered minecarts (0 = normal speed)
poweredCartBoost: 0.1

# The boosting factor of powered rails (default = 0.06)
poweredRailBoost: 0.06

# The maximum velocity (blocks/tick) a minecart can possibly have set
maxVelocity: 5.0

# The multiplier used to slow down minecarts
# Normal is the default, slow is when the minecart is meant to slow down.
slowDownMultiplier:
  normal: 0.997
  slow: 0.96

# The maximum allowed enter radius for enter signs
maxEnterDistance: 50.0

# The maximum allowed ejection distance for eject signs
maxEjectDistance: 10.0

# The amount of velocity stations give when launching trains
launchForce: 10.0

# Destroys all existing minecarts on startup and shutdown of the plugin
destroyAllOnShutdown: false

# Settings used when carts collide with entities
collision:
  # If train owners are ignored
  ignoreOwners: false
  # If global train owners are ignored
  ignoreGlobalOwners: false
  # The amount of force at which minecarts push away others
  pushAwayForce: 0.2

# Whether or not all minecarts spawned on the server turn into TrainCarts' Minecarts
# Note that the TrainCart placement permission is then no longer active
allMinecartsAreTrainCarts: false

# Whether or not powered minecarts obtain their coal from attached storage minecarts
useCoalFromStorageCart: false

# Whether or not the player that places a minecart is set owner
setOwnerOnPlacement: false

# Whether or not a hissing sound is made when trains stop at a station
playSoundAtStation: true

# What style of launching to use in stations and launcher sign systems by default. Possible values:
# - 'linear': gradually switches from one motion speed to another at a linear rate
# - 'bezier': uses a bezier curve (ease in-out), resulting in slower changes in motion at start/end of launch
launchFunction: bezier

# Whether or not chunks are only kept loaded when the train is moving
keepChunksLoadedOnlyWhenMoving: false

# Whether to enable or cancel collisions with blocks above minecarts
# Some constructions depend on these block collisions to block minecarts
# If these collisions are unwanted, they can be turned off here
enableCeilingBlockCollision: true

# Advanced: Whether trains use a different way of server->client synchronization
# With this enabled, trains are expected to move smoother with less bumping
# With this disabled, no smoothing is applied. Only disable it if it causes problems/incompatibility
useNetworkSynchronizer: true

# Enable or disable seeing yourself in third-person on vertical rails
# Turning this off only causes this mode to activate when going upside-down
enableSeatThirdPersonView: false

# The maximum length a detector region (between two detectors) can be
maxDetectorLength: 2000

# The maximum amount of minecart items that can be stacked in one item
maxMinecartStackSize: 64

# The maximum radius chest/furnace sign systems look for the needed blocks
maxTransferRadius: 5

# The default radius chest/furnace sign systems look for the needed blocks
defaultTransferRadius: 2

# Whether or not empty minecarts slow down faster than occupied minecarts
slowDownEmptyCarts: false

# Whether storage minecarts get fuel when launching from stations
refillAtStations: true

# Whether destroying or entering minecarts is made easier to do
# When optimized, block / air clicks are intercepted and handled as clicks with minecarts instead
optimizeInteraction: true

# When set to true, players will be able to break minecarts with a single slap
#
# No item drops are spawned for minecarts destroyed this way. Minecart contents ARE dropped.
# They can still select minecarts by crouching and then slapping the minecart
#
# When set to false, players will never instantly destroy minecarts and they will have to break it as if in survival.
instantCreativeDestroy: true

# Whether upside-down rail functionality is enabled on the server
# When disabled, minecarts can not be rotated upside-down
allowUpsideDownRails: true

# Before TrainCarts v1.12.2-v1 speed limiting was done on each individual axis
# This had a big impact on air physics, because it never made a good ellipse fall
# This was changed to preserving the motion vector direction when doing speed limiting
# Slight changes may have occurred in curves, slopes and through-air physics
# To restore the old limiting system, set this option to True
legacySpeedLimiting: false

# Whether players (with build permissions) can edit existing rails by right-clicking on them
allowRailEditing: true

# Velocity factor to apply when a player tries to move a cart using movement controls
manualMovementFactor: 0.1

# The currency Ticket signs will display in messages, %value% represents the displayed value
currencyFormat: '%value% Dollars'

# Whether trains can be teleported to the nether (or back) when rails are laid close to the portals
allowNetherTeleport: true

# The delay (in ticks) between ejecting and re-entering by collision (e.g. mobs auto-entering carts)
collisionReEnterDelay: 100
# Whether powered activator rails eject players inside Minecarts (Vanilla)
# If activator rails are used for decoration purposes, this should be disabled
activatorEjectEnabled: true

# A list of world names where TrainCarts should be disabled
# World names are not case-sensitive
disabledWorlds:
  - DefaultWorld1
  - DefaultWorld2

# The block materials that can be broken using minecarts
# Players with the admin block break permission can use any type
# Others have to use one from this list
allowedBlockBreakTypes:
  - LEGACY_CROPS
  - LEGACY_LOG

# Whether or not to show item animations when transferring items
showTransferAnimations: true

# Whether a crafting table must exist when crafting items inside a storage minecart
# When this is set to false and no crafting table is nearby, no item transfer animations are shown
craftingRequireWorkbench: true

# Several shortcuts you can use on announce signs (text is replaced)
messageShortcuts:
  welcome: &eWelcome to &f

# Several shortcuts you can use on switcher and detector signs (text is replaced)
statementShortcuts:
  diamond: i@diamond

# Several shortcuts you can use on signs to set the items
itemShortcuts:
  fuel: ''
  heatable: ''
  armor: golden_helmet;golden_leggings;diamond_helmet;legacy_chainmail_helmet;legacy_leather_leggings;legacy_leather_chestplate;legacy_leather_boots;legacy_iron_boots;iron_chestplate;legacy_gold_chestplate;legacy_diamond_chestplate;iron_boots;legacy_diamond_boots;legacy_gold_helmet;leather_leggings;diamond_chestplate;legacy_iron_chestplate;leather_chestplate;legacy_leather_helmet;diamond_boots;legacy_diamond_leggings;golden_chestplate;chainmail_chestplate;golden_boots;turtle_helmet;chainmail_boots;legacy_gold_leggings;chainmail_helmet;chainmail_leggings;legacy_iron_helmet;legacy_gold_boots;diamond_leggings;legacy_chainmail_leggings;legacy_chainmail_chestplate;leather_boots;iron_helmet;legacy_chainmail_boots;legacy_iron_leggings;legacy_diamond_helmet;iron_leggings;leather_helmet
  sword: wooden_sword;stone_sword;iron_sword;golden_sword;iron_sword;diamond_sword;legacy_wood_sword;legacy_stone_sword;legacy_iron_sword;legacy_gold_sword;legacy_iron_sword;legacy_diamond_sword
  boots: leather_boots;iron_boots;golden_boots;diamond_boots;chainmail_boots;legacy_leather_boots;legacy_iron_boots;legacy_gold_boots;legacy_diamond_boots;legacy_chainmail_boots
  leggins: leather_leggings;iron_leggings;golden_leggings;diamond_leggings;chainmail_leggings;legacy_leather_leggings;legacy_iron_leggings;legacy_gold_leggings;legacy_diamond_leggings;legacy_chainmail_leggings
  chestplate: leather_chestplate;iron_chestplate;golden_chestplate;diamond_chestplate;chainmail_chestplate;legacy_leather_chestplate;legacy_iron_chestplate;legacy_gold_chestplate;legacy_diamond_chestplate;legacy_chainmail_chestplate
  helmet: leather_helmet;iron_helmet;golden_helmet;diamond_helmet;chainmail_helmet;turtle_helmet;legacy_leather_helmet;legacy_iron_helmet;legacy_gold_helmet;legacy_diamond_helmet;legacy_chainmail_helmet

# Enables parsing signs with (train), as well as [train]
# This makes it easier to write signs with a Mac keyboard layout
parseParentheses: true

# Requires all neighbouring chunks to be loaded too before
# initializing the redstone state (powered or not) of signs in a chunk
# True can prevent crashes and helps performance by avoiding recursive chunk loads
# False will make sure signs initialize sooner and respond to redstone faster
initRedstoneWithRadius: true

# Sets whether only powered switcher signs without statements on them
# actively switch tracks to lead trains towards their destination
# When true, only [+train] switcher signs do pathfinding logic
# When false, the original behavior is used, where any switcher sign handles path finding
# False will allow switching of trains overriding standard path finding
onlyPoweredEmptySwitchersDoPathfinding: false

# Default attachment animations that can be applied to the base of all trains
defaultAnimations:
  rotate:
    nodes:
      - t=0.25
      - t=0.25 yaw=90.0
      - t=0.25 yaw=180.0
      - t=0.25 yaw=270.0
      - t=0.0 yaw=360.0
  roll:
    nodes:
      - t=0.25
      - t=0.25 roll=90.0
      - t=0.25 roll=180.0
      - t=0.25 roll=270.0
      - t=0.0 roll=360.0
  pitch:
    nodes:
      - t=0.25
      - t=0.25 pitch=90.0
      - t=0.25 pitch=180.0
      - t=0.25 pitch=270.0
      - t=0.0 pitch=360.0

# Sets whether attachment animations use tick time or wall clock time
# When false, wall clock time is used, and server lag will not slow down/speed up animations
# When true, tick time is used, and server lag will cause speed changes. Animations do stay in sync with physics
animationsUseTickTime: false

# Sets whether the player can move around by holding shift in the attachment editor
enableSneakingInAttachmentEditor: false

# Sets the interval at which all the properties of all trains on the server are saved to disk
# This saving may have a negative performance impact, as seen in the AutoSaveTask in timings
# If you do not worry about preserving this information, you can raise this interval
# A manual save can be performed using /train saveall
autoSaveInterval: 600

# Sets whether players automatically claim new saved trains that they save
# Once claimed, other players cannot overwrite the saved train, effectively protecting it
# Setting this to false will have new trains exist in public domain, and anyone can modify it
# The original owner can put the train in public domain by disclaiming it (/savedtrain [name] disclaim)
# Players (moderators) with the train.command.savedtrain.global permission are exempt
claimNewSavedTrains: false

# The hastebin server which is used to upload saved trains
# This will be used when using the /savedtrain [name] paste command
hastebinServer: https://paste.traincarts.net

# Parse signs made in Minecraft 1.7 and before without re-creating
parseOldSigns: false

This settings allows mobs to enter trains but it won't stand still (occupied cart will move and finally disconnect). It is possible to configure that correctly?
Expected behaviour:
Pushed entities will enter empty train carts but whole train should stand still and accupied carts shouldn't disconnect.
Steps to reproduce:
I've pasted my config, just place long track, few carts and push villager into the cart.
Have a nice day.

What version is paper 332?
Can you show a video of what's happening?

I'll upload video in next 24h.
Paper 332 is 1.14.4.

Mistake - not paper 332, it's 233
video: https://streamable.com/031kx
(sorry for lags, hosting is terrible)

Oh wow that looks messed up... can you confirm that this does not occur when you summon a villager with no AI?

I haven't summoned any with no AI. These are from MC 1.14.4 (previous was wiped up, created couple from eggs, then they populated normally). Should I try one Villager with no AI? If yes, tell me how to do that, thanks.

Use the following command
/summon villager ~ ~1 ~ {VillagerData:{profession:farmer,level:2,type:plains},NoAI:1}

Are you able to confirm it still occurs with the latest snapshot of both bk and tc? Provide the build number you tested with if it still occurs.

https://www.dropbox.com/s/okrwe3cw6spdxfz/2020-02-14 19-29-40.mkv?dl=0
Same version as described above, I've tested it on live server and will test it as soon as optifine for 1.15.2 releases.
About video - Villager with disabled AI don't move train. But albo prevents me to do manual movement.

Thanks for the update, we will make sure to look into this immediately once we have time.

Wait so, villagers can 'steer' minecarts like humans do? Is that what Im getting from this?

I can confirm this issue exists. Bizar as it may be, lol. Had a train take off the moment I did /train manualmove true

https://github.com/bergerhealer/TrainCarts/commit/c9b2f2298c6320718f603794402aeda2491f9118
Mobs now no longer control trains when manual movement is enabled. If for whatever mysterious reason do want that behavior to exist, there is a separate 'mobmanualmove' property.
https://ci.mg-dev.eu/job/TrainCarts/581/


Mailer is encoding char = as =3D

Laravel Version: 9.22.1
PHP Version: 8.1.4
Database Driver & Version:

Description:
When sending an email, laravel is encoding the char = to =3D, it is a problem when sending HTML emails since it is not rendered properly
Steps To Reproduce:

clone repository
php composer.phar install
copy .env and set MAIL_MAILER=log
php artisan key:generate

php artisan tinker
Mail::raw('Hello=hola', function ($message) { $message->to('a@example.com')->subject('english=spanish');});
laravel.log

[2022-07-29 23:33:49] local.DEBUG: Laravel<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Subject: english=spanish
MIME-Version: 1.0
Date: Fri, 29 Jul 2022 23:33:49 -0300
Message-ID<EMAIL_ADDRESS>Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hello=3Dhola

One repo example:
https://github.com/bernardo-campos/testing-laravel-packages

This would be an issue with symfony mailer as that's used under the hood to send the mail. Feel free to open an issue on their repo.


client: add timeout to submit_transaction

Saw #2089 and it sort of sounds like something I saw while converting client to tonic which was fixed when I added back a timeout (which existed with the old grpcio client but I had missed adding back in the conversion). Maybe this will address the issue with faucet hanging?

ah rad, good find, will try this out for next push
@bors-libra r+

:pushpin: Commit 445d1ea has been approved by opsguy

:hourglass: Testing commit 445d1ea1d80bc8aa7573253bbb6af0a755e8aa32 with merge b00f706e204327147a4ab52c479882601b0accf2...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: opsguy
Pushing b00f706e204327147a4ab52c479882601b0accf2 to master...


6/2 Ting-fen Lin review:

The information can be easily deployed on the website. With its reproducibility, this information can benefit many others when they are searching for similar information online. Additionally, the information is well organized. It’s easy to follow.
I like how you are using simple codes to do powerful work!
I’m not sure if showing the plots on the knitted html can be helpful. If not, please feel free to just ignore this comment.

Nice job, Ting-fen.


Delayed job - add exclude queue name and support for ActiveRecord 2

New options called exclude_queue_name which gets all data for DJ except the specified queue
Added support for ActiveRecord 2

:+1:

:+1: Looks good to me.

:+1: LGTM, too!


real-time problem

hello
I'v runned the script demo.py  (I turned off draw option when call detector.feed_forward) using your pre-trained model BlitzNet300_COCO+VOC07+12 on our GPU Tesla P100. but I found that only 12 fps when feed 300x200 pictures to the model. Your article "BlitzNet: A Real-Time Deep Network for Scene Understanding", However, shows that It can reach 24 fps on GPU Titan X.  Actually, the performance of Tesla P100(4.7 ~ 5.3 TFLOPS) is better than Titan X(up to 0.355 TFLOPS), Why?

Run the code for benchmark, please. It's benchmark.py. For more details refer to #7


squid:S1319 - Declarations should use Java collection interfaces such…

This pull request is focused on resolving occurrences of Sonar squid:S1319 - Declarations should use Java collection interfaces such as "List" rather than specific implementation classes such as "LinkedList"
You can find more information about the issue here: https://dev.eclipse.org/sonar/coding_rules#q=squid:S1319
Please let me know if you have any questions.
M-Ezzat

I will close this as most of the cases are just variables and fields. In general, we are taking care of exposing just interfaces in the API


Proper function DML support

In order to support the Networking Module RFC (https://github.com/edgedb/rfcs/blob/master/text/1026-net-module.rst), I think we need to support functions that contain DML.
Currently there is a flag that allows it, but it doesn't work very well. The DML is actually contained inside the postgres function, and it doesn't work very well. In particular, it can be potentially optimized away and also can't properly return the created object.
I think the correct approach here is to support them by inlining functions that contain DML.
I'm filing this now as a tracking issue but there are some serious semantic questions to answer.

The semantic question:
Imagine a function like:
function make_user(name: str) -> User using (insert User { name := name })

The behavior of select make_user('Bob') is clear, but how about select make_user(<str>{}) or select make_user({'foo', 'bar'}).
I think we really do not want to have the number of inserts done be implicitly determined by the cardinality of the argument (we firmly disallow that sort of thing with DML currently).
I think the alternative is rejecting those queries with a cardinality error, which requires making DML containing functions have a very different argument matching behavior than regular ones.
Sigh. I think the second choice is the right one but it means more design to be done.

I think we really do not want to have the number of inserts done be implicitly determined by the cardinality of the argument (we firmly disallow that sort of thing with DML currently).

How is this different from DML in a for over a set with variable cardinality?

Because the FOR makes it explicit.
On Wed, Aug 28, 2024, 16:52 Elvis Pranskevichus @.***>
wrote:

I think we really do not want to have the number of inserts done be
implicitly determined by the cardinality of the argument (we firmly
disallow that sort of thing with DML currently).
How is this different from DML in a for over a set with variable
cardinality?
—
Reply to this email directly, view it on GitHub
https://github.com/edgedb/edgedb/issues/7692#issuecomment-2316427761,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACTC7POKMLTNSYQ6NYSC3TZTZPB7AVCNFSM6AAAAABNI7MO3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJWGQZDONZWGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

We should write some docs but this is done, right?

@msullivan Yeah, I would say so. Just tidying some stuff up with the volatility before starting on the docs.