Loading from P12 broken on Python 3

Loading credentials from a P12 file via oauth2client.service_account.ServiceAccountCredentials.from_p12_keyfile is broken in Python 3. The relevant portion of the stacktrace is:
...
  File "/usr/local/lib/python3.4/dist-packages/oauth2client-3.0.0-py3.4.egg/oauth2client/service_account.py", line 334, in from_p12_keyfile
    token_uri=token_uri, revoke_uri=revoke_uri)
  File "/usr/local/lib/python3.4/dist-packages/oauth2client-3.0.0-py3.4.egg/oauth2client/service_account.py", line 291, in _from_p12_keyfile_contents
    private_key_password)
  File "/usr/local/lib/python3.4/dist-packages/oauth2client-3.0.0-py3.4.egg/oauth2client/_openssl_crypt.py", line 119, in from_string
    pkey = crypto.load_pkcs12(key, password).get_privatekey()
TypeError: must be str, not bytes

I've followed the stacktrace to _openssl_crypt.py's OpenSSLSigner.from_string method and noticed that the password defaults to bytes and is also converted to bytes (if it isn't already). This results in the TypeError when it is passed along to get the private key.
The issue appears to be resolved if we don't force the password to be bytes, e.g.:
    @staticmethod
    def from_string(key, password='notasecret'):
        key = _helpers._to_bytes(key)
        parsed_pem_key = _helpers._parse_pem_key(key)
        if parsed_pem_key:
            pkey = crypto.load_privatekey(crypto.FILETYPE_PEM, parsed_pem_key)
        else:
            pkey = crypto.load_pkcs12(key, password).get_privatekey()
        return OpenSSLSigner(pkey)

I've verified that this works in Python 3, and doesn't seem to introduce any issues to Python 2.

This is a surprise, since this project has system tests which check if a P12 key works that run on every checkout.

@msaniscalchi ASIDE: Why are you still using PKCS12/P12 keys? Google hasn't endorsed / supported them for years and JSON keys have much more information in them.

Because I own the Google Ads Python Client Library, which is only now in the process of transitioning from 1.4.12 to the latest version due to... reasons. :-)
While we will recommend JSON key files going forward, we plan to support both for the time being.

Gotcha. Well P12 support has not been DERP-recated yet in this library so hopefully someone can help sort it out.

Thank you for creating this issue, however, this project is deprecatedand we will only be addressing critical security issues. You can read moreabout this deprecation here.
If you need support or help using this library, we recommend that you ask yourquestion on StackOverflow.
If you still think this issue is relevant and should be addressed, pleasecomment and let us know!


Make Solver Strategy and Music Choosable

Add a control to the welcome screen that lets the user choose from  a list of solvers to solve the "how-to-place-the-buildings" problem.

Add checkbox to choose music is played or not.

solved with COG-19


updated Readme.md - added project building step

updated Readme.md - added project building step

Please merge latest upstream branch and open a new pull request


container/encapsulate: Fix pushing to OCI directories with a tag

We need to support e.g.
rpm-ostree compose container-encapsulate --format=oci manifest.yaml oci:foo:42

@lukewarmtemp mind reviewing/approving this one?

@lukewarmtemp you need to accept the invitation to the org

@cgwalters I joined the org, good to merge.


Added SQLite support

Cause of my MySQL configuration, I don't know why but it drops VulcanDatatabase's connection (only to this plugin), and flat files of Vulcan have a horrible performance, so I made it compatible with SQLite and make the PR if you want to add it in the future, and therefore save you work.
I think this could work, I have to make connection not final to modify it, because if I try to put connection = null on catch clause, the IDE forces me to use a temp variable (connection1), I think you understood me, didn't you?
On the other side, I have tested it on my network and it works correctly, but I think anyway to will test it :)


Fix test commands

Coverage remained the same at 93.493% when pulling 06183635f58365278bca88ebbad929f55c9cc72f on shinderohitt:patch-1 into 848f9c3edfbfbfa0903f4dd76ee2fec1cfb12224 on webonyx:master.

Thanks!


AddFeedRangeSupportInChangeFeed

Description:
In this PR, we added support for getting the feedRanges of the container and added support for getting change feed by using feed ranges.

Getting feed ranges from container
feedRange - represents a set of co-located logical partitions. For each container, customer will be able to get a list of feedRanges(each representing a hash-range of single physical partition). For query(future) and changeFeed(in this PR), SDK will allow customers to config a feedRange(can map to a single physical partition, span of multiple physical partitions or a subset of single physical partition) to filter the results.

Examples:
created_collection.read_feed_ranges()
await created_collection.read_feed_ranges()

Adding feed range support in change feed query

There are few issues with current changeFeed query API:

It allows customer to pass in a physical partition id for filtering the results, however there is no official public contract exists today for customer to acquire the physical partition id.
Physical partition id is an internal concept which from SDK perspective, we would like to keep as internal implementation details.
Currently, the continuation token being returned is simple _lsn, which is not split/merge proof. A new format continuation token will need to be returned
Does not support all change feed mode(Not included in this PR, will add in following PR)

Based on the above considerations, except adding feedRange support, we are also going to deprecate partition_key_range_id parameter. The API will be changed into the following:

The new continuation token format:

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-cosmos

/azp run python - cosmos - tests

azp run python - cosmos - tests

azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - ci

Failed tests are not caused by the change in the PR:
test_user_agent_suffix_special_character
test_wrong_queries

/check-enforcer override


fix: generate BigInt type as bigint

The type of BigInt in Typescript is bigint (not BigInt). bigint is the type and BigInt is the constructor.
Here is the typescript docs for reference: https://typescriptlang.org/docs/handbook/release-notes/typescript-3-2.html#bigint

BigInt support in TypeScript introduces a new primitive type called the bigint (all lowercase). You can get a bigint by calling the BigInt() function or by writing out a BigInt literal by adding an n to the end of any integer numeric literal

let foo: bigint = BigInt(100); // the BigInt function
let bar: bigint = 100n; // a BigInt literal

function fibonacci(n: bigint) {
...
}

I need this to stop VSCode to complain :)

Good catch although be careful using bigint types due to the loss of precision that can happen with JSON.parse!

@oscartbeaumont thank you for the quick merge!
you are right, I did run into the bug. What is the right way to handle bigint types? (I am using specta with tauri-specta)

Your best bet is to convert it to a string using Serde and manually decode it to a BigInt on the frontend. It's annoying but the issue is with JSON.parse so nothing Specta can do about it.
You can do it like so:
#[derive(Serialize, Type)]
struct Header {
	#[specta(type = String)]
	#[serde(serialize_with = "as_string")]
	timestamp: u128,
}

fn as_string<T: ToString, S>(x: &T, s: S) -> Result<S::Ok, S::Error>
where
	S: Serializer,
{
	s.serialize_str(&x.to_string())
}


Travis fix cdp

@zshaheen not sure it's a good idea to remove all the tests
@doutriaux1 @gleckler1

@durack1 The tests are still in test root directory. These were copies in src/test/.


[stable/knox] (NEW) Initial version of the Apache Knox chart

Signed-off-by: Dennis Pfisterer<EMAIL_ADDRESS>What this PR does / why we need it:
This is a new chart that contributes Apache Knox, which is an Application Gateway for interacting with the REST APIs and UIs of Apache Hadoop deployments. This chart is primarily intended to access HDFS from outside a Kubernetes cluster using simple REST APIs.
This is a follow up to my PR #13142, which added WebHDFS support to the Apache Hadoop chart as a prerequisite for this chart to work.
Special notes for your reviewer:
@maorfr: since you have approved the mentioned PR, maybe you can join the discussion here.
Sorry for messing up the first PR #16614 regarding the signoff.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @mattfarina

please take a look at https://github.com/helm/helm/pull/6095#issue-301608768
we strongly encourage people to self host chart repos:
https://github.com/helm/hub/blob/master/Repositories.md
you can even do that using GitHub pages:
https://github.com/helm/hub/blob/master/docs/github.md#github-pages-as-a-repository

Ok. Thank you. Just for future reference, the new repo is available here: https://github.com/pfisterer/apache-knox-helm/


Please add linkable button

This is not an issue but i would like to request you to add an clickable link in you whatsapp-plus rather than text.

Like this👇👇

I don't think that's possible right now, as the library it uses right now don't have that feature. But i will try 👍🏻


Fix/cap-authentication

@vobu cap authentication is working again but our app on the btp is now using Universal ID which is breaking our other auth tests....


fix: extend cred offer accept timer

Summary of Changes
Extends the time before the 'This is taking longer than usual' message is displayed
Related Issues
N/A
Pull Request Checklist
Tick all boxes below to demonstrate that you have completed the respective task. If the item does not apply to your this PR check it anyway to make it apparent that there's nothing to do.

[x] All commits contain a DCO Signed-off-by line (we use the DCO GitHub app to enforce this);
[x] Updated LICENSE-3RD-PARTY.md for any added dependencies or vendored components;
[x] Updated documentation as needed for changed code and new or modified features;
[x] Added sufficient tests so that overall code coverage is not reduced.

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!
Pro Tip 🤓

Read our contribution guide at least once; it will save you a few review cycles!
Your PR will likely not be reviewed until all the above boxes are checked and all automated tests have passed.

PR template adapted from the Python attrs project.

@bryce-mcmath , I think it would be nice the have it configurable, like I did in this PR #685 (see the optional configuration connectionTimerDelay) , so I can configure when the timer will finish.


[Perf] Avoid Cast in SceneBuilder.PropagateLayer

In follow lines
https://github.com/AvaloniaUI/Avalonia/blob/bbd2cfaed4ad0516776c5c66efc5639abf7b4256/src/Avalonia.Base/Rendering/SceneGraph/SceneBuilder.cs#L447-L454
node.Children is IReadOnlyList<IVisualNode>, when foreach run, every item of Children  is cast to VisualNode for retrieve the LayerRoot

Note that SceneGraph/SceneBuilder will be removed before 11.0 release


updated name

app is showing the expected result.

