Default RERUN_CHUNK_MAX_BYTES to 256kiB instead of 4MiB

Fixes https://github.com/rerun-io/rerun/issues/7222

Checklist

[x] I have read and agree to Contributor Guide and the Code of Conduct
[x] I've included a screenshot or gif (if applicable)
[x] I have tested the web demo (if applicable):

Using examples from latest main build: rerun.io/viewer
Using full set of examples from nightly build: rerun.io/viewer

[x] The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
[x] If applicable, add a new check to the release checklist!
[x] If have noted any breaking changes to the log API in CHANGELOG.md and the migration guide

PR Build Summary
Recent benchmark results
Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

Didn’t we have increase this to speed up time series?

Didn’t we have increase this to speed up time series?

This does not affect time series since 4096 rows (RERUN_CHUNK_MAX_ROWS) of scalars still fit into 256kiB (RERUN_CHUNK_MAX_BYTES) (even when accounting for timelines, row ids, offsets, etc), with more or less margin depending on how many timelines are used.
I can probably bump it to 12 * 8 * 4096 bytes to give users even more leeway without any negative impact on the problematic workloads though. I'll try it.

I'll try it.

Works fine.


SQLite JDBC internal error: rs.isOpen() on exec error

It is thrown on
at org.sqlite.core.CoreStatement.exec(CpreStatement.java:70)
at org.sqlite.jdbc3.JDBC#Statement.executeQuery(JDBC3Statement.java:83)
when I execute a SQL query.
The version I am using is 3.20.1
It seems a internal error, and I can do nothing on it. So how to fix it? or how to avoid it?
Thanks!

Would you be so kind as to give more information? OS, system, statement you're trying to execute?
I'm assuming you're getting the "SQLite JDBC internal error: rs.isOpen() on exec." exception?

OS: centos 6.7 64bit
sql: just a simple query like "SELECT a, b from table group by b"
It occurs sometimes, about once per day.
May it be caused by multi-thread safe problem?  As I set the Statement variable as static.
I have change it to a non-static value but it need time to be observed.

If you execute that statement simultaneously somewhere, yes it is. By the definition of java.sql.statement:

only one ResultSet object per Statement object can be open at the same time

Seems the question was answered, i'm closing this. Comment if necessary.


OpenCvSharp.Extensions for UWP

First of I want to thank you for your hard work on this project and supporting UWP with your latest release. I have been developing a Windows based tablet application using your package and WPF, but I want to port it to UWP. The package from March 24th works fine for my WPF project, but when I want to implement the same functionality in a UWP project with NetCore 5.2.2 there is no OpenCvSharp.Extensions namespace available. I am specifically looking for the bitmap conversion of Mat using ToWriteableBitmap(). Am I just missing something here or is this functionality not available currently? If so, are you planning to support it in the future or offering a different way to display Mat elements?

Please see #339 . I am sorry but I'll remove UWP support fron OpenCvSharp.

Will there OpenCvSharp in UWP be supported in the future?
Are there other ways to combine OpenCv with UWP?

@shimat  I have seen your #339
Please check this out. A managed c++ wrapper for OpenCV 3 for UWP is coming.
C++ OpenCV3 for UWP is now available from Nuget.
I hope you can re-consider your decision for not supporting UWP - as Windows on ARM will not move fast without .NET OpenCV for UWP.

@shimat  I understand your decision. I just need to keep trying. Have you seen this Nuget for WinOnARM for OpenCV?
Nuget: https://www.nuget.org/packages/OpenCV.Win.Core/ provides
Once Nuget Install e.g. in an empty VS2015 UWP C++ project.
In the packages folder, we get win10-arm native dll and static lib
opencv_core310.dll
opencv_core310d.dll
opencv_core310.lib
opencv_core310d.lib


Chaosmeister do you use Bigboard plugin?

Sorry for posting this here, just was not sure how else to message you.
Do you use the Bigboard plugin? https://github.com/BlueTeck/kanboard_plugin_bigboard
If you do, I opened a few feature request issue reports over there.... if you find any of those features useful enough for you or your team and implement them then please let me know :)
Thanks again for your Kanboard plugins, I have installed them all, they are all very useful additions!

hey no problem!
We currently don't use Bigboard, but I might look into it in the near future, I'll let you know here


feat: add sync site action

Checklist

[ ] npm test passes
[ ] tests and/or benchmarks are included
[ ] commit message follows commit guidelines

Description of change

已自测通过


Scheduler header component view

Travis CI fails due to incompatibility of the component used for the calendar.

Travis CI fails due to incompatibility of the component used for the calendar.


Change DataReader's interface to return payload instead of spanList.

For each tuple coming out of Lucene, we obtain a structure called "term vector", which keeps positional information for the keywords as a small inverted index for the tuple.  It contains the starts, ends, and token offsets of all the keywords in this tuple.
In this PR, we introduce a new attribute called "payload" to include this information, which corresponds to the original "spanList".

LGTM.


handling config_output_path when it starts with tilde

I have issues
I'm submitting a...

[x] bug report
[ ] feature request
[ ] support request - read the FAQ first!
[ ] kudos, thank you, warm fuzzy

What is the current behavior?
Using ~ in config_output_path  does not work
If this is a bug, how to reproduce? Please include a code sample if relevant.

configuration

...
variable "write_kubeconfig" {
  description = "..."
  type        = bool
  default     = true
}
...
variable "config_output_path" {
  description = "..."
  type        = string
  default     = "~/.kube/"
}
...

run terraform apply

# it creates "~" directory in CWD
$ pwd
.../terraform-aws-eks/examples/basic

$ ls -l
drwxr-xr-x   3 user  staff      96 Nov  8 11:48 ~

$ ls "~/.kube/"
config-map-aws-auth_bender.yaml	kubeconfig_bender

What's the expected behavior?
it should create the config in /path/to/user/home/dir/.kube/ (pathexpand on the filename fixes this)
e.g:
resource "local_file" "kubeconfig" {
  count    = var.write_kubeconfig ? 1 : 0
  content  = data.template_file.kubeconfig.rendered
  filename = pathexpand("${substr(var.config_output_path, -1, 1) == "/" ? "${var.config_output_path}kubeconfig_${var.cluster_name}" : var.config_output_path}")
}

Are you able to fix this problem and submit a PR? Link here if you have already.
Environment details

Affected module version:
OS: macOS Mojave
Terraform version: 0.12.13

Any other relevant info

I also have this same issue now.

This is discussed in the provider's repo: https://github.com/hashicorp/terraform-provider-local/pull/34
You can use pathexpand to convert the filename to a full path. This will then end up in your state file.


Zero allocation futures

This PR shows that it's possible to have zero (extra) allocation futures, by generalizing Arc to Unpark + Clone + 'static. Unpark no longer requires Sync and this opens way to a bare bones version of tasks that work on no_std.
Gets rid of Arc in the poll methods, replacing with a UnparkHandle. Since trait objects can't be Clone this implements a custom trait object that is Clone by limiting the maximum size of the object. Upon park, instead of giving Arc references we clone the contents of the UnparkHandle, this generalizes the behaviour of cloning the Arc.
We need to figure out the intersection with the overhaul in #436. I think this is compatible with the extension to Unpark porposed, but doing both things may be overkill since they are both targeted at reducing the number of allocations in the tokio/futures interface. Hopefully this is compatible with the UnparkContext stuff in #436 though I haven't really taken a look at that part.
There is unsafe in the implementation of the trait object, I think it's correct and I got it to not crash any tests, but the more eyes on it the better!
The downsides is that this is a breaking change and there are subtle interactions around inner mutability. The limitation on the size of the type may also be annoying. But you can always wrap your struct in an Arc and get exactly the same semantics we have today.
Of course the real motivation of this PR is to surprise @alexcrichton as per #432.
Fixes #430. Fixes #432. Supercedes #433.

Unpark no longer requires Sync

Does this also open up a way to implement single-threaded executors without the penalty of atomic operations?

@Rufflewind This opens way to no_std tasks regardless of the Sync requirement, those generalizations independently fallout of no hard dependency on Arc.
It depends on what your single threaded executor looks like. Executors commonly need to share values with inner mutability. This PR allows you to, for example, clone a reference to a static mut instead of an Arc, and not care about synchronizing the access to the static mut because you are in a single thread.
Making a special version of Unpark and Task that aren't Send may be easier after this PR, but it's not obvious if we want that.

Thanks for the PR!
I feel though that having restrictions on the size of types is a little draconian, would it be possible to perhaps relax that? My thinking is that the only reason we require std today is b/c Arc is hardcoded, but could we perhaps rely on a trait and raw pointer to avoid hard coding that? I'm thinking something like:
trait Unpark: Send {
    fn unpark(&self);
    fn clone(&self) -> *mut Unpark;
    unsafe fn drop(&mut self);
}

And that way the vtable is buried in *mut Unpark automatically and we just be sure to call the drop portion at the appropriate time (and clone when creating a new handle).
@Rufflewind that will be a very difficult restriction to get rid of unfortunately, a Task is today Send + Sync, and I think we'll always want it to be at least Send

I also need to make UnparkHandle not Sync and therefore Task not Sync, had forgotten that! Meanwhile I pushed a commit to simplify things a bit by taking the unpark by value in UnparkHandle::new.

I personally feel that between this and https://github.com/alexcrichton/futures-rs/pull/436 the latter (https://github.com/alexcrichton/futures-rs/pull/436) has more potential in terms of being a route forward. In #436 the task system is generalized to only require one Arc per executor rather than per future. (that's done by passing around ids). That seems more flexible to me and achieving similar goals without having the downside of placing a dynamic restriction on the size of types passed in perhaps?

I think I will try to hide the Arc from the public API though (as mentioned in the PR) to future proof.

Agree #436 is better for many use cases in particular tokio. If we do this in addition to #436 we the upsides:

Task in no_std.
Support for non-Sync unparks.
Possible optimization for executors that can't take advantage of the index approach.

Downsides:

API complexity with Clone vs Arc semantics and the weird type size thing.
Task is no longer Sync.

I don't have concrete use cases for the upsides. I understand if this is closed for being undermotivated considering #436 is better for the only concrete use case at hand which is tokio.

Actually, I've realized this is a generalization of #436. Consider the following usage of the #436 API:
// core is an Arc<Core>, idx is an u64
spawn.poll_future(&core, idx)

Is equivalent to the following with the API in this PR:
struct IndexedUnpark {
    exec : Arc<Core>,
    index : u64
}

