Feature to connect to redis-cluster hostdomain from lettuce

Feature Request

Is your feature request related to a problem? Please describe
A clear and concise description of what the problem is. Ex. I have an issue when [...]
Hello,
When connecting to redis-cluster, I want to connect to the host domain.
I confirmed that it was possible to connect to individual nodes.
However, I need the ability to connect only with the host information of redis-cluster.
Please provide the ability to connect only to the host of redis-cluster.
If there is an existing method, please provide guidance.
Thanks
Describe the solution you'd like
I want to connect only with the host name, rather than defining each node as shown below.
To-Be
    val clusterConfig = RedisClusterConfiguration().apply{
        this.setClusterHost("redis-cluster.com:6379")
        this.password   = RedisPassword.of(redisPassword)
    }

As-Is
   val node1 = RedisNode("<IP_ADDRESS>",6379)
    val node2 = RedisNode("<IP_ADDRESS>",6379)
    val node3 = RedisNode("<IP_ADDRESS>",6379)
    val clusterConfig = RedisClusterConfiguration().apply{
        this.setClusterNodes(setOf(node1, node2, node3))
        this.password   = RedisPassword.of(redisPassword)
    }

As-Is full code
   val node1 = RedisNode("<IP_ADDRESS>",6379)
    val node2 = RedisNode("<IP_ADDRESS>",6379)
    val node3 = RedisNode("<IP_ADDRESS>",6379)
    val clusterConfig = RedisClusterConfiguration().apply{
        this.setClusterNodes(setOf(node1, node2, node3))
        this.password   = RedisPassword.of(redisPassword)
    }
    val options = ClientOptions.builder()
        .disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS)
        .autoReconnect(true)
        .socketOptions(SocketOptions.builder()
        .keepAlive(SocketOptions.KeepAliveOptions.builder()
            .enable(true)
            .build()
         ).build())
        .build()
    val clientConfig = LettuceClientConfiguration.builder()
        .clientOptions(options)
        .commandTimeout(redisCommandTimeout)
        .build()
    return LettuceConnectionFactory(clusterConfig, clientConfig)

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Teachability, Documentation, Adoption, Migration Strategy
If you can, explain how users will be able to use this and possibly write out a version the docs.
Maybe a screenshot or design?

How is the client supposed to resolve the initial cluster node? Generally, if there's an A or AAAA DNS record, then you can use redis-cluster.com already.

@mp911de
Can I get a lettuce sample code based on kotlin that connects to the host of redis-cluster?

@mp911de
thank you! As you guid, I entered the domain instead of the server IP and it connected normally!

I am assuming the issue is resolved. Please reopen in case you are still facing an issue.


Right hand RigidMount of prototype 4 does not have a download button

Prototype 4's left hand rigid mount has a download button and seems to be working as intended.
The right hand rigid mount does not have a download button, and is significantly larger for a file that should be basically the same as the left (76KB vs 374KB).

Same issue here

it is recommended to download the entire repository, then use the files from the download. You can download the repo by pressing the green code button on the homepage, then pressing download zip.


CLOUD-515 added version check possibility

@keyki or @matyix

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/periscope-build-pull-request/8/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/periscope-build-pull-request/9/


BPIP-3: Pre-minted Vouchers (Shell rNFTs)

The proposal describes a new feature which allows sellers to pre-mint vouchers, making them available for primary purchase on NFT marketplaces.

Hi @cliffhall, do you mind adding author field to the proposal? Thanks!


Æternal notification about seed phrase linking no where

Hi!!
I have noticed that the notifications bell of the extension is always showing the "You need to backup your seed" , even though you have already done so, the bell still keeps on showing a "1".
And when clicking the bell to see the notification, you see a supposedly clickable text to backup the seed that does nothing when clicking. This happens in both Firefox and Chrome version 0.0.9.

thanks  @mradkov , closing  the issue....


Issues with greedy_facility_location.py

Hi,
I think the file greedy_facility_location.py  is not executable because I can see in the
line 31
#for lab in dat['gt_f'].shape[0]): There are some unbalanced parenthesis
line 38
no = numpy.argmax(d)  . d is not defined.
It would be great if you can share your code which you used for the results obtained in the ICLR paper

Also according to the paper you should be using Subset s for calculating the distance matrix if I'm not wrong. But in this code you are not computing the distance matrix with the subset . This file is also not error free . Can you please fix the errors?

Most of the code is actually not complete.
The implementation details provided in the paper are different from those that in the repo. Can you please let us know why?

This is only the active learning part. The actual training part is not here. Unfortunately, we can not open source it but it is based on http://torch.ch/blog/2015/07/30/cifar.html.
If you only need the greedy solver, you can use this active learning module: https://github.com/google/active-learning/blob/master/sampling_methods/kcenter_greedy.py which also implements our method.
Full solver is functional if you generate and pickle the embeddings. I will add a how-to document for it.

Can you please let me know the implementation details of the method. Like
learning rate epochs per each iteration.. Etc etc
On Thu, Sep 20, 2018, 12:06 AM Ozan Sener<EMAIL_ADDRESS>wrote:

This is only the active learning part. The actual training part is not
here. Unfortunately, we can not open source it but it is based on
http://torch.ch/blog/2015/07/30/cifar.html.
If you only need the greedy solver, you can use this active learning
module:
https://github.com/google/active-learning/blob/master/sampling_methods/kcenter_greedy.py
which also implements our method.
Full solver is functional if you generate and pickle the embeddings. I
will add a how-to document for it.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ozansener/active_learning_coreset/issues/3#issuecomment-422912508,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AajsNy3H64YcmnWMPdDKLueB_UHLIa6zks5uco7IgaJpZM4WVjoN
.

We trained for 200 Epochs and half the LR at every 50 epochs. We are using random horizontal flips. We subtracted average R,G,B values from respective channels.

Cool thanks a lot Ozan. But it was mentioned that lr was constant with
0.0001 and rms prop so it's a bit conflicting.
Also these settings are valid for cifar-100 also I hope. Most
importantly for reducing the weights of the input neurons, alpha in the
paper you are using regularizer I suppose?
On Thu, Sep 20, 2018, 12:21 AM Ozan Sener<EMAIL_ADDRESS>wrote:

We trained for 200 Epochs and half the LR at every 50 epochs. We are using
random horizontal flips. We subtracted average R,G,B values from respective
channels.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ozansener/active_learning_coreset/issues/3#issuecomment-422917747,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AajsNwjyosJ8qF41df5MsUb5xoDQfqa8ks5ucpI0gaJpZM4WVjoN
.

What is alpha? I do not remember any alpha in the paper.
Cifar 10 and 100 uses the same script.
As I mentioned, the network is exactly same as here: http://torch.ch/blog/2015/07/30/cifar.html We only used its Tensorflow version. They use SGD, wee use RMSprop thats the only difference. You can use that script and save the feature embeddings to file and use our code for active learning.

Sorry my bad.
Also the ratio of labelled images mentioned in the graphs refer to total
number of labelled images ?
Ratio of labelled images = [0.1, 0.2, ...1] So are you training with 5k
samples when you mean 0.1 for which you get an accuracy of ~30% ?
On Thu, Sep 20, 2018 at 12:33 AM Ozan Sener<EMAIL_ADDRESS>wrote:

What is alpha? I do not remember any alpha in the paper.
Cifar 10 and 100 uses the same script.
As I mentioned, the network is exactly same as here:
http://torch.ch/blog/2015/07/30/cifar.html We only used its Tensorflow
version. They use SGD, wee use RMSprop thats the only difference. You can
use that script and save the feature embeddings to file and use our code
for active learning.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ozansener/active_learning_coreset/issues/3#issuecomment-422921498,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AajsN7XGxlVLo-sKQb-9E_Ifx5TLSpmeks5ucpTqgaJpZM4WVjoN
.

Yes, the ratio is to the full training set.

This is only the active learning part. The actual training part is not here. Unfortunately, we can not open source it but it is based on http://torch.ch/blog/2015/07/30/cifar.html.
If you only need the greedy solver, you can use this active learning module: https://github.com/google/active-learning/blob/master/sampling_methods/kcenter_greedy.py which also implements our method.
Full solver is functional if you generate and pickle the embeddings. I will add a how-to document for it.

Hi,
Do you plan to add a "how_to" document anytime soon?!? It would be a great help to understand your method.
Thanks

I will make an update soon probably in the month of November with the detailed readme and training details.

I will make an update soon probably in the month of November with the detailed readme and training details.
Thanks Ozan,
I ran your code, and final results are some models saved as "*.sol" format( such as "s_100_solution_0.055231944963340884.sol"). Now how could I find which points have been chosen to be sent to the oracle?

@redsadaf
You can use the script at https://github.com/ozansener/active_learning_coreset/blob/master/coreset/gurobi_solution_parser.py
to parse the results

Hi Ozan,
Do you still have a plan to make an update soon with the detailed readme and training details?

Hi Ozan,
Could you please update the details of training settings and how to use your code?


Allow noEmit and composite together in 3.7

TypeScript Version:  3.7.0-beta
Search Terms: composite noEmit monorepo
Expected behavior:
In 3.6 I was able to compile with those 2 options enabled now in 3.7 beta I cannot do that anymore.
Actual behavior:
error TS5053: Option 'noEmit' cannot be specified with option 'composite'.
Related Issues: No?

@sheetalkamat this breaks vstsc for projects with composite because the task adds noEmit to the commandline

As part of it's incremental compilation, VS runs a pass with --listEmittedFiles --listFiles --noEmit.  cc @uniqueiniquity

interesting.. Technically with --noEmit shouldn't listEmittedFiles be empty list?

@sheetalkamat, I would think so too, but @uniqueiniquity or @PranavSenthilnathan would know more about why it's there.

It should - I don't think --listEmittedFiles necessarily needs to be part of that pass.

The issue seems to be back in 3.8.2.

The revert was reverted again in https://github.com/microsoft/TypeScript/pull/36483 because, per https://github.com/microsoft/TypeScript/issues/32882, it really doesn't make sense to have incremental and noEmit together, since noEmit prevents us from writing incremental metadata. (So nothing is actually incremental).
You should consider emitDeclarationsOnly instead of noEmit, if you actually just want incremental checking.

Thank you. It makes sense.

For other readers: the parameter to use is emitDeclarationOnly (declaration is singular).