Hi,
Thanks for the pull request!
The technical aspects of this patch looks good but I'm not sure if ODK Notifications is the name we want to go with.
@jbeorse what do you think?
Thanks

Hi,
Thanks for the pull request!
The technical aspects of this patch look good but I'm not sure if ODK Notifications is the name we want to go with.
@jbeorse what do you think?
Thanks

ok no problem

Sorry for the delayed response. Choosing an official name is larger decision that requires community input. I think we can call this project by its code name "Bat" for now, until it approaches release and an official name is chosen.

Done Sir. @jbeorse @linl33


AfterConfiguration - Name/Running Context

Describe the bug
AfterConfiguration, ideally should be renamed, and have it's running context altered.
To Reproduce

in env.rb mix in some Helpers to the World
Create an AfterConfiguration hook.
Try to access World Helpers - You cannot (The running context is main)

Expected behavior
AfterConfiguration should run in the World instance
Your Environment

Versions used 3.2.0
Operating System and version Ubuntu 18.04LTS
Cucumber Ruby on Browserstack / Locally

Additional context
This should be renamed to BeforeAll as that is what it is, and it would hint it would run first. AfterConfiguration running before a Before is a bit confusing.

That could totally make sense I think (while reading your comment I was surprised an After... was running before other hooks).
It could also be interesting to check if what happens in those steps is correctly shown in the messages (and I'm fairly sure it is not :/ )

I'm happy to dedicate some time diving into this / coding it. Would need a bit of a push as I tried scanning the hook code a while back for the long standing "Around hooks" issue (I know this is going to be redundant soon), and got so confused.

Related issue: https://github.com/cucumber/cucumber-js/issues/1393


Doesn't show request body params, and doesn't add a request body in the code examples.

Some of my routes have a required JSON request body. oax doesn't show which parameters are needed in the request body, rather it only shows the comment from the request body, which isn't enough information to make a successful request.
The code examples also don't show sending a request body at all, which they should show, otherwise they are showing an incorrect and incomplete request example.
And is there a way to show the code examples using the standard fetch() instead of axios and angular, which I think should be deprecated now that we have fetch?

Here's a screenshot of one of my POST routes which takes a request body, only it doesn't show what needs to be in the body, which is pretty important if I am going to use the route:

It needs to show which parameters need to be in the request body, as well as their datatype, something like:
body: {
userID: 0
}
Otherwise there's no way to know how to make the request properly, we only know that we need some type of request body, it leaves us guessing.
The code examples also need to show requesting with a body, which they currently don't down a body, only headers.
Thanks for looking into it.

You have to patch up the generated code to handle JSON body for all calls, it doesn't generate placeholder parameters for them. Not hard, just a little tedious.


Typing for knex.schema.raw() is missing the bindings param.

Environment
Knex version: master
Database + version: PostgreSQL 12.4
OS: Manjaro Linux
@lorefnon.
Bug

The typing for table.schema.raw is missing the bindings param.

Error message

TSError: ⨯ Unable to compile TypeScript:
src/db/migrations/20201019214408_add_reminders.ts:19:41 - error TS2554: Expected 1 arguments, but got 2.

19   await knex.schema.raw('DROP TYPE ??', 'reminder_types')

Reduced test code, for example in https://npm.runkit.com/knex or if it needs real
database connection to MySQL or PostgreSQL, then single file example which initializes
needed data and demonstrates the problem.

Here's a migration that should drop a PostgreSQL enum type.
export async function down(knex: Knex): Promise<void> {
  await knex.schema.raw('DROP TYPE ??', 'reminder_types')
}

This code produces the error above.
However, casting to any fixes it, since the problem is only in the typings.
export async function down(knex: Knex): Promise<void> {
  await (knex.schema as any).raw('DROP TYPE ??', 'reminder_types')
}

The line in question is this: https://github.com/knex/knex/blob/80355e48509857fb4941f65f4b611973a9ee99d5/types/index.d.ts#L1550
It's missing the bindings param, although it has support for it and works.
The typing for raw when used on the client works, although I'm not sure ...args: any[] is the best type either: https://github.com/knex/knex/blob/80355e48509857fb4941f65f4b611973a9ee99d5/types/index.d.ts#L2018

@lorefnon What would be the best type of the ...args that are passed to raw? I would love to open a PR to fix this, but I'm not sure which is the right type.

@lorefnon What would be the best type of the ...args that are passed to raw? I would love to open a PR to fix this, but I'm not sure which is the right type.

@vladev Apologies for late reply and thanks for your interest in contributing to the project.
This had previously been addressed in other places, but seems like SchemaBuilder was left out.
We can update SchemaBuilder.raw to return a RawSchemaBuilder similar to the RawQueryBuilder which uses readonly RawBinding[] | ValueDict | RawBinding as the type for bindings.


Flow step id labels are obscured by runtime border

Step labels should be moved up slightly for Stop/Start/Pause steps. This is a fix in flowbee.

Using Manoj's spacing for all activity id labels now in flowbee.


Fix edf preview

i think this branch has some changes from saxsdisplay merged into it; i think i will hold off merging this until the saxsdisplay branch is merged into master. Then, we can pull master into this and merge this PR.


Add Token 2022 Support

Done:

Create Mint
To-do:
Transfer
Minting
Change to Mint State With extentions to default
Add mint extentions

Thanks for submitting this!
I think some of what you have is heading in the right direction, but ultimately I don't like the idea of having the user specify whether or not to use Token2022 at the function call level (ie. create(&self, .., token2022: Option<bool>).
I think instead we should have a way for them to declare a Mint with a program ID - this way the Mint struct inherently uses Token2022 instructions instead, and the user can call the same functions they normally would.
We can also leverage traits & generics so that only Token2022 mints get the extension instructions.

Using a mint with a program id would be easy and can be implemented.
One thing to take into consideration (and why I have added program id to create) is that a person could could add an unwanted program id in an instruction. For that the program should check the passed in program id, is that good devex?
The same goes for token accounts.

We could do it a few different ways, I have two in mind:

Two separate structs: Mint and Mint22.

Make Mint take some specific struct U ie. Mint<U> where U is a simple struct:

pub trait TokenSelector {
    fn id(&self) -> Pubkey;
}

pub struct MintLegacyProgram {}

impl TokenSelector for MintLegacyProgram {
    fn id(&self) -> Pubkey {
        spl_token::id()
    }
}

pub struct Mint2022Program {}

impl TokenSelector for Mint2022Program {
    fn id(&self) -> Pubkey {
        spl_token_2022::id()
    }
}

pub type MintLegacy<'a> = Mint<'a, MintLegacyProgram>;
pub type Mint2022<'a> = Mint<'a, Mint2022Program>;

#[derive(Clone)]
pub struct Mint<'a, T>
where
    T: TokenSelector,
{
    pub account_info: Box<AccountInfo<'a>>,
    pub token_program: Box<AccountInfo<'a>>,
    pub token_program_selection: T,
    pub data: MintState,
}

Then you just use the types! MintLegacy or Mint2022.

Sounds good. I like the thought of just using Mint and passing in a program id into the instruction to define which program should be used. This would work like token interfaces out of the box and devs could restrict to a specific token program in their code if they want to. On the other side this may not be nice for security purposes.

They're declaring which program the mint is supposed to use in their function signature, which means they're declaring in their program config and IDL (kinda) that it's a Token2022 Mint.
And yes, you're right. This puts us in a good spot to be able to add one additional TokenSelector for "Custom" where anyone's interface implementation can be used. But that may prove to require a little bit of additional work


Where to put the configuration as code yaml file

Sorry for boring question, re this section: https://github.com/jenkinsci/slack-plugin#configuration-as-code
where do we put that yaml file?
For example, with plugins.txt using Docker we would do:
COPY plugins.txt /usr/share/jenkins/plugins.txt
RUN /usr/local/bin/install-plugins.sh < /usr/share/jenkins/plugins.txt

is there a similar place we can put the CaC yaml file?

Hi
https://github.com/jenkinsci/configuration-as-code-plugin#getting-started

If you do not set the CASC_JENKINS_CONFIG environment variable, the plugin will default to looking for a single config file in $JENKINS_ROOT/jenkins.yaml.

I'm going to close this as its not related to the slack plugin specifically, there's a gitter chat room for questions like this:
https://gitter.im/jenkinsci/configuration-as-code-plugin

Can you update the readme to point to those docs linked above?  Came here with the same question...

done


Support drop-ins in customSystemdUnits

I'd like to use drop-ins to modify existing systemd units, but the customSystemdUnits schema/template don't support them.
https://github.com/coreos/coreos-cloudinit/blob/master/Documentation/cloud-config.md#units

@groner, this PR adds the ability to create drop-ins inside the customSystemdUnits section of the cloud-config.  Does this meet your needs?

@jeremyd, thanks for responding to my feature request.  I've responded on the PR.


⚠ Bofrost.be has degraded performance

In b8efa22, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1606 ms

Resolved: Bofrost.be performance has improved in 0a38382 after 46 minutes.


Update fullnode.md

Ad chapter Typical issues. This section will show common problems and solutions for people who are not familiar with installing nodes and who are setting up a node for the first time. For instance, I add typical error 98/99.

Hey folks, I am working with grossbel12 after some chatting in Discord. This is a trial run with a new user, thanks for your patience. We'll fix the branch etc.

Thanks for the contribution @grossbel12 , coordination @randall-Mysten, and input @huitseeker. Randall, we can discuss how to improve this in our meeting today.
It would be good to have more than one issue. I wonder if @tharbert, @bmwill , @mystenmark , @allan-bailey or @ebmifa have other known fullnode issues we can include here too. Thanks, all.

Asking @bmwill to take a look.

I created new common error in my repositories, I send message to @randall-Mysten. If the topic with common problems with Fullnode is relevant, I'll add some.

I created new common error in my repositorie, I send message to @randall-Mysten. If the topic with common problems with Fullnode is relevant, I'll add some.

Please include the common errors here. Thanks!

I created new common error in my repositorie, I send message to @randall-Mysten. If the topic with common problems with Fullnode is relevant, I'll add some.

Please include the common errors here. Thanks!

Done check plz

I created new common error in my repositorie, I send message to @randall-Mysten. If the topic with common problems with Fullnode is relevant, I'll add some.

Please include the common errors here. Thanks!

Done check plz

Thank you. I see some comments from huitseeker that are still pending. Do you want to try and address those?

I created new common error in my repositorie, I send message to @randall-Mysten. If the topic with common problems with Fullnode is relevant, I'll add some.

Please include the common errors here. Thanks!

Done check plz

Thank you. I see some comments from huitseeker that are still pending. Do you want to try and address those?

Actually, this entire solution is covered in:
https://docs.sui.io/devnet/build/fullnode#built-from-source
So I agree with @huitseeker we should qualify the error with your environment as the new information here. Can you confirm your operating system and version? Also, please send a higher resolution version of the image as it is blurry at full size:
https://user-images.githubusercontent.com/86624298/184237312-4af31e15-c939-47e9-8055-535bee579dba.png
Thanks, @grossbel12 !

I am closing this PR as it is stale and some of the issues are being addressed with other content updates. Please submit another PR if there are still unresolved issues. Thanks for contributing to Sui.


Profile based workspaces

Should have profile based workspace you opt to use.
This means, for example, when you are developing for django web development, you have a profile that has all the extensions that django needs.
Users can custom design those profiles to fit their needs, for their specific project development or workspace development.
Another example is that, when someone is using opencv, it uses python, opencv related extensions, and a bunch of extensions and helps and smooths out the development pace, and this profile should be like an image type, so that it can be deployed, shared, and managed between teams as well.
Hope you get my point.
Regards,
danidavid

Another example is that you use React as frontend (any frontend you like) with the backend (node,deno or other framework you really like) both of them having similar extensions packed altogether in a profile. So when you want to use them together, you can use them easily or direct to your teams to deploy with ease.

/duplicate


Rename README.md to Ishmaello

npm install @thirdweb-dev/react @thirdweb-dev/sdk ethers@5

Confused by thirdweb-dev directory need assist with build app on contract from thirdweb import ThirdwebSDK
sdk = ThirdwebSDK("polygon")
contract = sdk.get_contract("0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270")

No clue Using react, python or JavaScript... It hard to survive codespace usage at 100% I guess quitting is dumb as I

import { ThirdwebProvider, useContract } from "@thirdweb-dev/react";
function App() {
return (

)
}
function Component() {
const { contract, isLoading } = useContract("0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270");
}


Add mechanism to signal secure vs. insecure MQTT

This is one option to resolve #80 if we choose to.
I haven't included authorization as yet, but this brings MQTT into line with what is visible for WebSockets.
I've used 'broker_scheme' for now but I'm not wedded to that. 'broker_protocol' would have been more consistent with what we use elsewhere, but 'protocol' was never an ideal choice there.

Yeah, I think I'd have gone for broker_protocol for consistency. 🤷♂ (IANA call it a 'service name' for extra confusion.)
I suppose we have to have an enum? Means a version-up to add "ws" and "wss" support.
Also makes me wonder again why we don't call them broker_host and broker_port on both Senders and Receivers, rather than having destination_ and source_ variants.

Yeah, I think I'd have gone for broker_protocol for consistency.  (IANA call it a 'service name' for extra confusion.)

I'll change that

I suppose we have to have an enum? Means a version-up to add "ws" and "wss" support.

Is this likely to be necessary? I don't know the details of this, but wouldn't MQTT over WebSocket use the WebSocket IS-05 type? If so that already has the means to specify a scheme.

Also makes me wonder again why we don't call them broker_host and broker_port on both Senders and Receivers, rather than having destination_ and source_ variants.

This was purely for consistency with the already defined RTP parameters.

I suppose we have to have an enum? Means a version-up to add "ws" and "wss" support.

Is this likely to be necessary? I don't know the details of this, but wouldn't MQTT over WebSocket use the WebSocket IS-05 type? If so that already has the means to specify a scheme.

Yes, I've been reading MQTT specs but not thinking hard enough - I think it's unnecessary, because MQTT over WebSocket is only likely to be used in browser-based MQTT clients (see e.g. https://www.hivemq.com/blog/mqtt-essentials-special-mqtt-over-websockets/).
FWIW, the WebSocket IS-05 type wouldn't make sense, however. That's point-to-point between Sender (server) and Receiver (client), whereas MQTT over WebSocket is still two connections: Receiver (client) to broker (server) and Sender (client) to broker (server).

One more comment: "plain text" to describe non-TLS is a bit confusing because MQTT is a binary protocol.

I need to add support for 'auto' to these parameters too in case they're using DNS-SD.

Fixed an omissions from the previous commits, and added a proposal for authorization parameters (needs discussion). Further consideration of use of 'auto' particularly for authorization parameters with WebSockets would be a good idea.


Flags for polygon-edge not known --path --admin-key

Flags for polygon-edge not known --path --admin-key
when running the command line:
./polygon-edge rootchain init-contracts --manifest ./manifest.json --path ./core-contracts/artifacts --json-rpc http://<IP_ADDRESS>:8545
--admin-key
says that the flags --path and --admin key are unknown

OS and version - Debian Linux 11
Polygon Edge v0.8.1
Hosted locally

Steps to reproduce

at the command line run the following command:
./polygon-edge rootchain init-contracts --manifest ./manifest.json --path ./core-contracts/artifacts --json-rpc http://<IP_ADDRESS>:8545
--admin-key

Expected behavior

command should run and deploy smart contracts
It gave an error that the --flags path and admin-key was unknown

This occurred while attempting to deploy a local Polygon Supernet in Bridge Mode

As I know, --path param has been replaced with --data-dir.
You could run
./polygon-edge rootchain init-contracts --help
then see all available params.

thanks for the help.  But, looks like they have changed the documentation and taken the --path option out and --admin-key is also incorrect its --deployer-key instead.  But, thanks again.

thanks for the help. But, looks like they have changed the documentation and taken the --path option out and --admin-key is also incorrect its --deployer-key instead. But, thanks again.

@squiddyswap That's right:

instead of using --admin-key, a --deployer-key flag should be used,
as per the --path flag, it was obsoleted some time ago (a couple of months ago), but possibly documentation got updated recently.

If you can point to the docs page where the wrong flags are enumerated so that we can fix the docs itself. Otherwise, the issue can be closed.


Add support for crash dumps

Today, our Process Explorer lets you take a dump of its current state. Often users also need a crash dump.
We can achieve this via procdump -t. e.g. UI could be:

Go to process explorer
Right click a process and choose 'enable Crash Dump'
Then on crash it would go in some well known folder

do you happen to know if these tools exist in the same place in WAP?

You mean in d:\devtools\sysinternals, right? Good question, I don't know. We should ask. If not, I guess we can do detection and light up?

yea, I wanted to check first before complicating things.

One idea is to put  d:\devtools\sysinternals in the path (DWAS fix).  It will be last in the path to minimize regression.  Our kudu codes could check if exists in the path to light up feature.   Public kudu can override etc.
Have we thought about REST apis?  For instance, ...

Start procdump.   POST /api/processes/{id}/crashdump.   To not run forever, a timeout on how long it will monitor.
List crash dumps.   GET /api/crashdumps
Get crash dump.   Get /api/crashdumps/{pname}-{time}.  We want to return zip (crash dump zip ratio is efficient).  We might compress it at storing time.
Delete crash dump.   DELETE /api/crashdumps/{pname}-{time}.  We will also auto GC the dump files.
(Perhaps) Analyze crash dump.   POST /api/crashdumps/{pname}-{time}/analyze.   (!analyze -v).  This is useful, client side no need tooling at all.

Support to safe dump to blob storage etc.

thanks for the feedback. I'll implement these.
What's an appropriate timeout? I thought this scenario is meant to launch it to wait forever. One problem is that killing procdump.exe will kill the process it's attached to. To make it not do that, you have to send CTRL-C signal which doesn't work in Azure.

Also right now I call procdump.exe -t, this creates a dump with only thread and handle information. -ma will include process memory. I think this is more useful, but the dumps will be significantly bigger. Thoughts?

For timeout, don't kill it then.  It will just run forever.
For -ma, it should be optional (not default) - eg thru query string.   We did the same for /processes/{id}/dump.  You can borrow the sematic.


Remove composer as a production requirement

By removing composer as a production requirement it should make the install process easier and quicker.

I think the only way to do this, is to include all files from vendor/ (filesize will be between 20 and 25 MB). This is the only way to make it independant from hosting restrictions. There are lots of providers who do not offer ssh in basic hosting plans which are totally fine for BookStack.
Updating dependecies is not really difficult, since this is nothing a user does on a regular basis. The vendor folder, which is generated by composer install from the update steps, will be including the same versions of packages a user gets until the next release of bookstack.
In my opinion the main points to consider are:

How to enable the "updater" since we can not rely on BookStack-Logins because the System might be broken until the updates are performed. This might be achieved by simply placing a file with a defined name in a defined folder which will be deleted after the update is performed.
How to determine which steps need to be taken. This is easy for things like migrations and clearing cache/view because we can use the artisan commands from code. Files which are not included in the download (.env) might change. We can simply tell the user to compare relevant files (.env with .env.example) and ask them to manually merge changes.

The easiest way would be implementing a route which looks for a specific file, runs artisan migrate, artisan cache:clear and artisan view:clear, displays generic information which files might have changed that the user has to merge manually and finally delete the enabling file.


cmsalpha.c is missing from project files for VC2010 solution

In the version 2.9 VC2010 solution (lcms2.sln) the projects 'lcms2_DLL' and 'lcms2_static' are missing the 'cmsalpha.c' file.
Without this file an unresolved external '_cmsHandleExtraChannels' is reported by the linker when the 'lcms2_DLL' project is built.
I have not checked the other VC201x versions as I do not have the relevant Visual Studio versions available to me.

fixed in 2.10 rc1


App crashed after taking photo on Android

Actual behaviour
On Samsung Galaxy J7 Android 6.0, app crashed after taking a photo.
Here is the stacktrace I got from the Google Play:
java.lang.OutOfMemoryError: Failed to allocate a 51121164 byte allocation with 16777216 free bytes and 36MB until OOM
	at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
	at android.graphics.Bitmap.nativeCreate(Native Method)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:975)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:946)
	at android.graphics.Bitmap.createBitmap(Bitmap.java:877)
	at com.lwansbrough.RCTCamera.RCTCameraModule.rotate(RCTCameraModule.java:562)
	at com.lwansbrough.RCTCamera.RCTCameraModule.fixOrientation(RCTCameraModule.java:581)
	at com.lwansbrough.RCTCamera.RCTCameraModule.access$300(RCTCameraModule.java:45)
	at com.lwansbrough.RCTCamera.RCTCameraModule$3.onPictureTaken(RCTCameraModule.java:673)
	at android.hardware.Camera$EventHandler.handleMessage(Camera.java:1165)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:158)
	at android.app.ActivityThread.main(ActivityThread.java:7230)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1230)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1120)