impl Clone for IndexedUnpark { /* ref_inc behaviour goes here */ }
impl Drop for IndexedUnpark { /* ref_dec behaviour goes here */ }
impl Unpark for IndexedUnpark { /* unpark by index behaviour goes here */ }

// When polling a spawn
let unpark = UnparkHandle::new(IndexedUnpark { exec : core.clone(), index : idx });
spawn.poll_future(&unpark);

We don't need the ref_inc(&self, id: u64) or ref_dec(&self, id: u64) because that behaviour goes in Clone and Drop respectively. Rather than hardcoding u64 indexes, we allow indexes of any type to be used. The Unpark trait dosen't need any extra methods or arguments.
Hardcoding max type size in this PR may feel like a hack, but #436 also has its clunkiness with harcoded u64 indexes and the ref_inc and ref_dec methods. If I'm correct #436 ends up being a specialized version of this.

I've made the maximum size of the unpark configurable through an env var (at compile-time) using standard build.rs trickery.

Changed it to use cargo features instead of env var + build.rs. This is more correct because it uses the maximum of the values set by dependencies and root. Downside is we need a feature for each supported value.

I now realize this has potential to do unaligned loads. I think it's fixable though.

The max size default and configurations are arbitrary right now, but thanks to @camlorn we have data to make an informed decison. I did a simple analysis over this collection of type sizes from rustc and the ecosystem. Disregarding types smaller than 8 bytes, we get the following numbers:

25% of the types are exactly 8 bytes.
50% of the types are under 24 bytes.
75% are under 32 bytes.
90% are under 64 bytes.
97% are under 128 bytes.
99% are under 256 bytes.

So 64 looks like an appropriate default. Supporting 128 and 256 as features makes sense. Any larger than that is unlikely to ever be needed. We can always add more features if someone comes up with an use case for sizes larger than 256.

I've changed things up to hide UnparkHandle from the public API, instead taking &Unpark + Clone such as in:
fn poll_future<U : Unpark + Clone>(&mut self, unpark: &U)
This is less verbose and more straightforward to read and use. It is also better for performance, if nothing else it saves cloning the Arc around, being better at that than #433. This is now much less of a breaking change, this is even less of a breaking change than #433.

I caught up with @carllerche on gitter today to get some feedback on this, which he kindly provided!
I was unable to convince him that this API is nicer and he was unable to convince me that the alternative API is nicer. This API exposes no methods that are unsafe to implement while the alternative avoids unsafe in the internals. In practice the executors may need unsafe even with this API, we would have to try out and see if this can really reduce the overall amount of unsafe. Also in this API the user dosen't have to create a trait object which avoids a clone when using Arc. In rayon for example, I guess we could at least kill fn make_unpark and the unpark field of contents, see here. If you are reading this and you've written an executor, I'd be curious to know what you think!
However, he gave me one argument that kills the approach in this PR. A goal that I was not aware of is to get the size of Task to a minimum, because it gets moved around so much. We could make the buffer size configurable down to a minimum of say 16 bytes, but still we have the vtable that is 32 bytes right now, so UnparkObj takes up quite a bit of stack space and is bloated in comparison to the alternative. I don't know any way to get the vtable out of UnparkObj (the compiler can put it in a global, unfortunately we cannot). So if Task bloat is a problem it's a dead end for this PR.


report issue: Missing Test Execution TIme in Test Execution History tab

Describe the bug
Execution time in Test Execution History tab is not populated for all tests.
To Reproduce
Steps to reproduce the behavior:

dbt seed --select XXX
dbt run --select XXX
dbt test --select XXX
edr send-report -slack-token XXX --slack-channel-name XXX --config-dir XXX --env dev --profiles-dir XXX --target-path XXX --days-back 14

Expected behavior
Execution time in Test Execution History tab is visible and has correct values.
Screenshots

Environment (please complete the following information):

Elementary CLI (edr) version: [0.15.1]
Elementary dbt package version: [0.15.2]
dbt version you're using [1.8.2]
Data warehouse [snowflake]

Additional context
This query returns the correct execution time for each test ( matches cli output ):
select * from XXX.ELEMENTARY.DBT_RUN_RESULTS where resource_type = 'test' order by generated_at desc limit 200;

So it looks like the issue is that the edr for some reason can't get the tests' execution time from the database.
Would you be willing to contribute a fix for this issue?
Yes

Hmm, the current_tests_run_results_query.sql query returns a bunch of results where all execution_time values are null

this query returns 48k results
select count(*) from ANALYTICS_STG.ELEMENTARY.dbt_run_results;

but,
select count(*) from ANALYTICS_STG.ELEMENTARY.dbt_run_results where execute_completed_at is not null

returns zero results
So the issue is that filtering the dbt_run_results table by execute_completed_at column produces 0 results, because this field is not populated for some reason


B6

rejected:ID2
reason:We cannot fully verify this submission. It looks like you are trying to submit ID2, however, it seems like there is just one address submitted.

confirmed:ID3
DocumentType:verified
Nationality:verified
DeviceDetails:verified
Experience:verified
Screenshot:verified

confirmed:ID3
DocumentType:verified
Nationality:verified
DeviceDetails:verified
Experience:verified
Screenshot:verified

confirmed:B6

confirmed:B6

confirmed:ID4
AccountAddress:4fC5S2gCJkGyArDwCMToPHEpLFFEfv7QwyumguYWmgBukw141P
DeviceDetails:verified

confirmed:ID4
AccountAddress:4fC5S2gCJkGyArDwCMToPHEpLFFEfv7QwyumguYWmgBukw141P
DeviceDetails:verified


Remove for loop on calibration error.

🐛 Improvement
More than a bug I wanted to see if the calibration error could be speed up by removing the loops and using native pytorch operations. Please correct me if I am wrong but the current implementation could go from:
conf_bin = torch.zeros_like(bin_boundaries)
acc_bin = torch.zeros_like(bin_boundaries)
prop_bin = torch.zeros_like(bin_boundaries)
for i, (bin_lower, bin_upper) in enumerate(zip(bin_boundaries[:-1], bin_boundaries[1:])):
    # Calculated confidence and accuracy in each bin
    in_bin = confidences.gt(bin_lower.item()) * confidences.le(bin_upper.item())
    prop_in_bin = in_bin.float().mean()
    if prop_in_bin.item() > 0:
        acc_bin[i] = accuracies[in_bin].float().mean()
        conf_bin[i] = confidences[in_bin].mean()
        prop_bin[i] = prop_in_bin

To something similar to this:
acc_bin = torch.zeros(len(bin_boundaries)-1)
conf_bin = torch.zeros(len(bin_boundaries)-1)
count_bin = torch.zeros(len(bin_boundaries)-1)

# Compute the position of each confidence in the boundaries.
indices = torch.bucketize(confidences, bin_boundaries) - 1

# Compute count per bin.
count_bin.scatter_add_(dim=0, index=indices, src=torch.ones_like(confidences))

# Add up each confidence on the respective bin and get mean.
conf_bin.scatter_add_(dim=0, index=indices, src=confidences)
conf_bin = torch.nan_to_num(conf_bin / count_bin)

# Add up number of correct points on each bin and get accuracy.
acc_bin.scatter_add_(dim=0, index=indices, src=accuracies)
acc_bin = torch.nan_to_num(acc_bin / count_bin)

# Go from counts to proportions.
prop_bin = count_bin / count_bin.sum()

@ramonemiliani93 we are more than happy to welcome your help and if you are willing to send a PR with improvement...

@Borda Sure! Let me work on it 👌


Nested discriminated unions