@weswigham right now its impossible to use composite projects, where one of the project is react-based. Because create-react-app adds "noEmit": true to tsconfig automatically (even if you set it to false, once you run app it will change it to true) it makes impossible to use react and composite projects.
Its a big issue because guess over 95% of react users use create-react-app.

I'm still not sold on this. I used noEmit within our tests folder, because we don't want test files being compiled, nor generating declaration files. Now this pattern isn't possible without using a ton of gitignore patterns.

I am in the exact same situation as you are; I was using noEmit with incremental on test files. However the point is that you're not actually benefiting from incremental if you are not emitting declaration files.

Now this pattern isn't possible without using a ton of gitignore patterns. (...) It also breaks other tooling like ESLint as these built files are now being pulled in (...)

I wonder about the specifics of your project. For ours, all build artifacts are in a build/ folder. It is ignored by both git and ESLint. When setting emitDeclarationOnly for test files, I didn't have to change anything as the declaration files were emitting alongside the normal code.
The only thing I have to add is something to delete these declaration files when publishing.

This isn't the project, but a similar setup: https://github.com/airbnb/lunar/blob/master/packages/core/test/tsconfig.json Each test folder has its own tsconfig.json, separate from the package itself, since it has different requirements.
Now that incremental emits files, it's converting our test files to js, like foo.test.ts -> foo.test.js, which resulted in ESLint running against all of these new js files (and failing a ton). I got around this with emitDeclarationOnly: true, and gitignoring the d.ts files, but it still feels super ugly.

I got around this with emitDeclarationOnly: true, and gitignoring the d.ts files, but it still feels super ugly.

You can also use the declarationDir option to dump the declaration files in a cache directory that's easier to ignore, if you'd prefer.


Feature request: note public fields as readonly in cargo docs.

This crate is cool, thank you! I've tested that indeed I can write the following in crate foo:
# crate/foo/src/lib.rs
#[readonly::make]
pub struct Data {
    #[readonly]
    pub name: String,
    ...
}

And then within that crate, I can do data.foo = "blah".into() or whatever, but from outside the crate attempting to set data.foo yields a DerefMut compilation error.  That's awesome, thank you.  However the generated docs still show:
pub struct Data {
    pub name: [String](https://doc.rust-lang.org/1.79.0/alloc/string/struct.String.html),
    /* private fields */
}

If would be nice if the docs somehow automatically showed the field as read-only. How, I'm not entirely sure. I see two obvious options:
A:
pub struct Data {
    #[readonly]
    pub name: [String](https://doc.rust-lang.org/1.79.0/alloc/string/struct.String.html),
    /* private fields */
}

B:
pub struct Data {
    pub name: [String](https://doc.rust-lang.org/1.79.0/alloc/string/struct.String.html), # read-only
    /* private fields */
}

Right now I'm forced to manually explain in the accompanying help text that the fields are read-only, which is less than ideal.

I think relying on the crate author to explain using handwritten docs the intended use of the type, including the fact that writing to the field is not supported, is my preferred approach.


Fix typo in keyword kmw_embedjs for prism-keyman.js

Added extra keywords baselayout, layer, platform, as well


Error: connect ECONNREFUSED ::1:8000

Hello,
I was curious about your stripe implementation and stumbled on a few problems:
SECRET_KEY = os.environ['SECRET_KEY'], I guess you have an .env file?
To test, I can access http://localhost:8000/api/categories/?format=json but the client react app fails with Error: connect ECONNREFUSED ::1:8000

Hey, I published the django secret key since this project isn't used in production. The stripe keys need to be setup yourself and added to a .env. Also the STRIPE_PUBLISHABLE_KEY needs to be set in settings.py. Let me know if that helps :)

Thank you @courtneypattison :)
I solved that by replacing it with string. The issue is mainly the ECONNREFUSED ::1:8000.
If you can do a fresh install of it, you might get the same issue. I'm using Ubuntu, maybe there's a difference.

I found the issue and made a PR!
See https://github.com/courtneypattison/thegrouch/pull/2
In vite config file, it must be target: "http://<IP_ADDRESS>:8000",
I was helped by the reply at https://stackoverflow.com/questions/75994380/how-to-resolve-error-connect-econnrefused-13306-on-my-node-js-backend

Awesome, thank you so much!


Interoperability between Rucio and DestinE data management

Short Description of the issue
In our workflow, output from DT Flood Early Warning and DT Flood Climate Impacts is written to Rucio.
Here we discuss interoperability requirements and impacts related to integration of interTwin core modules with DestinE.

The equivalent technology for Rucio in the DestinE projects would be the Polytope API for fetching the DT Extremes and DT Climate data, and the DestinE HDA. Incorporating these technologies into our workflows is part of the DestinE 370a work. How to integrate those technologies with Rucio is something that should be discussed with the Rucio team

notes from meeting with Thomas

action to figure out how rucio can talk to polytope and / or HDA
action to understand how dcache fits into this ecosystem

notes from meeting with Andrea

polytope reads data from datalake

HDA is interface to datalake (will store everything, single interface towards all available data, incl e.g. CDS)

need to integrate with both for the DT

approach from DestinE is to offer an interface to existing repositories (HDA)

[ ] chat to EODC (Christoph Reimer) who are contributing to both interTwin and DestinE datalake devs


How to build Java parts?

Hey there, I've stumbled upon your great work while trying to build my own solution with the original reverse engineered code. As I am basically trying to do the same thing you did, I tried building yours.
I tried "gradle build" from the gui folder. I got some jar files but no executable jars. I've only ever worked with gradle in the context of android studio and generally don't have much java experience. Can you help me?
Thank in advance.

I'm using IntelliJ IDEA, so you have to configure artifacts. There is a nice official guide here. When configured, you will need to build with Build > Build artifacts menu.
There are two artifacts: one for the client and another one for the server. That way you can generate two jars.
Note that you can also Run/Debug the client and server modules.

Hi @Sch1nken, I have created a new Gradle task called buildAll that will generate the server and client JARs. Just run gradlew buildAll and you're good to go. If you don't need to make changes to the code, you can use the precompiled JARs. Tell me if it works!


Hard delete items in decrypt box

I think it would be preferable to hard delete text that is pasted into the DECRYPT box, rather than allow edit undo, once it is deleted.
It is currently possible to EDIT -> UNDO (CMD + Z) to restore text pasted into the DECRYPT box, after it is deleted, which could potentially compromise security.

It appears that if you click the clear button instead of deleting the data in the box, this issue is mitigated.


Simplify the way WeldError parameter passed in

The way that WeldError parameter passed to weld_module_compile and weld_module_run looks obscure for now.
This is going to simplify it.

Hi @viirya,
Can you please fix the breaking tests? (you can run locally using cargo test)
Thanks!
Deepak

@deepakn94 I've fixed the tests. Please take a look again. Thanks.

ping @deepakn94

Hi @viirya,
There's a few places where this API update needs to be reflected. Can you update the following files accordingly (unfortunately these things aren't tested by the CI system yet, but they will be soon):

./examples/cpp/add_repl/add_repl.cpp (use weld_error_new instead of NULL)
./docs/api.md (add the new API call here)
./c/weld.h (add the new API call here)
./benches/benches.rs (update this in the same manner you updated integration_tests.rs; you can test it using cargo bench).

Thanks!

@sppalkia Thanks for pointing out the necessary changes! I've done the changes. Please take a look and let me know if anything else is needed. Thanks!

Hi @viirya,
This looks good! I'll go ahead and merge this in.
Thank you for contributing to the project! If you have any suggestions or comments, feel free to share your thoughts on the Google Group.

@sppalkia @deepakn94 Thanks for review!


fix pipelining

Addresses https://github.com/channelcat/sanic/issues/337.
$ wrk -t 10 -c 100 -d 10 -s pipeline.lua http://localhost:8000
Running 10s test @ http://localhost:8000
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    47.21ms   31.48ms 174.15ms   71.39%
    Req/Sec     1.27k   641.14     4.04k    67.24%
  126848 requests in 10.06s, 15.00MB read
Requests/sec:  12608.15
Transfer/sec:      1.49MB

@kolanos apparently you added the cleanup method, which doesn't seem necessary -- was there any reason for this, aside from it seeming like a good idea? Cleaning up the connection is preventing it from being reused, which is in turn violating HTTP 1.1

Haha, just removing cleanup can indeed resolve the pipeline issue.
But it's 78% slower on my machine without it.
With cleanup:
➜  sanic git:(master) ✗ wrk -t 1 -c 100 -d 10 http://localhost:8000                        <<<
Running 10s test @ http://localhost:8000
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.29ms  767.36us  12.59ms   61.52%
    Req/Sec    43.41k     2.80k   45.72k    89.00%
  432394 requests in 10.03s, 52.78MB read
Requests/sec:  43125.84
Transfer/sec:      5.26MB

Without cleanup:
➜  sanic git:(master) ✗ wrk -t 1 -c 100 -d 10 http://localhost:8000                        <<<
Running 10s test @ http://localhost:8000
  1 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    11.07ms    7.34ms  60.46ms   67.29%
    Req/Sec     9.43k     6.52k   43.01k    89.00%
  93852 requests in 10.03s, 11.46MB read
Requests/sec:   9359.23
Transfer/sec:      1.14MB

Derp :) I swear we need more tests...

@zkanda btw thanks, I thought we had just gotten much slower :facepalm:

@r0fls I can't remember the reasoning behind the cleanup method, so remove/alter as necessary.

The cleanup method is so that keep-alive works as intended. After every request the variables that are set for the particular request should be cleaned up.
It's not a perfect implementation but it works for right now.


Cannot vote , ENS all good

Deposited 1.5 ENS , ENS still 0 !
Voting for FOR!
izzyfrkz.eth

@izkillaz You should have some tokens in your wallet before the snapshot. and should you should delegate your self before the snapshot block to be able to vote on ENS proposals, more details here: https://github.com/snapshot-labs/snapshot/discussions/1015
closing this, feel free to reopen if needed. Thanks

Ok will do that next time.


Main

👷 Deploy Preview for damyanadesign processing.
🔨 Explore the source changes: 45f5a07ea48b98f0c73452d63141f56f611a9c07
🔍 Inspect the deploy log: https://app.netlify.com/sites/damyanadesign/deploys/6145e5921f6f69000728a48e


WIP: path MTU discovery