Environment

Node.js version: 6.8.1
React Native version: 0.41.0
React Native platform + platform version: Android 6

react-native-camera
Version: 0.6.0

Seems to be this issue: https://github.com/lwansbrough/react-native-camera/issues/591

@minhchu can you try the master branch?  there are some changes in there that have not been released to npm yet which might help.

I think this is a duplicate of #590.
The problem is the rotation done after the image is taken (introduced in 0.4.1). On some devices there is not enough memory for doing this operation... We should investigate why this rotation is even necessary.
One solution for you might be to use<EMAIL_ADDRESS>(if you are using React Native < 0.40.0).

@skovhus are you able to test this: https://github.com/lwansbrough/react-native-camera/pull/682
it removes image rotation but i can't properly test it on android because the device i'm using rotate the image for me.

This issue is closed because of inactivity.
Furthermore RCTCamera is deprecated now, use RNCamera instead. If this issue is also related to RNCamera, please open a new one.


Simplify redundant allOf and oneOf in JSON

We simply indent the references to the respective definitions for
readability.

@Manu3756 FYI


Remove workaround for GUID constants

Now that https://github.com/microsoft/win32metadata/pull/1204 has been fixed, we no longer need this workaround to harmonize GUID constants.

Sigh. Turns out we need to keep the workaround.
https://github.com/microsoft/win32metadata/issues/1212