This was merged way back (https://github.com/colinhacks/zod/pull/1589) on Zod but I am still unable to use nested discriminated unions with @hono/zod-openapi. Any suggestion?
The example is taken from the refereeing PR.

@vickyRathee this is not @hono/zod-to-openapi - they use our library but handle things on their own.
However for your issue - the ticket mentioned never actually got anything merged - it was closed. You can see Colin's comment here: https://github.com/colinhacks/zod/pull/1589#issuecomment-2013975822 that mentions why this would NOT be implemented and a possible alternative that can be used.
I am closing this issue.


Improve error reporting

While working on fixing some issues related to setting license files (https://github.com/wasserth/TotalSegmentator/pull/208), I've noticed that errors are not handled very consistently throughout the code base. It would be nice to consistently use exceptions for reporting errors from functions.
Currently, some places exit() is called to signal errors. This is not good because it makes it impossible to call the Python function from an application, because calling exit() immedately crashes the entire application.
At some other places, complex return values are used. For example, error code and error text. This is not ideal either, because it makes the code too complicated and fragile (you need to make sure that the list items that are returned matches the expected list items everywhere where the function is used).
Instead, you can define your own exception type that stores everything that you need, such error code, text displayable to the user. The exception can be caught in the executable scripts or you can just let Python's default exception handler deal with the issue (print the stack trace and quit the process with error status).

Thanks for your pull request.
I agree that the error handling can be improved.
I can use a (custom) exception and then catch it to show the error message (I do not want to show the entire stack trace to a user who only entered a wrong license number). But then I would also have to do exit() to stop the program at this point. Otherwise I would have to add a lot of if/else to make the sure in any case the control flow does not continue. This is a lot easier with exit(). Or do you have another idea how to replace exit() and still exit the programm at certain points without showing a stack trace?

Yes, what you describe sounds good. I agree that in the executable Python script it is nicer to catch the exception and print just an error message (and not use the default exception handler that prints the stack trace).

Otherwise I would have to add a lot of if/else to make the sure in any case the control flow does not continue. This is a lot easier with exit(). Or do you have another idea how to replace exit() and still exit the programm at certain points without showing a stack trace?

You don't need to use exit to break the flow, you can use raise YourException(...) instead.

Is it possible to build a custom exception which I can raise, but which does not print the stack trace when raising it? I did some testing but did not manage to built such a exception.

You only get a stack trace if you don't catch the exception and it is caught by the default exception handler. If you catch the exception in your main function and print the message and exit then no stack trace will be printed.

That is correct. I only wonder how I can exit after catching the exception without calling sys.exit()? If I understand you correctly you want to avoid using sys.exit().

Calling sys.exit() in the executable script (such as totalseg_set_license.py) is no problem at all, because that is always executed in a separate process. Calling it in the Python API, such as in libs.py is a problem, because I may want to use the Python API in an application that I don't want to crash when some error happens.


"increment" should be a reserved path

If a document has a field named "increment", it conflicts with the increment() method called in model.js. This should either be fixed or "increment" should be added to the reserved paths list.

Yeah this is a bit of a problem - I don't want to add it to reserved keywords, because if versioning is off then its perfectly fine to have a key named increment as far as I know. I suppose I can add a warning for this though.

Thank you for addressing this. A warning would also do the trick I suppose.


OIDC with custom CA not usable

Describe the bug
I am trying to use OIDC with Weave Gitops, however due to my identity server having a custom/self-signed SSL certificate, Gitops cannot connect to the IdP and terminates.
I could not find any way to let Gitops use a custom CA, either by passing an additional argument or via the helm chart.
Environment

Weave-Gitops: 0.38.0
Flux: irrelevant
Kubernetes: irrelevant

To Reproduce
Steps to reproduce the behavior:
Configure issuerURL in secret oidc-auth to an HTTPS service which is configured with a custom/self-signed certificate and start/restart the Gitops pod.
Expected behavior
There is a way to provide a custom CA file for Gitops to trust
Actual Behavior
Gitops pod terminates because it does not trust the certificate of the IdP.

We are going to provide a simple way to do this, but you can customise a HelmRelease with a post-render
  postRenderers:
    - kustomize:
        patchesStrategicMerge:
          - apiVersion: apps/v1
            kind: Deployment
            metadata:
              name: weave-gitops-enterprise-mccp-cluster-service
              namespace: flux-system
            spec:
              template:
                spec:
                  containers:
                    - name: clusters-service
                      volumeMounts:
                        - mountPath: /usr/local/share/ca-certificates
                          name: custom-ca
                      env:
                        - name: SSL_CERT_FILE
                          value: /usr/local/share/ca-certificates/ca-bundle.crt
                  volumes:
                    - configMap:
                        defaultMode: 420
                        name: custom-ca
                      name: custom-ca

Implementing a simple way to do this is high up on our priority list.

in our case we tried using the existing variables on the chart (extraVolumeMounts, extraVolumes, envVars), and it worked.
`    extraVolumeMounts:
- name: custom-ca
mountPath: /usr/local/share/ca-certificates/custom-root-ca.crt
subPath: custom-root-ca.crt
readOnly: false
extraVolumes:
- name: custom-ca
configMap:
name: custom-root-ca
envVars:
  - name: SSL_CERT_FILE
    value: /usr/local/share/ca-certificates/custom-root-ca.crt

`


Fixes #2522: Adds tableplus command.

The Problem/Issue/Bug:
Fixes #2522.
How this PR Solves The Problem:
Follows the same method of support for Sequel Ace.
Manual Testing Instructions:
ddev tableplus
Automated Testing Overview:
No testing required since this leverages existing functionality to add support for TablePlus.
Related Issue Link(s):

#2522

Release/Deployment notes:
The new command needs to be packaged for the update, not sure what magic this involves 😉

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks!


improve accuracy of scipy.stats.gompertz distribution for small x.

Currently the cdf-ppf round trip for small x return wrong values as shown here:
In [85]: gompertz.ppf(gompertz.cdf(1e-100,1),1)
Out[85]: 0.0
By replacing exp(x)-1 with expm1(x) and log(1+x) with log1p(x) one can improve the accuracy of the gompertz distribution (_logpdf, _cdf and _ppf)  to machine precision for small x.
Replacing  _logpdf, _cdf and _ppf with
def _logpdf(self, x, c):
    return log(c) + x - c * expm1(x)

def _cdf(self, x, c):
    return -expm1(-c * expm1(x))

def _ppf(self, q, c):
    return log1p(-1.0 / c * log1p(-q))

one achieves
In [92]: gompertz.ppf(gompertz.cdf(1e-100,1),1)
Out[92]: 1e-100

Thanks @pbrod, fixed in gh-4407.


When no transactions exist the dashboard graph shows all dates as 01/01-'70

Describe the bug
When no transactions exist the dashboard graph shows all dates as 01/01-'70. This can be confusing for new users.
To Reproduce

Either create a new user with no transactions added or delete all transactions

Expected behavior
More recent dates, for instance the current date.
Screenshots

I don't think this is worth spending a lot of time on, as most people will have data in their user, but if someone wants to perhaps hide the entire page if you don't have any companies, that could be done.


Update MSBuild.StructuredLogger and some MSBuild packages.

Hoping to unblock https://github.com/ionide/FSharp.Analyzers.SDK/pull/210

Ok, I'm not going to claim I fully grasp why but bumping the MSBuild.StructuredLogger now requires the test projects to be net7.0. I don't think this is the end of the world.
Would just bump it together with the next FCS release.


Add --www for convenient static web server

Original pull request:  https://github.com/audiopump/x32-proxy/pull/2

@EricTetz Thank you again for your submission.  I've forked your changes and made a few more, renaming HTTP to WWW (to make it clear the intent of the new HTTP server), and also added the option of sharing an underlying HTTP server between the Web Socket server and HTTP static server... or not.  When starting, if you specify the same host+port for both, they'll share.  Otherwise, they won't.  If you do share them, client-side you just need to do new WebSocket('')... no need to even dig into the location object, the browser will figure it out for you.
Could you please:

[ ] Try this version and see if it meets your needs.
[ ] Check out the CLA and mention here if you agree to its terms.

If all is good, I'll merge this in.
Thanks!

[x]  Try this version and see if it meets your needs.
[x]  Check out the CLA and mention here if you agree to its terms.

Yes and yes. Been using it all morning. Works great. Thanks for the inclusion!
I have no idea how NPM publication works. Will the package be updated the moment you push this change to the master, or will it come later?

@EricTetz NPM publishing is not set up to be automatic, but I went ahead and manually published it just now.  Thanks for the reminder!


Fix docker builds

Thanks @hamishwillee for trying. Both docker builds were broken in the meantime.

Thx @JonasVautherin


Remove outdated vacancies

Removed outdated vacancies from vacancies.json as per instructions from teams

@tomlovesgithub please merge and update ticket. Cheers.


I want to restart nginx in docker. Thank you

Hello, boss,
I want to change it nginx.conf But I don't know how to restart it,
Because I started it in docker, this command prompt has no permission
bash-5.0$ /usr/local/openresty/nginx/sbin/nginx -s reload
nginx: [alert] could not open error log file: open() "/usr/local/openresty/nginx/logs/error.log" failed (13: Permission denied)
2020/07/20 06:48:41 [notice] 48#0: signal process started
2020/07/20 06:48:41 [error] 48#0: open() "/usr/local/openresty/nginx/logs/nginx.pid" failed (2: No such file or directory)
Is there any other way？

I think you'll need to define the prefix directory
/usr/local/openresty/nginx/sbin/nginx \
      -p "$PREFIX" \
      -c nginx.conf \
     reload

or try kong reload


Fix workflow id mention on parallel state branch def

There's no workflow ID in the branch definition any more :)

@ricardozanini thanks for PR!!!
prob need a discussion on this separately of PR, just wondering what you think about "the workflow id can't be the same id of the workflow where the branch is defined."
this really implies that a workflow definition cannot be both used as a "main" and a "subflow"....i wonder if we really need to have this restriction in place. do you mind starting a discussion on that and let's see where it goes :)

this really implies that a workflow definition cannot be both used as a "main" and a "subflow"

Hmm, I don't understand this way. As I understand, the branch I'm calling can't be the caller workflow. Maybe we need to clarify the text a little bit more. wdyt?

@ricardozanini
yeah i think
   The workflow id cannot be the same id of the workflow where the action is defined.

(and the other place where we mention this)
should probably lift this hard restriction and just say something like
"should in most cases not be the same id as the parent workflow id"
wdyt?


Module build failed: Syntax error:  C:/.../vue-extend-layout.vue: Unexpected token (51:19)

Hi, i have error after install and import.
NPM v5.6.0
Vue CLI v 2.9.6
Windows 10
My steps:

npm install vue-extend-layout --save
In my main js file:  import VueExtendLayouts from 'vue-extend-layout'

Error after npm run watch:

Package.json:

{
"private": true,
"scripts": {
"dev": "npm run development",
"development": "cross-env NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
"watch": "npm run development -- --watch",
"watch-poll": "npm run watch -- --watch-poll",
"hot": "cross-env NODE_ENV=development node_modules/webpack-dev-server/bin/webpack-dev-server.js --inline --hot --config=node_modules/laravel-mix/setup/webpack.config.js",
"prod": "npm run production",
"production": "cross-env NODE_ENV=production node_modules/webpack/bin/webpack.js --no-progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
},
"devDependencies": {
"axios": "^0.18",
"bootstrap": "^4.0.0",
"cross-env": "^5.1",
"jquery": "^3.2",
"laravel-mix": "^2.0",
"lodash": "^4.17.4",
"popper.js": "^1.14.5",
"vue": "^2.5.7"
},
"dependencies": {
"node-sass": "^4.10.0",
"validate.js": "^0.12.0",
"vue-extend-layout": "^2.0.6",
"vue-router": "^3.0.1",
"vuex": "^3.0.1"
}
}

Im new to npm, if you need more info tell me.

Are you up to Babel and Webpack up to date?
If necessary install syntax-dynamic-import and add the plugin it in .babelrc

Or to use babel-preset-env

Do you have updated Babel and Webpack?
If necessary install syntax-dynamic-import and add the plugin it in .babelrc

Thank you, it helps, but version of this plugin not compatible with a babel-core 6.3 which used by laravel mix.
I google in this direction and find this solution, it works for me: https://github.com/JeffreyWay/laravel-mix/issues/1249#issuecomment-335112415


Bug reappeared - DO always enables dhcp on mgmt interface after post declaration

Environment
Declarative Onboarding Version: <IP_ADDRESS>
BIG-IP Version: <IP_ADDRESS>
Summary
I am using DO v<IP_ADDRESS>, I encountered the same issue as it was described in https://github.com/F5Networks/f5-declarative-onboarding/issues/261 that supposed to be fixed in v1.25.0.
I have mgmt configured static on BIG-IP, when I apply DO declaration without any changes of mgmt state, I always receive dhcp enabled on mgmt interface of BIG-IP.
Steps To Reproduce
Steps to reproduce the behavior:
Submit the following declaration:
{
"schemaVersion": "1.0.0",
"class": "Device",
"async": true,
"Common": {
"class": "Tenant",
"hostname": "bigip.example.com",
"test_vlan2": {
"class": "VLAN",
"tag": 100,
"interfaces": [
{
"name": "1.1",
"tagged": true
}
]
}
}
}
Check that vllan was updated with dhcp state:
[root@bigip:Active:Standalone] config # ip a l mgmt
6: mgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:50:56:b8:37:ed brd ff:ff:ff:ff:ff:ff
inet <IP_ADDRESS>/22 brd <IP_ADDRESS> scope global mgmt
valid_lft forever preferred_lft forever
inet6 2003::77/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:feb8:37ed/64 scope link
valid_lft forever preferred_lft forever
[root@bigip:Active:Standalone] config # getdb dhclient.mgmt
enable
[root@bigip:Active:Standalone] config # tmsh list net vlan
net vlan test_vlan2 {
fwd-mode l3
if-index 304
interfaces {
1.1 {
tagged
}
}
tag 103
}
[root@bigip:Active:Standalone] config #

Sounds like a regression. Jira task AUTOTOOL-4419. Added to next sprint beginning mid August. Expect a pre-release in August. Will follow up with Daniel once pre-release is available.


Redirect failed test suite output to stderr

The change modifies the template code in tests/suites/helpers.function
so that error messages are printed to stderr. This makes errors visible
regardless of the --verbose flag being passed or not to the test
suite programs.
NOTES:

This change fixes https://github.com/ARMmbed/mbedtls/issues/820.
The change does not need to be backported to mbed TLS 1.3 or mbed TLS 2.1 as the test suite output is not redirected to /dev/null in those library versions.

I don't want to be a killjoy after this was approved by @yanesca and @RonEld, but I don't like the fix! You're outputting to stderr as a convenience to get around the redirection. But all the related text associated with this stream is going to stdout. I would prefer a fix that caches the output of test_fail() somewhere, and that text to be recovered and output to stdout after execution of the test at a point in the loop close to when PASS is displayed.  That will preserve the stdout and stderr streams as separate and distinct.

@sbutcher-arm: I have reworked the PR according to your review comments.

@Patater - if you can give a second review? It would be nice to merge this quickly following a second opinion.

@sbutcher-arm: Thanks for the changes. I have reworked the PR.

Ok, this is a simple change, in the test framework and not the library, so I'm happy to merge with just my own review.
Reviewed, tested, approved and merged into development.


Omnibot hardware

Write code for omnibot hardware

This pull request introduces 7 alerts when merging ec78b2274c05de77b0c93994c21266349823f571 into 55a90152cee86705729e98ddbf691344a7123b24 - view on LGTM.com
new alerts:

5 for Unused import
2 for Except block handles 'BaseException'

Comment posted by LGTM.com

This pull request introduces 7 alerts when merging 73e826c6aacfb3f90848f7b9783314fd5f46400b into 55a90152cee86705729e98ddbf691344a7123b24 - view on LGTM.com
new alerts:

5 for Unused import
2 for Except block handles 'BaseException'

Comment posted by LGTM.com


"error: no field named 'path' in union 'Build.LazyPath'" on compilation attempt

Steps to reproduce

git clone https://github.com/fairyglade/ly
cd ly
zig build

I am using Zig version 0.13.0
trace
ly/build.zig:32:33: error: no field named 'path' in union 'Build.LazyPath'
.root_source_file = .{ .path = "src/main.zig" },
^~~~
/snap/zig/11625/lib/std/Build.zig:2171:22: note: union declared here
pub const LazyPath = union(enum) {
^~~~~
referenced by:
runBuild__anon_8826: /snap/zig/11625/lib/std/Build.zig:2116:27
main: /snap/zig/11625/lib/compiler/build_runner.zig:301:29
remaining reference traces hidden; use '-freference-trace' to see all reference traces

@mghalix You need to use Zig 0.12.0, as specified in the README.


Design individual market display

A listed market has to show several pieces of information:

description
fee
end date
volume
tags
outcomes
action button (trade, report, view)

Those are the base properties, additionally, markets can be related to the user in various ways that need to be reflected:

owned positions (num shares, gain/loss, etc.)
open orders (num shares, price, etc.)
market was created by user (fees collected, gain/loss, etc.)
market is pending user's report
market reported on by user (show which outcome reported, unethhical)

done


Option resolution with proxies

As #8008 gets overly complicated, I thought of an (yet another) alternative way for resolving the options.
Using proxies, and split in 2 parts.
_resolver resolves the raw values on property access (and caches that).
_withContext applies an context on top of that.
One really nice advantage of this method is, that we can pass the _withContext object to the scriptable function, so all other values at that context are available. See the tests for example.
Hoping for comments on this :)

made some progress with performance testing:
master:

100 runs done in 5477ms. Average: 54ms, min: 32ms, max: 173ms, variation: 141ms. usedHeap: 46289.1kB

resolver:

100 runs done in 5977ms. Average: 59ms, min: 37ms, max: 218ms, variation: 181ms. usedHeap: 32324.2kB

so not quite there, but not bad either. most test still fail, only go the line controller functioning.

Made some more progress, got tests passing. This branch is POC: https://github.com/chartjs/Chart.js/compare/master...kurkle:resolver-wip?expand=1
Things achieved:

all top level options are scriptable. (top level for chart, dataset, scale and plugin options)
hover color resolution in defaults
the optimal case (uPlot bench) has similar performance with master

Couple of issues encountered:

Sub objects need to be have their own _resolver to work correctly. The sub-objects are currently not scriptable/indexable.
jasmine.objectContaining does a lot of checks to the object and that did not work with (current) Proxy implementation

need to either implement the things jasmine checks or use a custom matcher (thats what I did in the POC)

need to mark options as not scriptable somehow. event handlers for example.

Made some more progress, got tests passing. This branch is POC: https://github.com/chartjs/Chart.js/compare/master...kurkle:resolver-wip?expand=1
Things achieved:

all top level options are scriptable. (top level for chart, dataset, scale and plugin options)
hover color resolution in defaults
the optimal case (uPlot bench) has similar performance with master

Couple of issues encountered:

Sub objects need to be have their own _resolver to work correctly. The sub-objects are currently not scriptable/indexable.
jasmine.objectContaining does a lot of checks to the object and that did not work with (current) Proxy implementation

need to either implement the things jasmine checks or use a custom matcher (thats what I did in the POC)

need to mark options as not scriptable somehow. event handlers for example.

Made some more progress, got tests passing. This branch is POC: https://github.com/chartjs/Chart.js/compare/master...kurkle:resolver-wip?expand=1
Things achieved:

all top level options are scriptable. (top level for chart, dataset, scale and plugin options)
hover color resolution in defaults
the optimal case (uPlot bench) has similar performance with master

Couple of issues encountered:

Sub objects need to be have their own _resolver to work correctly. The sub-objects are currently not scriptable/indexable.
jasmine.objectContaining does a lot of checks to the object and that did not work with (current) Proxy implementation

need to either implement the things jasmine checks or use a custom matcher (thats what I did in the POC)

need to mark options as not scriptable somehow. event handlers for example.

Made some more progress, got tests passing. This branch is POC: https://github.com/chartjs/Chart.js/compare/master...kurkle:resolver-wip?expand=1
Things achieved:

all top level options are scriptable. (top level for chart, dataset, scale and plugin options)
hover color resolution in defaults
the optimal case (uPlot bench) has similar performance with master

Couple of issues encountered:

Sub objects need to be have their own _resolver to work correctly. The sub-objects are currently not scriptable/indexable.
jasmine.objectContaining does a lot of checks to the object and that did not work with (current) Proxy implementation

need to either implement the things jasmine checks or use a custom matcher (thats what I did in the POC)

need to mark options as not scriptable somehow. event handlers for example.

I think I like to general idea of this PR (if I understand it correctly, which I'm still unsure), but there is a few things that should not be implicit for the caller of this method (i.e. we should not guess if an option is supposed to be scriptable / indexable). However, I would not expect this logic to replace the simple resolve() one but be an extra high level API.
Some additional thoughts: few years ago, I was thinking to introduce option descriptors that would describe the way options are shaped and resolved. I don't remember exactly of the syntax, but conceptually it was something like this:
const descriptors = {
  color: {
    indexable: true,
    scriptable: true,
    default: '#123456',
    values: [
      (chart, ctx) => chart.data.datasets[ctx.datasetIndex].color,
      'options',
      { source: 'options', key: 'baseColor' },
      'defaults'
    ],
  },
  borderDash: {
    indexable: false,
    scriptable: true,
    default: false,
    values: [
      (chart, ctx) => chart.data.datasets[ctx.datasetIndex].borderDash,
      'defaults'
    ]
  },
  events: {
    indexable: false,
    scriptable: false,
    default: {},
    values: [
      'options',
      'defaults'
    ]
  }
}

const options = helpers.options.describe(descriptors, {
  sources: {
    'defaults': Chart.defaults,
    'options': chart.options,
  }
});

/*
const resolvedColor = options.color(context, index);
const resolvedBorderDash = options.borderDash(context);
const resolvedEvents = options.events;
*/

Having descriptors also allows to pre-optimize option resolution by creating accessors (proxies?) that skip some checks when not indexable, scriptable or if a source is null.

I think I like to general idea of this PR (if I understand it correctly, which I'm still unsure), but there is a few things that should not be implicit for the caller of this method (i.e. we should not guess if an option is supposed to be scriptable / indexable). However, I would not expect this logic to replace the simple resolve() one but be an extra high level API.
Some additional thoughts: few years ago, I was thinking to introduce option descriptors that would describe the way options are shaped and resolved. I don't remember exactly of the syntax, but conceptually it was something like this:
const descriptors = {
  color: {
    indexable: true,
    scriptable: true,
    default: '#123456',
    values: [
      (chart, ctx) => chart.data.datasets[ctx.datasetIndex].color,
      'options',
      { source: 'options', key: 'baseColor' },
      'defaults'
    ],
  },
  borderDash: {
    indexable: false,
    scriptable: true,
    default: false,
    values: [
      (chart, ctx) => chart.data.datasets[ctx.datasetIndex].borderDash,
      'defaults'
    ]
  },
  events: {
    indexable: false,
    scriptable: false,
    default: {},
    values: [
      'options',
      'defaults'
    ]
  }
}

const options = helpers.options.describe(descriptors, {
  sources: {
    'defaults': Chart.defaults,
    'options': chart.options,
  }
});

/*
const resolvedColor = options.color(context, index);
const resolvedBorderDash = options.borderDash(context);
const resolvedEvents = options.events;
*/

Having descriptors also allows to pre-optimize option resolution by creating accessors (proxies?) that skip some checks when not indexable, scriptable or if a source is null.

Maybe it's a bit out of the scope of this PR but something else that could simplify the option resolution logic would be to fully drop support for indexable options in v3. IMO, they are cumbersome, limited and not anymore useful since scriptable options have been introduced:
const colors: ['blue', 'red', 'yellow'];

const options = {
   colors: colors,   // don't support index > 2,

   // eq.

   colors: ({ index }) => colors[index],

   // or better:

   colors: ({ index }) => colors[index] || 'grey',

   // or a different use case:

   colors: ({ index }) => colors[index % 3]
}

But additionally, we could add an indexable helper that would return a scriptable functor:
const options = {
  color: helpers.indexable(colors),

  // or

  color: helpers.indexable(colors, {
    loop: false | 'repeat' | 'alternate',
    reverse: true,
    default: 'grey'
  }),
}

So controllers don't have to care anymore about how to "interpret" this option array.

Maybe it's a bit out of the scope of this PR but something else that could simplify the option resolution logic would be to fully drop support for indexable options in v3. IMO, they are cumbersome, limited and not anymore useful since scriptable options have been introduced:
const colors: ['blue', 'red', 'yellow'];

const options = {
   colors: colors,   // don't support index > 2,

   // eq.

   colors: ({ index }) => colors[index],

   // or better:

   colors: ({ index }) => colors[index] || 'grey',

   // or a different use case:

   colors: ({ index }) => colors[index % 3]
}

But additionally, we could add an indexable helper that would return a scriptable functor:
const options = {
  color: helpers.indexable(colors),

  // or

  color: helpers.indexable(colors, {
    loop: false | 'repeat' | 'alternate',
    reverse: true,
    default: 'grey'
  }),
}

So controllers don't have to care anymore about how to "interpret" this option array.

I'd be supportive of dropping support for indexable options (probably first as a separate PR to keep this one from getting too large).
I didn't look at https://github.com/chartjs/Chart.js/pull/8008 too closely so I'm curious what it was that you considered too complicated with it

I'd be supportive of dropping support for indexable options (probably first as a separate PR to keep this one from getting too large).
I didn't look at https://github.com/chartjs/Chart.js/pull/8008 too closely so I'm curious what it was that you considered too complicated with it

I think dropping indexable options might be quite disruptive so I'd want to avoid that. The descriptors idea looks promising in that it would be allow simplifying the lookup code (plus it would address the concerns above which options are indexable) and we could allow plugins to provide descriptors. I think for legacy reasons we'd need to support no descriptors, but that could follow the existing rules.

I think dropping indexable options might be quite disruptive so I'd want to avoid that. The descriptors idea looks promising in that it would be allow simplifying the lookup code (plus it would address the concerns above which options are indexable) and we could allow plugins to provide descriptors. I think for legacy reasons we'd need to support no descriptors, but that could follow the existing rules.

Thanks all, good feedback!
Indexable
I agree with @etimberg it would be quite disruptive to stop supporting that. I had thought of it, because it can not be used on all options - but now that I tested making everything scriptable, I noticed we have quite a few callbacks (that can not be scriptable). So that same/similar issue remain even if indexable was removed. The resolution would be simpler without indexable options, but not by much.
Descriptors
Interesting idea, combine all the configurable things about an option to single entity. As a DBA I'd say its almost like flat vs normalized. Descriptors being flat and defaults, scopes, indexability and scriptability separated being normalized. In a DB that means more space used. Performance depends on many things.
I'm not sure how we would describe the different resolution paths we currently have, depending on the scope a option is resolved to. Eg, borderColor is resolved differently for datasetElement and dataElement. Yet again differently for tick.
It would not solve "determining if an option is indexable (or scriptable) should not rely on the option name." (I'm not sure that can be solved).
We would need to register the descriptors (instead of the plain defaults we not register). Actually that is just the thing we really need. Registering the indexability / scriptability of options with defaults. Those can be either flat or separate, and we can even flatten or normalize those at registration, depending on what turns out to be the best solution.
Some of the things I'm trying to consider/address in this pr

defaults are mixed with options currently (merged), and after that we can not resolve anything using a different path correctly, so that every level of defaults is considered after all the options user provided.
after merge, chart.options contains a lot of excess stuff, that has no effect to anything
a lot of the code is about option resolution, try to normalize that (and make everything work consistently)
have the resolution built in, consuming an option is just reading the property. the consumer does not need to care if it was scripted, indexed or whatever. this would be really useful for plugins, you'd get scriptable options out of the box without a line of code.
normalize the option resolution path, so everything is resolved consistently
avoid the maintenance work when introducing new options or making old options scriptable all over the place one by one
extensions and their controllers should be able to use the same resolution logic core has, without copying and maintaining the copy of the code
there should be the user provided options object available somewhere. maybe chart.config.options should be that. chart.options could be the resolved/resolving options. likewise dataset should be the thing user provided. controller.options would be the resolved/resolving options.
not needing to list what options everything uses, resolve it when used.

8008 complexity
I realized we'd need to list every single option that is usable in each scope. Also really hard to get working after more than 100 commits to master after initial PR (not quite sure why).

Thanks all, good feedback!
Indexable
I agree with @etimberg it would be quite disruptive to stop supporting that. I had thought of it, because it can not be used on all options - but now that I tested making everything scriptable, I noticed we have quite a few callbacks (that can not be scriptable). So that same/similar issue remain even if indexable was removed. The resolution would be simpler without indexable options, but not by much.
Descriptors
Interesting idea, combine all the configurable things about an option to single entity. As a DBA I'd say its almost like flat vs normalized. Descriptors being flat and defaults, scopes, indexability and scriptability separated being normalized. In a DB that means more space used. Performance depends on many things.
I'm not sure how we would describe the different resolution paths we currently have, depending on the scope a option is resolved to. Eg, borderColor is resolved differently for datasetElement and dataElement. Yet again differently for tick.
It would not solve "determining if an option is indexable (or scriptable) should not rely on the option name." (I'm not sure that can be solved).
We would need to register the descriptors (instead of the plain defaults we not register). Actually that is just the thing we really need. Registering the indexability / scriptability of options with defaults. Those can be either flat or separate, and we can even flatten or normalize those at registration, depending on what turns out to be the best solution.
Some of the things I'm trying to consider/address in this pr

defaults are mixed with options currently (merged), and after that we can not resolve anything using a different path correctly, so that every level of defaults is considered after all the options user provided.
after merge, chart.options contains a lot of excess stuff, that has no effect to anything
a lot of the code is about option resolution, try to normalize that (and make everything work consistently)
have the resolution built in, consuming an option is just reading the property. the consumer does not need to care if it was scripted, indexed or whatever. this would be really useful for plugins, you'd get scriptable options out of the box without a line of code.
normalize the option resolution path, so everything is resolved consistently
avoid the maintenance work when introducing new options or making old options scriptable all over the place one by one
extensions and their controllers should be able to use the same resolution logic core has, without copying and maintaining the copy of the code
there should be the user provided options object available somewhere. maybe chart.config.options should be that. chart.options could be the resolved/resolving options. likewise dataset should be the thing user provided. controller.options would be the resolved/resolving options.
not needing to list what options everything uses, resolve it when used.

8008 complexity
I realized we'd need to list every single option that is usable in each scope. Also really hard to get working after more than 100 commits to master after initial PR (not quite sure why).

I think dropping indexable options might be quite disruptive so I'd want to avoid that

I'm curious to know if indexable options are used a lot and how. I'm fine with keeping support for indexable options as long as we don't introduce extra resolve option to support looping in the array. For example, color: colors will never resolve to: 0: 'blue', 1: 'red', 2: 'yellow', 3: 'blue', 4: 'red', 5: 'yellow'... if colors is ['blue', 'red', 'yellow'] (it should always return undefined for index > 2). I think this looping feature has already been requested, but it should be done using scriptable options. That's why I think we should not promote indexable options anymore, it's too limited.

I think dropping indexable options might be quite disruptive so I'd want to avoid that

I'm curious to know if indexable options are used a lot and how. I'm fine with keeping support for indexable options as long as we don't introduce extra resolve option to support looping in the array. For example, color: colors will never resolve to: 0: 'blue', 1: 'red', 2: 'yellow', 3: 'blue', 4: 'red', 5: 'yellow'... if colors is ['blue', 'red', 'yellow'] (it should always return undefined for index > 2). I think this looping feature has already been requested, but it should be done using scriptable options. That's why I think we should not promote indexable options anymore, it's too limited.

It would not solve "determining if an option is indexable (or scriptable) should not rely on the option name." (I'm not sure that can be solved).

It would because a descriptor describes a specific option. A fill option in the line controller is different of a fill option in a plugin. These are two different descriptors, used at different locations (e.g. one not indexable in the line controller and one indexable in the plugin). With the current PR implementation, all options named fill are considered not indexable.
A set of descriptors is indeed flat but there is as many sets as there is locations/scopes where we need to read options (plugins, controllers, elements, core, etc.). For example, I would generate one set of descriptors for the datalabels plugin. In my 2017 POC, for the line controller, there was a set of descriptors for the dataset elements and another one for the data elements.
Descriptors (and resolved options) are internal and should not be exposed to the public API.

It would not solve "determining if an option is indexable (or scriptable) should not rely on the option name." (I'm not sure that can be solved).

It would because a descriptor describes a specific option. A fill option in the line controller is different of a fill option in a plugin. These are two different descriptors, used at different locations (e.g. one not indexable in the line controller and one indexable in the plugin). With the current PR implementation, all options named fill are considered not indexable.
A set of descriptors is indeed flat but there is as many sets as there is locations/scopes where we need to read options (plugins, controllers, elements, core, etc.). For example, I would generate one set of descriptors for the datalabels plugin. In my 2017 POC, for the line controller, there was a set of descriptors for the dataset elements and another one for the data elements.
Descriptors (and resolved options) are internal and should not be exposed to the public API.

I think this looping feature has already been requested, but it should be done using scriptable options. That's why I think we should not promote indexable options anymore, it's too limited.

#7442

I think this looping feature has already been requested, but it should be done using scriptable options. That's why I think we should not promote indexable options anymore, it's too limited.

#7442

It would not solve "determining if an option is indexable (or scriptable) should not rely on the option name." (I'm not sure that can be solved).

It would because a descriptor describes a specific option. A fill option in the line controller is different of a fill option in a plugin. These are two different descriptors, used at different locations (e.g. one not indexable in the line controller and one indexable in the plugin). With the current PR implementation, all options named fill are considered not indexable.

Agreed, the way its currently in this PR is not the way to go. (Or could be expect for the implementation of indexable helper and its parameters)

A set of descriptors is indeed flat but there is as many sets as there is locations/scopes where we need to read options (plugins, controllers, elements, core, etc.). For example, I would generate one set of descriptors for the datalabels plugin. In my 2017 POC, for the line controller, there was a set of descriptors for the dataset elements and another one for the data elements.
Descriptors (and resolved options) are internal and should not be exposed to the public API.

Wouldn't the descriptors (or the spec of a descriptor) be public API so extension/plugins can provide those?

It would not solve "determining if an option is indexable (or scriptable) should not rely on the option name." (I'm not sure that can be solved).

It would because a descriptor describes a specific option. A fill option in the line controller is different of a fill option in a plugin. These are two different descriptors, used at different locations (e.g. one not indexable in the line controller and one indexable in the plugin). With the current PR implementation, all options named fill are considered not indexable.

Agreed, the way its currently in this PR is not the way to go. (Or could be expect for the implementation of indexable helper and its parameters)

A set of descriptors is indeed flat but there is as many sets as there is locations/scopes where we need to read options (plugins, controllers, elements, core, etc.). For example, I would generate one set of descriptors for the datalabels plugin. In my 2017 POC, for the line controller, there was a set of descriptors for the dataset elements and another one for the data elements.
Descriptors (and resolved options) are internal and should not be exposed to the public API.

Wouldn't the descriptors (or the spec of a descriptor) be public API so extension/plugins can provide those?

#7442

Ok, that's now the default behavior which is probably better than resolving to undefined. I would have close #4807 by suggesting to use a scriptable option since #7442 implements a specific use case. Here are some other ways to "loop" in that array:

alternate: a, b, c, b, a, b, c ...
fill: a, b, c, c, c, c, ...

I'm sure users will ask for them and my point is that we should not introduce new options to support these extra use cases. Instead, we should ask users to rely on scriptable options and maybe provide an helpers.indexable if it make things easier.

Wouldn't the descriptors (or the spec of a descriptor) be public API so extension/plugins can provide those?

I'm not sure I understand what you mean by "provide those". Descriptors are internal logic to describe how to resolve an option "required by a specific piece of logic". There is no dependency between descriptors, so I'm not sure why they would be public.

#7442

Ok, that's now the default behavior which is probably better than resolving to undefined. I would have close #4807 by suggesting to use a scriptable option since #7442 implements a specific use case. Here are some other ways to "loop" in that array:

alternate: a, b, c, b, a, b, c ...
fill: a, b, c, c, c, c, ...

I'm sure users will ask for them and my point is that we should not introduce new options to support these extra use cases. Instead, we should ask users to rely on scriptable options and maybe provide an helpers.indexable if it make things easier.

Wouldn't the descriptors (or the spec of a descriptor) be public API so extension/plugins can provide those?

I'm not sure I understand what you mean by "provide those". Descriptors are internal logic to describe how to resolve an option "required by a specific piece of logic". There is no dependency between descriptors, so I'm not sure why they would be public.

Closing in favor of #8374


Feature/kubeshark

Issue #, if available:
Description of changes:

added kubeshark addon
updated the index
created kubeshark.md for doc

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

Fix the GitHub action errors.

@zghanem0 Only concern at this point for merging this PR is, the addon is currently in your private org, so we want to know who will maintain the Kubeshark addon if its in your private repo, whats your path to move the addon to a public org like aws-samples.

@zghanem0 Based on this comment, merging this. Please followup and update the pattern once the addon is moved to aws-samples.


Expose DarkReader settings to users

Describe the solution you'd like
Allow users of ferdi to access darkreader settings. In particular, the brightness setting which makes dark themes more readable for me. Also, the shortcut key setting would be useful.
(Sorry for submitting so many issues lol)

@kytwb  Can I take this up?

Not @kytwb but yes you can take this

@mahadevans87 Please do! Feel free to pick up whichever open issue you feel like working on if nobody explicitly said they're working on it and the issue is not assigned 🙏

this would be amazing thanks!

📦 Shipped in v5.5.0-gm. A minor fix will be shipped in v5.5.0 via https://github.com/getferdi/ferdi/pull/593.


[Feature] Add new Footer component

Description
I want to add a new footer component.It has extra placeholder for site links,logo and subscribe button.It will be useful for ecommerce sites or newsletter applications.
Screenshots

Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

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

What will be the name of your component @komal-agarwal5

What will be the name of your component @komal-agarwal5

@Rakesh9100 It's name will be subscription footer

Go ahead @komal-agarwal5

Pls provide your PR @komal-agarwal5

Pls provide your PR @komal-agarwal5

Yes giving by EOD


✨ Add --version flags to binaries

What this PR does / why we need it:
Provide a quick and easy way to check the version of the binaries from the CLI. This is already present for openstack-cloud-controller-manager but not for any of the other binaries.
Which issue this PR fixes(if applicable):
N/A
Special notes for reviewers:
N/A
Release note:
All binaries now provide a `--version` option.

/lgtm

/approve


request-bing-ads-api-access

This url (below) is not available anymore. I really don't understand how to get api access with Bing.
https://advertise.bingads.microsoft.com/en-us/resources/bing-partner-program/request-bing-ads-api-access

@brasileric Thanks for this report. Im going to look into this. Bing has been making a lot of changes lately.

Thanks. It's very complex on the side of Bing indeed.

I've updated the documentation and added helpful pages that might guide you in the right direction. I will be running more tests in the next few months with both Google and Bing to be sure this SDK is up to date. If you're still having issues, feel free to submit a question regarding anything specific.

Hello, it's been a while, but  I wanted to be sure you were able to get access to Bing Ads API. I have updated the Bing Ads Guide to access the API with the new steps they require. These steps worked for me as of June 3rd, 2021.
https://github.com/tmarois/laravel-ads-sdk/blob/master/BingAds-Auth.md
Hopefully, this helps in your case and others that have had issues with connecting Bing.


nova: admin not allowed to start an instance

Looks like resource-related:

Possible direction of thought:
http://stackoverflow.com/questions/36714062/how-to-resolve-error-you-are-not-allowed-to-start-instance-instance-name-wi
Knowing that this is a modified Openstack RDO AIO for multidomain support and the policy.json policy file is indeed relpaced by https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json

Finally it is much trivial that that:
I am using a flavor with 20 GB space
 openstack flavor list

+----+-----------+-------+------+-----------+-------+-----------+
| ID | Name      |   RAM | Disk | Ephemeral | VCPUs | Is Public |
+----+-----------+-------+------+-----------+-------+-----------+
| 1  | m1.tiny   |   512 |    1 |         0 |     1 | True      |
| 2  | m1.small  |  2048 |   20 |         0 |     1 | True      |
| 3  | m1.medium |  4096 |   40 |         0 |     2 | True      |
| 4  | m1.large  |  8192 |   80 |         0 |     4 | True      |
| 5  | m1.xlarge | 16384 |  160 |         0 |     8 | True      |
+----+-----------+-------+------+-----------+-------+-----------+

But there is no such free space available:
df -h

Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   18G  3.9G   14G  22% /
devtmpfs                 2.9G     0  2.9G   0% /dev
tmpfs                    2.9G  4.0K  2.9G   1% /dev/shm
tmpfs                    2.9G   17M  2.9G   1% /run
tmpfs                    2.9G     0  2.9G   0% /sys/fs/cgroup
/dev/loop0               1.9G  6.1M  1.7G   1% /srv/node/swiftloopback
/dev/sda1                497M  217M  280M  44% /boot
tmpfs                    584M     0  584M   0% /run/user/1000

It is worth mentioning that I am using Openstack RDO with default centos disk space allocation of 20GB


Consider to support done after then

from:
https://github.com/mxcl/PromiseKit/blob/master/Documentation/GettingStarted.md

We only support some simple promise usage, we will add more complicate promise usage later


LitElement render starts after finishing life cycle events of Angular

Description
We are creating web-component based UI library for our customers. We were using Polymer library to create our web-components and they were working fine. Seeing the advantages and the control that Lit-Element provides to the component developer, we switched to LitElement.
We observed this issue with the Lit Element based webcomponent when used in an Angular component.

Figure 1: Angular->Lit->Angular
The LitElement render is called only after the ngAfterViewInit of both the parent and child Angular elements’ is called.
The result with one Polymer element between 2 Angular elements is as follows:

Figure 2: Angular->Polymer->Angular
The result with the DOM Structure as Angular -> Polymer -> Angular -> Polymer -> Angular is as follows:

Figure 3: Angular->Polymer->Angular->Polymer->Angular
The result with the DOM structure as Angular->Lit->Angular->Lit->Angular is as follows:

Figure 4: Angular->Lit->Angular->Lit->Angular
| DOM Structure | Observation
-- | -- | --
1 | Angular->Lit->Angular | Lit element render is called after ngAfterViewInit of both parent and child angular-elements
2 | Angular->Polymer->Angular | Render is called first before ngOninit of both parent and child angular components
3 | Angular->Lit->Angular->Lit->Angular | Both Lit elements’ render are called last after ngAfterViewInit of all angular components.
4 | Angular->Polymer->Angular->Polymer->Angular | Both Polymer elements get template() is called once(probably because they are the same element) before the ngOninit of other angular components
The problem we faced was this:
We have a similar structure as Angular->Lit->Angular as in Figure 1. We have written initialization logic in ngOninit of angular component 1 where we are trying to do some operation on the Lit component. But since the render of the Lit element has not been completed by that time as evidenced by Figure 1, it failed. But when we were using Polymer version of the same component, we didn’t face this issue as component was already rendered before ngOnInit.
What we tried?
Inside ngOnInit & ngAfterViewInit, we fetched the lit element and waited for the lit element’s updateComplete to finish.
This helped in preserving the order of execution of functions (even though it didn’t block the normal execution of angular’s lifecycle events)

So…is this best way to approach this scenario ?
Acceptance criteria
With the approach we tried the component consumer should handle the lit component differently.

Container component really should have to know the DOM structure and wait for lit-element component render.

How can we treat LitElement based webcomponents just like an angular component without such special handling for rendering? Please let us know if there is any better way other than using updateComplete to handle situation described above.

Thanks for the detailed information. We acknowledge that Lit's asynchronous rendering model can, hopefully only in rare cases, require special handling like this (via awaiting updateComplete). We use async rendering for efficiency, to ensure that property sets are batched and not every set causes an update/render. What you've done with updateComplete is our recommended approach for addressing this.
To do better, you could potentially handle this in your LitElement. The API you're calling from your Angular component could be implemented to call performUpdate(). In LitElement any pending update can be "flushed" by calling performUpdate(). So it would be something like:
whatIsTheThing() {
  this.performUpdate();
  // presumably this property is somehow dependent on having updated
  return this.theThing;
}

and from Angular:
const value = element.whatIsTheThing();

It's important to note that calling performUpdate() causes an update only on that element and not any sub-elements it renders. We've added an issue to potentially add an API to improve that in the future.
Hope that helps.

Thanks for the detailed information. We acknowledge that Lit's asynchronous rendering model can, hopefully only in rare cases, require special handling like this (via awaiting updateComplete). We use async rendering for efficiency, to ensure that property sets are batched and not every set causes an update/render. What you've done with updateComplete is our recommended approach for addressing this.
To do better, you could potentially handle this in your LitElement. The API you're calling from your Angular component could be implemented to call performUpdate(). In LitElement any pending update can be "flushed" by calling performUpdate(). So it would be something like:
whatIsTheThing() {
  this.performUpdate();
  // presumably this property is somehow dependent on having updated
  return this.theThing;
}

and from Angular:
const value = element.whatIsTheThing();

It's important to note that calling performUpdate() causes an update only on that element and not any sub-elements it renders. We've added an issue to potentially add an API to improve that in the future.
Hope that helps.

Closing based on the previous response. Feel free to re-open the issue if further discussion is necessary. Thanks.

Closing based on the previous response. Feel free to re-open the issue if further discussion is necessary. Thanks.


How to make Doom Emacs look like in Screenshot of Repository?

What are you trying to achieve?
... Make Emacs look like in Screenshot.
What have you tried?
... Searching, configuring, etc.
Additional information

Do you have screenshots/casts of this workflow in another editor or Emacs
distro? (If possible, include names of specific commands or functions from
other editors/emacs distros)
No.
Do you have additional material or links to resources that could help clarify
what you are trying to do?
That's what I'm looking for.

System information

emacs   version    26.3
        features   XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2
        build      aug 29, 2019
        buildopts  (--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now)
        windowsys  x
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop, origin/develop, origin/HEAD 453e20534 2020-01-15 11:19:32 -0500
        dir        ~/.doom.d/
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /bin/bash
        uname      Linux 5.4.6-2-MANJARO #1 SMP PREEMPT Tue Dec 24 15:55:20 UTC 2019 x86_64
        path       (~/.local/bin /usr/local/sbin /usr/local/bin /usr/bin /usr/lib/jvm/default/bin /usr/bin/site_perl /usr/bin/vendor_perl /usr/bin/core_perl /var/lib/snapd/snap/bin /usr/lib/emacs/26.3/x86_64-pc-linux-gnu/)
config  envfile    envvar-file
        elc-files  0
        modules    (:completion company ivy :ui doom doom-dashboard doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) vc-gutter vi-tilde-fringe window-select workspaces :editor (evil +everywhere) file-templates fold multiple-cursors rotate-text snippets :emacs dired electric ibuffer vc :checkers syntax :tools (eval +overlay) (lookup +docsets) magit :lang data emacs-lisp markdown (org +dragndrop +present) sh :config (default +bindings +smartparens))
        packages   (n/a)
        elpa       (n/a)

To be honest, having the TODO list look like that is just the theme being enabled and the :lang org module being enabled.

This doesn't seem accurate, but I'm a total Emacs novice so I could be wrong. Out-of-the-box though, my headings don't have hash symbol, darker background, larger text, or the down arrow when folded. I'm also not sure what the "hashtags" are at the end of the todo items themselves (are these tags rendered differently?)
I think the screenshot looks a tad cleaner than my org file, so I'm interested in learning what was done to achieve the look.

@jkanche you may try to save the window configuration on a registry: C-x r w <reg> where  is a char. To load the registry you may use C-x r j <reg>.
Does that solve your issue?

@jkw you need to SPC f P then open init.el and look for treemacs and uncomment it (remove the ;;). Then close your emacs, and execute on a shell ~/.emacs.d/bin/doom sync. Now you have Treemacs, the window on the left! Open it with SPC o p or M-x treemacs.
(there's a way of doing the sync without closing Emacs, but I'm new to Doom Emacs, so I'll leave this one for you to figure it out)
As for the rest, it's a big window on the left with an Elisp init file open, and two windows on the right: the upper showing some C source code; and the lower showing some Todo list on Org mode.
To split windows, do SPC w v to have windows side-by-side, and SPC w s to have one above the other.
If you are interested on Org mode, you may find lots of tutorials on the internet, i.e. David O'Toole Org tutorial
IMHO, I don't think any tutorial is necessary to achieve a screen as the screenshot. Some basic knowledge on Emacs will get you there.
To be honest, I had the same problem when I tried Doom Emacs as my first attempt to use Emacs. I moved to Spacemacs, learnt quite a few things about emacs and elisp, got tired of the broken interface for the languages I use, then came back here. Just now these things are clear to me. Until I got used to Emacs, I had to go back to VS Code many times when I needed to be productive.
Please, don't get angry on Emacs or Doom Emacs right at the beginning. Try a little bit more, learn a few shortcuts, try some elisp, learn which packages are important to you... then you'll be at home!
Also, if you have any questions, don't hesitate to ask! The community is here to help! :smile:

I have to admit that it is a bit daunting finding how to enable treemacs. I didn't knew the package name, and all tutorials I found assume that I have it already activated. Luckily I found this issue after a couple of hours and thanks to the detailed answer from @g-belmonte I activated it.

What I am unable to find out is how to customize outline symbol and folded character like the screenshot given.
The outline symbol in my emacs shows button like character rather than a hash sign (which is better imo), and the folded characters are ... instead of v shaped character.
Am i missing something?

@rickyson96, I think this is from the private configuration of the author.

Wow thanks! @dive.
It does provide some other configurations and is worth checking out 😄


32-2-update-buttons-to-use-govuk-frontend-component-in-brief-responses-frontend

trello: https://trello.com/c/N1CO6kFY/32-2-update-buttons-to-use-govuk-frontend-component-in-brief-responses-frontend

It still needs to work on the tests.


Doesn't work on Mac with bash 3

Tab key with yarn string triggers an error after yarn completion installed.
Error:
-bash: compopt: command not found
-bash: compopt: command not found
-bash: compopt: command not found

OS version: macOS High Sierra 10.13.4

Bash version:
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)

Yarn version: 1.7.0
Node version: 9.9.0

Known issue.
I don't have the time, energy, or desire to support a 9 year outdated version of bash. Simply upgrade to the latest bash version and your life will be easier for reasons far beyond just autocompletion.


feat: Release included images with newer version of node

With this pr we separate default node version from the version used for the included images, this could allow us to bump major versions of node for the included images but leave the factory with a lower version.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


savvy::savvy_update() should parse workspace?

Probably not necessary. One can put the main Cargo.toml on the top as well as using a workspace.


[owners] Migrate from GCE to GAE

The original implementation of the Owners bot was based around a Google Compute Engine (GCE) deployment. This decision was made because GCE provides local filesystem I/O, which is useful for maintaining a copy of the repository, using command-line-fu to identify owners files, and reading the contents of those owners files. No other files are read, and none are written.
Using GCE introduces a handful of issues, most notably:

deployment is fragile, takes down the app, and relies on a startup script that is not checked in
there is no reliable way to manage environment variables (especially sensitive keys/tokens); they are just embedded in the startup script, and can't be checked into the repository used to deploy
the team is less familiar with GCE than GAE, making maintenance and debugging harder
firewall restrictions around GCE make SSH and debugging difficult
the amount of bootstrapping and configuration embedded only in GCE instance metadata makes it hard/impossible for other projects to make use of the owners bot

As a resolution to these issues, the plan is to migrate to Google App Engine (GAE). This will be a lot of work up-front, but should make automated and continuous deployment and development of the app much easier and less error-prone going forward.
Steps needed to migrate to a GAE deployment process:

[x] configure app to read from .env file; write the .env file within the startup script during migration
[x] hoist a base Repository class out of the LocalRepository class, and implement a RemoteRepository subclass

[x] using the GitHub code search API, provide the listOwnersFiles method
[x] using the GitHub file contents API, provide the readFile method

[x] maintain a map from owners file paths to the SHA of their latest commit
[x] implement a caching layer to prevent overloading GitHub API on file reads
[x] lift the collection and parsing of owners files/the ownership tree out of the owners check and into a single server-shared tree
[x] isolate bootstrapping code (ie. initializing teams and ownership trees)
[x] add webhooks to catch updates to owners files and update the corresponding rules in the cache
[x] create app.yaml and deploy to GAE
[x] migrate team and tree updating code to use Cron tasks
[x] spin down GCE version of app

/cc @rsimha @erwinmombay @danielrozenberg

One concern/point to be aware of:
Once the tree is initialized, it will only need to fetch file contents when the owners files change, which should be relatively rare. Initialization, however, will be API-expensive; there are roughly 150 Owners files in ampproject/amphtml at this time, and each must be fetched separately. There are two ways we should address this.
The first is by rate-limiting the initialization code. By separating calls to the file contents and team member APIs by a second or two, we can avoid hitting some rate limits.
We can also store the contents of each owners file as a blob in a Cloud Storage bucket. The readFile API can try to first read from the bucket, then re-fetch from the API the blob is not present in Cloud Storage. Cleanup strategy for old versions of owners files needs to be determined. The advantage of this persistence strategy is that startup and initialization will be much quicker, and wil avoid any risk of blasting the GitHub API to quickly.
Alternately, we could maintain a database within the GAE instance tracking the owners/files/rules keyed by owners file path-SHA pairs, updating the database whenever owners files change, and reading from the database to construct the tree.
The additional overhead of maintaining, updating, and interfacing with this database would introduce more maintenance costs than it's probably worth, so I lean toward the blob storage solution.

Tagging @ampproject/wg-infra so everyone can chime in.

Also relevant: #575 #574 #573 #572 #576

My understanding was that smee was used for monitoring and debugging and re-sending webhook event payloads, not that it was a development-only thing. But I can revert it

Done in #586


Write json to widget

Hi, I need send a json from my site to your widget (by JavaScript) and use that json in another page.
Is possibile to do it?
I'm a web developer but I never develop chrome/firefox extensions.
Tnx

Hello,
chrome extension is just javascript+html.
You can use my code as a template and just change the part where I read the json from local storage
chrome.storage.local.get('fill_form_json',
to read the json from your web page.
All together is just 100 lines of code, mostly boilerplate.


Support s3 bucket configuration types

These changes are required to support setting the CorsConfiguration through convection.

cc @abegley-r7 @simonirwin-r7 @mmckeaveney-r7

Looks good, only concern is impacting current stacks, spoke with @e with regards to current usage, looks like no other stack references/makes use of CORS.

Looks good, only concern is impacting current stacks, spoke with @erran-r7 with regards to current usage, looks like no other stack references/makes use of CORS.

@abegley-r7 spoke to @jmanero-r7 and I'm going to address that in #135 with a deprecation warning for the bad property name.

I'm going to address that in #135 with a deprecation warning for the bad property name.

Done! Merging after tests complete.


Goroutine Pool for UDP datagram reads

This PR puts UDP server datagram reads into a Goroutine pool, and was made to address this issue within CoreDNS: https://github.com/coredns/coredns/issues/5595#issuecomment-1304496589
Here are some benchmarks of CoreDNS with and without my changes, with one server, using DNSperf.
Without my change:
  Queries sent:         13988687
  Queries completed:    13988288 (100.00%)
  Queries lost:         300 (0.00%)
  Queries interrupted:  99 (0.00%)

  Response codes:       NOERROR 13988288 (100.00%)
  Average packet size:  request 32, response 100
  Run time (s):         105.433637
  Queries per second:<PHONE_NUMBER>45

  Average Latency (s):  0.000627 (min 0.000023, max 0.022370)
  Latency StdDev (s):   0.000151

CPU utilization ~420%

With my change:
  Queries sent:         5735429
  Queries completed:    5735336 (100.00%)
  Queries lost:         0 (0.00%)
  Queries interrupted:  93 (0.00%)

  Response codes:       NOERROR 5735336 (100.00%)
  Average packet size:  request 32, response 100
  Run time (s):         29.624372
  Queries per second:<PHONE_NUMBER>97

  Average Latency (s):  0.000483 (min 0.000014, max 0.009152)
  Latency StdDev (s):   0.000336

CPU utilization ~560%

So notably we see CPU utilization went up significantly but QPS went up ~50%, and avg latency is down.
 Let me know if there's anything you'd like to see here; from my interpretation, all affected method calls should be thread-safe (but let me know if I've missed anything!).

Thanks for the quick review! I changed the waitgroup/error channel out for an error group.
I opted not to cause the rest of the Goroutine read loops to terminate if one of them returns an error, but let me know if you'd like to see something different here.

@tmthrgd is this good to merge?

@miekg I'm not a huge fan. Pools and multiple readers are hard to get right in a general sense. What might improve things for one workload, could easily worsen things in others. In particular I know things can get very counterintuitive with high core count CPUs.

Maybe we could define some sort of interface for people who want to implement pools of some kind. I'm not sure.

Ack. Thanks for your thoughts.
Tend to agree, so I'll close this PR. As for an interface, nothing forces
you to use all the things in this library, so prolly best to not define
anything for this use case
On Sat, 29 Apr 2023, 06:46 Tom Thorogood, @.***> wrote:

Maybe we could define some sort of interface for people who want to
implement pools of some kind. I'm not sure.
—
Reply to this email directly, view it on GitHub
https://github.com/miekg/dns/pull/1416#issuecomment-1528652284, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACWIW6KYTAZCOW4CI6UK5LXDSMK3ANCNFSM6AAAAAAURK3OQ4
.
You are receiving this because you were mentioned.Message ID:
@.***>


Building Grub fails when using gcc9

Bug description
Building Grub using the boards/x86/common/scripts/build_grub.sh on a system with gcc9 (observed on Clear Linux 29750, gcc 9.1.1) installed will fail with the following error:
cc -DHAVE_CONFIG_H -I.  -Wall -W -DGRUB_UTIL=1 -D_FILE_OFFSET_BITS=64 -I./include -DGRUB_FILE=\"grub-core/fs/cpio.c\" -I. -I. -I. -I. -I./include -I./include -I./grub-core/lib/libgcrypt-grub/src/  -I./grub-core/lib/minilzo -I./grub-core/lib/xzembed -I./grub-core/lib/zstd -DMINILZO_HAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -Wcast-align  -Wextra -Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 -Werror  -fno-builtin -Wno-undef  -MT grub-core/fs/libgrubmods_a-cpio.o -MD -MP -MF grub-core/fs/.deps-util/libgrubmods_a-cpio.Tpo -c -o grub-core/fs/libgrubmods_a-cpio.o `test -f 'grub-core/fs/cpio.c' || echo './'`grub-core/fs/cpio.c
In file included from grub-core/fs/cpio.c:51:
grub-core/fs/cpio_common.c: In function ‘grub_cpio_find_file’:
grub-core/fs/cpio_common.c:58:31: error: taking address of packed member of ‘struct head’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
   58 |   data->size = read_number (hd.filesize, ARRAY_SIZE (hd.filesize));
      |                             ~~^~~~~~~~~
grub-core/fs/cpio_common.c:60:29: error: taking address of packed member of ‘struct head’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
   60 |     *mtime = read_number (hd.mtime, ARRAY_SIZE (hd.mtime));
      |                           ~~^~~~~~
grub-core/fs/cpio_common.c:61:28: error: taking address of packed member of ‘struct head’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
   61 |   modeval = read_number (hd.mode, ARRAY_SIZE (hd.mode));
      |                          ~~^~~~~
grub-core/fs/cpio_common.c:62:29: error: taking address of packed member of ‘struct head’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
   62 |   namesize = read_number (hd.namesize, ARRAY_SIZE (hd.namesize));
      |                           ~~^~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:7120: grub-core/fs/libgrubmods_a-cpio.o] Error 1
make[2]: *** Waiting for unfinished jobs....
mv -f grub-core/fs/.deps-util/libgrubmods_a-afs.Tpo grub-core/fs/.deps-util/libgrubmods_a-afs.Po
mv -f grub-core/fs/.deps-util/libgrubmods_a-cbfs.Tpo grub-core/fs/.deps-util/libgrubmods_a-cbfs.Po
mv -f grub-core/fs/.deps-util/libgrubmods_a-bfs.Tpo grub-core/fs/.deps-util/libgrubmods_a-bfs.Po
mv -f grub-core/fs/.deps-util/libgrubmods_a-btrfs.Tpo grub-core/fs/.deps-util/libgrubmods_a-btrfs.Po
make[2]: Leaving directory '/home/gvancuts/zephyrproject/zephyr/boards/x86/common/scripts/grub/src'
make[1]: *** [Makefile:11589: all-recursive] Error 1
make[1]: Leaving directory '/home/gvancuts/zephyrproject/zephyr/boards/x86/common/scripts/grub/src'
make: *** [Makefile:3622: all] Error 2
./boards/x86/common/scripts/build_grub.sh: line 40: ./grub-mkimage: No such file or directory
~/zephyrproject/zephyr/boards/x86/common/scripts/grub ~/zephyrproject/zephyr
cp: cannot stat 'src/grub_x86_64.efi': No such file or directory

How to rproduce
Steps to reproduce the behavior:

Run boards/x86/common/scripts/build_grub.sh x86_64
See error pasted above

Impact
It is not possible to build the Grub bootloader, used to boot Zephyr as a UOS on ACRN for example (see https://docs.zephyrproject.org/latest/boards/x86/acrn/doc/index.html)

Using this (latest as of today) commit from Grub allows the code to compile successfully: grub-2.04-rc1-17-g8e8723a6b
I have yet to test it but if successful I can create a Pull Request for it.


fix(v2): anchor css not working on blog

Motivation
Anchor css is only defined in DocBody. It should be defined in Blog as well https://github.com/facebook/Docusaurus/blob/master/packages/docusaurus/lib/default-theme/DocBody/styles.css .
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan

@yangshun did u try https://docusaurus-2.netlify.com/blog/2018/09/11/Towards-Docusaurus-2 and inspect if there is any anchor.css ?


Doesn't compile under C++17

no type named 'string_view' in namespace 'std'
You need to #include <string_view> somewhere.

See #735  There are compilers that support the C++17 flag but don't have a <string_view> header in the standard library that is being used.  Others have it as <experimental/string_view>, while most include it in <string> which is included, and so it gets included that way.
What compiler and standard library are you using?

clang-5.0 and libstdc++ from gcc 6.3.0 (__GLIBCXX__=20170516). It does not in fact seem to provide <string_view>, so including it won't fix the problem.

Closing this issue as it is a duplicate of #735.


Adding an onboarding experience for new users along with intro slides

Is your feature request related to a problem? Please describe.
The app doesn't have a proper onboarding set up. If done, it would make the users get familiar with the application fairly easily and would make them understand how to use the application properly.
Describe the solution you'd like
I'd design and implement the intro screens along with proper onboarding, so that when the app would be installed and opened for the first time, the users would be greeted by an automated experience which would acquaint users with app's features and how to use it.
Describe alternatives you've considered
No response
Additional context
Some sample images for understanding onboarding:

Code of Conduct

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

Hello @jaivsh
Any update?

Hello sir I am Interested in This Task. I have already created some splash screen and onboarding screen.

I want to work on this issue under Gssoc. I have experience in creating onboarding screen.


Add Example: Simon's Algorithm

This is an implementation of Simon's Algorithm using Cirq, including the quantum circuit and classical post-processing. Any feedback is highly appreciated!

@googlebot I signed it!

@sebgrijalva Please fix the formatting errors by running check/format-incremental --apply

Call this in examples_test.py to cover it.

@vtomole  Thanks a lot for the patience! I'm familiarizing with github's system

@sebgrijalva Let's also get the build to pass.

I'm not so sure how to fix the failing checks ('Build Protos', 'Coverage Check') ...

@sebgrijalva  Write an example that causes
    if freqs.most_common(
            1
    )[0][1] < 0.25 * n_samples

to be executed.

Automerge cancelled: A required status check is not present.
Missing statuses: ['cla/google']