This adds initial support for PMTUD. The PMTU starts at 1200 bytes
(minimum QUIC packet size), then 1452 is tried (maximum QUIC packet
size). If the probe fails we keep using 1200 and not attempt any
additional probe.
Due to the fact that the probe might be lost due to a lower path MTU, we
also need to ignore PMTUD probe losses for congestion control purposes,
otherwise we might decrease the cwnd even though there is no actual
congestion on the path.
The probing happens immediately after the handshake is completed (on the
server it is sent after HANDSHAKE_DONE, to avoid delaying the handshake
confirmation), so it might be too aggressive as it means the connection
incurs the cost of sending the additional packet even when the total
number of bytes is very small (e.g. potentially if the whole data would
have taken a single flight to send, it will now take 2).
For these reasons, PMTUD is disabled by default, and can be enabled with
a config flag. In the future we can experiment with smarter strategies.

I need to some additional testing, but this should be ready for review now.

A couple of thoughts:

C FFI for discover_pmtu() is needed too?
I recommend to try 1350 (not 1452) first and fall back to 1200: For example Google uses 1350 as a default value - See sectino 7.1 of https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46403.pdf
When PMTU is updated by a new PMTU discovery, congestion control need to be notified for ths change of max_datagram_size to tune cwnd changes properly. e.g. let's say we start with initcwnd 10 x 1452, when we found that actual MTU is 1200 later, then it's better to decrease cwnd value to 10 x 1200 (or de-scale properly) to make sure we don't oversend the data -- most likely at this point we already have sent 10 packets, so this cwnd decrease will make sure we won't over-send the data from this point. Also max_datagram_size is used for other places (e.g. collapse_cwnd()).

This seems to be making transfers slower, so marking as WIP until I figure out why.

Superseded by https://github.com/cloudflare/quiche/pull/1635


Clean-up of the existing theme for UI

Added per @tdonohue  -- task to clean up the existing UI theme. No estimate, requires investigation

This is cleanup of the base Bootstrap theme

Turning the old Mantis theme (or something like it) into our new base theme.  It should no longer be named Mantis.

@artlowel will add an estimate

Bringing the current mantis theme up to date (taking in to account changes that have been made to the themed components since it was made), making it the default, and theming all the new components will take an estimated 40h

Depends on our upgrade to Angular 10: #787 as we'll be switching to Ivy (https://angular.io/guide/ivy) which will result in changes to the current theming strategies.

NOTE: As discussed today, the person who works on this ticket should likely also be assigned #976...as it is easiest to achieve as part of this larger cleanup task.

NOTE: As discussed today, the person who works on this ticket should likely also be assigned #976...as it is easiest to achieve as part of this larger cleanup task.

In today's DSpace 7 meeting, we scoped this ticket to the following:
First, this ticket is NOT about creating a new theme or significantly changing the (existing) default, vanilla-Bootstrap theme visible at https://demo7.dspace.org/
Instead, this ticket is more about cleaning up all current Angular Component in the following ways:

Ensure Angular components meet basic accessibility guidelines (e.g. alternative labels included, color contrast exists, etc).  This should NOT be a deep accessibility analysis (as we hire a firm to do that at a later date), just a resolution of most obvious, highest priority issues based on using automated accessibility tools.
Per accessibility & readability, we may want to switch to a more readable font.  This free font was recommended from within LYRASIS: https://brailleinstitute.org/freefont   If possible, I'd recommend we use this font as the default.
Ensure Angular components provide consistent layout/look and feel for common components (e.g. OK and Cancel buttons should always appear in the same order and have the same base styles applied). This includes ensuring we have common Bootstrap look and feel to similar Angular components (e.g. lists, buttons, forms, pagination is all implemented similarly across the site)

This should include fixing #976, which is one of these consistency issues.
The cleanup steps should be documented as we hope to use them as the start for more formal "DSpace UI style guidelines" for all future components.  Initial notes in the PR itself are fine, but we'll want to move them to the Wiki eventually to formalize them.

Minor cleanup to CSS or styles is expected to be necessary to ensure the above two points are met.  However, we are not doing a larger style redesign as part of this ticket.  Instead, any minor redesign/theming work will be left to #727

@abollini expressed interest in starting this work immediately.  @abollini, can you provide an updated estimate of this effort based on the above scope?


MONDO:0100016 early-onset generalized dystonia [Revise text def]

Mondo term (ID and Label)
MONDO:0100016 early-onset generalized dystonia
Suggested revision of textual definition. Please include a source, like a PubMed ID (in the format PMID:#######)
There are currently synonyms that seem more like definitions on this term:
"A generalis[z]ed isolated dystonia characteris[z]ed by early-onset, which may be clinically indistinguishable from DYT-TOR1A and may be the most common cause of early-onset generalis[z]ed dystonia, at least outside the Askenazi Jewish population."
Your nano-attribution (ORCID)
If you don't have an ORCID, you can sign up for one here
Note that there is a UMLS concept that is 'similar' to this preferred name, but I am not sure that 'early' and 'childhood' should be equated in this situation: "Childhood Onset Dystonias" (UMLS CUI: C0752202) includes one of the many different concepts on https://id.nlm.nih.gov/mesh/D020821.html . Because of the lack of clarity in the scope of this MeSH term, I am not advocating for it as an X-ref, just trying to connect the dots on the various sources of information we're trying to reconcile in MedGen.  I cannot find a better match in UMLS for this "early-onset generalized dystonia."

Dear @kanems,
Thank you for reaching out to the Mondo Disease Ontology, part of the Monarch Initiative!
We have received your ticket and will review it as soon as possible.
If you have any additional information or updates relevant to your inquiry, please add them in a comment on this ticket. Your input is valuable in helping us understand and resolve the issue effectively.
Thank you for your patience and for your contributions to Mondo!
Sincerely,
The Mondo Team

There a synonyms that of early-onset generalized dystonia that seem more like definitions:
I agree with the collaborator that these synonyms seem like definitions.
Linking early-onset generalized dystonia with UMLS concept childhood onset dystonia:
According to the following publication (PMID:20301665), "Onset ranging from age four to 64 years has been reported with the vast majority beginning before age 26 years". The average age is far outside of childhood. For now, I recommend we do not X-ref this term unless a clinical expert chimes.


python3Packages.pymysensors: 0.21.0 -> 0.22.0

Motivation for this change
Update to lastest upstream release 0.22.0
Change log: https://github.com/theolind/pymysensors/releases/tag/0.22.0
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 145414 run on x86_64-linux 1

3 packages built:

home-assistant
python38Packages.pymysensors
python39Packages.pymysensors


New add-on idea or improvement to NflxMultiSubs

This is a great add-on to learn languages. But it also works pretty good to just improve Netflix's native/primary subtitle for someone who doesn't need secondary subtitle. I am currently using NflxMultiSubs for the ability to select unsupported subtitle (Primary: Off, Secondary: On) and Size, Layout settings. I haven't found any other addon/script that can enable "disabled" subtitles or adjust vertical position.
Anyways, here are some suggestions.

Option to enable/merge unsupported subtitles in Native/Primary Subtitle window.

Option to disable "Secondary Subtitles" window.

"Font, Font Style, Window (Not important) Shadow (Not important)" settings

I am currently using NflxMultiSubs for the ability to select unsupported subtitle (Primary: Off, Secondary: On) and Size, Layout settings.

Same 😁
Thanks for the suggestions!

Not sure what you mean by this. Do you want to use the "extra" primary languages (the ones below the horizontal line) as secondary subs? This is already possible thanks to aeebe4b, it will be included in the next release.
The extension's core functionality is dual subtitles and I don't want to change that, so this option makes less sense to me.
This is a good idea, I'll add this to my todo list but it's low priority (what do you mean by Window settings?). PR welcome!


Tinyfix/202009

Issues associated with this PR
Your PR should present related issues you want to solve.
Solutions
You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At this time, Chinese is allowed to describe these.
UT result
Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases. And you need to show the UT result.
Benchmark
If your code involves the processing of every request, you should give the Benchmark Result.
Code Style

Make sure Goimports has run
Show Golint result

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7e9599e). Click here to learn what that means.
The diff coverage is 0.00%.

@@            Coverage Diff            @@
##             master    #1405   +/-   ##
=========================================
  Coverage          ?   59.09%
=========================================
  Files             ?      332
  Lines             ?    26833
  Branches          ?        0
=========================================
  Hits              ?    15857
  Misses            ?     9206
  Partials          ?     1770

Impacted Files
Coverage Δ

pkg/configmanager/parser.go
69.66% <0.00%> (ø)

pkg/mosn/starter.go
54.00% <0.00%> (ø)

pkg/network/connection.go
41.97% <ø> (ø)

pkg/stream/xprotocol/conn.go
36.80% <0.00%> (ø)

pkg/upstream/cluster/host.go
46.53% <0.00%> (ø)

pkg/xds/conv/convertxds.go
52.42% <ø> (ø)

pkg/trace/skywalking/tracer.go
40.00% <0.00%> (ø)

pkg/upstream/cluster/loadbalancer.go
65.69% <0.00%> (ø)

pkg/cel/cexl/translate.go
76.19% <0.00%> (ø)

... and 328 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 7e9599e...c49d3ff. Read the comment docs.


reference bibxml URL directly

I have created some bibxml format files that do not (yet?) live on xml2rfc.tools.ietf.org.
I think that xml2rfc would be happy if I could pass a  entry through to it.
Is there a way to just put the URL that I want to point to into the normative:/informative: sections of the YAML?

cabo<EMAIL_ADDRESS>wrote:
> I think I tried to avoid randomly dereferencing URIs, which becomes a
> security issue (but then there is {::include}).  This could be added
> after I return from vacation. Care to flesh out the idea a bit?
Could be that I just set some $VARIABLES or cmdline arguments of places
to look in addition to xml2rfc.tools.ietf.org.  Could include file://
URLs.
Basically, I just wrote:
http://www.sandelman.ca/SSW/ietf/bibxml/
because I needed it, but now I'm not sure how to reference it nicely.
I guess if the XML is gonna be processed by others, one needs to the
entire URL.
I don't know how to use ::include to create <ENTITY things in the heading.
--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]<EMAIL_ADDRESS>http://www.sandelman.ca/        |   ruby on rails    [

For now, it is certainly easier to put the content of that XML file into yaml form into the yaml header. {::Include} would work there.
Kramdown-rfc does not use entities unless you set standalone to false. Why would you want to use them?  To get xml2rfc to do the dereferencing? Easier to {::include} the XML in the references section (but I forget how to do this exactly). Much easier to forget XML and use yaml.