[DOCS] add anish de to the contributors list

What would you like to share?
add anish de to the contributors list
Additional information
No response

@all-contributors please add @AnishDe12020 for code and docs

@kr-anurag
We had trouble processing your request. Please try again later.

sure! go die!

Lol

@all-contributors please add @AnishDe12020 for code and docs


Add Test Cases for 'Ecommerce web-site/application'

Add Test Cases for 'Ecommerce web-site/application'

will u please assign this issue to me


Fixes incorrect "more" calculation for attack speed #380

I needed to convert the percentage values from whole numbers to their decimal representation in order for the calculation to be correct.

I think I stated in the issue something wrong, sorry. I believe the less attack speed here is wrong since you need to multiple the product with the more attack speed product.

@EmmittJ should be good now

What happens when you have an odd amount of less attack speed? I believe
you will get on overall negative attack speed?
On Sep 26, 2016 7:49 PM, "Jason Robinson"<EMAIL_ADDRESS>wrote:

@EmmittJ https://github.com/EmmittJ should be good now
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/381#issuecomment-249753088,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHIbbWgFL8569asqgmR6neIA6iwbHp5iks5quIRGgaJpZM4KHJzV
.

Yeah, I think there's a deeper problem with how "more" and "less" values are stored in the attrs map. I'm not sure where those values are obtained in source, but I assume the collective value is just added together for the "#% less Attack Speed" and "#% more Attack Speed" value?

The "more" and "less" values are calculated incorrect for every value that I'm seeing, so maybe it's best to discard the PR and create a new issue to address the global problem and fix it all in one fell swoop.

Yeah, I can correct it. The two values need to be calculated separately
(products) then the product of those is the final result.
On Sep 26, 2016 8:10 PM, "Jason Robinson"<EMAIL_ADDRESS>wrote:

The "more" and "less" values are calculated incorrect for every value that
I'm seeing, so maybe it's best to discard the PR and create a new issue to
address the global problem and fix it all in one fell swoop.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/EmmittJ/PoESkillTree/pull/381#issuecomment-249755290,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHIbbZ0fAiqpM2MJvkoSO-YvsPAEhFX0ks5quIkIgaJpZM4KHJzV
.

Yep


Change google_cloud_bigdataoss_version to 2.2.8.

Fixes #21492
This release includes https://github.com/GoogleCloudDataproc/hadoop-connectors/pull/865 which fixes https://github.com/google/conscrypt/issues/864 .

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PreCommit

@Abacn Tests are green now (unrelated flakes)

Thanks, LGTM


Builtin termcap fix

It looks that built-in termcap entry has some problems.
xterm
keypad keys
There are no key codes for keypad number keys.
We can't use keypad number keys in the default setting.
vt320
keypad keys
same as xterm.
cursor keys
There are no key codes for application cursor mode cursor keys.
Normaly, OS's vt320 termcap/terminfo entry changes cursor key mode to application mode, then cursor key does not work in vim.

Codecov Report

Merging #2973 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2973      +/-   ##
==========================================
+ Coverage   75.84%   75.85%   +<.01%
==========================================
  Files          92       92
  Lines      135295   135295
==========================================
+ Hits       102620   102622       +2
+ Misses      32675    32673       -2

Impacted Files
Coverage Δ

src/term.c
59.94% <ø> (+0.15%)
:arrow_up:

src/if_xcmdsrv.c
84.35% <0%> (-1.08%)
:arrow_down:

src/terminal.c
72.74% <0%> (-0.17%)
:arrow_down:

src/gui_gtk_x11.c
47.83% <0%> (-0.05%)
:arrow_down:

src/window.c
82.22% <0%> (+0.03%)
:arrow_up:

src/channel.c
83.28% <0%> (+0.03%)
:arrow_up:

src/eval.c
81.52% <0%> (+0.04%)
:arrow_up:

src/gui.c
49.45% <0%> (+0.05%)
:arrow_up:

src/message.c
74.78% <0%> (+0.19%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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

The escape sequences in the form OA  are left out intentionally.  This is actually something the user might type: Leave Insert mode, Open a line above and start typing a sentence starting with a capital.
For recent xterm versions the actually used codes will be obtained.


How much data required and how to train on custom speaker data

Hi,
I have downloaded LJS speaker pre-trained model and configured it as warm-start for custom speaker data training.
And i have both wave glow models waveglow_old.pt and waveglow_256channels.pt for prediction but prediction is too bad audio is unclear.
Any suggestions on how to proceed further ? do i need to train waveglow model also by considering above waveglow models as warm-start.

Hard to say without seeing the loss and alignments of your tacotron2 trained on your data.

Hi,
Loss = 0.503 (approx) at 200 epoch (4000 steps). I didn't understand about alignments where can i check that ?

You'll need to train longer and anneal the learning rate to reduce the validation loss.

Hi,
I have reduce learning rate from 10e-4 to both 10e-6 and 10e-5 but there are no differences in prediction performance.

we took pretrained model (tacotron2_statedict.pt) and our data (1000 samples = 1.5 hr)-> didn't worked at all.
we have trained from scratch with our data (1000 samples = 1.5 hr) -> didn't worked at all.

In above both cases while testing prediction on test files we have used both waveglow_256channels and waveglow_old.pt but no differences in output performance in prediction.
And we also trained waveglow model both from scratch and fine-tune using pre-trained but didn't worked at all.
Could you please help us ? what mistake we are committing on our side ?

@shivamani-ans check whether your WAV files are int or float... If float, training will not work.

Hi,
when we open .wav file in audacity it shows Mono, 16KHz 32-bit float.
To which int format do i need to convert (16-bit PCM or 24-bit PCM) ?

Could you share your attention graph?

@rafaelvalle
could you please re-open this issue, after "anneal the learning rate to reduce the validation loss", there is no difference in prediction output (its complete empty noise).

As I said, it's hard to help without seeing your tensorboard log with loss curves and attention graphs, etc...

Hey you can use this GUI


WIP: Integrate LOS vector in CSLC-S1 static layers product

This PR integrates the LOS vector in the CSLC-S1 static layers product. Specifically, the PR removes the heading_angle layer and adds east_los_vector and north_los_vector.
TO DOs:

[ ] 1. Merge ISCE3 PR computing LOS vectors in Topo
[x] 2. Test if the correct LOS vectors are returned for a couple of test bursts
[x] 3. Remove incidence_angle and heading
[ ] 4. Check generated static layers product
[ ] 5. Modify static layers product specifications

No sure why the measure of the runtime is off when I ran the static layers:
journal: elapsed time (GEO-IN) [s]: 6.477
journal: s1_geocode_metadata burst successfully ran in 0:00:46 (hr:min:sec)
journal: s1_static_layers burst successfully ran in 19066 days, 15:54:45 (hr:min:sec)

Any idea how to fix this @LiangJYu ?

No sure why the measure of the runtime is off when I ran the static layers:
journal: elapsed time (GEO-IN) [s]: 6.477
journal: s1_geocode_metadata burst successfully ran in 0:00:46 (hr:min:sec)
journal: s1_static_layers burst successfully ran in 19066 days, 15:54:45 (hr:min:sec)

Any idea how to fix this @LiangJYu ?

This line should look like this one.

@seongsujeong can you please review this PR? Thanks

No sure why the measure of the runtime is off when I ran the static layers:
journal: elapsed time (GEO-IN) [s]: 6.477
journal: s1_geocode_metadata burst successfully ran in 0:00:46 (hr:min:sec)
journal: s1_static_layers burst successfully ran in 19066 days, 15:54:45 (hr:min:sec)

Any idea how to fix this @LiangJYu ?

This line should look like this one.

The 2 following places need time.time() changed to time.perf_counter()
s1_geo2rdr.py
s1_resample.py

Process timing counter fixed and @seongsujeong comments addressed.


Applied skeletal implementation to interface migration automated refactoring

This is a semantics-preserving automated refactoring that migrates existing method implementations in classes to the corresponding implemented interface methods as default methods. The tool does not add new code; it only rearranges existing code.

We are evaluating a research prototype automated refactoring Eclipse plug-in called Migrate Skeletal Implementation to Interface. We have applied the tool to your project in the hopes of receiving feedback.
The approach is very conservative. That may mean that not all changes that can be made were made. Please feel free to continue the refactoring manually if you wish.
We only migrated methods declared in abstract classes with the hopes of such methods being suitable default methods in corresponding interfaces.
The source code should be semantically equivalent to the original.

Thank you for your help in this evaluation! Any feedback you can provide would be very helpful. In particular, we are interested if each of the proposed changes are helpful or not.

That's really cool. I think @lukaseder may be interested in automated refactoring from default interfaces to concrete types if that is possible also (see https://github.com/jOOQ/jOOL/issues/158)

Oh! Interesting! Thanks!

On Jul 18, 2016, at 3:39 PM, johnmcclean-aol<EMAIL_ADDRESS>wrote:
That's really cool. I think @lukaseder https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_lukaseder&d=CwMCaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=6uKeUC2WdS1jZj5ReoLELl1tlCgOxzC60qom_XA4tC8&s=LBzrOPZjUlsO6iFf3_yx1HWdvZ1cLqltkYdvJQjVKvI&e= may be interested in automated refactoring from default interfaces to concrete types if that is possible also (see jOOQ/jOOL#158 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jOOQ_jOOL_issues_158&d=CwMCaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=6uKeUC2WdS1jZj5ReoLELl1tlCgOxzC60qom_XA4tC8&s=7ostbeM1E-S184gUXylAv1mMR5GI_jpHGeg4rGW7Dm4&e=)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_aol_cyclops-2Dreact_pull_258-23issuecomment-2D233435569&d=CwMCaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=6uKeUC2WdS1jZj5ReoLELl1tlCgOxzC60qom_XA4tC8&s=EhUOaoihoLk1vd309OkFn5LarRtg86oevnDCyWDIay0&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AB9DP5WwhdaCMBpm0lo7ZkAdpRSnbcpNks5qW9aOgaJpZM4JO248&d=CwMCaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=6uKeUC2WdS1jZj5ReoLELl1tlCgOxzC60qom_XA4tC8&s=NwYUFxD2Wi5d15HmvP9mCsBYulWgDR9rfPeSYsfETEE&e=.

Thank you!

On Jul 22, 2016, at 9:32 AM, johnmcclean-aol<EMAIL_ADDRESS>wrote:
Merged #258 https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_aol_cyclops-2Dreact_pull_258&d=CwMCaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=yl-J3HTmcyxXxD-r6iTrTjiH_H1It-ykClG__IaGKkg&s=d3SxORQG87dH29dDg-J1veTNL8W8f1-jvvbdaUcIlsA&e=.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_aol_cyclops-2Dreact_pull_258-23event-2D731750987&d=CwMCaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=yl-J3HTmcyxXxD-r6iTrTjiH_H1It-ykClG__IaGKkg&s=_0C8XR5XJuymxLovPBZDwDDwJghbKyLDpVS_eDl71Go&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AB9DP2q1Sc0-5FWowLRjE-5FE3BD7837IT8eks5qYMZdgaJpZM4JO248&d=CwMCaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=yl-J3HTmcyxXxD-r6iTrTjiH_H1It-ykClG__IaGKkg&s=Qt7LSX7QyBEPd-pcgWdAGAVwfzBPnWrw3FoQZJSD8hQ&e=.


Participation status is not updated, list of accounts in Staff group is incomplete.

A user (Ahmed Shimal<EMAIL_ADDRESS>joined a project (seasketch.org/maldives) after receiving an invitation. He is assigned to the Staff group. His invitation is listed under "Sent Invitations" which shows that he opened the email and that he belongs to the Staff group.
However, under Participation Status, it says, "Recipient has created an account but has chosen not to join the project and share a public profile. For this reason they will not appear in the participants list or receive any assigned access control permissions." Furthermore, his account does not appear in the list under the Staff group.
In fact, there are 16 accounts that have been invited and assigned to the Staff group, but on 10 are listed.

Group lists only show participants who have joined the project and shared a public profile.


initilization/lookup format for running examples with ofi+tcp

Describe the bug
I was trying to run the built-in examples with the ofi+tcp plugin. According to https://mercury-hpc.github.io/documentation/, we should set ofi+tcp://ip:port for initialization while setting ofi+sockets://ip:port for lookups. However, it seems only setting both of them to ofi+tcp works. Do you think the documentation should be updated? Could anyone explain why we use different formats here at the very beginning?
To Reproduce
Just set the formats in the example_rpc_clients.c for lookups and example_rpc_server.c for initilization.
Expected behavior
Only setting both to ofi+tcp works, otherwise, both sides get stuck.
Platform (please complete the following information):

Centos 8
Compiler version: gcc-8.3
Plugin and protocol used ofi+tcp
libfabric 1.10.0

That field in the plugin/protocol/lookup table field on that page is out of date.  Mercury uses the ofi tcp provider by default now, so the address format should be either ofi+tcp://ip:port or tcp://ip:port for most users.
You can also still use ofi+sockets:// to force use of the sockets provider rather than the tcp provider, but if you do so then you also need to initialize Mercury to use ofi+sockets at initialization time as well.  (i.e. it should be either all tcp or all sockets, the two providers are not compatible).

Thanks for pointing that out, I had definitely missed that. Will update it.


Enable RBAC and support using ServiceAccounts

As a CRD developer, in production I run my controller in a Namespace with a ServiceAccount and RBAC rules configured for it.  I want the integration tests for my controller to mimic production as closely as possible and catch errors if the RBAC rules are incorrectly setup.  To do this I need:

RBAC to be enabled in the cluster
To create a Namespace in the cluster and setup RBAC rules for my controller
To get a Config (credentials) authorized as the ServiceAccount

We discussed in the SIG-testing-commons meeting yesterday the longer term goal for this framework: It should have a API to ask for a k8s cluster (similar or a layer around the cluster API). A user should then be able to choose which cluster should be deployed and probably the default will be some sort of kubeadm DIND deployment. Other deployment options might also be available. The spec about that is in the works.
Now when you say you want "to mimic production as closely as possible" probably implementing this in our strategy (bringing up some binaries) is the wrong way to do it, but for that case the kubeadm DIND deployment should be used.
In case we add more and more things (RBAC, ...) to the current implementation and supporting them, will we end up rewriting something like kubeadm?
cc: @jamesjoshuahill @marun @timothysc @apelisse


Drop nwbinspector as a dependency

The only place where we use it is here:
https://github.com/catalystneuro/nwb-conversion-tools/blob/7a52631a236f2be339e443401b0d2ca5162fec0b/src/nwb_conversion_tools/datainterfaces/behavior/movie/moviedatainterface.py#L13
And that is a use of check_regular_series which is a super simple function:
https://github.com/NeurodataWithoutBorders/nwbinspector/blob/dd58ddf34cfa0e1d81ec18739e1e3fa2f3e2cd8f/nwbinspector/utils.py#L45-L48
Are we planning on using more functionality? if not, I think that we should maintain a local version of the same function and drop the dependency as a whole.

I agree, it doesn't seem worth it to have this dependency for such as simple function.

The idea here wasn't just for the free utility function, which avoids duplicated code over multiple repo's, but also to encourage people to use the NWBInspector any time they are writing NWBFiles, which is the purpose of this repo.

I feel that right now we are saving the hypothetical user a pip install at the price of increasing our dependency complexity. My vote is for dropping it until code duplication becomes large enough that the scale is tipped or the need arises from another direction.


a quick embedded youtube hack

Rebased version of #1040 since the original author is unresponsive

done

Not sure why GitHub didn't notice but this was merged a while ago.


Schema.ActualProperties explodes with StackOverflow exception on schema containing cyclic reference

While I can understand this to happen for a nonsensical schema containing cyclic references, it's still not a nice experience. If validating user-defined schemas (and using the property ActualProperties). there's no way to guard against a DoS.
The workaround is, of course, not to use that property. But then why have it in the first place?
I would expect a recurrence depth limit check.
Here's an input that triggers it:
{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "definitions": {
    "myDef": {
      "allOf": [
        {
          "properties": {
            "myDef_prop1": {
              "type": "integer"
            },
          }
        },
        {
          "$ref" : "#/definitions/myDef"
        }
      ]
    }
  },
  "allOf": [
    {
      "$ref": "#/definitions/myDef"
    }
  ],
  "properties": {
    "topProp": {
      "$ref": "#/definitions/myDef"
    },
    "topArrayProp": {
      "type": "array",
      "items": {
        "$ref": "#/definitions/myDef"
      }
    }
  },
  "required": [
    "pages"
  ]
}

Yes, it should throw something like:
new InvalidOperationException("Cyclic references detected.");


Blog Featured Image stopped working

Hi, I have used ananke theme since December 2021. Now when I updated it, my featured image stopped working.
The current code (not working) is https://github.com/theNewDynamic/gohugo-theme-ananke/tree/8fdfd205f9b4fd2f52eac9dfd2da8e11bea2015e
The previous working code was https://github.com/theNewDynamic/gohugo-theme-ananke/tree/c7b9901e01ec3720b47fcef3d33bdbd6ce53f000
My featured image is defined in config.toml (nothing changed since that day):
[params]
  ...
  featured_image = "https://ik.imagekit.io/mirontoli/bridge_UngKtedn3OP.jpg?updatedAt=1639597203043"

I am using Ananke as a git submodule (right or wrong). I suppose you recommend using Hugo Module. I'll take look into it and the cascade configuration. Thank you very much for pointing me in right direction.

I find it much more easier to use Hugo Module indeed, but to each his own. As a maintainer, I often push changes to master that might introduce breaking changes, but the only way I can communicate with the users about those potential breaking changes is using release notes, so I like the fact that the default Hugo Module update command will use the latest release (whose notes documents changes etc...)


fix link to WASI API header

Hello!
The link wasn't working for me, but the new one is; I think it's the same file.

Yes, that's right. Thanks for the fix!

Ah, actually this is already fixed in c37f245fc8b360d30d8717861bf576d2eeaed390. Thanks for the PR though!


Paths with spaces are not handled well

Steps to reproduce:

Create a Sketch file with spaces in the file name
Start the stylesync wizard
For the Sketch file, attempt to reference the Sketch file

Expected behaviour:

Wizard recognises Sketch file and continues

Actual behaviour:

Wizard claims the path is invalid

The issue seems to be with using Text\ Styles to represent Text Styles, since if you don't add the \ character then it recognises the path. A simple fix would be to just replace \  with  .


Feat/adaptive templates geometry classes

Adaptive templates functionality

Also can you build docs with tox -e doc and verify that the docstrings you are writing look correct in html docs


Search

[x] Search modal with debounce inputs and basic functions
[ ] Replace mock data with OneDrive API
[ ] Mobile layout and responsive design
[ ] New loading images

Supercedes #230

cc @myl7


release v2.0.9

Signed-off-by: disksing<EMAIL_ADDRESS>What have you changed? (mandatory)
Pump version and add change log.
What are the type of the changes? (mandatory)

Improvement (non-breaking change which is an improvement to an existing feature)

How has this PR been tested? (mandatory)
No code changes.
Does this PR affect documentation (docs/docs-cn) update? (mandatory)
No
Does this PR affect tidb-ansible update? (mandatory)
No
Refer to a related PR or issue link (optional)
Benchmark result if necessary (optional)
Add a few positive/negative examples (optional)

LGTM.


Releases changelog missing notes from Sep 25th release

Documentation
The release on September 25th doesn't have notes over at https://www.radix-ui.com/primitives/docs/overview/releases.
Relevant Radix Component(s)
Multiple components from this release: https://github.com/radix-ui/primitives/commit/c31c97274ff357aea99afe6c01c1c8c58b6356e0

Oops, I should have searched, many issues already about this.
#2508, #2465, #2435, #2415


is the map necessary

a non-expert who reviewed the site found that the map was somewhat unwiedly and not really necessary.  the list of countries is a much better way to actually find a country (especially if they are small).  Maybe allow toggling the map on/off?

We can make it smaller. That way people find the other elements more easily.

I am wondering if at some point one of you tried a  horizontal table instead of a vertical one for the country. It could be added under the map with the same size?
(NB: I find the map much handier and intuitive)


onEvent->eventRefs array should have unique values

onEvents-eventRefs array should have only unique values

@tsurdilo What do you mean with that?

          "eventRefs": ["HighBodyTemperature", "HighBodyTemperature", "HighBodyTemperature", "HighBloodPressure],

what does that mean? :)

@tsurdilo Ah! Indeed! 👅


AWS Jumbo MTU size disagrees with Calico docs

I noticed that Calico's official docs on MTU size recommend 8981 when using IP-in-IP.

If you need IP-in-IP then the MTU size for both the workload and tunnel interfaces should be 20 bytes less than the network MTU for your network. This is due to the extra 20 byte header that the tunnel will add to each packet.

Typhoon recommends 8991. Could you provide a reference for how you chose 10 bytes instead of 20?

8981 is the correct value to use. AWS test cluster uses 8981 and the performance measurements were done on a cluster configured that way. Looks like a typo in the Typhoon docs - https://typhoon.psdn.io/cl/aws/ shows 8981 in the table, but 8991 (wrong) in the tip section. Meanwhile, variables.tf shows the correct 8981.
I'll fix up the inconsistency, thanks for pointing it out.

Fixed in 0764bd30b5682931ab50348fedfee72798965c51


gromacs: 4.6.7 -> 2018

Semi-automatic update. These checks were done:

built on NixOS
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/GMXRC.bash -h got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/GMXRC.bash --help got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/GMXRC.bash help got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/GMXRC.zsh -h got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/GMXRC.zsh --help got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/GMXRC.zsh help got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/gmx -h got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/gmx help got 0 exit code
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/gmx --version and found version 2018
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/gmx -h and found version 2018
ran /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/gmx help and found version 2018
found 2018 with grep in /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018

Success on x86_64-darwin (full log)
Partial log (click to expand)
-- Installing: /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/include/gromacs/trajectoryanalysis/cmdlinerunner.h
-- Installing: /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/bin/gmx
-- Up-to-date: /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/bin
-- Installing: /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/bin/gmx-completion.bash
-- Installing: /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/bin/gmx-completion-gmx.bash
post-installation fixup
gzipping man pages under /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/share/man/
strip is /nix/store/4sdh09gmvl15cy0zb6i7mbvxh5syz206-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/lib  /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018/bin
patching script interpreter paths in /nix/store/70bjknx7si5wdx2sfg4iammlzlb1vgbh-gromacs-2018

Success on x86_64-linux (full log)
Partial log (click to expand)
-- Installing: /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/gmx-completion-gmx.bash
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018
shrinking /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin/gmx
shrinking /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/lib/libgromacs.so.3.0.0
gzipping man pages under /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/share/man/
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/lib  /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018/bin
patching script interpreter paths in /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018
checking for references to /tmp/nix-build-gromacs-2018.drv-0 in /nix/store/i2ls9z094j6a3vqvq6gz4hyhl86dh31d-gromacs-2018...

Success on aarch64-linux (full log)
Partial log (click to expand)
-- Installing: /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018/bin/gmx-completion-gmx.bash
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018
shrinking /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018/lib/libgromacs.so.3.0.0
shrinking /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018/bin/gmx
gzipping man pages under /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018/share/man/
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018/lib  /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018/bin
patching script interpreter paths in /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018
checking for references to /build in /nix/store/83zh6xyhx0yk9wiga7j55j7lv5gzfrrz-gromacs-2018...


redhat.sap_install.sap_hana_preconfigure : Include OS specific vars Issue

While running sap_hana_preconfigure on azure blank host (RHEL for SAP HA + US) faced with following issue
TASK [redhat.sap_install.sap_hana_preconfigure : Include OS specific vars] **********************************************************
failed: [localhost] (item=/usr/share/ansible/collections/ansible_collections/redhat/sap_install/roles/sap_hana_preconfigure/vars/RedHat_8.yml) => {"ansible_facts": {}, "ansible_included_var_files": [], "ansible_loop_var": "item", "changed": false, "item": "/usr/share/ansible/collections/ansible_collections/redhat/sap_install/roles/sap_hana_preconfigure/vars/RedHat_8.yml", "message": "We were unable to read either as JSON nor YAML, these are the errors we got from each:\nJSON: Expecting value: line 1 column 1 (char 0)\n\nSyntax Error while loading YAML.\n  block sequence entries are not allowed in this context\n\nThe error appears to be in '/usr/share/ansible/collections/ansible_collections/redhat/sap_install/roles/sap_hana_preconfigure/vars/RedHat_8.yml': line 283, column 47, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# The following two parameter should always be set:\n  - {name: net.core.somaxconn, value: 4096}   - {name: net.ipv4.tcp_max_syn_backlog, value: 8192}\n                                              ^ here\n"}

Here is playbook
---
- name: Apply SAP Ansible roles to localhost
  gather_facts: true
  hosts: localhost
  become: true
  become_user: root
  roles:
    - redhat.sap_install.sap_general_preconfigure
    - redhat.sap_install.sap_hana_preconfigure

same issue when running same playbook on RHEL for SAP 8.4 blank host on IBM Cloud

It seems to be confused by the commented line.
What is your ansible version?

[azureuser@rhel84 ~]$ ansible --version
[DEPRECATION WARNING]: Ansible will require Python 3.8 or newer on the controller
starting with Ansible 2.12. Current version: 3.6.8 (default, Sep 12 2021, 04:40:35) [GCC
 8.4.1 20200928 (Red Hat 8.4.1-1)]. This feature will be removed from ansible-core in
version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False
 in ansible.cfg.
ansible [core 2.11.12]
  config file = None
  configured module search path = ['/home/azureuser/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.6/site-packages/ansible
  ansible collection location = /home/azureuser/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.6.8 (default, Sep 12 2021, 04:40:35) [GCC 8.4.1 20200928 (Red Hat 8.4.1-1)]
  jinja version = 2.10.1
  libyaml = True

ansible installed with pip3, following command
sudo pip3 install ansible -y

Issue stays even if I use python3.8 on Azure VM.

The problem might be related to the Ansible version you are using on RHEL 8.4. I suggest that you run some tests with an Ansible version which is supported and delivered in a RHEL 8.4 package. The last Ansible version for RHEL up to and including RHEL 8.5, according to https://access.redhat.com/articles/6393361, is 2.9.

Issue resolved
On line 282 in file https://github.com/sap-linuxlab/community.sap_install/blob/main/roles/sap_hana_preconfigure/vars/RedHat_8.yml#L282
Following code is copied incorrectly to RPM, it is in one line in RPM, not in two lines, as it supposed to be.
  - { name: net.core.somaxconn, value: 4096 }
  - { name: net.ipv4.tcp_max_syn_backlog, value: 8192 }

@kksat As a workaround until the bug is fixed, you can use the Ansible roles under /usr/share/ansible/roles instead of those with the same names under /usr/share/ansible/collections/... .


Linear: Add attachments on Create Issue

Description
Add a file picker on the Create Issue command to add a single attachment on a newly created Linear issue
Screencast
https://user-images.githubusercontent.com/16003285/214275210-3a7d385a-497b-4ab7-a27e-cd86d5e86707.mp4
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Neat addition and perfect for filing some bug reports :-) Would it make sense to allow uploading multiple attachments?

Makes perfect sense. I added a single attachment as of now for simplicity's sake. I added this feature request to the backlog!

Yeah, let's start simple.


fix(parseURL): handle data: and blob protocols

🔗 Linked issue
Resolves #158
❓ Type of change

[ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
[ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality like performance)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description
As parseURL accept an ambegious input (path or URL), we cannot allow all proto:... without proto:// syntax. This PR adds special handler check for data and blob
📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Parsing can be optimized. Following up in next PRs.


vscode:(version 1.74.3) not supported: Cannot install nbdev extension on VSCode

Getting this message while installing on VSCode-1.74.3
Can't install 'hamelhusain.nbdev' extension because it is not compatible with the current version of Visual Studio Code (version 1.74.3).

Same issue, can't install for VS Code 1.75.1 too.

It's solved . I installed it for my vs code version : 1.77.3


Fetch with cookies

This PR adds init options for fetch() request. Only credentials supported in these changes.
https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch
Related: https://github.com/koute/stdweb/issues/67
Bonus: Badges reordered in README.md.

bors r+

bors r+


[sig-scale] virt-controller-node workqueue has too many key requeues

What happened:
Thanks to the PR #7879 the virt-controller now has higher throughput, and VM creation latency is lower.
By increasing the throughput we are able now to see some hidden issues that was not showing up before. For example, when creating 1k VMs, there are a lot of requeues in the virt-controller-node workqueue.
In the figure below, the first bump is the original virt-controller QPS/Burst configuration, the other ones are increasing the QPS/Burst.

What you expected to happen:
Lower requeue by fixing what is preventing the key to be properly processed or maybe increase the requeue time if possible. This will improve the performance and scalability.
How to reproduce it (as minimally and precisely as possible):
A cluster where you can create a large number of VMs, in my case was 1k.
Increase the virt-controller QPS/Burst
Additional context:
Environment:

KubeVirt version (use virtctl version): N/A
Kubernetes version (use kubectl version): N/A
VM or VMI specifications: N/A
Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): N/A
Kernel (e.g. uname -a): N/A
Install tools: N/A
Others: N/A

NodeController in virt-controller is doing kind of monitoring for node responsiveness and node orphaned/errored VMIs so by design it constantly re-enqueue nodes(with 1 minute delay). The catch is that the controller watches for both node and VMI events, so 1 minute after the burst of VMI events there will be a burst of re-enqueue. The reconciliation is short and simple(if the node is responsive) but still can impact virt-controller performance. To improve this we should reconcile nodes and VMIs but re-enqueue only on node events.


Improve Python program metrics collector and add test

use MultiAssignableMetrics to record threads' metric
bug fix on GC metrics collector naming
add test using Mock

👍


Discuss: Should 3rd party language grammars be version tagged?

We're just about to introduce some nice new features in version 11 (such as multi-class modes, beforeMatch, etc).  These improvements should make doing some complex things much simpler than it was previously - including some things that were perhaps impossible before.  Grammars using these (or other future) new features would then no longer be backwards compatible with version 10.
If so, should this just break silently or with a strange JS error (whatever it might be)?  Or should we add some sort of version info to the language definitions:
{
name: "SmartSQL",
requiresVersion: "11.0.0",
}

If we did this, what would the expected behavior be?  Would older grammars result just result is us console.error logging that the grammar was incompatible with the current version?

Also, our build system makes no accounting for different distributable assets, but I imagine someone wanting to live in the new world could just rename smart_sql.min.js to smart_sql_v10.min.js and update the README accordingly.
I guess mostly I'm talking about the "simple" CDNs + static distributable use cases... On the NPM side this could all be dealt with by correct version pinning and that's indeed what should happen for NPM packaging I think.  If you make a change to your library that requires version 11, then you should indicate that in your package.json.  I'm not sure we've encouraged grammars to have us as an official dependency in the past (since technically we aren't), but this may be something we need to change.  Although perhaps we should be using peerDependencies?  I'm not 100% sure.
This same issue would also apply to plugins as well.
Open to thoughts and feedback here.
@highlightjs/core @highlightjs/grammar-maintainers

This is a welcome addition in every place I've ever seen it.  Strongly supported.

Although I was just thinking hljs is exposed to languages - and that includes the version info... so they could also perhaps do a check themselves against versionString (though perhaps we'd expose a nicer API).  A grammar (since it's run-time code)  could even detect if it was running on v10 or v11 and then adjust itself to provide the best results for either... so I think that actually might complicate the matter just a bit more.
Although I suppose we could have it both ways... a grammar could say requiredVersion: "*" or some such if it wanted to try to handle the versioning info itself.

Version tagging sounds nice. Lets say the major version should always conform the major version of hljs. For instance my version would be 10.0.1 now. And when I make something that require 11 at least then 11.0.0 and so on...

Yeah I would probably support/require all 3 digits and then you could say "I support >10.2.0" or I support ">11.1"... that doesn't cover us removing features in a major version, but I'm not sure it's within scope to cover all possibilities.  At this point I'm more worried about grammars using new feature on old engines.  I'm also fine with this remaining a discussion for a while and waiting to see if it's a real issue in practice before we jump to solving it.  I just wanted to start the discussion early.

My opinion is that if you do this, which I support, that you should use the
semver stuff from the standard library. Principle of least surprise, and
all that jazz
On Fri, Apr 2, 2021, 4:47 AM Josh Goebel @.***> wrote:

Yeah I would probably support/require all 3 digits and then you could say
"I support >10.2.0" or I support ">11.1"... that doesn't cover us removing
features in a major version, but I'm not sure it's within scope to cover
all possibilities. At this point I'm more worried about grammars using new
feature on old engines. I'm also fine with this remaining a discussion for
a while and waiting to see if it's a real issue in practice before we jump
to solving it. I just wanted to start the discussion early.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/highlightjs/highlight.js/issues/3096#issuecomment-812496445,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAS5KWHENUYKT5C6UXFRDDTGWVGVANCNFSM42HXPPXA
.

from the standard library.

What standard library?  semver?  I'd have to look at how much code it pulls in.
https://packagephobia.com/result?p=semver%407.3.3
All together that's a HUGE dependency when generally we believe in 0 dependencies.  I honestly don't WANT us specifying versions with such insane specificity.  If that is required, we've broken something badly.  If that was required then I'd just push it back onto the packager and say if people need maximum compatibility guarantees to use npm/yarn for dependency management rather than rebuild the same thing ourselves.  So what we do has to be simple and useful and minimal.

:+1: for adding basic semver support. I don't think it's necessary to bring in the semver package; on the Node.js side, we can encourage peerDependencies.
Now, for internal and CDN use. What if we supported something super simple like this:
10.7.0|11

This would mean:

it will support every minor and patch release in the 10.x series after 10.7.0 (inclusive)
it will also support everything in the 11.x series starting at 11.0.0

When we release a hljs 12, the core library will throw a warning that a specified language has not been tested on the 12.x series (with a way to silence these warnings).

I'm thinking rather than force everyone to manage this (bump versions, keep track of what is compatible with what) that perhaps the library should just do some stronger checks at grammar compile time.  Examples:

If a scope key exists but v10 doesn't know what that is, error.
If match is an array but v10 expects it to be a string/regex, then error.

Generally breaking changes with grammars are changes to the keys and/or "shape"/types of the data allowed... so it should be possible to detect incompatible grammars merely by looking for unexpected keys or values.  Thoughts?

There will be times at which you won't be able to detect.

Occasionally those will be problematic

You can just make it optional.  Most people will skip it.
People who need to constrain the floor version because of support, and know that, will be glad the facility exists.
If you look at it the way node looks at engine, then it's generally an at-author-time one-time thing; as the library increments we have no maintenance cost.

We don't have to keep track of anything or bump anything; we just say something like "my highlighter needs at least v9."  That won't change in v10.

You could do it yourself, but it's a big burden on you, and it's just as good to make this optional and leave it a once-write, IMO.

Good thoughts.

You can just make it optional. Most people will skip it.

I feel like that's a point for the auto-detection though.  If most just skip it then people just randomly find grammars that don't work anyways - and that was exactly the kind of thing we were trying to avoid. :-)  Mostly here I'm just trying to avoid the urge to solve problems that really don't exist (or won't exist) in the real world.  I feel like this is maybe a good idea, but how many people is it helping, how much time is it really saving vs investment, etc?
There is also a chicken/egg problem here in that anything we add doesn't exist in v10.  So it actually doesn't help ANY existing users... of course we could add it to the very latest v10 release... but that doesn't help anyone running prior versions of 10.  But again I worry this actually isn't a huge problem to begin with.  If anything right now I'd start with:
requiresVersion: 11

Integer. No semver, no nuance, just a big flag drawing a line from 10 to 11.  But adding this isn't at the top of the list.

Nothing official made it into 11 but we'll keep an eye on this as we go thru the 10 -> 11 transition and perhaps by the time 12 rolls around (or sooner) we'll have  a better idea of what is needed here.

Closing for now, can be reopened in the future if necessary.


deps(spdx-utils): Update the SPDX license list version to 3.25.0

Done by running [1].
Note: The trailing ".0" in the version string is intended, because the Git tag format has been changed.
[1] ./gradlew --no-configuration-cache generateSpdxEnums

Note: The trailing ".0" in the version string is intended, because the Git tag format has been changed.

That comment is obsolete now as that change happened from version v3.23 to v3.24.0 already.


Merlin for arabic speech synthesis

I'm trying to use Merlin to produce Arabic speech, i used the same label files as for HTS, same question file as well, everything went well except for long sentences, starting from the second half of the sentence, some words disappear, i tried different solutions :
1- I put the long sentence in the training corpus
2-I checked if the missing words do exist in the training corpus
3- I tried to produce only the second half of the sentence
unfortunately, none of theses solutions worked out.
I'm wondering if anyone already had this problem with long sentences ?
amal

Have you solved this issue?


Establish H3 equivalent for NaN?

Maybe somewhat random, but would it make sense to establish a convention for something equivalent to floating point NaN, but for H3. Something to indicate missing or invalid data?
This could be useful for when users are processing arrays of H3 indices, and need a way to represent missing data. For example, integer arrays are sometimes cast to float for this purpose, due to the lack of a NaN for integers.
This could be as simple as stating that 0 is the "NanH3", which is essentially what we already implicitly do in the library. It could be beneficial to establish this convention officially.
I'm not sure this would even require a code change. Maybe just stating this in the docs somewhere as the recommended convention. A code change might be as small as just establishing a constant in the C code.
Thoughts? I don't have a killer use case for this yet, but I thought there was a chance it might be useful in the future.

We have a constant H3_INVALID_INDEX for this purpose:
src/h3lib/include/h3Index.h:#define H3_INVALID_INDEX 0

We should add to the documentation that unlike other modes, the API specifies the index 0 will not be valid in the future.

Ah perfect!
However, I'm not sure I understand what you mean here:

unlike other modes, the API specifies the index 0 will not be valid in the future.

Ah perfect!
However, I'm not sure I understand what you mean here:

unlike other modes, the API specifies the index 0 will not be valid in the future.

The Index format supports multiple modes, but we currently only use two. We have plans for a third, so that collection of indexes will then become valid. But a full zero set of 64 zeroes will never be a valid H3 Index value (since it's not valid under mode zero, it's impossible for that to change).

Got it. I do wonder if there's a slight difference between "being invalid" (which, as y'all have sated, may change in the future) and the "NaN of H3".
Uniqueness would be the big one, probably. We wouldn't want folks having the freedom to use just any invalid index for NanH3.
The NanH3 might indicate a little more meaning: missing data and/or a potential return value for a nonsensically-called function (but error codes might handle that better). Just a regular invalid index would have a bit less meaning: just gibberish, and would probably indicate a bug somewhere.
If you buy those arguments, then H3_INVALID_INDEX might not be as descriptive of a name as something like H3_NAN or H3_NAI (not an index?).

I personally like H3_NULL since it is literally a 8 NUL bytes.

Closed with #379


chore: Add location information to memory operations

Description

Problem*

Resolves #1412
Summary*
Adds location information to memory operations and handle the new index-out-of-bounds error from ACVM.
We therefore need a new ACVM with PR https://github.com/noir-lang/acvm/pull/468 merged in.
Documentation

[ ] This PR requires documentation updates when merged.

[ ] I will submit a noir-lang/docs PR.

[ ] I will request for and support Dev Rel's help in documenting this PR.

Additional Context

PR Checklist*

[X] I have tested the changes locally.
[X] I have formatted the changes with Prettier and/or cargo fmt on default settings.

Is this PR still needed? It is showing as 0 lines changed currently.

Is this PR still needed? It is showing as 0 lines changed currently.

Indeed, after merge from master, it has no more changes, so the feature is already there. I close it.


[Gradle Plugin] make generating operation ids part of the task graph

Closes #2455
This pull requests adds the possibility for users to wire their own GenerateOperationIdsTask with setGenerateOperationIdsTaskProvider
. For an exemple:
abstract class GenerateCustomOperationIdsTask: ApolloGenerateOperationIdsTask() {
  override fun generateOperationOutput(operationList: OperationList): OperationOutput {
    return operationList.map {
      // use the operation name as Id
      it.name to it
    }.toMap()
  }
}

configure<ApolloExtension> {
  onCompilationUnit {
    val task = tasks.register("generate${name.capitalize()}OperationIds", GenerateCustomOperationIdsTask::class.java)
    setGenerateOperationIdsTaskProvider(task)
  }
}

To do this, I had to split the main task in three:

generate${variant}${service}ApolloIR: takes the schema and GraphQL files as input and generates ir.json and operationList.json as output
generate${variant}${service}ApolloOperationIds (or the task registered by the user: takesoperationList.json  as input and generates oprationOutput.json  as output
generate${variant}${service}ApolloSources: takes ir.json and operationOutput.json  as input and generates the models

@sav007 Regarding performance, below are a few build scans using 24k lines of Github queries resulting in a 10MB ir.json (and doing rm -rf build and changing the plugin version in between builds):
With the IR serialisation (this branch):

https://scans.gradle.com/s/rmfibi3vrpeog -> 6.9s
https://gradle.com/s/fdrw7h7rzg6im -> 7.1s
https://gradle.com/s/sba6i4iaswbqw -> 7.2s

Without (master):

https://scans.gradle.com/s/a2n5pyv5jgufe -> 6.5s
https://scans.gradle.com/s/g4ciudzqg5zjw -> 5.4s
https://scans.gradle.com/s/y73mhrkr3k3h4 -> 6.5s

There is a performance impact in the of order of 7-8%. Of course it depends a lot of factors like the warmness of the gradle daemon and stuff but the above should be a good approximation.
Serializing ir.json takes ~100ms (same for deserializing) so they account for ~200ms in the ~500ms slowdown, the rest being the bigger task graph I guess, time checking the up-to-date-ness of the inputs and computing checksum?
0.5s might not be a huge thing in the grand scheme of Android builds but it might be worth keeping everything as a single task and relying on bumping version as we currently do. Let me know what you think. (Also ping @DSteve595 for awareness.)

I updated this PR to keep everything in a single task and skip serialization. Sample usage is in the (edited) original post. Let me know what you think.

Does operationDescriptorList need to be a List? Does a Set make more sense, since there's no inherent ordering?

Does operationDescriptorList need to be a List? Does a Set make more sense, since there's no inherent ordering?

I guess it can even be a Collection. Let me try

I'd like to make a release this week. If there's no additional comments, I'll merge this tomorrow so we have some time test the snapshots until a release at the end of the week.


Dimmer device remote status

However "brightness_state_topic" defined in the templates, it seems that Domoticz AD will not update Dimmer status if changed on the remote side.
Needs sample data and payloads to report upstream.

"bri_val_tpl" is not working
https://github.com/domoticz/domoticz/issues/5824

"state_on" and "state_off" added to Dimmer devices at commit https://github.com/enesbcs/shellyteacher4domo/commit/fb4220ea77540eb88600e147cc9cb40c309325c3
From Domoticz 2023 beta 15597 version the Dimmer devices ON/OFF and brightness state reported correctly in Domoticz when teached with latest ShellyTeacher


⚠ Bofrost.be has degraded performance

In c8739df, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2272 ms

Resolved: Bofrost.be performance has improved in c5a4796.


swipe broken when continously swipe rows in ios

when open continually swipe rows  swipe got broken and rows are not able to swipe, its only occurs in real device of ios (all devices)
Steps to reproduce
At least swipe 7times on diffrent postion like first scroll a listview up and down and next swipe a rows left to right ,now rows are get jumped in every swipe.and not opened the rows.

Hey @Jagadeesh-Govindaraj thanks for the report! I'm almost positive this is a dupe of issue #34 which currently doesn't have a fix. Going to close this but it's being worked on


rxjs: add bindCallback funtion

as documented in
http://reactivex.io/rxjs/class/es6/Observable.js~Observable.html#static-method-bindCallback

Could you add a test for this?

Hello. Consider:
static bindCallback(
f: (...args: any) => void, // Change to this part.
selector?: () => T,
scheduler?: rxjs$SchedulerClass
) : (...args: any) => rxjs$Observable;
When converting function to Observable. Setting return to void is desirable because the return won't be returning and will be lost. Makes sense?

This hasn't been updated for quite a while.
If this is still relevant please submit a new PR.


Where to enter amount of nft i want to generate?

Hey in the previous version there was a line "generate_unique_images (50, {"
In the updated 2.0 version I can't find where should I enter the amount :(  I have this error now: "heimdall: error: Missing a mandatory option (-n or -c). Use -h to show the help menu"

The module uses argparse now, so you tell it how many to generate using the -n flag. To tell it what config to use, use the -c flag.
Ex: generate.py -n 10 -c config.json

Got it! Thank you


Add NodeType.checkContent method

I noticed that the RangeError thrown by Node.check will include some debugging information, which is super useful. I'd like to add these debugging strings to the other two places that check the content, so I add a new NodeType.checkContent for this purpose.
I marked checkContent as an internal method just because I think it might be too small for a public API. I will remove @internal if your think it's better to set it as a public API (so that we can use this method in prosemirror-transform).

Good idea! Merged.


SVC with RobustScaler

Should I make any changes?

Hey Goodmorning,
just add few lines of description for RobustScaler in the model section max 2-3 lines

Yeah done with the updates can you verify it


test(Toaster): add more tests

Seems, these tests know a lot of the component's internal logic.

Seems, these tests know a lot of the component's internal logic.

Yes, i need to know animation name to trigger animationend event in some cases


Adding sections prop, removing series and colors props

Description
It didn't make much sense to have colors and series in their own separate arrays, when in reality they are tied to the same logical entity (both work together). I have clubbed them together in a single sections object. My argument is this makes the Pie more readable and easier to use.

Other Details
PropTypes were changed to reflect the new structure.
Changed the readme and examples
Bumped package version to a major because this is a breaking change.

@nihgwu Let me know what you think!

@zgordon01 Thanks for your contribution, I love the idea

it's out of scope, but it would great if you could help to verify if this workaround could be removed 86adf51, which is mentioned here

This could be included in a separate Pr as it's out of scope

Addressing https://github.com/nihgwu/react-native-pie/issues/25

@zgordon01 OK, that's go with this for now, I asked your help on removing the workaround because I don't use React Native for years so I can't do it myself, BTW, if you are willing, I can add you as the maintainer of this package

@zgordon01 OK, that's go with this for now, I asked your help on removing the workaround because I don't use React Native for years so I can't do it myself, BTW, if you are willing, I can add you as the maintainer of this package

When I get time I can look into the workaround you mentioned. Also I would love being a maintainer of the package, in addition to @milindagrawal. We are currently both working on integrating this into our app and you might see some more PRs from us.


Build binaries and images on arm

Current dependencies on/for this PR:

main

PR #183   👈

This comment was auto-generated by Graphite.