Proxy auth with custom HTTP transport

What does this PR try to resolve?
This PR makes cargo authenticate against proxies when needed.
Closes https://github.com/rust-lang/cargo/issues/7330
Add three settings:

http.proxy-auth
http.proxy-username
http.proxy-password

proxy-auth defaults to "auto" so that most use cases work out of the box. I don't know why you would disable authentication support, but I added a "disable" option in this case. You can also force the use of a mechanism and abort if the proxy doesn't advertise it.
proxy-username and proxy-password: String vs Option<String>?
curl doesn't negotiate (SPNEGO, here "gss") if handle.proxy_username and handle.proxy_password aren't called. This authentication mechanism doesn't require a user/pass in cargo config. This shouldn't hurt (?) when the proxy doesn't require authentication.
About curl-rust's spnego and ntlm features:
https://github.com/alexcrichton/curl-rust/blob/b50c5d355aab69483752db51815c5a679b29d6c4/curl-sys/Cargo.toml#L54-L60
This is the last blocker I think. If we require those features, then vendored curl builds will require "a suitable GSS-API library or SSPI on Windows" [0] for the "gss" setting to work (which is what corporate proxies are using most of the time). I think this PR is blocked until we can either  vendor those dependencies, or we change the official cargo builds to link dynamically to libcurl.
The official cargo builds seems to be made with vendored curl.
How should we test and review this PR?
Complete testing is a bit tedious since you'd need e.g. squid [1] to test each authentication mechanism. With such proxy, run cargo update with http-proxy environment variables (plus --config http.proxy-{username,password}= if needed).
[0] https://docs.rs/curl/0.4/curl/easy/struct.Auth.html#method.gssnegotiate
[1] http://www.squid-cache.org/

Unfortunately this seems like a relatively meaty change, so it can be difficult to nail everything down.
@hhirtz Is there a specific authentication scheme that you personally are interested in using? I was wondering if there is some way to narrow the scope of what is being added here. For example, if cargo needs to move to a different backend, then it would need to support all the mechanisms added here, which can be a large burden.  Additionally, it looks like building curl with all the appropriate support looks potentially complicated. Exactly what will be supported on all of Cargo's platforms with the current build system?
Another issue is that we try to avoid including secrets in the configuration files. Adding the password here seems like an anti-pattern, so I think we may need to look at some alternate approach. I'm not sure if that involves using credentials.toml or something else.
In general, it can also be difficult for me to review and understand a change like this since I am not deeply familiar with all the different proxy authentication mechanisms. I think to move forward, I would need some kind of ELI5 introduction to what is being added here to help evaluate how these will be used and the consequences.