http://www.sandelman.ca/SSW/ietf/bibxml/_reference.ISO.18004.2015.xml has a syntax error that makes it invalid XML.  Also, this reference is indeed easy to put into the YAML.  Can we close this issue?

Thanks!
(And thanks for the great "target=" in that bibxml :-)


fix(fsi18n): Add set locale to fscomponents

Replace all occurrences of "any" in FSCheckout package

It looks like you have the wrong commit message.

@Cauldrath fixed


Generic class with itself as argument of base type equality problem

Hello, I don't know if I'm missing something here (about your library or Roslyn), but until know I had compared all class types by equality:
classType1 = // some code which returns IClass

classType2 = // some other code which returns IClass

if classType1 == classType2
    }} same {{
end

However if I have a class like this in C#:
public class Base<T>{}

public class Derived : Base<Derived>{}

This does not work:
classType = // some code which returns IClass = Derived

if classType.BaseType.IsGeneric && classType.BaseType.TypeArguments[0] == classType
    }} same {{
end

So apparently Derived and its parent generic argument Derived are different types, why?

It is on NTypewriter side, the equality operator is not overridden, so standard reference comparison is used, and since an instance of object representing a given type is not cached, the results are exactly as you described.

Oh, so types are not cached like System.Type? Is there an alternative to compare two given types?

They are not, probably only by using their FullName right now.


node network list now calls from esisdk

To centralize logic, the esi node network list will call from esisdk.

Thanks!


Flatbutton to be discarded?

I see that in the new flutter master branch, the FlatButton prompt will be discarded. It is suggested to change it to TextButton.
@Deprecated(
  'Use TextButton instead. See the migration guide in flutter.dev/go/material-button-migration-guide). '
  'This feature was deprecated after v1.25.0-8.1.pre.'
)

But we have used a lot of FlatButton , and the effect of TextButtonis not consistent with that of FlatButton (unless I specifically specify style, but that requires a lot of code changes).
Can't FlatButton coexist with TextButton? Please answer, thank you.

Hi @yangyxd
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
FYI, yes it is deprecated but you can still use it, just be aware that it will be removed in the future.
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you

Hi @yangyxd
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
FYI, yes it is deprecated but you can still use it, just be aware that it will be removed in the future.
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


Fix an off-by-one error due to the comma in a struct lit field

Also allows splitting the field expression on a new line after the field name.
Fixes #698
r? @marcusklaas

Nice fix! I remember playing a bit with this, but I wasn't able to find the culprit.


Add keyboard navigation

Is your feature request related to a problem? Please describe the problem
Right now doing any actions in the application requires a mouse, it may be not very efficient for people who prefer to use keyboard navigation.
Describe the solution you'd like
Add the ability to do basic actions (such as selecting scripts, editing parameters, and running the execution) using only the keyboard.

This is mostly done, except for editing configuration and script configuration, and editing script parameters (only arguments).
It would be nice to cover those as well, ideally one shouldn't need to touch the mouse to do anything.


Dark theme?

Would it be possible to have dashboards displayed in a dark theme?

Can i go for it ?

Hi @sayanmondal2098 !
yes please do, any involvement is highly appreciated 👍

Suy nghi lai di..dug qua voi. Gap gap ma ket luan..ko nhu nhug gi tui noi
bao nhiu tui thền cho
Vào 3:34 Th 4, 10 thg 7 2019 Adam Kasprowicz<EMAIL_ADDRESS>đã
viết:

Closed #101 https://github.com/keen/dashboards/issues/101.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/keen/dashboards/issues/101?email_source=notifications&email_token=AMMY3EZS7ITGDYZ5FRMNXG3P6TY6NA5CNFSM4FIGR3G2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOSNBEWRQ#event-2470595398,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AMMY3EYH6YT5HP3B2JNDQCDP6TY6NANCNFSM4FIGR3GQ
.


Set plugin parallel value true by default

Describe the feature
Since we've got the dependsOn property, we can set the parallel field of plugins to true by default
Additional information

[X] Would you be willing to help implement this feature?
[ ] Could this feature be implemented as a module?

Final checks

[X] Read the contribution guide.
[X] Check existing discussions and issues.

Would modules need to expose some plugin names then "somehow"?
e.g. if you need/want to wait for i18n plugins, or some plugins from your own module?

This seems like it would cause difficult to debug problems stemming from plugins executing in a different order than expected.
dependsOn wants the name of a plugin, and it currently is not a required field. It's unclear to me how you can reference an unnamed plugin by name, if it is possible.
So if there was an issue from this that could be resolved by declaring dependsOn for a plugin, it would be at the mercy of the other plugin having been given a name.
I found this issue because I am trying to use dependsOn and struggling with this problem already.
Please consider a migration path that doesn't introduce pain. Maybe first deprecate APIs around plugins that support the relaxed nameless plugins.
What happens when multiple plugins use the same name?

I think that's a good suggestion.

This seems like it would cause difficult to debug problems stemming from plugins executing in a different order than expected.
dependsOn wants the name of a plugin, and it currently is not a required field. It's unclear to me how you can reference an unnamed plugin by name, if it is possible.
So if there was an issue from this that could be resolved by declaring dependsOn for a plugin, it would be at the mercy of the other plugin having been given a name.
I found this issue because I am trying to use dependsOn and struggling with this problem already.
Please consider a migration path that doesn't introduce pain. Maybe first deprecate APIs around plugins that support the relaxed nameless plugins.
What happens when multiple plugins use the same name?

Exactly. How do you depend on a plugin without a name? @manniL


Regarding this tool

Whether this tool works in india

It should work in every country you can try

It should be working in every country


⚠ RPC server - Infura Mainnet has degraded performance

In 5840890, RPC server - Infura Mainnet ($INFURA_MAINNET_RPC_URL) experienced degraded performance:

HTTP code: 429
Response time: 700 ms

Resolved: RPC server - Infura Mainnet performance has improved in 9124913 after 14 minutes.


Not Working

Uh, I don't know why my issue was closed, the hack is still broken and the game has been patched.
Please keep this open

we only need one issue and its below yours. Stop opening more issues or we'll ban you from this repo.

You clearly don't know what you are talking about, friend.
Below is the freeze bug, that was opened 3 days ago. The new update was released 1 day ago. It is a different bug because the entire hack stopped working, but it doesn't freeze the game.
Please actually take the time to read before closing issues wildly for no reason. It is not necessary and, frankly, it shows lack of detail.
Play surviv.io and you will see.

On Dec 6, 2018, at 8:12 PM, silentes<EMAIL_ADDRESS>wrote:
we only need one issue and its below yours. Stop opening more issues or we'll ban you from this repo.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/Kalaborative/survivio-plus/issues/174#issuecomment-445117019, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7pT3-0B03CmDGjWPEfb6r7VvAsFZsmks5u2eqXgaJpZM4ZHwcs.


Added partition function data for D2O

Same as my previous pull request, but for D2O.  HITRAN's supplied grid of temperatures doesn't exactly match ctips's grid of temperatures, so I used spline interpolation.

I'm not sure why the build errored, the change log looks identical to the previous pull request except it's for D2O rather than N2.

I missed updating the cumiso array, and the tests didn't catch that on the last pull request.  I think it might be good to add in a sanity check for that.  Also, given that it is tedious to update those numbers each time, do you think it would be good to have a directory of scripts to handle processing the PF data and updating ctips.h?  Essentially, it would check if the isotope already exists in ctips.h, if it does exist then it updates the data, if it doesn't exist then it adds the data to the Qdata array and updates the niso, cumiso, and isoID arrays accordingly.


SPINEL - protocol concerns

some issues with the SPINEL protocol need to be addressed, specifically these deal with power management and sleepy devices.
Issue 1 - the NCP may be in a deep sleep.
The NCP device may be asleep, or in an ultra low power state and not ready to respond quickly  (immediately) to a host that may be transmitting data.
Typically a GPIO signal from the HOST to wake, or draw the attention of the slave.
The simple approach would be to think the SPI-CS signal is the solution. The reason this fails is many SPI hosts will drop the CS to active, and immediately (within ZERO micro seconds) begin transmitting (clocking) data out of the SPI port.
Depending upon the sleep state of the NCP and the wakup timing requirements the NCP may not be able to respond, and configure it self for the SPI transfer prior to the host transmitting (or perhaps the UART baudclock source needs to be turned back on)
Examples include:  Interrupt servicing over head at "slow (ie: 32khz) sleep clock rate", length of time to re-enable the on chip oscillator, startup the external crystal and walk the internal power regulators back up to operating voltages.
This can often be made worse when the SPI interface is operating at 10mhz, or higher (vrs the 32khz sleep clock the NCP is waking up from).
The result is the Host & NCP slave can be "off-by-a-bit" or two, or three during the transfer and this problem only occurs rarely... and nobody can figure out why or when this occurs.. maybe the chip wakes up slower when it is very cold (think sensor inside a freezer, or a pool sensor in midwinter)
What is missing is a "NCP-IS-READY" hand shake back to the host.
(total 2 pins)
Issue 2 How fast can the HOST wake up?
The NCP may need to wake the host up and tell the host there is data to be sent.
This slightly discussed in the SPINEL protocol and repeated here for completeness.
What is not considered is this: A battery powered Linux host might be asleep and in a low power state (example: A cell-phone-data-only device connected to an NCP) the NCP cannot just "raise the request" and start transmitting out the UART... that host might also need to "wake up" and turn clocks on, enable PLLs and so forth before the UART baudrate clock is operational.
Typically another GPIO pair (ncp to HOST) is used to indicate this request.
total: 4 pins.
Issue 3 - Timing (latency) Problems
COST PROBLEM - every pin on a chip costs money, or makes a product require a more expensive chip with more pins to provide the solution (this is great for those selling the chip, but bad for buyer of the chip)
A fundamental truth is this:  Digital signals can cross 3 to 4 inches on a circuit board without problems at relatively high frequency. There is a myth that UARTs are not reliable, that was true when the signal ran across 300 feet of wire from one end of a factory to another end of the factory. Here we are dealing with 3 to 4 inches of signal traces on a circuit board or small flex cable. The state of the art is such that you do not have signal quality problems. The truth is often something else. The problem is often the power up sequences (above) or this race condition, or you are writing very in-efficient C code.
In general, one does not want 4 GPIO hand shake pins

To solve issue 1  (host -> ncp) requires 2 pins, a request and ack
To solve issue 2 (ncp -> host) requires 2 pins, a request and ack.

The economic need is this:
2 pins UART (txd/rxd)  + 2 GPIO handshake = total 4
3 pins SPI  (mosi,miso,clock)  + 2 GPIO handshake = total 5
Notice that the SPI does not use an actual CS signal - in theory it is present, just not hooked up or the GPIO pin is reconfigured in a "non-SPI-mode" and is used as a GPIO pin instead.
If the slave (NCP) requires this signal, the HOST_REQACK can be used as the SPI_CS signal. The slave will see the SPI_CS assert, then a seemingly long delay before the SPI_CLK starts.
Issue 4  - hardware design problem, power management
Sometimes the GPIO signals are also used to enable power to voltage level shifters between different power domains (ie: maybe the HOST uses VDD-IO as 1.2v, but the radio uses 3.3v?) Will enabling the level shift cost another GPIO pin? Or can we reuse one of the HANDSHAKE GPIO signals? The Money answer is simple: An existing GPIO signal needs to be reused reused.
The Timing Race Problem that occurs because of issues 1, 2, 3 and 4.
The race condition happens because of economizing the number of GPIO signals
The race condition is this:
At Time 0 -
Both the Host and the NCP decide "i-need-to-send-data"
Both assert their single GPIO signal at the exact same time.
the host is often a linux machine, the user level IRQ latency is horrible compared to the NCP-microcontroller. Latency is defined as:  NCP-GPIO assert, to HOST-GPIO-Ready assert, or further first bit has transferred over the connection.
The RACE is this:
The host assumes the slave responded "OK-READY" via the GPIO, however the slave is sending "REQUEST_TO_SEND"
Depending upon which packet is "longer" - the other side will need to insert "SPI-STUFFING" values.
(the UART case does not require stuffing values)
Consider the scenario:

The host begins transmitting a very tiny packet.
The slave begins transmitting a very LARGE packet.
Note: the opposite can also occur.

At time HOSTDATA_end
When the host finishes, in the SPI case, the host will "drop the GPIO" or stop the SPI clock
The slave however is still sending data.
In the UART case
The host can easily tell if the target has sent anything.
do you have bytes in the UART RX buffer? yes or no.
IF YES - determine the length of the message.
And if required wait until the end of the message before dropping the handshake pin.
In the SPI case
Assuming the host (linux) is a SPI-MASTER, the NCP will be the SPI-SLAVE role, the side sending the smaller packet must send "stuffing" values over the wire.
Or - maybe the (the race condition is occurring) the NCP slave is sending a response while handling an incoming message.
Because we limit to only 1 transfer per handshake..
Again, the host needs to examine the first (N) bytes of the SPI transfer and determine
Question 1:  Is the slave sending "stuffing values"
OR question 2: Is the slave sending a packet?
The host needs to examine the partial SPI transfer and determine: Was this stuffing values? or Is this the start of a message?  And if so - how many more SPI clocks are required? Or how long can we wait to turn the power off to the level-shift devices?
Recall that - we only transfer a single message per handshake, and the message will always start at an appropriate place (where the sender REQACK signal was first asserted).  We never start a message in the middle of, or during the transfer of another message. The transfer then becomes some what atomic, due to the REQACK framing that occurs.
Summary
Only one transfer is performed per "handshake". This means the host must deassert the HOST_REQACK signal at the end of the transfer. (more about this below)
To send (HOST -> NCP)

GPIO (1) = HOST REQACK, the host asserts this to send data.
GPIO (2) = SLAVE REQACK, the slave indicates it is ready to receive.

To send (SLAVE -> NCP)

GPIO (2) = SLAVE REQACK, the slave asserts this indicating it needs to send.
GPIO (1) = HOST REQACK, the host asserts this indicating it is ready to receive

For UARTS - this can be done with the RTS/CTS signal mapping and various IO/CTL operations
But honestly using the GPIO api is a better solution.
For SPI:

the host (linux) is always a master (some smartphone chips are really dumb, and cannot operate in slave mode) we can assume these have more resources.
SPI requires the SCLK, MOSI, MISO - we cannot avoid these.

The SPI_CS is something we can work around. On the slave side may require the SPI_CS signal to operate correctly. If so - the HOST_REQACK signal can function as a SPI_CS signal.
While the host may generate a SPI_CS - it is not really required or usable (see issues 1 and 2 above) this signal can either be (a) left as a no-connect, or (b) the mode of the HOST_SPI_CS signal could be set to "GPIO mode" and controlled via software.
FAST TURNAROUND - streaming packets.
Often in the NCP (micro-controller) this is not an issue, within a few microseconds it is ready to go.
The host side, from user space through the kernel and out the GPIO driver is slow. We can use this to our advantage.
First: Measure latency.
Write a simple user space 'pulse-the-gpio' application on Linux and measure fastest time an
The code needs to perform a WRITE pin (X [toggling the pin]), then READ pin (Y). Measure the period of the wave form, this is 2x the fastest speed the board change a GPIO Pin.  Note: Linux (and windows) user space GPIO is rather slow. We will use this to our advantage.
Second:
Pick 50% of that period - the NCP must meet this timing requirement: From END OF DATA to SLAVE_REQACK de-assert - must be completed in that (50%) time window.
OR - The host must insert a busy wait( as described below )
The host at the end of any transfer:

step 1 - write the HOST_REQACK pin,
step 2 - if required insert a short sleep (often this is not required)
step 3 - read the SLAVE_REQACK pin
step 4 - determine: Loop for more data, or wait for another interrupt.
Note: this technique is often found in UART drivers where the hardware supports a FIFO buffer, you will notice the actual hardware IRQ contains a loop - that drains the fifo. That is effectively what we are doing here, the loop draining the transfer buffers.

Note that a Microcontroller based HOST is often much faster at raw GPIO io then a host.
It does vary greatly due to the architecture of the host chip ( often a 2ghz android device cannot read the GPIO pins at 2ghz... they instead require/use a bus frequency shift to a lower speed IO bus)

It isn't entirely clear what you are proposing overall, so I'll go over individual statements below.
By the way, Spinel isn't acronym, so you can just call it "Spinel", not "SPINEL".

The simple approach would be to think the SPI-CS signal is the solution. The reason this fails is many SPI hosts will drop the CS to active, and immediately (within ZERO micro seconds) begin transmitting (clocking) data out of the SPI port.

This isn't actually a problem with the recommended Spinel SPI protocol. If the slave is just waking up and isn't ready to transmit, the slave would keep MISO high. This signals to the master that the slave is throttling. The master will then either poll (very dozen milliseconds or so) and/or wait for the interrupt pin to be asserted.
Granted, this could likely be better documented.

The result is the Host & NCP slave can be "off-by-a-bit" or two, or three during the transfer and this problem only occurs rarely... and nobody can figure out why or when this occurs.. maybe the chip wakes up slower when it is very cold (think sensor inside a freezer, or a pool sensor in midwinter)
What is missing is a "NCP-IS-READY" hand shake back to the host. (total 2 pins)

I emphatically disagree with any recommendation that requires more pins: It is simply not necessary.
If you and the host are "off by a bit or two", then the problem is in your implementation. If the NCP wakes up from CS being asserted and it can't guarantee that it can handle the transaction then it should keep MISO high and ignore the frame and wait for the next one. The master will then prepare another frame that will start at the next slave-to-master interrupt or wait a dozen (or so) milliseconds and try again (whichever is sooner). No harm, no foul.

The NCP may need to wake the host up and tell the host there is data to be sent.
This slightly discussed in the SPINEL protocol and repeated here for completeness.
What is not considered is this: A battery powered Linux host might be asleep and in a low power state (example: A cell-phone-data-only device connected to an NCP) the NCP cannot just "raise the request" and start transmitting out the UART... that host might also need to "wake up" and turn clocks on, enable PLLs and so forth before the UART baudrate clock is operational.
Typically another GPIO pair (ncp to HOST) is used to indicate this request.
total: 4 pins.

Traditionally, we have done this using flow control and BREAK signals. When the host goes to sleep, it asserts flow control. When the NCP has something to send to the master while flow control is asserted, it will occasionally send a UART "break" until flow control is no longer asserted, at which point frames are transmitted as normal.
The same mechanism can be used with software flow control (requiring only two pins), as long as the underlying hardware treats BREAK as a specific UART signal, but this may be rather tricky to get right.
Another way that this could be handled is with a serial reliability layer. This is nice because flow control is implicit and wouldn't require additional pins (at the cost of some additional wakeup latency). But this isn't yet specified.
I agree this needs to be better elaborated on in the appendix. We also haven't implemented this yet in the OpenThread NCP, so we need to go ahead and do that.

The economic need is this:
2 pins UART (txd/rxd) + 2 GPIO handshake = total 4
3 pins SPI (mosi,miso,clock) + 2 GPIO handshake = total 5

We use TXD, RXD, CTS, RTS for UART, using the signaling scheme I described above. Works great. We could define a mechanism which only uses TXD and RXD, but for that we would need a reliability and retransmission layer which hasn't been specified.
For SPI we use MOSI, MISO, CLK, CS, and INT. We also use RESET. Theoretically RESET isn't required, but we have found that it is useful for the master to have the ability to force a hardware reset of the slave out-of-band. Also, theoretically even INT isn't required, since you can always poll with the current SPI protocol, further reducing pin count.

Notice that the SPI does not use an actual CS signal

It seems like you are proposing that we change the SPI protocol to require a two-way handshake before the master starts clocking out bits, something like Master-Ready and Slave-Ready, where if at any point one side wants to start a transaction, that side asserts its pin and then waits for the other side to assert their pin. The signal of asserting CS is then effectively the logical AND of the state of both pins (at least for the starting edge), where de-asserting CS is (presumably) just the falling edge of Master-Ready.
I don't like this system for the following reasons:

It doesn't solve any problem that isn't already sufficiently solved by the current recommended protocol
It makes the implementation that drives the master from Linux user-space more complex.
It prevents (or reduces the efficiency of) sharing the SPI bus with other peripherals.

We are using the Spinel-recommended SPI protocol right now and it works great.
That being said, I think the documentation could use improvement, which we are working in internally.

This isn't actually a problem with the recommended Spinel SPI protocol. If the slave is just waking up and isn't ready to transmit, the slave would keep MISO high.

Effectively the MISO pin becomes another handshake signal.
An important thing to to note is handshake signals may be active low, or active high depending upon the actual HW architecture in the system.  Active high signals (ie: 0V is the idle state) are more power hungry only due to parasitic leakage in the HW design, and very anti-battery life. A few micro amps integrated over a long sleep time adds up. To paraphrase Yogi Berra - A few microamps here, and a few microamps there now you are talking about real money. Another problem you can have is the VDD-IO voltage rails may change level in sleep mode, remember power (watts) is a driven by voltage (e) more specifically e^2, so being able to drop voltage during sleep is important,  and 0^2 is always 0.  Changing VDD-IO presents other problems if the signal is active low, where as an active high signal does not. Momentary over voltage in those situations is cheaply solved with an inline resistor.
Some SOCs provide pin-observation at all times, others do not, which means: Some hosts must dynamically reconfigure the MISO pin, which is not always simple from user space (ie: Linux Device tree nonsense)

[in the uart case] When the NCP has something to send to the master while flow control is asserted, it will occasionally send a UART "break"

Interesting concept...  In my experience UART break detection does not work very well across all the micro controller that I have used in projects. Some do well, some do horribly it is very hit or miss.  Thus I have always avoided this.

Theoretically RESET isn't required, but we have found that it is useful for the master to have the ability to force a hardware reset of the slave out-of-band.

Agreed - also needed for UART mode to do 'in-place' flash update of the device from the linux host.

It seems like you are proposing that we change the SPI protocol to require a two-way handshake

yes exactly. This is also needed for UART mode. I probably was not very clear.

It makes the implementation that drives the master from Linux user-space more complex

not really, it works like this:
Send Steps
Send Step 0:
DO NOT assert READY yet
Perform a MUTEX lock in the IO scheme.
DISARM the RX request logic (ie: edge irq)
Power up IO circuit,
Enable clocks in all required power domains.
SEND Step 1:
sender  assert MY_READY  (master or slave)
(set GPIO pin)
SEND Step 2:
sender wait    OTHER_READY
(poll GPIO pin)
SEND Step 3:
Transfer is performed (uart or spi)
In spi case the Linux host starts clocking the SPI_CLOCK pin.
In linux user space this is just a call to the SPI transfer function.
SEND Step 4:
to handle race condition:
Sender must examine other reply
in UART case - if no bytes - no message
in SPI case - if all bytes = STUFFING value no message
If "other_message exists" and is not yet complete
The host must complete this message:
Example SPI case
HOST only clocked in/out 20 bytes,
And the other message is longer...
The SPI interface will not complete the transfer
The host must send "stuffing values" to produce transfer clocks.
Example UART case
typically nothing to do here
What you don't want to do is shut down the IO power yet.
If the message was completed - post the message into the RX thread.
SEND Step 5:
REARM the RX request logic, this must occur before dropping request.
Sender DROPS request.
SEND step 6:
Note: Do not wait until receiver Drops READY
This might never happen, you might be too slow and miss this.
SEND step 7:
Release Mutex lock on the IO scheme
SEND step 8:
Done.
Rx Step
RX STEP 1:  Wait for REQUEST signal..
Note this is an EDGE request, not a level request.
RX STEP 2:   MUTEX LOCK transfer scheme.
RX STEP 3:  Power up IO circuit, enable clocks, set IO voltages.
RX STEP 4:   Assert READY (this is the request to other side)
RX STEP 5:  Wait for others to assert ready.
RX STEP 5:  Transfer is performed.
If using SPI, the the receiver must send "stuffing values"
Either all FF or all 00
RX STEP 6:  End of transfer
RE-ARM rx-edge detect.
DROP ready signal.
Release Mutex
RX STEP 7:
Post RX message received.

Effectively the MISO pin becomes another handshake signal.

More like the contents of the MISO frame are used as a handshake signal.

An important thing to to note is handshake signals may be active low, or active high depending upon the actual HW architecture in the system. Active high signals (ie: 0V is the idle state) are more power hungry only due to parasitic leakage in the HW design, and very anti-battery life. A few micro amps integrated over a long sleep time adds up. To paraphrase Yogi Berra - A few microamps here, and a few microamps there now you are talking about real money. Another problem you can have is the VDD-IO voltage rails may change level in sleep mode, remember power (watts) is a driven by voltage (e) more specifically e^2, so being able to drop voltage during sleep is important, and 0^2 is always 0. Changing VDD-IO presents other problems if the signal is active low, where as an active high signal does not. Momentary over voltage in those situations is cheaply solved with an inline resistor.

The current implementation of the SPI protocol in spi-hdlc-adapter makes no differentiation between the slave sending a frame full of 0x00 bytes or 0xFF bytes. Both will induce the host simply try again later. At sleep, the slave would pull MISO to whatever state is the lowest power. At wakeup, the slave would boot up and then wait for CS to no longer be asserted before initializing the SPI component.

Some SOCs provide pin-observation at all times, others do not, which means: Some hosts must dynamically reconfigure the MISO pin, which is not always simple from user space (ie: Linux Device tree nonsense)

Why in the world would the host need to reconfigure the MISO pin? The host just gets the frame. If it is all 0xFFs or all 0x00s, then it knows the slave is busy. No need to reconfigure the MISO pin.
This isn't hypothetical code that needs to be written. The Linux host side works Right Now™ with the scheme I just described.

Interesting concept... In my experience UART break detection does not work very well across all the micro controller that I have used in projects. Some do well, some do horribly it is very hit or miss. Thus I have always avoided this.

Which is why I pointed out the XON alternative, for when hardware doesn't do BREAKs well.
I personally implemented the deep sleep and wakeup signaling on both our shipping UART-based products and shipping SPI-based products. I designed the recommended Spinel framing protocols with that experience in mind. Now I'm not perfect, I certainly have been known to make mistakes, so I'm more than willing to consider that there may be better alternatives. But so far I still do not understand what problem you are trying to solve that can't be easily solved using simple adjustments to what is already specified, implemented, and working.

duane>Why in the world would the host need to reconfigure the MISO pin?
darconeous> Why in the world would the host need to reconfigure the MISO pin?
As I said, some SOCs do not provide pin observably.
Your suggestion was the SPI-SLAVE holds MISO as an additional handshake. The problem occurs on SPI-MASTER side, example: PIN(X) is in mode GPIO, or PIN(X) is in mode (MISO).  For some SOCs when the pin is in a NON_GPIO mode reading the raw pin value (ie: as if it was a GPIO) is not possible due to the way the hardware was designed.
How then will the host know the slave is ready?

As I said, some SOCs do not provide pin observably.

We observe the pin by looking at the MISO frame after the transaction.

If the slave holds MISO low, the frame received by the master will be all zero bits. If the slave holds MISO high, the frame received by master will be all one bits. There is absolutely no reason to change any pin settings on the master.

And it isn't really a handshake. It is a refusal by the slave to handle the frame.

How can we avoid this refusal?

We don't avoid it. Refusals are normal: they are how the slave asserts flow control.
The master tries again a dozen (or so) milliseconds later, or we try again immediately if interrupt gets asserted (which it likely would be if the NCP is just waking up).
There are two ways the slave can refuse a frame from the master:

Passive refusal: Don't wiggle MISO. Leave it in the same state for the duration of CS being asserted.
Active refusal: Clock out a well-formed 5-byte header on MISO, with a RECV_LEN of zero.

Closing. Please re-open if you have additional concerns.


[Python] The local log error stack is truncated

Search before asking

[X] I had searched in the issues and found no similar issues.

Apache SkyWalking Component
Python Agent (apache/skywalking-python)
What happened
When reporting to the server, I can understand that the error stack printed to the log is truncated, but the error stack recorded to the local log is truncated, so the specific error cannot be located
What you expected to happen
The error stack recorded to the local log is not truncated and the error can be located smoothly
How to reproduce
An error with an error stack depth greater than 5 occurred, and the log on the server was truncated, as was the local log
Anything else
Every time
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Are you going to propose some changes?

Are you going to propose some changes?

Are you going to propose some changes?

https://github.com/apache/skywalking-python/pull/190

this occurs to me too,
skywalking save backtrace depth of 5 with default, this constrait take effect to standard logging module either.

Thanks for the pull request! But on second thought, the solution provided in the PR look a bit off to me.
To my understanding, the problem occurs due to the existence of a cached exc_text attribute contained inside the LogRecord object which sw_logging.transform() set during the interception.
The following is from the Python logging module, as we can see the cache is done by this chunk of code. The bug occurs because SkyWalking agent did not clear the cache after doing the formatting, therefore, other formatters would just reuse the cached exception, essentially bypassing the arguments.
    if record.exc_info:
        # Cache the traceback text to avoid converting it multiple times
        # (it's constant anyway)
        if not record.exc_text:
            record.exc_text = self.formatException(record.exc_info)

Now, if we simply switch the lines around by executing the user's handler first and then format by SkyWalking agent, it seems to me that it would cause the same issue (but reversed - UI shows whatever exception format that user handler.formatter uses).
I will send another PR to address the issue.

@Superskyyy Would you send a pull request soon? So should I revert https://github.com/apache/skywalking-python/pull/190?

@Superskyyy Would you send a pull request soon? So should I revert https://github.com/apache/skywalking-python/pull/190?

Yes sir I will PR later today. Please revert it for clarity.


ValueError: too many values to unpack (expected 2) when passing more than two headers

Problem Description
Hello,
I am trying to forward the requests received by mitmproxy to an external API using request then return the new response body, status code, and headers to the client.
An example of what I am doing is:
def request(flow: http.HTTPFlow):
    request = request.get("http://example.com")

    flow.response = http.HTTPResponse.make(request.status_code, request.text.encode(), request.headers)

However, the 3rd parameter of  http.HTTPResponse.make throws an error if there's more than two headers:
Addon error: Traceback (most recent call last):
  File "addon.py", line 38, in request
    flow.response = http.HTTPResponse.make(
  File "/usr/local/lib/python3.8/site-packages/mitmproxy/net/http/response.py", line 92, in make
    resp.headers = nheaders.Headers(headers)
  File "/usr/local/lib/python3.8/site-packages/mitmproxy/net/http/headers.py", line 80, in __init__
    for key, value in self.fields:
ValueError: too many values to unpack (expected 2)

System Information
Mitmproxy: 5.1.1
Python:    3.8.2
OpenSSL:   OpenSSL 1.1.1g  21 Apr 2020
Platform:  Linux-3.10.0-1062.18.1.el7.x86_64-x86_64-with-glibc2.17

I'm having the same problem. I also used the same as your code


ns dev: stop swallowing errors from "setWorkspace"

Error examples:

No registry configured in the environment "dev".
dev: no kubernetes runtime configuration available.

Closes #38

LGTM


JSLint

JSLint the <code> and <pre> blocks.

Probably not a task for a 'Proofreader'. Checking code should be a different task during the build process.


Doesn't find absolute imports to parts of a module when Python itself does

Hello,
I have a structure like this:
foo
`-- __init__.py
`-- common.py
`-- bar.py

where in bar.py I do import foo.common.
When running lazydocs, I get the message Failed to generate docs for module foo.bar: AttributeError("module 'foo' has no attribute 'common'",)
However, when just starting a new Python shell and doing import foo.bar there are no complaints, so I'd expect it to work in Lazydocs as well.
Anything that I'm missing, or is this a bug?

you probably need to add  PYTHONPATH = path/to/module/

I'm also running into this issue when using the generate_docs function


Setup dayjs with timezone and locale plugins

We'll be using dayjs instead of moment in the project.
Setup the project with example date and a timezone switcher.

Date should be parsed as ISO8601 string and shown in two timezones: local and SGT.
And a select element with timezone switcher should be added to demonstrate second date changing time on changing the timezone while local timezone date remains same
The formatted date should follow the locale selected as current. Meaning AM/PM 12hr/24hr rules, day names like Thursday, etc should be according to the selected locale
Locales must be loaded dynamically, on demand and not be bundled with main bundle

If dayjs or its plugins cannot fulfill the criteria, suggest some other small treeshakable library or create your own methods using native JS Intl API

i am starting working on this issue. please don't make any PR.

@iamdevvalecha Status?

@iamareebjamal dependencies installed with locale plugins.
i have some questions regarding this issue. i will ask in eventyay meeting.

@pc-beast Please take this up

sure

sure

@iamareebjamal Please watch the video and let me know if there is need to change.
https://user-images.githubusercontent.com/26649558/115474877-12246c80-a25c-11eb-9298-cca9f26a005b.mp4

Changing language to hindi should change the dates to hindi as well

@takshch are you working on it?

We have to import every locale in dayjs if we want to convert the date locale-specific @iamareebjamal @mariobehling

@codedsun Even after doing that it will not change the current displayed date. Simply, it means it is not gonna rerender the dates with new locale.

@pc-beast You can take this issue if you want. Also, I would suggest that it is better to use any library because our own solution will produce errors and will not be testable as that of library.

@takshch I think it's mentioned in the doc so it will work, but the way is not better as you have to import every supporting locale of your site.

@pc-beast Any other solution you would like to mention?

@takshch I think it's mentioned in the doc so it will work, but the way is not better as you have to import every supporting locale of your site.

We can also use dynamic import if our setup supports it but still it changing locale will not change displayed date.
Every time we change the locale, then we need to publish that your locale is changed, to every subscriber.
If you don't know  about pubsub pattern, then please learn it.

@pc-beast Any other solution you would like to mention?
Sorry for replying late.
yes, I think we can use days js. but it requires making one function. I found this while I was exploring it. please refer this-
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString


Update WALA to 2.1.3 for Azure.

@AbelHu what's in the update? why do we need to bump?

@cppforlife New WALA supports new protocols on Azure. It also supports AzureStack.

Does that mean older stemcells will stop working because they dont support newer protocol?

The old stemcell still works now but in future it can not work after the protocols are switched.
Best Regards,
Abel HU
? 2016?3?3??08:59?Dmitriy Kalinin <notifications<EMAIL_ADDRESS>???
Does that mean older stemcells will stop working because they dont support newer protocol?

Reply to this email directly or view it on GitHubhttps://github.com/cloudfoundry/bosh/pull/1153#issuecomment-191520095.

Do you have the timeline when protocol may change?
On Wed, Mar 2, 2016 at 5:03 PM, Chou Hu<EMAIL_ADDRESS>wrote:

The old stemcell still works now but in future it can not work after the
protocols are switched.
Best Regards,
Abel HU
? 2016?3?3??08:59?Dmitriy Kalinin<EMAIL_ADDRESS><EMAIL_ADDRESS>???
Does that mean older stemcells will stop working because they dont support
newer protocol?

Reply to this email directly or view it on GitHub<
https://github.com/cloudfoundry/bosh/pull/1153#issuecomment-191520095>.
—
Reply to this email directly or view it on GitHub
https://github.com/cloudfoundry/bosh/pull/1153#issuecomment-191520825.

@cppforlife Azure still supports the old protocols in future. But AzureStack only supports new protocols. In order to use the same stemcell both on Azure and AzureStack, we need to update WALA to 2.1.3.

Got it. Story: https://www.pivotaltracker.com/story/show/115712317


Added csv and request as dependencies

Project was playing up until I ran npm install csv and npm install request so I added them to the package.json file

Merging the pull but these are actually already included in the package.json for the plugin (plugins/r_r). The framework itself doesn't use these modules. My original intent was for the framework to provide the commonly used modules (which requests could easily qualify) and let the plugins define their own. This way the plugins could be completely self contained. Until I have a better solution for installing plugins, I'll just accept this I suppose.


iOS App crashes when tapping "Enter SOL Amount"

When trying to send SOL through the black helium app it will crash upon tapping the amount to send.
Tested on multiple different iPhones iOS 16.4.1 Helium app Version 2.0.5
Steps:

Open app
Tap SOL tokens
Tap send
4 App will crash when tapping "Enter SOL Amount"

Fixed in 2.0.6

2.0.6 is pending review in the Apple App Store and will be released shortly.

Can confirm this works in 2.0.6 for me now.


Questions about the legal judgment of indexCount

The notation here should be <=, because indexCount starts counting from 1

或者我觉得indexCount应该从0计数，如果从1计数的话，可以看到如下代码逻辑，导致少使用了一个IndexEntry的空间

IMO you're right, indexCount should start from 0.
The first index of the file was designed to be a invalid index, but I don't know why.

多谢，从你的描述我想了下从1计数的原因是这样的。
当putKey方法触发，某个slot被第一次命中的时候，该slot本身的值就是0。如果indexCount从0计数的话，当this.mappedByteBuffer.getInt(absSlotPos)返回0的时候，无法确认返回的0是表示【从来没有过key落在该slot上】，还是表示【之前已经有一个indexCount=0的indexEntry落到了该slot上】。
Thanks a lot. From your description, I think the reason for counting from 1 is like this.
When the putKey method is triggered and a slot is hit for the first time, the value of the slot itself is 0. If indexCount counts from 0, when this this.mappedByteBuffer.getInt(absSlotPos) returns 0, it is not possible to confirm whether the returned 0 means that [no key has ever landed on the slot] or that [an indexEntry with indexCount=0 has previously landed on the slot].


docs: add xprotocol codec changes introduction

Issues associated with this PR
Your PR should present related issues you want to solve.
Solutions
You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At this time, Chinese is allowed to describe these.
UT result
Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases. And you need to show the UT result.
Benchmark
If your code involves the processing of every request, you should give the Benchmark Result.
Code Style

Make sure Goimports has run
Show Golint result

merged in https://github.com/mosn/mosn/commit/0dc4302326714990b782eb9012a98492adeddd09


Question - Applying query filters while loading collections

I am using this API to query from a large Mongo DB collection. Is there any way I can specify query filters to load selected documents as dataframe and not the whole collection. Probably some kind of equivalent of find({'key':'value'}) or more complex queries in MongoDB)  I'm currently using version spark-mongodb_2.10:0.11.0.
I'm querying in PySprak using the below command and the load() method would just load the whole collection, which is taking a lot of time.
reader = sqlContext.read.format("com.stratio.datasource.mongodb")
data = reader.options(host='<IP_ADDRESS>:27017', database='ProductionEvents', collection='srDates').load()

Hi @gohilankit
There are several ways to specify filters, the easiest one is just using the filter function
Thus, you should do something like data.filter(df.age > 3).collect(). The filter would be pushed down to Mongo when possible.
DataFrames are lazy, so will be executed when the Spark action (collect, first, take...) is performed

Do you means that by this, the Spark will load the filtered data instead of the whole data set of the target  collection?
So as the Spark SQL performed like this?


Support for setting specific logger levels via environment variable

Some combination of:
$ LOG_LEVEL=logger1:trace node ./cli.js

or
$ DEBUG=logger1 node ./cli.js

Or something like env_logger in Rust
$ LOG=logger1=info,logger2=warn node ./cli.js


Attachments a file said "Could not parse JSON"

it said "Could not parse JSON" when I attachments a file on  version <IP_ADDRESS>5 Beta

Good time to try the new upload: https://try.gogs.io/unknwon/gogs/issues/new

Closed as implemented. :star:


Update to sea ice plots

Updates for sea ice plots in coupled diagnostics.

@yvikhlya Can you please add me or @bena-nasa as a reviewer for this. Only you have the right to do so, it seems.

Wait, nevermind. Now I can add myself as a reviewer. Github had a hiccup.


feat: well-founded definitions irreducible by default

we keep running into examples where working with well-founded recursion
is slow because defeq checks (which are all over the place, including
failing ones that are back-tracked) unfold well-founded definitions.
The definition of a function defined by well-founded recursion should be
an implementation detail that should only be peeked inside by the
equation generator and the functional induction generator.
We now mark the mutual recursive function as irreducible (if the user did not
set a flag explicitly), and use withAtLeastTransparency .all when producing
the equations.
Proofs can be fixed by using rewriting, or – a bit blunt, but nice for adjusting
existing proofs – using unseal (a.k.a. attribute [local semireducible]).
Mathlib performance does not change a whole lot:
http://speed.lean-fro.org/mathlib4/compare/08b82265-75db-4a28-b12b-08751b9ad04a/to/16f46d5e-28b1-41c4-a107-a6f6594841f8
Build instructions -0.126 %, four modules with significant instructions decrease.
Alternative designs explored were

Making WellFounded.fix irreducible.
One benefit is that recursive functions with equal definitions (possibly after
instantiating fixed parameters) are defeq; this is used in mathlib to relate
OrdinalApprox.gfpApprox with .lfpApprox.
But the downside is that one cannot use unseal in a
targeted way, being explicit in which recursive function needs to be reducible here.
And in cases where Lean does unwanted unfolding, we’d still unfold the recursive
definition once to expose WellFounded.fix, leading to large terms for often no good
reason.

Defining WellFounded.fix to unroll defintionally once before hitting a irreducible
WellFounded.fixF. This was explored in #4002. It shares most of the ups and downs
with the previous variant, with the additional neat benefit that function calls that
do not lead to recursive cases (e.g. a [] base case) reduce nicely. This means that
the majority of existing rfl proofs continue to work.

Issue #4051, which demonstrates how badly things can go if wf recursive functions can be
unrolled, showed that making the recursive function irreducible there leads to noticeably
faster elaboration than making WellFounded.fix irreducible; this is good evidence that
the present PR is the way to go.
This fixes https://github.com/leanprover/lean4/issues/3988

Whoohoo, mathlib is green!
After having discussed this with Leo, I will move forward with this approach.
We can reduce the impact on mathlib (seen here) by rewriting some functions using structural recursion (I’m looking at you, Array.ofFn.go and Nat.modCore), but that can happen in separate PRs.
Another possible way to reduce the impact a bit is if the decides tactics reduces more aggressively by default.

The PR says "by default". Is there a way to change the default for a given definition? Is slapping @[semireducible] on the definition sufficient?

The latter, see https://github.com/leanprover-community/mathlib4/compare/nightly-testing...lean-pr-testing-4061#diff-fd2963a2e28f1375d7ef28b499c216ed5b86dceabd79c37154edf5f6bdb62295R82

Perhaps rebase now that #4053 is in a nightly? Not essential.

No need to rebase for that, the diff will simply disappear if there is no conflict.

I plan to merge this once
https://github.com/leanprover/lean4/pull/4098
and
https://github.com/leanprover-community/batteries/pull/784
have landed.
I should trigger a stage0 update right afterwards, else it won’t have an effect on the released stdlib.


Add validator and minimum test

Resolve: #2

Due to the scope increase, this PR will get a lot more comments than necessary. Can I suggest adding a validator type but only return "not implemented" error first?
I suggest a breakdown:

Add CI with unimplemented validator (this PR)
Add http logic to get the issue with the given issue key (do it the right way)
Add more JQL logic

It is actually easier to file a new PR, split out https://github.com/abcxyz/jvs-plugin-jira/pull/10/files for 1 instead while I am resolving comments from this current PR


disabled trailing whitespaces

(From Ian: This rule has slightly different semantics from the prettier yaml formatter. Disable in favor of the latter.)

@kengodleskidot this should fix the trailing whitespace issue you're currently running into on your PR. From @ian-r-rose "It looks like prettier will trim trailing whitespace most of the time, but not in multi-line text blocks. This makes a certain amount of sense to me, as those are intended to be literal text, rather than configuration/code." So in other words prettier (lint/fix) was not "fixing" trailing whitespaces that were literal whitespaces in multi-line text

I misspoke, this would not have fixed the trailing whitespace issue you were running into on PR #96. There was a real trailing whitespace in a SQL file that needed to be addressed. I fixed it in this commit: https://github.com/cagov/caldata-mdsa-caltrans-pems/pull/96/commits/188bc794dae5acec33587a76354d80f8309172ad @kengodleskidot


fix(amplify-provider-awscloudformation): Ensure the right profile is used with SSO and with credential_process

Description of changes
When using credential_process in the AWS profile (to get SSO to work for example) the ProcessCredentials Provider is used.
When using the default chain from the aws-sdk no options are passed to it and it default to using AWS_PROFILE.
With this change, we detect credential_process and specifically pass the profile name into the credential chain to ensure it gets used.
The problem this solves for me is when using multiple environments.
When adding an environment with aws env add even though a profile is picked, if it is using credential_process it won't be used.
In my patrticular use case the environments are in multiple accounts.
I suspect most people are using environments in the same account and have an AWS_PROFILE set so the default fallback works.
I haven't added any tests but could attempt it given some guidance.
Issue
#4488 is an example where the workaround suggest setting AWS_PROFILE, which should be unnecessary.
Description of how you validated changes
# Configure two  AWS SSO profiles using separate accounts
# Add a wrapped entries that uses credential_process with something like aws2wrap

unset AWS_PROFILE # Make sure we don't have any creds
# unset AWS_* # All the other standard export
amplify init
# Choose the first profile

amplify env add
# Choose the other profil

Both environments are created without any auth errors
Checklist

[x ] PR description included
[ x] yarn test passes
[ ] Tests are changed or added

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

Note: The way the current fix works it assumes that if credential_process exists in the profile that this is the way you want to authenticate.
It only adds the process provider to the chain.
We could put the others in there as well in case AWS_ variables are also set

@sachscode Anything we can do to help get this merged? It's preventing me from moving to 8.x

@sachscode If you can help point me in the right direction I can try, but not really sure where to start

Hi @johnf
Sure thing!
Reference
You could find referencing this test helpful:
https://github.com/aws-amplify/amplify-cli/blob/master/packages/amplify-provider-awscloudformation/src/__tests__/system-config-manager.test.ts#L28-L36
You can add your unit-test in this file.

The unit-tests use the Jest framework. https://jestjs.io/
The goal of the unit-test is to define a contract in the newly added code describing how it interacts with rest of the code in that file. A unit test consists of two important artifacts , mocking and the expect statement.
a. Mocking is used to describe the expected input shape and representative data for the interfaces in the newly added code:
e.g profileConfig.credential_process (boolean, and must be mocked to true for the code is executed ),
What’s the interface returned from aws.CredentialProviderChain.
What is the interface returned from aws.ProcessCredentials.
2. Expect is used to assert the expected output shape and data for the given input data.
you could add an expect clause to assert the final output available in the received awsConfigInfo.

If this newly added code changes in the future or any new code branches are added, then the unit-test hopefully breaks and future devs can update the unit-test accordingly. Please let me know if you have any other questions.

@sachscode thanks for the pointers.
I've added some extra assertions.
I'm checking we have a CredentialProviderChain, previously this was empty.
I wasn't sure of a good way to check aws.ProcessCredentials given it is inside an anonymous function inside an array.
We know it's the last one so I could mock ProcessCredentials and call the last entry in the array and ensure it's called. BUt that felt a bit brittle.

Thanks @johnf for the contribution, the change would be merged after another approval.  @akshbhu is taking a look.


Update composer.json

fix composer with warning:
Class ParsedownExtraTest located in ./vendor/erusev/parsedown-extra/test/ParsedownExtraTest.php does not comply with psr-0 autoloading standard. Skipping.

@erusev We need this merge!

Thanks for the PR.
How can I reproduce the issue? When I do composer require erusev/parsedown-extra, I get no warning; I'm on composer 2.0.12.

It happens specifically on composer dumpautoload:
$ composer --version
Composer version 2.1.5 2021-07-23 10:35:47

$ composer dumpautoload
Generating optimized autoload files
Class ParsedownExtraTest located in ./vendor/erusev/parsedown-extra/test/ParsedownExtraTest.php does not comply with psr-0 autoloading standard. Skipping.

I believe its because the test files don't have namespaces.
https://github.com/erusev/parsedown-extra/issues/156
https://github.com/erusev/parsedown-extra/issues/162

@erusev
This occurs specifically with the composer optimizer. You can replicate this by generating the autoloader with the optimize flag set -o
composer dump-autoload -o

Should output
Class ParsedownExtraTest located in ~/vendor/erusev/parsedown-extra\test\ParsedownExtraTest.php does not comply with psr-0 autoloading standard. Skipping.

Hope this helps

the warning is about ParsedownExtraTest not ParsedownExtra, so the change is not related to the warning message.

@erusev
I believe PSR is wanting ParsedownTest to be in the namespace test since it resides in a directory of that name.
\test\ParsedownTest

Most other libraries will place the source files in the src directory and then instruct PSR to look inside there. That way the tests and other materials are kept out of the way.
So basically,

create a src/ directory
move Parsedown.php inside src/
update composer.json to find the source file in there, eg:

"psr-0": {"Parsedown": "src"}

I haven't tested this, but it is the theoretical fix. I hope this helps.

@daftspunk this has nothing to do with Parsedown or ParsedownExtra class.
To fix this, namespaces of the classes in tests/ directory could be adjusted to use another autoloading strategy, e.g. putting them into a test\ namespace.

I still don't understand why the same issue doesn't occur with Parsedown, and now I have one more question, perhaps it's related:
Why does composer require erusev/parsedown-extra add dev files to the vendor folder, including:tests/, .travis.yml, phpunit.xml.dist? This doesn't happen for parsedown -- on composer require erusev/parsedown. What's different in parsedown-extra?

Hey @erusev. Me again. I note that in both repos you are implementing the use of .gitattributes which are being instructed to ignore the test/ folder.
This will have an interesting effect, via composer:

if you install the "source" version of a package, the test/ folder will be included
if you install the "dist" version of a package, the test/ folder won't be delivered, this is because the zip/tarball is made using git directives

This is likely why you are seeing inconsistent outcomes with equivalent packages.

Hey @daftspunk thanks for sharing your thoughts, but I still don't understand it.
In an empty folder, run composer require erusev/parsedown-extra and you get both parsedown and parsedown-extra in vendor/. One of them (parsedown-extra) has a test/ folder and the other one (parsedown) doesn't.
Why is that?

@erusev
That's because the latest tagged version of parsedown-extra (v0.8.1) does not contain the .gitattributes file. See here: https://github.com/erusev/parsedown-extra/tree/91ac3ff98f0cea243bdccc688df43810f044dcef


define the connection type config map typescript types

https://issues.redhat.com/browse/RHOAIENG-10310
Description

Defines the typescript types used to describe connection types.
A connection type is stored in a config map.
A connection type is an ordered collection of field descriptors. Each descriptor typed by a unique string identifier which identifies the corresponding field type. The field type is used to associate a rendered which knows how to consume their specific properties.
Note. The current field types are based on a non-finalized version of the UX. Therefore the fields and field properties are subject to change. However the general structure will remain the same.
How Has This Been Tested?

Manually.
No automated tests. Only new types are contributed.
Test Impact

N/A
Request review criteria:

Self checklist (all need to be checked):

[x] The developer has manually tested the changes and verified that the changes work
[x] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

[ ] Included any necessary screenshots or gifs if it was a UI change.
[ ] Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

@andrewballantyne we use annotations for storing display name and descriptions for k8s resources. While that approach continues to work here, it could be argued that these properties should be part of the connection type definition and therefore live within the config map data itself. I'm indifferent to either approach. Do you have an opinion?

/lgtm seems good to me

/lgtm