:umbrella: The latest upstream changes (presumably #11646) made this pull request unmergeable. Please resolve the merge conflicts.


Telemetry

Proposed changes
The telemetry package: Thread-safe, low memory footprint, efficient collection of time-varying quantities in 286 lines of code. Using this module you can easily:

time the duration of selected code blocks;
turn on the Python built-in profiler (cProfile);
gather garbage collection and OS resource usage metrics---memory, user/kernel time, etc.

Telemetry data collection works seamlessly across process boundaries so even if the main process forks children, you can still be sure there won't be nasty race conditions and no overhead either as it would happen when using a DB backend.
Duration, GC and OS measurements are assembled in time series. Every time you sample a duration, a corresponding measurement is added to an underlying duration series at the current time point. GC and OS metrics, if enabled, work similarly, except they're automatically gathered in a background thread every second. Notice we use a nanosecond-resolution, high-precision timer under the bonnet. Time series data are collected in a memory buffer which gets flushed to file as soon as the buffer fills. Files are written to a directory of your choice.
Types of changes

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have signed the CLA
[x] I have added tests that prove my fix is effective or that my
feature works
[x] I have added necessary documentation (if appropriate)
[x] Any dependent changes have been merged and published in
downstream modules

Further comments
Concurrency and performance
The whole data collection process, from memory to file, is designed to be efficient and have a low memory footprint in order to minimise impact on the runtime performance of the process being monitored and guarantee accurate measurements. At the same time, it is thread-safe and can even be used by multiple processes simultaneously, e.g. a Gunicorn WSGI app configured with a pre-forked server model. (See the documentation of the flush module about parallel reader/writer processes.)
As a frame of reference, average overhead for collecting a duration sample is 0.31 ms. Memory gets capped at 1 MiB as noted below. (You can use the overhead gauge script in the tests directory to experiment yourself.)
Output files
Time series data are collected in a memory buffer which gets flushed to file when the buffer's memory grows bigger than 1 MiB. Files are written to a directory of your choice with file names having the following prefixes: the value of DURATION_FILE_PREFIX for duration series, the value of RUNTIME_FILE_PREFIX for GC & OS metrics, and PROFILER_FILE_PREFIX for profiler data. The file format is CSV and fields are arranged as follows:

Timepoint: time at which the measurement was taken, expressed as number of nanoseconds since the epoch. (Integer value.)
Measurement: sampled quantity. (Float value.)
Label: name used to identify a particular kind of measurement when sampling. (String value.)
PID: operating system ID of the process that sampled the quantity.

Out of convenience, the CSV file starts with a header of: Timepoint, Measurement, Label, PID.
Usage
You start a monitoring session with a call to the start function
import server.telemetry.monitor as monitor

monitor.start(monitoring_dir='/my/output/',  # where to output files
              with_runtime=True,             # enable GC & OS sampling
              with_profiler=False)           # but keep profiler off

This function should be called exactly once, so it's best to call it from the main thread when the process starts. There's also a stop function you should call just before the process exits to make sure all memory buffers get flushed to file:
monitor.stop()

This function too should be called exactly once. With set-up and tear-down out of the way, let's have a look at how to time a code block:
sample_id = monitor.start_duration_sample()       # start timer
try:
    # do stuff
finally:
    key = 'my code block id'      # unique name for this series
    monitor.stop_duration_sample(key, sample_id)  # stop timer

Now every time this block of code gets hit, a new duration sample ends up in the "my code block id" series. If you later open up the duration file where the series gets saved, you should be able to see something similar to
Timepoint, Measurement, Label, PID
    ...
1607092101580206000, 0.023, "my code block id", 5662
    ...
1607092101580275000, 0.029, "my code block id", 5662
    ...

Since timing functions is a pretty common thing to do, we have a shortcut for that
from server.telemetry.monitor import time_it

@time_it(label='my_func')
def my_func():
    # do stuff

The time_it decorator wraps the function you annotate to basically run the same timing instructions we wired in manually earlier. With runtime metrics collection enabled (see start method), a background thread gathers GC and OS data (CPU time, memory, etc.) as detailed in the documentation of GCSampler and ProcSampler. Another thing you can do is turn on the profiler when calling the start function. In that case, when the process exits you'll have a profile data file you can import into the Python profiler's stats console, e.g.
python -m pstats profiler.5662.data  # 5662 is the process' PID

Finally, here's a real-world example of using this module with Gunicorn to record the duration of each HTTP request in time series (one series for each combination of path and verb) as well as GC and OS metrics. To try it out yourself, start Gunicorn with a config file containing
import os
import server.telemetry.monitor as monitor

bind = "<IP_ADDRESS>:8080"
workers = 2               # pre-fork model (two processes)
worker_class = 'gthread'  # with threads,
threads = 2               # two of them for each process
loglevel = 'debug'

monitoring_dir = '_monitoring'  # output files go in ./_monitoring

# init monitoring with duration and runtime samplers just after Gunicorn
# forks the worker process.
def post_worker_init(worker):
    os.makedirs(monitoring_dir, exist_ok=True)
    monitor.start(monitoring_dir=monitoring_dir,
                  with_runtime=True,
                  with_profiler=False)

# start the request timer just before Gunicorn hands off the request
# to the WSGI app; stash away the sample ID in the request object so
# we can use it later.
def pre_request(worker, req):
    req.duration_sample_id = monitor.start_duration_sample()

# stop the request timer as soon as the WSGI app is done with the
# request; record request duration in a time series named by combining
# HTTP path and verb.
def post_request(worker, req, environ, resp):
    key = f"{req.path} [{req.method}]"
    monitor.stop_duration_sample(key, req.duration_sample_id)

# flush any left over time series data still buffered in memory just
# before the process exits.
def worker_exit(server, worker):
    monitor.stop()

Customisation
For common telemetry scenarios (timing, profiling, GC) you should just be able to use the monitor module as is. See there for details and usage.
For more advanced scenarios or writing your own samplers, familiarise yourself with the observation module (core functionality, comes with lots of examples) first, then have a look at the samplers in the sampler module to see how to write one, finally you can use the implementation of the monitor module as a starting point for wiring together the building
blocks to make them fit for your use case.
Prod monitoring
We can use this module as is to gather prod telemetry data. Ideally we'd add a couple of tweaks though, just to make it more convenient to use with K8s pods:

Make buffer flushing configurable: time intervals and memory thresholds.
Sidecar to move telemetry files to a place where they can be easily analysed. Importing into Crate or Timescale could be as simple as a COPY FROM. Another option is to copy them to a local directory and then import them into Pandas or any other data analytics framework.
Turning on/off of telemetry without restarting containers.

Data analysis with Pandas
Out of convenience I've added a pandas_import module to, you guessed it, import telemetry files into Pandas frames and series. This module doesn't really belong in the telemetry package but I couldn't find a better home for it just now. If you want to use it to analyse data produced during benchmark sessions (see src/tests/benchmark), you'll have to install Pandas and Matplotlib, which you can do easily with pipenv since I've added those packages to the dev dependencies:
$ pipenv install --dev

Notice those packages and their dependencies won't wind up in the Docker image.

I have read the CLA Document and I hereby sign the CLA

@chicco785 I've just pushed a commit (8af5e67) with some cosmetic changes to keep Code Climate happy. But it looks like there's a problem with how Code Climate counts lines of code:

File observation.py has 299 lines of code (exceeds 250 allowed).
Consider refactoring. NEW

That's bogus. Real count is 84:
$  cloc src/server/telemetry/observation.py
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                           1             93            248             84
-------------------------------------------------------------------------------

I've double checked the figure by tallying up lines of code myself and still got 84. (Well 80 if I exclude imports.) We should probably disable the check?

@c0c0n3 can you update documentation about running load tests and refer to this addition and ditch k6?
https://github.com/smartsdk/ngsi-timeseries-api/blob/master/docs/manuals/admin/benchmarks.md
very briefly, just to let people know how to run benchmarks.

I've added a new section to the manual to detail telemetry features and how to use them:
https://github.com/smartsdk/ngsi-timeseries-api/blob/profiling/docs/manuals/admin/telemetry.md

can you update documentation about running load tests and refer to this addition and ditch k6?

Sure, I can update that section too, but do you also want me to zap all the k6 related stuff too in the code base? i.e. scripts & friends?

Sure, I can update that section too, but do you also want me to zap all the k6 related stuff too in the code base? i.e. scripts & friends?

yep, clearly your shell script is less resource intensive and give burst (k6 provides more a user like dynamic behaviour)

@c0c0n3 can we finalise this PR?

can we finalise this PR?

I think it's ready to go. I haven't updated the benchmark manual section, I opened a separate issue for that: #415.


Adding "Surprise Me" button

This commit adds "Surprise Me" button to side of "Generate" button. The "Surprise Me" button chooses the random prompt for user.

You need to first raise an issue for the feature and if assigned then only raise a PR @rutujp78.
While adding a feature please drop the demo pics.

Now I am closing this PR kindly do this in the way I mentioned . 📌


Remove old notebooks used for prototyping

This PR removes the notebooks (from git history) that were used during the early prototpye

The RTD failure is unrelated, and it appears to be coming from the nb_gallery_generator

Extension error (nb_gallery_generator):
Handler <function main at 0x7f1788883310> for event 'builder-inited' threw an exception (exception: 'title')

Sorry I guess I should have waited for the check to finish before approving...

Sorry I guess I should have waited for the check to finish before approving...

No worries... I am going to look into this nb_gallery_generator issue and see if it's an easy fix that can be included in this PR.

I can't remember now what's the origin of nb_gallery_generator.py. It seems like something we may need again when we start to build out our hosted galleries. Is that not true?

I can't remember now what's the origin of nb_gallery_generator.py. It seems like something we may need again when we start to build out our hosted galleries. Is that not true?

Yes I think it is if we want to display an example notebook gallery. We might want this in the future.

Yes I think it is if we want to display an example notebook gallery. We might want this in the future.

Restored it

Pending @jukent approval


refactor dask test units

Pull Request Description
should close #1002.
reviews welcome while work still in progress.

After creating the pull request: in order to pass the changelog_updated check you will need to update the "Future Release" section of docs/source/changelog.rst to include this pull request.

test_calls_progress_callback in test_calculate_feature_matrix.py and test_dfs_method.py also could be split out

Test units pass on these two, but as xfail. If that is acceptable then the PR is ready to merge, if not, would like to know how to work around this one.


Cloud KMS batching not supported?

My question is does the googleapiclient's cloudkms service supports batching because the following script isnt working however
if i remove batching from the script it works just fine
also if batching is not supported what else can improve the performance because it almost takes more than a minute for me to fetch all the keyrings for all the regions thanks !
My Request code to list all the keyrings in all locations
service = discovery.build("cloudkms", "v1", http=token)

locations = service.projects().locations().list(name=f"projects/{keys.get('project_id')}").execute().get('locations')

batch = service.new_batch_http_request()

for location in locations:
      location = location.get('locationId')
      batch.add(service.projects().locations().keyRings().list(parent=f"projects/{keys.get('project_id')}/locations/{location}"))

print(batch.execute())

the fallback response i got:
---------------------------------------------------------------------------
HttpError                                 Traceback (most recent call last)
C:\Users\STAKAN~1\AppData\Local\Temp/ipykernel_140668/1819180182.py in <module>
     32       batch.add(service.projects().locations().keyRings().list(parent=f"projects/{keys.get('project_id')}/locations/{location}"))
     33
---> 34 print(batch.execute())

~\AppData\Local\Programs\Python\Python310\lib\site-packages\googleapiclient\_helpers.py in positional_wrapper(*args, **kwargs)
    129                 elif positional_parameters_enforcement == POSITIONAL_WARNING:
    130                     logger.warning(message)
--> 131             return wrapped(*args, **kwargs)
    132
    133         return positional_wrapper

~\AppData\Local\Programs\Python\Python310\lib\site-packages\googleapiclient\http.py in execute(self, http)
   1563                 _auth.refresh_credentials(creds)
   1564
-> 1565         self._execute(http, self._order, self._requests)
   1566
   1567         # Loop over all the requests and check for 401s. For each 401 request the

~\AppData\Local\Programs\Python\Python310\lib\site-packages\googleapiclient\http.py in _execute(self, http, order, requests)
   1498
   1499         if resp.status >= 300:
-> 1500             raise HttpError(resp, content, uri=self._batch_uri)
   1501
   1502         # Prepend with a content-type header so FeedParser can handle it.

HttpError: <HttpError 404 when requesting https://cloudkms.googleapis.com/batch returned "Not Found". Details: "<!DOCTYPE html>

  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>

404. That’s an error.

The requested URL /batch was not found on this server.  That’s all we know.
">

Hi @geekyshubham,
Batch operations are not possible for Cloud KMS (see note).
google-cloud-kms is the recommended client library for accessing the Cloud KMS API. Here is a sample showing how to list keyrings using that library.
However, I see that google-cloud-kms does not currently provide a way to do the equivalent of service.projects().locations().list(...). I'm looking into that now.
Are your keyrings distributed across all regions? If you have a shorter list of regions, you could consider only sending requests to those regions instead. That should cut down on the number of requests that is sent to the API and speed up your script.

Following up on my comment from earlier, it is not currently possible to do list all locations using google-cloud-kms, but there are plans to add that feature to the library.

thanks for replying @busunkim96 yes indeed my keys are distributed across multiple regions which is why i was querying through all the regions anyways i will consider using the cloud client library instead


Update gulp to gulp 4.0.0

Updating gulp from 3.9.0 to 4.0.0, which deprecated gulp-util in favor of using the separate modules themselves

At the very least, I think you'll need to bump the patch version number for the GulpV1 task.

It came out of #7839 and #3890.
Gulp 4 is almost a year old now, and gulp-util is deprecated because of it. It's causing difficulties for some.

@bryanmacfarlane I think we can hold off on this change until mid-December if there's some larger work going on. @azureDaveOps might have a different opinion, though. I think he wants it done for RC2.
One user reported needing to update the global gulp version for each build task (I don't know why they said "each build task", it seems like it only needs to be done at the start of the build?). Probably the biggest issue is that since our Gulp Task didn't support overriding the gulp.js location (now fixed, but not released), users were stuck using our provided version. There are some vulnerabilities in gulp 3.x dependencies, plus with it being a year old it enforces outdated usage that can be cleaned up with 4.

@moswald - this gulpfile has nothing to do with builds and tasks at runtime.  This was a gulpfile for building the tasks (our eng system).   I also think it's largely a dead file not touched in 2 years and we use make.js.  I think we left it for a transitionary period but I think the right fix is to delete it.  The reason I was asking is I was trying to understand how and where it could possibly be relevant :)

@bryanmacfarlane lol, gotcha. @austin-jensen, we should talk next week when you're back.

Closing since gulpfile no longer exists as of #9605 and we also now don't have the dependencies that are being bumped


Rsp dropzone

RSP DropZone is built on top of the RAC DropZone implementation so in terms of functionality and behavior, it should be pretty much the same besides the styling and extra banner that appears if the DropZone is filled.
RSP DropZone takes two additional props: replaceMessage and isFilled.
replaceMessage allows the user to decide what the message is presented in the banner, although it will default to ‘Drop file to replace’ if nothing is passed.
isFilled is used to determine whether the DropZone has been dropped with valid data or not. This is used to determine when the banner should be shown (which is only when the DropZone is in a filled state).
Previews are controlled by the user who determine what to show. This implementation simply provides the core structure of a DropZone with additional styling.
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

also chose to remove focus styling based on other people's opinions so let me know what you think. we can still bring it up to design but wanted to see how other feel

Can you add an example of a filled state in the stories? Maybe one with an image (you can use images from the CardView story examples). I think you will need to reduce the padding significantly, remove the illustrated message and center the content.

Still need to answer https://github.com/adobe/react-spectrum/pull/4757#pullrequestreview-1592626684

Still need to answer #4757 (review)

so after working on this comment on Friday, i found that VO behaves differently for the different browsers so while it will announce the message in Safari and FireFox, it won't announce in Chrome. not sure if there's a way to work around that but it would be good to do some testing to see which combination of browsers + OS the screenreader will/won't announce this message.


Add support for remotely-hosted workerHelpers script

Closes #6

Published as 1.0.3.

@josephrocca Now that I think about it a bit more... does this actually work for you? I'd expect it to fail because SAB requires COOP/COEP, and those still enforce same-origin restrictions.

@RReverser Hmm, I don't know the detauls of the COOP/COEP headers, but it seems to work fine for me 🤷 Contents of index.html:
<script type="module">
	let decode = (await import("https://deno.land/x/wasm_image_decoder@v0.0.4/mod.js")).default;
	let buf = await fetch("https://i.imgur.com/LYVUrUf.jpg", {referrer:""}).then(r => r.arrayBuffer());
	let result = decode(buf);
	console.log(result);
</script>

then serve with COOP/COEP headers:
deno run --allow-net --allow-read=. https://raw.githubusercontent.com/josephrocca/denoSimpleStatic/master/main.ts --port=3001

and it logs the image data to the console with no warnings/errors in Chrome. You can see in the source that v0.0.4 is using the fetch/blob approach.
If I run the above code without the COOP/COEP headers I get a warning in the console:

[Deprecation] SharedArrayBuffer will require cross-origin isolation as of M91, around May 2021.

On this explainer page for COOP/COEP it says:

These headers instruct the browser to block loading of resources or iframes which haven't opted into being loaded by cross-origin documents, and prevent cross-origin windows from directly interacting with your document. This also means those resources being loaded cross-origin require opt-ins.

What do they mean by "resources which haven't opted into being loaded by cross-origin documents"? deno.land doesn't serve the COOP/COEP headers, but it does serve with access-control-allow-origin: *. Maybe that's why it works? My first counter-thought was: "Well, you always need access-control-allow-origin: *, so they can't have meant that." But of course there are some resources (e.g. images/scripts) which can usually be loaded cross-origin without that header, and so I'm guessing that the above-quoted paragraph is talking about those ones?

I mean... if you don't have those warnings when serving main HTML with COOP/COEP, then I guess it's fine, but I'm not entirely sure how those rules work or why it's accepted 😅
Just to be on the safe side, I'd also check in Firefox which is already stricter regarding COOP/COEP headers and implements the restrictions mentioned in the warning in Chrome.

I did try to test with Firefox, but it turned out to be a bit of a pain, since it doesn't support top-level await yet, which is used in the module. I downloaded nightly and enabled it, but then it complains about the export in workerHelpers.no-bundler.js - saying that export can only be used at the top-level (even though it is already at the top-level) :/

I downloaded nightly and enabled it, but then it complains about the export in workerHelpers.no-bundler.js - saying that export can only be used at the top-level (even though it is already at the top-level) :/

Oh yeah, it's because it doesn't support module workers yet. See https://twitter.com/RReverser/status/1384837796159008770.
Or TL;DR - include https://www.npmjs.com/package/module-workers-polyfill too for polyfilling those (note that you'll have to download it locally, since it suffers from the same issue as you fixed in this PR due to Worker being hosted on a different domain).

Okay, I've done that and now I get this error:

Some other Firefox feature missing?

Oh, I thought you said you've already fixed it, but, apparently, that was someone else. See https://github.com/GoogleChromeLabs/wasm-bindgen-rayon/issues/1 for details (it's also mentioned in the README).

Most notably, even when you're using threads, the main thread still can't be blocked while waiting for the Rayon pool to get ready or for all the calculations to finish. You need to instantiate the main JS+Wasm in a dedicated Worker to avoid blocking the UI altogether.

Oh wow, so you need to init everything in a web worker and create your own glue to talk to the main thread? If that understanding is correct, wouldn't it make sense for this glue to be automatically generated? Or maybe throw a more helpful error message and/or put that note in a more prominent place in the readme? I might have misunderstood something here. This is certaintly surprising to me and I'd expect it to surprise other users too. I guess ideally it would detect whether it's being initialised on the main thread and create a worker for itself if so.
If my understanding is correct and you'd like to keep the init code as-is, then I think it would be a good idea to put all this critical setup stuff in a single "setting up" section.
Interestingly firefox has the "waiting is now allowed on this thread" when using a local webserver, but silently fails when serving from glitch:

https://wasm-bindgen-rayon-coop-coep.glitch.me/
https://glitch.com/edit/#!/wasm-bindgen-rayon-coop-coep

This is certaintly surprising to me and I'd expect it to surprise other users too.

It's definitely surprising and definitely something Chrome needs to fix, I've pinged the relevant internal bug again.
As for the glue - in principle, it's possible to do something here with wasm-bindgen-futures, but it won't be as simple as "detect whether it's being initialised on the main thread and create a worker for itself if so" because all your exports etc. still need to be proxied to the main thread, and now become asynchronous too and so on.

More generally, the problem is that any mutex or similar blocking mechanism will attempt to block the current thread (by definition) but on the Web it was decided not to allow that, since blocking UI even for relatively short period of time degrades user experience significantly.
I'm working on something that might improve situation with glue code further in the future here, but for now, yeah, you just need to put Wasm in a Worker and send final results to the main thread. In most usecases it's not too hard to do though.

it won't be as simple as "detect whether it's being initialised on the main thread and create a worker for itself if so" because all your exports etc. still need to be proxied to the main thread, and now become asynchronous too and so on

Ah, I see!

In most usecases it's not too hard to do that

I think in a lot of cases it'd be a bit more complicated, because you may want to expose the full API surface of the wasm module to the main thread, and so you'd have to write a bunch of plumbing code to deal with that - probably involving tracking task IDs so that you know which main-thread promises to resolve when you recieve messages back from the worker. But maybe most users will tend to do everything in the worker and only send data back to the main thread as necessary.
Looks like there are some libraries to help deal with this sort of problem to some extent. It would be cool if there were a JS library like this except that it neatly exposes a module from the worker to the main thread without any plumbing required by the developer. Then main-thread use could perhaps be as simple as:
let module = await workerify("./wasm/wasm_image_decoder.js");
await module.default(); // init
await module.initThreadPool(4);

I'm working on something that might improve situation with glue code further in the future here

Looking forward to hearing more about this!

You might want to take a look at https://github.com/GoogleChromeLabs/comlink meanwhile - it sounds very close to what you want.

Oh neat, thank you!


[SLORA]  support slora

Motivation
as wechat talk about, add slora api and document
Related resources
No response
Additional context
No response

@lvhan028

better to support qwen

@AllentDan may refer to https://docs.vllm.ai/en/latest/models/lora.html and https://github.com/vllm-project/vllm/blob/main/examples/multilora_inference.py
Consider exposing lora adapters during non-stateful inference.

Yeah. Planned to add it after #1188.

关注！有支持了麻烦踢我一下

关注！有支持了麻烦踢我一下

PR #1286


Allow HashTable to reference itself

I would like to refer to previously defined fields within HashTable:
@{
   foo = 'bar'
   baz = 'foo' + $_.foo
}

This is very handy for number of situations, particularly handling of configuration stuff.
Current workaround is to do something like:
$cfg = @{
   foo = 'bar'
}

$cfg.baz = 'foo' + $cfg.foo

which doesn't look nearly that nice.
Backward compatibility might be problematic here, for example:
[pscustomobject]@{foo='A'} | % { @{
   foo = 'bar'
   baz = 'foo' + $_.foo
}}

If there is interest, I could try to find out backward compatible solution, otherwise feel free to close this.

You could:
$x = @{Foo='Bar}
$x.Baz = 'Foo' + $X.foo

I would like to refer to previously defined fields within HashTable:
@{
   foo = 'bar'
   baz = 'foo' + $_.foo
}

That would change the behavior of existing code, e.g. this would break:
Get-ChildItem | ForEach-Object {
    [PSCustomObject]@{
        Something = $_.Name
    }
}

You could:
$x = @{Foo='Bar}
$x.Baz = 'Foo' + $X.foo

I already provided such thing in original post. I know I can do it that way, but its ugly. This is syntax sugar category.

That would change the behavior of existing code, e.g. this would break:

I also provided that. $_ is not good choice for sure.

We could potentially use $this for this kind of thing, but that too has a (lesser) potential to break something.

We could potentially use $this for this kind of thing, but that too has a (lesser) potential to break something.

$this is just another variable. Any variable can break existing scritps including funky ones such as ${~} .. .although it does seem that at least for ~ you cant call it as $~.

Sorry, I meant half-beautiful (just kidding).
While this:

$myHash = @{
   x = 1
   y = $myHash.y
}

would solve the problem of needing an automatic variable, I think it would introduce a maintenance headache: it's too easy to change the variable name later only in the assignment, forgetting that it must also be changed in the entries.

BTW, this is possible in YAML and some extensions of JSON.

Markup languages don't have a lot of options though.  It's either force duplication or implement this. With PowerShell, you can already do this there just isn't any syntactic sugar for it.

One other solution that comes to mind is to allow usage of its own variable

Could break if folks are shadowing variables:
$that = @{ nah = 'test' }
$that = @{
    one = $that.nah
}

Do you have some examples of existing projects or use cases that would greatly benefit from this?

The other variant - [HashTable($id)] @{ ... } looks more promising (perhaps without the $, given that you're providing a variable name), because it would decouple the identifier used in the entries from the name of the receiving variable - but we'd also have to come up with a syntax for ordered hashtables.
While we already have one pseudo type literal in the context of hash literals - [ordered] - we should think about whether adding more is worth it.

it's too easy to change the variable name later only in the assignment, forgetting that it must also be changed in the entries.

Looks like a minor problem that can be minimized with some convention on variable name, like using all caps - If you change var with all caps, change it also in the HT body.

Do you have some examples of existing projects or use cases that would greatly benefit from this?

Yes I have, I keep my CICD configuration in gigant hashtable such as this one.
Here is complete sample that could use this feature A LOT - actually, almost everything you see outside of HashTable is due to the this problem.
Hash table with environment config
$sapwd = Get-Secret production\sa

$SqlServerUsers = [ordered] @{
    Admin = 'sa', $sapwd
    App   = 'sa', $sapwd
}

$OsUsers = [ordered]@{
    Admin  = 'administrator', (Get-Secret production\administrator)
    Deploy = Get-Credential deploy
}

$env = New-Environment @{
    Name          = $MyInvocation.MyCommand.Name.Replace('.ps1', '')
    ServerEnvName = 'prod'
    Description   = 'CIR Production Environment'

    db = @{
        DbLocation = 'db-remote'
        SqlServer = @{ Users = $SqlServerUsers }
        OS        = @{ Users = $OsUsers }
    }

    rest = @{
        Port                    = 80
        DeployType  			= 'IIS'
        InstallDir  			= 'C:\inetpub\wwwroot'
		WebApplicationName  	= 'CirRest'
        OS                      = @{ Users = $OsUsers }
        UseSsl                  = $true
    }

    reporting = @{
        Port                    = 80
        DeployType  			= 'IIS'
        InstallDir  			= 'C:\inetpub\wwwroot'
		WebApplicationName  	= 'CirReporting'
        WebApplicationPoolName  = 'CirReporting'
        OS                      = @{ Users = $OsUsers }
		UseSsl                  = $true
    }

    web = @{
        Port                    = 80
        InstallDir              = 'C:\inetpub\wwwroot'
        OS                      = @{ Users = $OsUsers }
    }

    docs = @{
        RootPath                = 'docs/user/'
        OS                      = @{ Users = $OsUsers }
    }

    Metadata = @{ Notes = 'All roles are on separate servers except web and docs which share it' }

}

$env.docs.Server = $env.web.Server
$env.docs.Port = $env.web.Port
$env.docs.Server.ExternalHostname = $env.web.Server.ExternalHostname

$env

The other variant - [HashTable($id)] @{ ... } - looks more promising (perhaps without the $, given that you're providing a variable name), because it would decouple the identifier used in the entries from the name of the receiving variable - but we'd also have to come up with a syntax for ordered hashtables.

[ordered][Hashtable(id)] ?

If something like this is implemented, I would consider a real (relative, e.g. .\foo) reference and not a copy, so that:

you actually can create and save a cyclic dependencies
you can reference more then just the previously properties
resolve the "Backward compatibility" limitation
prevent possible infinitive loops when referring to top (or parent) of the current property:

@{
   foo = 'bar'
   baz = 'foo' + $_
}

Besides, the way it is presented, it will only work for the interpreter because hash table keys are of type [object] (and not [string]):
$Int = 1
$String = '1'
@{
    $Int = 'Int'
    $String = 'String'
    baz = 'foo' + $_.1 # Which 1 ?
}

@majkinetor
Regarding your example: Note that you're referencing entries across different hashtables, even though they're all nested inside a single hashtable; e.g., $env.docs.Server = $env.web.Server
The beauty-half-full approach can handle this:
@{
  web = ($web = @{ port = 80 })
  docs = @{ port = $web.port }
}

However, an automatic-variable-based solution cannot, as such a variable could only refer to the immediately enclosing hashtable.
Given that @SeeminglyScience has demonstrated that the $myHash = @{ foo=1; bar = $myHash.foo + 1 } syntax would be a breaking change (and, as a moot aside, I wouldn't consider the renaming-the-variable-problem a minor one, I think it would become a source of many subtle bugs), that leaves us with the [Hashtable(id)] syntax or similar.
A more concise form would be preferable, such as @[id]{ ... }; e.g.:
@[main]{
  foo = 1
  bar = $main.foo + 1
  web = @[web]{ port = 80 }
  docs = @{ port = $web.port }
}

Unfortunately, @(id){...} isn't an option because of the array-subexpression operator and neither is @id{...}, because in argument-parsing mode the @id part would be considered an instance of splatting; ditto for @:id{...}, surprisingly.
Some symbol that would currently result in a syntax error would be needed immediately after the @; another option is
@<id>{ ... }, but it isn't great either.

@iRon7
If a (pseudo) variable were made available, the usual rules would apply, just as with the variable-based workaround.
This includes disambiguating between string and numeric keys: $hash.1 gives you the [string] entry, $hash[1] the integer one.
My sense is that the primary use for this feature, especially in the context of configuration, would be in hashtables whose values are either .NET primitive types  or strings, where effectively getting copies at declaration time works as intended (but the syntax won't prevent you from creating cyclic references, just like using regular variables won't).
The System.Collections.Hashtable / System.Collections.Specialized.OrderedDictionary types that PowerShell constructs from @{ ... } / [ordered] @{ ... } literals don't allow for references between entries (I assume that's what you meant). It isn't the role of such syntactic sugar to add capabilities to the underlying types.

baz = 'foo' + $_.1 # Which 1 ?

I was aware of this but it is minor limitation that can be documented or solved with convention that @mklement0 mentioned. Its completely not a reason to not implement it because of that. In case both string and numeric number exist as a key, one could be preferred (string probably).

However, an automatic-variable-based solution cannot, as such a variable could only refer to the immediately enclosing hashtable.

True and explicit names offered before solve it elegantly . This is basically the same as your beauty-half-full approach but without 'half-full' :)

A more concise form would be preferable, such as @[id]{ ... }

I like this one a lot.
Seems like explicit naming is most bullet proof suggestion so far, without breaking compatibility.

Glad to hear it, @majkinetor, but there's trouble afoot: #5643 is coming back to life, and it proposes @[ ... ] as the syntax to create lists.
That leaves @<id>{ ... } or perhaps even @=id{ ... }
Given all this discussion, perhaps it makes sense if you closed this issue and opened a new one with a focused proposal that summarizes everything discussed so far.


docs(v1.suspensive.org): update copyright

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (v1@f151056). Learn more about missing BASE report.

Additional details and impacted files

@@          Coverage Diff          @@
##             v1     #918   +/-   ##
=====================================
  Coverage      ?   85.34%
=====================================
  Files         ?       30
  Lines         ?      505
  Branches      ?      114
=====================================
  Hits          ?      431
  Misses        ?       64
  Partials      ?       10

Components
Coverage Δ

@suspensive/react
100.00% <0.00%> (?)

@suspensive/react-query
0.00% <0.00%> (?)

@suspensive/react-await
100.00% <0.00%> (?)

@suspensive/react-image
23.52% <0.00%> (?)


Allow frozen string in hooks message

In our code we currently use frozen_string_literal: true. This causes an error because the slack-ruby-bot is trying to mutate a string.
We only fixed and created a test for the example we found, but there might be more.
Would you be open to using frozen_string_literal by default? I would be open to do that if you want.

Thanks for this.


Cloud compaction retries and throttling

Goal is to eliminate the Cosmos 429 errors by breaking query up into smaller ones.

Codecov Report

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

@@            Coverage Diff            @@
##             master    #1393   +/-   ##
=========================================
  Coverage          ?   72.69%
  Complexity        ?     7015
=========================================
  Files             ?      508
  Lines             ?    39561
  Branches          ?     5001
=========================================
  Hits              ?    28759
  Misses            ?     9434
  Partials          ?     1368

Impacted Files
Coverage Δ
Complexity Δ

...ain/java/com.github.ambry/config/ServerConfig.java
100% <ø> (ø)
1 <0> (?)

...a/com.github.ambry.server/AmbryServerRequests.java
94.11% <ø> (ø)
78 <0> (?)

...y.clustermap/RecoveryTestClusterAgentsFactory.java
0% <0%> (ø)
0 <0> (?)

...b.ambry.clustermap/RecoveryTestClusterManager.java
0% <0%> (ø)
0 <0> (?)

...in/java/com.github.ambry.clustermap/AmbryDisk.java
68.88% <0%> (ø)
17 <0> (?)

...om.github.ambry.protocol/PartitionRequestInfo.java
93.93% <0%> (ø)
11 <0> (?)

...in/java/com.github.ambry.clustermap/Partition.java
80.21% <100%> (ø)
29 <4> (?)

....github.ambry.clustermap/StaticClusterManager.java
71.02% <100%> (ø)
83 <5> (?)

...b.ambry.clustermap/SimpleClusterChangeHandler.java
91.78% <100%> (ø)
50 <0> (?)

...om.github.ambry.router/SimpleOperationTracker.java
92.3% <100%> (ø)
60 <5> (?)

... and 14 more

Continue to review full report at Codecov.

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


Make public compilable without private externals

This PR allows the current head to be compiled when BUILD_PRIVATE_EXTERNALS is set to OFF and/or Matlab is not found. In the former case, it automatically deactivates driver modules that require private externals, and in the latter it deactivates spotless and control.
I've just noticed @mauricefallon's mf-extract-atlas-lcmtypes branch which does the state-sync separation of this PR cleaner and in addition refactors/moves lcmtypes out related to #30. So perhaps just scavenge this branch/PR for cherry-pickable commits, e.g. in the externals.cmake, or make sure it doesn't overlap?

I vote against using sed to edit tobuild.txt.  In my opinion, we should not add hacks to work around shortcomings of the pod build system, instead we could extend the functionality of the pod build system or stop using it.

Replaced by #37, #39, and #40


Impact study (broken)

@mulark here's a quick impact study between dmidecode-rs and smbios-lib 0.9.0 for 3.5.0.  Code currently broken, just pushing this as an overview to look at.

It's a good question.  When you iterate the set you know you should only
get strings or failed UTF-8 parse errors but not errors of out-of-bounds or
bad index like you would if given an index.  I'm going to sleep on this one
tonight.  After making this an SMBiosStringSet with SMBiosStrings it feels
odd having to answer the match arms.

Message ID: @.***>


Log reasons validation of code details failed

Purpose
Log failures when validating a code to add to an LPA so problems can be debugged/monitored/etc.
Fixes UML-603
Approach
It adds logging. Maybe it is too defensive?
Learning
Any tips and tricks, blog posts or tools which helped you. Plus anything notable you've discovered about the Refunds service
Checklist

[ ] I have performed a self-review of my own code
[ ] I have added relevant logging with appropriate levels to my code
[ ] I have updated documentation (Confluence/GitHub wiki/tech debt doc) where relevant
[ ] I have added tests to prove my work
[ ] The product team have tested these changes

Coverage increased (+0.2%) to 75.822% when pulling 7593dcf73c7b47c02dfe6a6022665c5866567929 on UML-603-log-failures-to-add-lpas into 5634af897a837ddd1f455a0817a859c49677cfd1 on master.

Does that exception handler do what we want? If any problem occurs then delete the map we just created seems weird.

Also I hate that UUID loop, the whole point of UUIDs is that in practice you won't see a collision.

Does that exception handler do what we want? If any problem occurs then delete the map we just created seems weird.

I think it's because we don't know what those exceptions might be, hence the catch-all.
This is a cleanup thing so we do not end up with orphaned records, not ideal but at least keeps the data consistent.  If we can capture what the exceptions are, via logging, we could change this to be more specific, and handle them more gracefully. Maybe a tech debt item for later?


Closing a sheet from the backend

Hi,
Thanks for making this library!
I'm trying to add a button to a sheet that sends an event back to the server and also closes the sheet. I tried this:
      <.sheet_close target="clip-preview-sheet">
        <.button type="button" id="export-video" phx-click="export-video">Export Video</.button>
      </.sheet_close>

This sends the event to the server, but doesn't close the sheet. If I understand correctly, I'll need to push an event from the backend to the frontend(when I'm handling the export-video event). I tried:
     # In the `handle_event`
     push_event(socket, "phx-hide-sheet", %{to: "#clip-preview-sheet"})}

but this didn't work. Is there a way to do this?

There is a thread here on automatically showing a modal on edit, and automatically closing the modal on a successful submit, which could be adapted to working with the sheet.
Untested code ahead...
An idea which might work is to conditionally show and close the sheet based on the presence of a video form assigns (note the if, phx-mounted and phx-remove attrs).
...
  <.sheet_content id="video_uploader" side="right" :if={@video_form} phx-mounted={JS.exec("phx-show-sheet")} phx-remove={JS.exec("phx-hide-sheet")}>
      ...
  </.sheet_content>
...

Then in your backend you just setup the form on your "edit" event and clear the form on a successful "update" event, whatever you decide to call them.
def handle_event("edit", _params, socket) do
  {:noreply, assign(socket, :video_form, build_video_form())}
end

def handle_event("update", %{"video" => video_params}, socket) do
  # after a successful update
  {:noreply, assign(socket, : video_form, nil)}
end

The above uses Phoenix lifecycle events when adding and removing the sheet content element so that it will both show and hide the sheet using all the transitions that the open and close triggers use.

After trying some solution, I think that we should add some js hook to handle event triggered from server-side

Hi I've added document on how to execute client command from server side
Add javascript to handle event from server This add ability to execute client action from server. It's similar to JS.exec/2. Thanks to this post from fly.io.
Add this code snippet to the end of app.js
window.addEventListener("phx:js-exec", ({ detail }) => {
  document.querySelectorAll(detail.to).forEach((el) => {
    liveSocket.execJS(el, el.getAttribute(detail.attr));
  });
});

Then from server side, you can close an opening sheet like this.
  @impl true
  def handle_event("update", params, socket) do
    # your logic
    {:noreply, push_event(socket, "js-exec", %{to: "#my-sheet", attr: "phx-hide-sheet"})}
  end


Get accessor

This PR adds a get() function to all property setter functions.
message.attachments.get() // returns array of attachment objects

message.attachments.get(0) // returns first attachment object

message.attachments.get(-1) // returns last attachment object

message.text.get() // returns text value

This will be useful for modifying an existing message object, like replacing the buttons on the last attachment with a text only attachment:
message.attachments.get(-1)
  .buttons(null) // passing in null to any
  .text('You clicked a button')

In order to access the correct scope when calling .get() on a setter function, needed to copy the scope object and set it on the setter function itself.  Not super happy with this, but it's not part of any public api.  After implementing this I wonder if there's a cleaner way to do this with Object.defineProperty.
Refactored a few things in there to make this happen:

Moved property values to the data object on instances. Previously had the complex object instances stored directly on the object, i.e. message._attachments is not stored in message.data.attachments
Formalized ability to define an alias for properties, i.e. buttons=>actions
Also plugging in ci

Changes Unknown when pulling 42c1cffbffb488d8e1243d3fa97f8b7b4912c2dd on get-accessor into ** on master**.


vue-toastr on Nuxt Js Error

document is not defined
on node_modules\vue-toastr\dist\vue-toastr.common.js

The problem is fixed, only set client side only in nuxt js config file, thanks anyway!!!!!!


How to pass parameters into the next middleware function?

Hi folks, could you guys show me how to pass parameters into the next middleware?

Hi @khoa162 look into this next
Use gitter to ask question :-)

why you close my question?

Hi @khoa162 because @chakrihacker provided the proper location to ask: on Gitter.


[5.1] refresh remember_token if reset Password

For security reasons, if the user to reset the password, refresh remember_token.
because:
In this case the user may have been hacking account
All the old password generated remember cookie should not be trusted

In fact, I think, at this time, the old session should also be invalid
But to do so, the user database must add new field session_token, if change or reset passwords, change session_token
session recording user_id | session_token to validate, not only recording user_id

Please send to 5.2. 5.1 is closed for changes other than bug fixes.

@GrahamCampbell It has been sent to 5.2.
But I think in the 5.1 branch should merge.
if refresh remember_token in logout function,why not refresh remember_token in reset password?
https://github.com/laravel/framework/blob/5.1/src/Illuminate/Auth/Guard.php#L550


你好，请问通过反向动力学得到的16个rotation_matrix的坐标系是怎么样的，我在应用到smpl的模型时发现不是很对。

@maitetsu

我在配置文件中看到这个，是不是反向动力学得到的rotation_matrix与MANO的排序不同？

拇指的顺序好像是有些问题

As I could remember, ID2ROT is to align the order of ration matrix to MANO fashion. I am busy with another project now, might @maitetsu could help.

As I could remember, ID2ROT is to align the order of ration matrix to MANO fashion. I am busy with another project now, might @maitetsu could help.

Thanks！ I find the vertexs matipulate the view_mat([[1.0, 0.0, 0.0],
[0.0, -1.0, 0],
[0.0, 0, -1.0]]),  so I really want to the konw the coordinate of rotation_matrix genertated by "AIK.adaptive_IK(). I directly use the rotation_matrix in blender ，it can't work well. The coordinate of 3d model of  in blender is Right hand coordinate system，and  the 3d model can be drived by smpl's outputs.

Thanks！ I find the vertexs matipulate the view_mat([[1.0, 0.0, 0.0],[0.0, -1.0, 0],[0.0, 0, -1.0]]), so I really want to the konw the coordinate of rotation_matrix genertated by "AIK.adaptive_IK(). I directly use the rotation_matrix in blender, it can't work well. The coordinate of 3d model  in blender is Right hand coordinate system，and the 3d model can be drived by smpl's outputs.

Thanks！ I find the vertexs matipulate the view_mat([[1.0, 0.0, 0.0],[0.0, -1.0, 0],[0.0, 0, -1.0]]), so I really want to the konw the coordinate of rotation_matrix genertated by "AIK.adaptive_IK(). I directly use the rotation_matrix in blender, it can't work well. The coordinate of 3d model in blender is Right hand coordinate system，and the 3d model can be drived by smpl's outputs.

I would check it once I am free.

Thanks！ I find the vertexs matipulate the view_mat([[1.0, 0.0, 0.0],[0.0, -1.0, 0],[0.0, 0, -1.0]]), so I really want to the konw the coordinate of rotation_matrix genertated by "AIK.adaptive_IK(). I directly use the rotation_matrix in blender, it can't work well. The coordinate of 3d model in blender is Right hand coordinate system，and the 3d model can be drived by smpl's outputs.

I would check it once I am free.

The rotation matrix of MANO might be different with yours.

sorry to say I don’t have free time to check it and I am not familiar with blender. The rotation matrix is actually based on manopth (the PyTorch implantation by hassony2).


Lockdown in Kernel 5.4 for Alpha

Current situation
Lockdown is available since mainline Kernel 5.4. So it is possible to turn on lockdown without having to add third-party patches. We should first decide when we start turning on the lockdown kernel config.
Impact
Since some distros had enabled lockdown in Kernel, there were bug reports around eBPF. See https://github.com/iovisor/bcc/issues/2565.
So we should carefully investigate how we can avoid such breakages.

Lockdown is available in kernel config since Alpha 2632.0.0.

Looks like it was already done a long time ago.


chore: Update line-endings in inflows.csv.

@Batch21 does this give you an issues on Windows / WSL?


Prevent nil pointer in GetPullRequestCommitStatusState

Ensure that pr.HeadRepo is loaded before using it in GetPullRequestCommitStatusState.
Fixes error on merging with successful commit merge statuses.

Codecov Report

Merging #10342 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #10342   +/-   ##
=======================================
  Coverage   43.69%   43.69%
=======================================
  Files         585      585
  Lines       81019    81019
=======================================
  Hits        35401    35401
  Misses      41230    41230
  Partials     4388     4388

Continue to review full report at Codecov.

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


Doesn't append instance parameters

#### Summary
I'm trying to create a new axios instance with default params assigned.
The baseURL is appended, but not the params:
I have a static HTTP class that I clone with options for an axios instance:
static create(options: Object = {}): Object {
    // See comment for class cloning <https://stackoverflow.com/a/41474987>
    const clone = Object.assign(Object.create(this), this)

    return Object.defineProperty(clone, 'axios', {
      enumerable: false,
      configurable: false,
      writable: false,
      value: axios.create(options)
    })
  }

And then I have a TMDbProvider class that uses the cloned class from HTTP.
constructor(state) {
    this.http = HTTP.create({
      baseURL: `${config.TMDB.API}/3`,
      params: {
        api_key: config.TMDB.KEY,
        language: state.saved.prefs.iso4,
        append_to_response: 'external_ids,videos'
      }
    })
  }

Example of a get function in the HTTP class:
  static get(url: String, params: Object): Promise {
    return this.axios.get(url, { params })
      .then(res => res.data)
  }

As stated above in the summary, the default params doesn't get attached as shown below.
/home/sentinel/git/venobo-redux/node_modules/axios/lib/adapters/xhr.js:178 GET https://api.themoviedb.org/3/movie/76341 401 (Unauthorized)
But if I console.log the clone.axios.defaults object then the params are assigned.

Just recoded it all to create a new HTTP instance instead of it being static.
Same error occurs, but when I console.log this.axios.defaults before doing a request, it says the params exists in the axios instance, but they don't get appended to the url.

I just ran into this as well and was pretty surprised. Using default params for APIs is pretty common. Any simple workaround (outside of adding it to my get()) call?

A temporary workaround is to use an interceptor:
            const client = axios.create()

            client.interceptors.request.use((config) => ({
                ...config,
                params: {
                    ...config.params,
                    api_key: 'xxx'
                }
            }))

config.params is replaced directly, instead of merge. Users can write an interceptor as https://github.com/axios/axios/issues/1000#issuecomment-503765362 mentioned.

Why is this closed though? Just because a workaround exists doesn't mean that the core issue isn't a... well an issue. If it's perhaps me (and others) misreading the docs, then perhaps the real issue is simply a documentation change that should be made to make it clear.
Right now the docs say, "You can specify config defaults that will be applied to every request." which to me makes it VERY clear that I should be able to use it for the case I mentioned above (an api key) and if that is truly not the case, then we should edit the docs to clarify that you can't specify defaults for GET requests.
I'd argue that this should be re-opened until it's clear.

@cfjedimaster Opened #2618. Thanks for your feedback.


UTY-581: Bugfix Support UNITY_HOME with spaces in ci/lint.sh

Description
ci/lint.sh doesn't like spaces in UNITY_HOME

@samiwh You made the change to eval previously and have context on this

@jamiebrynes7 It looks like the more important changes I made to get spaces working were removed in https://github.com/spatialos/UnityGDK/pull/55


Release tweaks

@josenavas, I think this is the final changes necessary. Once this is in, I expect make-release.py to just fly. The resulting build appears to be sane.

looks good! :+1:


Add hooks to save and partially clean the target href tag from dompurify

This adds a pre and post hook to preserve target attributes on A tags.
Additionally, this adds rel="noopener" if the target is set to _blank.
Based on recommended solutions in the DOMPurify git issues..

This PR will be obsolete if PR #3548 is merged.

No longer needed


Add a bread recipe

To automatically close the issue, you can use for example the keyword "fix" # issue number


Handle key file download formats

Issue:
As it stands when downloading key files they will format as .pem (as intended) or .cer depending on the OS of the user.
This issue seems to primarily affect macOS. I'm on Ubuntu Linux and have never had this issue.
Possible solutions:

Re-examine the download method and ensure it will always save as .pem.
Re-examine the import method and modify it to allow .cer files.

This is fixed able to upload .cer


Windows server restore / Filter in HailMary mode

Hi,
First of all, I want to thank you for this repository.
I've encountered a couple of issues while using the code. The first issue is that the restore point functionality seems to be available only for computers. When I tried using it with a server, I had to create a manual restore point to utilize the HailMary mode, and I was forced to use the -SkipRestorePoint option.
The second issue is related to category filtering. When I filter by category and use the HailMary mode, the hardening is applied to all categories, not just the selected ones.
Thank you for your attention to these matters.
Best regards

Hi @Blue-i-y
Thanks for your feedback :)
According to Microsoft, "_System restore points and the ComputerRestore cmdlets are supported only on client operating systems", so unfortunately there is nothing more I can do. Would it help if you got an additional error message on a server operating system?
For now, the filter function is only supported in Audit and Config mode. As the HailMary mode is a delicate matter, I suggest you create your own file and remove all the lines you want to filter.
All the best

Hi @0x6d69636b,
The error message you provided is sufficient for now.
Thanks again for your assistance.
Best regards

Hi @0x6d69636b,
The error message you provided is sufficient for now.
Thanks again for your assistance.
Best regards


MSID: 89356 Version: 2 DOI: 10.1101/2<IP_ADDRESS>0491

MSID: 89356
Version: 2
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>0491
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=89356
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>0491

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/89356v2
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>0491
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/89356/v2/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

elocations missing from references

@FionaBryant can you check the reviews have been loaded the right way around here? We've got an Author response on the RPv1, and none on the RPv2.
Thanks!

Thanks James. For this one, it looks like we posted the provisional author
response with the first version of the RP (preprint v1) on the 17th July.
On the 20th Feb we then posted the author response on the preprint v2 with
the updated reviews, but it looks like it was mistakenly posted twice - do
you think this has caused the confusion?
On Wed, 21 Feb 2024 at 10:01, JGilbert-eLife @.***>
wrote:

@FionaBryant https://github.com/FionaBryant can you check the reviews
have been loaded the right way around here? We've got an Author response on
the RPv1, and none on the RPv2.
Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/elifesciences/enhanced-preprints-import/issues/2705#issuecomment-1956290197,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARMNBZE5THNLEULDDRLQ6OLYUXAYHAVCNFSM6AAAAABC4HJXCKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJWGI4TAMJZG4
.
You are receiving this because you were mentioned.Message ID:
@.***
com>

--
Fiona Bryant
Senior Editorial Assistant, eLife
--
elifesciences.org https://elifesciences.org
eLife Sciences
Publications, Ltd is a limited liability non-profit non-stock corporation
incorporated in the State of Delaware, USA, with company number 5030732,
and is registered in the UK with company number FC030576 and branch number
BR015634 at the address Westbrook Centre, Milton Road, Cambridge, CB4 1YG.

Thanks Fiona - yes that'll be the cause of the issue - I think EPP is only expecting one author response.
The way to fix this would be to presumably add the hypothesis ID for one of the duplicated annotations to the deleted spreadsheet. Unfortunately it looks like I don't have editing access (which I think I used to have), otherwise I would add 7RFQbs_NEe6Db8egN6WbVg to one of the rows.
Looks like @HazalCiplak is the owner - please can I be given access? Or is this spreadsheet not in use anymore?

Hazal has provided access and I have added hypothesis ID. Hopefully the reviews will appear as expected tomorrow.


Fix race condition in Shard insert v bootstrap

Fixes race condition in async shard insert during bootstrap

/cc @robskillington

Coverage increased (+0.2%) to 77.937% when pulling 1b73a8519ee2ff2b30448bcc0bf429bcf8a95dcb on prateek/shard/async-insert-race into a68d85cb2aa4526a6307badf1ed72fd3a32b3788 on master.

Coverage increased (+0.1%) to 77.837% when pulling 1836f6085ecf81dc248b7744597294cebe6feacd on prateek/shard/async-insert-race into a68d85cb2aa4526a6307badf1ed72fd3a32b3788 on master.

Hey, I think the more preferable approach which is race safe even during async inserts would  be this:
https://github.com/m3db/m3db/compare/r/simple-new-series-bootstrapped-logic

Coverage increased (+0.1%) to 77.859% when pulling 4d756a46162ac6d0f713f88538fc56b267eed3f5 on prateek/shard/async-insert-race into a68d85cb2aa4526a6307badf1ed72fd3a32b3788 on master.


KeyVault requirements

posted in wrong document - please ignore!
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c9642c47-826b-017f-eff3-ab3b25e4e454
Version Independent ID: 091f26e7-6543-ef0f-b575-b44519943391
Content: Quickstart: Register an app in the Microsoft identity platform
Content Source: articles/active-directory/develop/quickstart-register-app.md
Service: active-directory
Sub-service: develop
GitHub Login: @mmacy
Microsoft Alias: marsma

Thanks for the notice, @idunbar46 - closing out.
#please-close


Excessively loose type inference

Compiler version
3.3.1
3.4.0-RC4
Minimized code
// Error: Cannot prove that A[U] <:< A[N].
Wrap(new A[N]{})

// Adding the obvious type argument to Wrap makes it compile just fine.
Wrap[N](new A[N]{})

final case class Wrap[T <: U](first: A[T])(using A[T] <:< A[N])

sealed trait A[+T]

type U = Any
type N = Nothing

Compiler output
Cannot prove that A[U] <:< A[N].

Expectation
No error, similarly to when U is inlined, or N is not set to Nothing.

Tweaked minimised code (this can be passed to the compiler raw for reproduction, the original post's code is in script format)
final case class Wrap[T <: U](first: A[T])(using A[T] <:< A[N])
sealed trait A[+T]
type U = Any
type N = Nothing

@main def main = {
  // Error: Cannot prove that A[U] <:< A[N].
  Wrap(new A[N] {})
}

Raw output:
-- [E172] Type Error: /Users/pchabelski/IdeaProjects/dotty2/repro.scala:8:19 ---
8 |  Wrap(new A[N] {})
  |                   ^
  |                   Cannot prove that A[U] <:< A[N].
1 error found
Compilation failed

If we forget about the implicit parameter and just write:
final case class Wrap[T <: U](first: A[T])
sealed trait A[+T]
type U = Any
type N = Nothing
def main = Wrap(new A[N] {})

we get as expansion
    type U = Any
    type N = Nothing
    def main: Wrap[Any] =
      {
        Wrap.apply[Any](
          {
            final class $anon() extends Object(), A[N] {}
            new $anon():A[N]
          }
        )
      }

That's what is intended. If a type variable X with an upper bound needs to be instantiated, and the lower bound is Nothing, the upper bound is taken instead. And A counts as an upper bound here. This could be useful and might be used already elsewhere to influence type inference. So tweaking the rules as #19735 does just to make this test pass is out.

@dwijnand What are these type inference rules? And why can they not be amended?
I see two main options:

The rules are specified somewhere.
The compiler itself represents the rules.

If 1 is the case:

Where are these rules specified? (I could find only a few rules in the spec, and no SIP about inference.)
How would fixing this issue change the rules? Which of the specified rules would have to change?
What about this principle? Shouldn't type inference satisfy it? If the rules can lead to its violation, couldn't it indicate an issue with the rules themselves? Spec bugs have happened before, and some have been fixed (see this issue, for example).

If 2 is the case:

Wouldn’t fixing any bug about type inference change the rules?
How is this issue different?

Perhaps it really does not make sense to fix this issue, but "We can't change type inference rules." seems like an insufficient reason in any case.

The rules aren't specified, so, yes, fixing bugs changes the behaviour and thus the unspecified rules, and this issue is no different.  We've basically moved to not changing them any more.
https://github.com/scala/scala3/pull/19735 is, by the way, my proposed change that fixes your issue, but it could, potentially, affect some other existing inference, so it was rejected.  I argued that specifying an alias of Any as the upper bound (equally for Nothing/lower) should behave as if it were omitted.

@dwijnand Why are all of these issues (and more unlabeled ones) open, then? Shouldn't they all be closed as well?
I was aware of your proposed change. It only seems to address type alias transparency violation.
Might there not possibly be some (complete) fix to this issue that does not affect existing intended inference much? In that case, shouldn't this issue remain open, even if there is no fix for it yet?
Also, I would love to see any valid uses of the current undocumented ad-hoc inference logic for Nothing. I doubt it is used much intentionally, as it violating monotonicity makes it highly counterintuitive, if not flat-out fundamentally wrong.
@odersky wrote

This could be useful and might be used already elsewhere to influence type inference.

That sounds rather hypothetical and unsubstantiated, particularly when compared to the concrete example I gave showing how the current logic is detrimental, as well as the general principles I gave which the current logic violates. It seemed like an acceptable argument against

tweaking the rules as #19735 does just to make this test pass

, but the situation has been shown to be quite different now; the test is just an example of a far more general issue.
SIP-56 was a much larger breaking change (which of course also solved a much more severe issue, namely soundness) to a non-experimental feature of Scala. Even still, it got amended after launch to fix an additional overlooked minor issue.
The amount of breakage that could potentially be incurred by a fix to this issue seems comparatively benign, even when taking into account that monotonicity is much less important than soundness. One could even argue that monotonicity was an (overlooked) implicit goal of the existing rules all along, in a similar vein to this argument.

How am I to interpret the lack of response?
Is it due to a lack of resources and low priority? In that case, could the issue be reopened (it can be closed again once someone answers)?
It is still unclear to me how tightening type inference (in a sound way) could possibly cause incompatibilities or other negative consequences. By the Liskov substitution principle, which is partially enforced in Scala's variance system, it should not be possible for such a change to cause issues. Moreover, this change would only affect inference at the type parameter level, so should not affect runtime semantics (due to erasure).

@som-snytt How is it not actionable or out of scope? I'm not trying to be difficult. I'd be happy to accept valid arguments showing why this is not an actionable bug. So far, the arguments I have seen seem to be little more than reflexive responses trying to shut down an annoyance (but I might be missing a key point, leading me to misinterpret them).  For example, I was told that

The rules aren't specified, so, yes, fixing bugs changes the behaviour and thus the unspecified rules, and this issue is no different. We've basically moved to not changing them any more.

But then, why are other issues regarding inference open? I have trouble believing that no clearly suboptimal behavior of the type inference system is to be fixed from now on, particularly when it would not cause any compatibility issues.
I also wonder how starting a discussion on Dotty Discussions would yield different results from the discussion I led on Scala contributors.

Previously, Discussions was visited more by "core" contributors, but that may not be as true any more, since the cast of characters is rotating. (I find the forum less easy to search, and stale topics tend to stay stale.)
Discussions side-steps your questions, in that it is the place for open-ended (not to say non-terminal) discussions. On Scala 2, they added "bug reports are not questions" to the issue template. I have seen concern here that excessive open tickets makes it harder to triage and plan. I think you're right that resource constraints are a deciding factor on tickets. I am failing so far in my own determination to make sure tickets I open are closed, one way or another. One may say, Closed but not forgotten.

@Bersier In an ideal world, project maintainers would exist in sufficient numbers that we would have time to write comprehensive responses to every ticket. We don't live in that world. Project maintainers have to constantly choose about what engineering work is best deserving of their time, and they also have to weigh that against how much of their time to spend writing detailed responses to all the tickets that come in — even tickets that we have strong reason to believe are unlikely to progress. We're balancing that as best we can, just as all maintainers of all open source projects do, because they must.
I would add that — here and on every open source project — there is a strong bias towards spending time responding to pull requests, rather than to issues. Wishing type inference behaved differently is one thing. Being willing to pour substantial engineering effort into actually improving it is something else entirely.

@SethTisue Thank you for that detailed answer. It is appreciated, and I agree with all your points. I entirely understand the that this might not be high enough priority to argue about any time soon, if ever.
However, I still think that, as I have provided what I believe are strong arguments supporting the status of this issue as a bug, rather than a feature request, it should remain open until such a time that someone refutes those arguments. That time might never come, in which case this issue would remain open, like many others. And that would be fine.
I would also like to point out that I spent a substantial amount of effort explaining this bug and its significance. In your words:

sufficient justification to convince others that the changes are correct and desirable and the right thing and will continue to be the right thing for the years and decades of project work that lie ahead of us

Though whether the justification provided is actually sufficient is moot if it is unread.
I do not have the expertise to submit a pull request with a fix, unfortunately, but would be open to being taught. It would also be rather pointless to submit a fix before the proposed change is recognized as positive. A closed ticket indicates the contrary.

If you like, I could convert the closed issue to an open discussion (GitHub allows this).
I'm afraid we're strict about reserving open issues for clearly actionable bugs rather than potential design changes. At present, the status is that this is working as designed, and thus the issue is definitely going to stay closed unless new information comes to light. That's just how we roll in this repo.

I do not have the expertise to submit a pull request with a fix, unfortunately, but would be open to being taught.

Type inference is quite complicated, so that would be a substantial commitment. If you or anyone else is interested in getting up to speed, the main pathway we offers is the Scala 3 Compiler Issue Sprees, https://www.scala-lang.org/blog/2022/11/02/compiler-academy.html#logistics — that's a place anyone interested can get a start on tackling smaller issues, regardless of whether they're interested in eventually working up to bigger ones.

However, I still think that, as I have provided what I believe are strong arguments supporting the status of this issue as a bug, rather than a feature request, it should remain open until such a time that someone refutes those arguments. That time might never come, in which case this issue would remain open, like many others. And that would be fine.

I agreed and continue to agree to your strong arguments, and I agreed to your issue even before you gave them, submitting #19735 on the 19 Feb.  But the change and the argument for the change were rejected, on grounds that I can see how you find to be too hollow.
But I also don't think that this change is a hill to die on, which is why I personally chose not to spent further time trying to advocate for the change, and also why I eventually chose to not keep responding to comments - not because the comments weren't valid, but because the issue is niche and not a priority (at least, to my estimation).
But keeping the issue closed isn't a hill to die on either.  Part of the reason why all those inferencing issues are still open is because closing them causes arguments, so we leave them to open, but only in name.

I guess we can all agree these distinctions are a bit blurry :-)


gz_ros2_control parameter files between separate filesystems

Configuration:
Docker Ubuntu 22.04 on Ubuntu 22.04
ROS Iron + Harmonic
ros_gz (ros2), gz_ros2_control(main) built from source
Steps to reproduce:
Start a ros2_control stack on one host and Gazebo on another and try to spawn the robot.
Problem:
I am currently working on a ROS2 stack that is both used on a real robot and in the simulation. To make the dev experience better, I isolated the actual robotics pipeline with e.g. ros2_control and the simulation with Gazebo in two separate Docker containers. If I start the real robot everything is fine. If I start the robot with the simulation, the URDF description is send to Gazebo and gz_ros2_control tries to load the params file with the filepath from the other image (The same situation would appear if there would be separate hosts for example.) and fails consequently. Is there a known pattern or workaround that would either allow modifying the received URDF on the gz_ros2_control side or put all the parameters for gz_ros2_control into the parameter server? Is the param file import important at all for the spawning procedure in Gazebo?

I think this is not possible. gz_ros2_control loads an instance of the controller manager, which needs the ros2_control.yaml file to load the controllers etc. You will have to make that file available in the container where your simulation works.
Amongst that I'm not sure what are the advantages of your approach of two separate containers. Consider that ros2_controllers share data via shared memory with the hardware components (which is gz_ros2_control in this case). How can you separate that in two containers?

Ah that makes sense. I wasn't sure where exactly the controller manager is started. In my use case I have two containers that both mount /dev/smh so communication works without a problem. The separation would have been nice, since there is a third container that contains the perception pipeline (which needs a Nvidia GPU) that I essentially simulate with Gazebo (with the Bounding Box Camera for example). Separating the parts allows me to switch out the "perception" part (real or simulated) without ever touching the pipeline container. I currently have a hack to map the ros2_control.yaml into the container, but I was wondering if there is a better way to do that. Thanks for the answer!

I personally never used shared memory of ros2_control across container boarders, good to hear that this works for you.


The additional content, which is being displayed on mouse hover, is disappearing while moving focus on it, in Publish screen.

Describe the bug
The additional content, which is being displayed on mouse hover, is disappearing while moving focus on it, in Publish screen.
To Reproduce
Steps to reproduce the behavior:

Go to Publish  (http://localhost:9992/cm/app/?view=publish&site=test&path=%2FSites%2Ftest%2F&pathType=page)
Click on a Site.
Mouse hover on the Add New Server button. It will show "Add New Server" label.
Now try move the pointer over the "Add New Server, the label disappears.
User should be able to move pointer over the additional content (tool tip, label etc.).

Expected behavior
User should be able to move pointer over the additional content (tool tip, label etc.), and this additional content should not disappear, while moving focus on it.
Additional context
Navigate all the options available for similar issue and fix.

This is not a bug as there is no additional content on Hover. In application on Hover, only title is displayed. So closing this.


Add complete names for interaction event annotations

The event names for our interactions are not currently showing up in the docs.  It looks like the longname for these doclets is not being generated correctly if the @event annotation doesn't have the full module path.
With this change, the longname for the "drawstart" doclet is "DrawEvent#event:drawstart".  With the full module path this becomes "module:ol/interaction/Draw~DrawEvent#event:drawstart".
Here is what the draw interaction docs look like after this change:

Fixes #9471
It feels like there should be an opportunity to fix this another way (supporting the existing syntax).  I'll keep digging to see where that longname is generated - but I think this is an ok change to merge in too.

It looks like this might be the code that is supposed to be generating full module longnames:
https://github.com/openlayers/jsdoc-plugin-typescript/blob/a2c2c3e5fd12653038681da85f4afcc15ee51971/index.js#L201-L215

See openlayers/jsdoc-plugin-typescript#5 for a change in the plugin package.  After that is published, I can update this branch to pull in the new version and make the one additional change mentioned above (https://github.com/openlayers/openlayers/pull/9476#pullrequestreview-231487224).


add to docs - making an iso details

ubuntu 18.04 w/ 16GB RAM, 60GB? volume
git submodule update --init
cd subiquity && make install_deps
cd ../
sudo apt install make and sudo apt install lxd and sudo apt-get install p7zip-full and also sudo apt install pigz and sudo apt  install snapcraft and sudo apt install xorriso and apt install isolinux
lxd init with all defaults
also needed to edit

deleted -p docker

make
copy out the posm.io file
make clean
make superposm.iso
copy out the superposm.io file

docs have been updated since this was opened


IWW Issue #47 😸, April 20th 2021

This pull request is for gathering links for the April 20th issue of the Immersive Web Weekly newsletter for the W3C Immersive Web Community Group.
If you have a link to a news article, event, artwork, or project that is directly related to the immersive web then we welcome your help!
To submit a link comment below using this template:
title: Example title of link
url: https://example.com/
author: Alice Smith
content: A short description of what is at the link and why it's related to the immersive web

Please keep in mind that comments here and all submitted links are public!
We keep each issue pretty short so we won't immediately use every submission but we keep track of them all and they may appear in a later issue.
Deadline
IWW goes out each Tuesday morning around 10am Pacific time.
Trevor will edit each issue on the Monday before publication so submissions after that will roll over for use in future issues.
If you need editorial support then email @TrevorFSmith<EMAIL_ADDRESS>

title: Virtual Frederick Visitor Center
url: https://braincavexr.com/fvc.html
author: BraincaveXR
content: The virtual Frederick Visitor Center includes custom 3D environments and interactive exhibits that visitors can explore with Oculus Quest VR headsets or PC web browsers. The BraincaveXR platform incorporates ThreeJS and WebGL with its own robust scripting language to produce spatially immersive experiences.

title: NVIDIA's metaverse plans
url: https://venturebeat.com/2021/04/12/nvidia-reveals-omniverse-enterprise-for-simulating-products-and-worlds/

title: Hands go live
url: https://twitter.com/rcabanier/status/1383216671725264900

title: Packaging Three.js projects as eco-NFTs
url: https://mobile.twitter.com/marioecg/status/1384195565857107971


Fix #575: Replaced deprecated utils.Unmarshal and removed unused variables

Description
This PR fixes #575 by replacing deprecated utils.Unmarshal with json.Unmarshal and removing unused variables from the codebase.
Notes for Reviewers

The changes involve updates to two specific files: config/provider/inmem.go and utils/kubernetes/crd.go.
Please verify that the replacement of utils.Unmarshal does not impact any other parts of the code that may rely on its specific behavior.

Signed commits

[x] Yes, I signed my commits.

Thank you, @ShivanshuGupta07!

@ShivanshuGupta07 merge conflicts

@MUzairS15, so no changes are request now?


FAQ: Fix headline

There must be no line break within the headline.

Hi Stephen, can you provide a Signed-off-by?  The syntax and meaning are described in CONTRIBUTING.md.

Hi @blp,
sorry for not reading. I've updated my branch by forced push.
Steffen

Thanks! I applied this to master.


Support listing and launching emulators through flutter tools

To support https://github.com/Dart-Code/Dart-Code/issues/490 I'm going to look at adding support for listing/launching emulators (and eventually creation).
@devoncarew Do we want this in the cli as well as daemon (eg. something like flutter emulator list, flutter emulator launch xxx)?

+1 for adding this to the flutter tool

maybe integrate into the existing flutter devices command?

This was completed a while ago (https://github.com/flutter/flutter/pull/17466).


Provide ability to set GitHub URL

The URL defaults to github.com in octokit/auth-app.js, which makes it impossible for this action to work with a GHE installation.

https://github.com/tibdex/github-app-token/pull/24


Ng model options extend

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
feat
What is the current behavior? (You can also link to an open issue here)
ngModelOptions cannot be inherited from ancestor ngModelOptions
What is the new behavior (if this is a feature change)?
ngModelOptions can inherit if specified via $inherit values
Does this PR introduce a breaking change?
A small internal-ish change to the programmatic API for reading options.
Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

Other information:

OK, trying again. See if you can find another failing scenario @gkalpak


Delete date_created on delete

Critical Changes
None
Changes
Deletes the "date created" field when deleting a scratch org. This makes the "days" column in cci org list display properly after deletion.
Issues Closed
None

Thanks for the fix, @21aslade! I'm going to close this pull request and open a new one from a branch within our github org so that the CI system will run the builds.


Create index.html

It seems there are no changes in this PR. So?

+0 −0

This is similar to a SPAM PR.


also babelify and move style.js to dist

error in building with version 0.5.0 since there is no style.js in dist

thanks :+1:


Settings menu opens in fixed position and cannot be moved

The settings menu is a modal dialog that blocks the main UI. However, the window cannot be moved.
On a multi-monitor Windows 10 setup the settings menu always opens on the primary monitor (and cannot be moved).
This issue is resolved if the settings menu can be moved.

Can confirm still valid, just happened for me 👍


Apparmor profiles from torbrowser-launcher 0.2.6-2 on debian jessie is broken.

Hello.
I use Debian Jessie 8.6 with installed torbrowser-launcher 0.2.6-2 from jessie-backports repository. Rules from apparmor files torbrowser.Browser.firefox and torbrowser.Tor.tor break Tor Browser 6.0.5 start.

Hi, we are aware of this. There is a pull request which fixes this issue: https://github.com/micahflee/torbrowser-launcher/pull/243 You might also edit the apparmor profiles yourself in the meantime,


Sync release

Purpose

Sync release

Codecov Report

Merging #19565 into master will increase coverage by 0.61%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #19565      +/-   ##
==========================================
+ Coverage    19.9%   20.51%   +0.61%
==========================================
  Files          55       52       -3
  Lines        1437     1394      -43
  Branches      218      216       -2
==========================================
  Hits          286      286
+ Misses       1138     1095      -43
  Partials       13       13

Impacted Files
Coverage Δ

tool-plugins/vscode/src/extension.ts
0% <0%> (ø)
:arrow_up:

...ool-plugins/vscode/src/debugger/config-provider.ts
0% <0%> (ø)
:arrow_up:

...ugins/vscode/src/syntax-highlighter/highlighter.ts

...ool-plugins/vscode/src/syntax-highlighter/index.ts

...plugins/vscode/src/syntax-highlighter/activator.ts

...lugins/vscode/src/core/extended-language-client.ts
24% <0%> (+1.77%)
:arrow_up:

Continue to review full report at Codecov.

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


update rainbow kit package to latest version

https://www.rainbowkit.com/docs/migration-guide

work has already been started a few weeks ago: https://github.com/bosonprotocol/interface/tree/upgrade-rainbowkit

we remove rainbow kit from the interface


feat: Improve docs around private reactor formulas

Description

Adds a bit more content around private reactor formulas

Testing required outside of automated testing?

[x] Not Applicable

Screenshots (if appropriate):

Rollback / Rollforward Procedure

[x] Roll Forward
[ ] Roll Back

Reviewer Checklist

[ ] Description of Change
[ ] Description of outside testing if applicable.
[ ] Description of Roll Forward / Backward Procedure
[ ] Documentation updated for Change

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


Remove document event listeners before setting readyState to complete

Hi.
Test scenario:

load page with <script>document.addEventListener("DOMContentLoaded", function() {})</script>
close window.

Problem: On window close, document implementation fires DOMContentLoaded event, which in turn executes function added within addEventListener.
Proposed solution: clear document eventListeners before setting it to readyState.
Tests added to test/window/script.js. If pull request is accepted and there is a requirement to write tests in Mocha please tell me in which file it should be rewritten.
Best regards,
Wojciech Nowak

Hmm. window.close() already handles this use case. But document.close() should not blow away event listeners (see spec).
This seems wrong to me.

Event listeners added to a window are in fact cleared and the problem doesn't exist. However we can see a comment in close function in document-impl.js:
// Set the readyState to 'complete' once all resources are loaded.
// As a side-effect the document's load-event will be dispatched.
...
ev.initEvent("DOMContentLoaded", false, false);
this.dispatchEvent(ev);
Is emmiting this event defined by spec or is it some kind of jsdom hack? Maybe we should consider removing only DOMContentLoaded from eventListeners?

document.close() should definitely never remove any event listeners. If you are trying to close the window and stop event listeners, use window.close(), not document.close().
It sounds like it might be a separate issue where document.close() should not be what fires the DOMContentLoaded event. Instead, the parser probably should.

I call window.close which in turn calls document.close which causes DOMContentLoaded to be fired. If proposed solution to this problem is incorrect what should be done next? Shall I create an issue to track this bug?

Yes. window.close() needs to clear the event handlers; if it is not doing so then something is wrong. But document.close() should not clear event handlers.

I checked window.close() function and I think I found the bug. I have provided a new solution. What do you think about it?

Oh, wow, excellent find, thank you! Yes, I'll include this in the next release (probably this weekend).

Great, I'm glad I could help.

Merged as 868560b63ab6544ab5b10913c640fcca0e814a60; thanks!


Set user tags on s3 bucket

Set installConfig.Platform.AWS.UserTags as tags on the created S3 bucket

/assign @legionus @dmage

@coreydaley please split this into two PRs, one for the usertags and the other for the managedstorage status field.

Will split it up in the next push

@coreydaley please split this into two PRs, one for the usertags and the other for the managedstorage status field.
Will split it up in the next push

separate commits!=separate PRs.  I was trying to help you expedite the merge since i expect the usertags PR to be less controversial than whatever discussion needs to happen around how we want to represent the ManagedStorage status.
anyway add the nil checking that @wking suggested and i think this is lgtm, but i guess we'll see if @legionus or @dmage have any concerns on the ManagedStorage status field.

@bparees I split this into two PRs now.  ptal

/lgtm
thanks @coreydaley


Operating on >4 numbers for a single output

I've been able to pass multiple numbers into a shader, and I can see how to do this with up to 4. However, I need to do an arbitrarily large number (30 today). Is there a way to do this with turbo?

Yes. This is going to be supported in the next version (i.e. 1.1.X). But support for low-precision platforms (like iOS) has priority.
You can keep an eye on the dev branch for changes.


MAINT: stats: fix skew/kurtosis empty 1d input

Reference issue
gh-15905
What does this implement/fix?

C:\Users\matth\Desktop\scipy\scipy\stats\_stats_py.py:1336: RuntimeWarning: Mean of empty slice.
  np.place(vals, can_correct, nval)
Traceback (most recent call last):

  File "C:\Users\matth\AppData\Local\Temp\ipykernel_2528\930322391.py", line 1, in <module>
    stats.skew([])

  File "C:\Users\matth\Desktop\scipy\scipy\stats\_axis_nan_policy.py", line 491, in axis_nan_policy_wrapper
    res = hypotest_fun_out(*samples, **kwds)

  File "C:\Users\matth\Desktop\scipy\scipy\stats\_stats_py.py", line 1337, in skew
    vals = np.where(zero, np.nan, m3 / m2**1.5)

  File "C:\Users\matth\Desktop\scipy\scipy\stats\_stats_py.py", line 1214, in _moment
    rel_diff = np.max(np.abs(a_zero_mean), axis=axis,

  File "<__array_function__ internals>", line 5, in amax

  File "C:\Users\matth\Miniconda3\envs\scipydev\lib\site-packages\numpy\core\fromnumeric.py", line 2754, in amax
    return _wrapreduction(a, np.maximum, 'max', axis, None, out,

  File "C:\Users\matth\Miniconda3\envs\scipydev\lib\site-packages\numpy\core\fromnumeric.py", line 86, in _wrapreduction
    return ufunc.reduce(obj, axis, dtype, out, **passkwargs)

ValueError: zero-size array to reduction operation maximum which has no identity

Instead, skew and kurtosis should behave exactly like np.mean when the input is empty. This PR makes that happen.
Additional information
Without this PR, this would be a regression in 1.9.0 caused by gh-15905, hence the backport candidate label @tylerjereddy. I understand if it's too late, though.

Thanks @mdhaber @tupui!