Feature Request: option to show and/or output all entries at once

Can we get an option to output all entries or all unread entries instead of just being able to show and output a specific entry by providing its entry id?  This would make it possible to script automated output of unread entries for syncing with various devices.

I thought about this and decided that it would be too much unnecessary work. Because you already can script this behavior with something like this:
for entry in $(wallabag list -n | grep -e '^[0-9]\+' | cut -f 1 -d' ' ); do wallabag show $entry; done

That sounds reasonable and thanks for the example script. I tried it though and it's not catching all of my unread entries. It only shows a couple of them when there are more that are unread and shown when I just do "wallabag list".

I think you need to modify wallabag execution by adding -q parameter and give it big enough number.

Have you succeed with it? Can we close issue?

Yes, it looks like it is working now with this command. Thank you so much!
for entry in $(wallabag list -n -q 20 | grep -e '^[0-9]\+' | cut -f 1 -d' ' ); do wallabag export $entry


Lifetime module branch

Tackling issue #6 : This update facilitates phasor coordinate calculations for frequency-domain signals, conversion to phase, and effective single lifetime and mixture management. I am considering  introducing spatial filtering and a couple of extra features but that also depends on the overall project structure you have in mind.Future enhancements, are open for community contributions, as I'm not well-versed in FRET or time-domain conversion.

Hi @Mariochem92
thanks for contributing to this project.
Since this is the first contributor pull request, it may be a good time to review the contributor guide and get feedback on how to improve it. Should we create a PR template repeating the requirements regarding code and documentation style requirements?
There is certainly a large overlap with the code I started porting from the vLFD lifetime calculator mentioned in issue #6. That issue also included a FRET calculator, time-domain functions, and generating simple synthetic signals.
I am not sure how "n-dimensional aware" the code is. For example, ideally the functions would accept a scalar or sequence of laser frequencies but that may make the implementation too complex. Expressions like mod = (g**2 + s**2) ** 0.5 are memory intensive for images and could instead use numpy ufuncs if available, numpy.hypot in this case. Other cases like numpy.sqrt((1 - (g**2 + s**2)) / (omega**2 * (g**2 + s**2))) could be candidates for Cython implementations or refactored using inline expressions and replacing g**2 with g*g for example. Tests covering all cases are needed.
Since the phasorpy.io file readers are returning xarray.DataArray instances, it would be nice to get the metadata like laser frequency from the array object if possible. But that may be added in another PR.
I am not going to be able to do a full in-detail review for a while. @bruno-pannunzio and @schutyb

Hey Christoph thank you very much for clarification!
In #6 the code is mentioned but i am redirect to an image, do you have a valid link for the analysis script?
I updated the code so that it can pass the tests, but I will go through the very interesting points you raised in the next few days. I didn't get the n-dimensionality right before, thank you for explaining this through an example.
As for the contribution guide I think it's pretty well documented, it's my bad as I am not too acquainted with GitHub as of yet.
Also I was considering including spatial filters but I am not sure how those should be implemented, would it be fine to import scipy?

hey all! it looks like there are problems with imports from zenodo, but I haven't touched that part of the code. Not sure what's the problem there.

there are problems with imports from zenodo, but I haven't touched that part of the code. Not sure what's the problem there.

That sometimes happens with cloud services, We might have to look for alternatives if Zenodo turns out to be too slow or unreliable for running the tests.

Hi @Mariochem92.
@bruno-pannunzio, who is working on the FLIM part of this library, is defending his thesis these days. The Uruguayan team is also occupied with the 5th Workshop in Advanced Microscopy and Biophotonics on November 19-24. So, please allow some more weeks for the review of this PR. Bruno and I have existing code that overlaps with this PR and we want to make sure all comes together nicely.
To improve this PR, please add comprehensive unit tests to the tests directory and add the new module to the API documentation.

No problem, best of luck to @bruno!

Hi @Mariochem92, sorry it took us so long to come back to you. We were discussing terminology, standardizing names and function signatures, so that we can all have some cohesion in the code we are developing. As you may see in the PR #28 , we have been discussing how to implement the manipulation of FLIM data, and more broadly, the phasor data. In the comments you can follow what we have agreed on and in the names and terminology we are going to be using, mainly:

signal: Time-domain, frequency-domain, or spectral data
decay, histogram: time-domain signal
wave: Frequency-domain signal
spectrum: Spectral signal
average (fdc): Average signal
background (fbg): Background signal
phasor: Phasor coordinates
real (re): Real component of phasor coordinates
imag (im): Imaginary component of phasor coordinates
polar: Polar coordinates
phase (phi): Angular component of polar coordinates in radians
modulation (mod): Radial component of polar coordinates
lifetime (tau): Fluorescence lifetime components
fraction (frac): Fractional intensity of lifetime component
amplitude (amp): Preexponential amplitude of lifetime component
apparent_lifetime Apparent single lifetime from phase or modulation
phase_lifetime (tauphi) Apparent single lifetime from phase
modulation_lifetime (taumod) Apparent single lifetime from modulation
reference: Signal, coordinates, lifetimes, etc used for calibration
real0 (re0): Real component of phasor coordinates for calibration
imag0 (im0): Imaginary component of phasor coordinates for calibration
phase0 (phi0): Angular component of polar coordinates for calibration
modulation0 (mod0): Radial component of polar coordinates for calibration
frequency: Laser or modulation frequency
omega or ohm: Radial frequency
omega_tau: Radial frequency multiplied with lifetime

Considering the code you proposed in your PR, I believe that there are some functions that can be partly covered by your code:
def phasor_to_polar(
    real: ArrayLike,
    imag: ArrayLike,
    /,
) -> tuple[NDArray[Any], NDArray[Any]]:
    """Return polar coordinates from phasor coordinates."""
    ...
    return phase, modulation

def phasor_from_polar(
    phase: ArrayLike,
    modulation: ArrayLike,
    /,
) -> tuple[NDArray[Any], NDArray[Any]]:
    """Return phasor coordinates from polar coordinates."""
    ...
    return real, imag

def phasor_from_lifetime(
    frequency: ArrayLike,
    lifetime: ArrayLike,
    /,
    fraction_or_amplitude: ArrayLike = 1.0,
    *,
    is_amplitude: bool = False,
) -> tuple[NDArray[Any], NDArray[Any]]:
    """Return phasor coordinates from lifetime distribution."""
    ...
    return real, imag

def phasor_from_apparent_lifetimes(
    phase_lifetime: ArrayLike,
    modulation_lifetime: ArrayLike,
    /,
    frequency: ArrayLike,
    *,
    frequency_axis: int | None = None,
) -> tuple[NDArray[Any], NDArray[Any]]:
    """Return phasor coordinates from apparent single lifetimes."""
    ...
    return real, imag

def phasor_to_apparent_lifetimes(
    real: ArrayLike,
    imag: ArrayLike,
    /,
    frequency: ArrayLike,
    *,
    frequency_axis: int | None = None,
) -> tuple[NDArray[Any], NDArray[Any]]:
    """Return apparent single lifetimes from phasor coordinates."""
    ...
    return tauphi, taumod

I think that this functions are partly covered by your implementation but needs thorough refactoring in order to meet the needs for this functions. Also you need to provide tests to cover all cases and documentation for all functions. You can read more in the contributor guide about tests and documentation required.
Please let us know what you think about our proposed standarized names and if you have any questions regarding this PR.

Hi @Mariochem92, the PR #28 has been merged to main and the following functions listed before were already implemented:

phasor_to_polar
phasor_from_lifetime

The rest of the listed functions before are not implemented yet and can benefit from the code you already implemented that can be improved to meet the requirements of the library.
Please let us know if you have any question regarding this PR.

Hi @Mariochem92,
I think the following functionality from this PR has been implemented:

phasor_coordinates -> phasor_from_polar
phasemodule_values -> phasor_to_polar
lifetime_computation_phasor, lifetime_computation_array -> phasor_to_apparent_lifetime
refplot -> phasor_from_lifetime

fractional_intensities: not implemented yet.
phasor_lifetime: what is the advantage of this function over calling numpy.mean and numpy.std on phasor coordinates or apparent single lifetimes as needed?
apparent_lifetime: could you explain why this function returns the apparent single lifetimes from phase and modulation? As far as I understood, the phasor coordinates of the second, unknown, single component lifetime are on the universal circle, which means the apparent single lifetimes from phase and modulation should be identical. Yet, in your example, the values are slightly different. I am thinking to break this functionality down in phasor_from_lifetime, phasor_to_apparent_lifetime (both implemented), and semicircle_line_intersection (a specialized version of circle_line_intersection)

Hi @cgohlke ,
thank you for the extensive update. Maybe I got wrong what is meant by apparent single lifetime in this very context. I document the rationale behind my approach here. Feel free to break functionalities:)


Version 1.14.1 causes Polymer to not load in Firefox 43.0.3

We get the following errors when rendering our app in Firefox after upgrading to 1.14.1. Rolling back to 1.14.0 fixes the issue. This problem does not affect Chrome.
TypeError: document.registerElement is not a function
 localhost:8080:775:1
TypeError: Polymer.Base._getExtendedPrototype is not a function
 localhost:8080:538:8
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: Polymer.Base._getExtendedPrototype is not a function
 localhost:8080:538:8
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: Polymer.Base._getExtendedPrototype is not a function
 localhost:8080:538:8
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: this._desugarBehaviors is not a function
 localhost:8080:648:1
TypeError: views.select is not a function

Please try with v1.14.2 or later, this is probably related to #297

Getting the same error with v1.14.5

@StephenTurley Is there any way you could provide an example of your project?
@azakus and I tracked down a very similar issue that was caused by some dependencies not being listed in HTML imports. Earlier versions of vulcanize would occasionally mask a missing HTML import as long as the dependency existed somewhere else in the project.

Its a private repo and I couldn't share it, but I'll check through the imports and see if anything is coming in transitively. If that doesn't work, I'll try to reproduce it in a public repo.

Also, should probably say that I'm working on the same project with @JamesFigler

@StephenTurley I don't know how to take this further without a reproduction, unfortunately.

Ahh sorry, We have just kept the old version of Vulcanize and it has worked well. We are starting another app that will have a separate pipeline. I will use the newest version of vulcanize there and see if the problem pops back up.

I've upgraded to 1.14.8 and everything is working. I think you can close this. Tested on Firefox 43.0.4


feat: pull missing params from ParameterStore

Description of changes
Merging into feature branch parameter-store-integration
During environment initialization, download missing parameters ParameterStore if they exist.

Issue #, if available

Description of how you validated changes
yarn test, manual validation
Checklist

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

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

Codecov Report

:exclamation: No coverage uploaded for pull request base (parameter-store-integration@35ee5c9). Click here to learn what that means.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@                      Coverage Diff                       @@
##             parameter-store-integration   #11928   +/-   ##
==============================================================
  Coverage                               ?   50.30%
==============================================================
  Files                                  ?      712
  Lines                                  ?    34509
  Branches                               ?     7087
==============================================================
  Hits                                   ?    17361
  Misses                                 ?    15643
  Partials                               ?     1505

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Directory Items Preview Tooltip

i have to deal with a large number of pictures in many folders.
i hope there is a function can set the first picture of the folder as the folder icon

@violenceandroid I can probably add a Tooltip that displays the first few items in a directory. The folder icon would require a lot more work.

Starting with #4744, Files will use the system thumbnails making this no longer relevent.


@opentelemetry/instrumentation-fs` fails to wrap fs promises

What version of OpenTelemetry are you using?
What version of Node are you using?
18.12.1
What did you do?
I installed Opentelemetry and use the auto-instrumentation meta package via node-sdk to instrument my node backend application but when starting up the application thrown a runtime error
What did you expect to see?
Successfully running my backend application without throwing errors
What did you see instead?
/Users/xxxx/node_modules/@opentelemetry/instrumentation-fs/build/src/instrumentation.js:53
                        if (instrumentation_1.isWrapped(fs.promises[fName])) {
                                                                   ^

TypeError: Cannot read properties of undefined (reading 'access')
    at InstrumentationNodeModuleDefinition.patch (/Users/xxxx/node_modules/@opentelemetry/instrumentation-fs/build/src/instrumentation.js:53:68)

Looks like the fs.promises is undefined in my case which causes the wrapping step to fail. I am not sure why fs.promises is undefined. Maybe the supportsPromises needs to be adapted so it also checks whether fs.promises is defined?
E.g.
const supportsPromises = parseInt(process.versions.node.split('.')[0], 10) > 8 && fs.promises
I can't really think of a reason why fs.promises could be undefined. Could a library maybe override it? If so, what would be a good way to detect that in Node?
Additional context
I am running Express

Which ohter modules have you loaded in your app? In special that ones loaded before the instrumentation would be insteresting.
Or can you even share a stripped down reproducer?

I'm experiencing what appears to be the same error in a NestJS environment. Likewise, I'm trying to use auto-instrumentations in node:
/app/node_modules/@opentelemetry/instrumentation-fs/build/src/instrumentation.js:53
                        if (instrumentation_1.isWrapped(fs.promises[fName])) {
                                                                   ^

TypeError: Cannot read properties of undefined (reading 'access')
    at InstrumentationNodeModuleDefinition.patch (/app/node_modules/@opentelemetry/instrumentation-fs/build/src/instrumentation.js:53:68)
    at FsInstrumentation._onRequire (/app/node_modules/@opentelemetry/instrumentation/build/src/platform/node/instrumentation.js:79:35)
    at /app/node_modules/@opentelemetry/instrumentation/build/src/platform/node/instrumentation.js:133:29
    at /app/node_modules/@opentelemetry/instrumentation/build/src/platform/node/RequireInTheMiddleSingleton.js:54:27
    at Module.Hook._require.Module.require (/app/node_modules/require-in-the-middle/index.js:175:32)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/app/node_modules/rotating-file-stream/dist/cjs/index.js:8:20)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
error Command failed with exit code 1.

For context, the codebase I'm attempting to add instrumentation to is now one I'm very familiar with. I had previously successfully attempted this same thing in another nestjs codebase (of similar size and complexity and with code in common) recently and did not experience this issue.
I attempted to reproduce the issue in a new nest app but have been unsuccessful as of yet.

using node 18.12.0 i see the issue with @opentelemetry/auto-instrumentations-node@npm:^0.35.0 but reverting to @opentelemetry/auto-instrumentations-node@npm:^0.34.0 fixes it

Nice one @modosc - that resolved it for me as well!

Created https://github.com/open-telemetry/opentelemetry-js/issues/3448 which includes a simple reproducer and some hints where the problem is located.
replacing any occurrence of require("fs/promises") is a workaround but most likely hard to do as this is spread across a lot npm modules.

This is still broken in<EMAIL_ADDRESS>Downgrading to v0.34.0 seems to do the trick. Also seeing lots of these in the logs, which I assume are somewhat related:
no original function cpSync to wrap
no original function cp to wrap
no original function cp to wrap

I reproduced the issue in this repository
I hope it will help as https://github.com/open-telemetry/opentelemetry-js/pull/3451 still didn't solve the problem

This should have been resolved by https://github.com/open-telemetry/opentelemetry-js/pull/3451. If you upgrade to<EMAIL_ADDRESS>or higher, you will no longer see the error.
Proper instrumentation of fs/promises will be addressed by https://github.com/open-telemetry/opentelemetry-js-contrib/pull/1375.

<EMAIL_ADDRESS>is working in my case
Thanks


Issue using lodash's "_.partial" on function generated with ".promisifyAll()"

I'm getting a strange error when applying a partial on a promise. Not sure why this is happening. The tests here prove that it only occurs on a promise generated using bluebird's ".promisifyAll()" function.
I created an issue in lodash and I'm thinking I should create one here as well.
https://github.com/lodash/lodash/issues/1369
Here's the stack trace for the issue.
TypeError: Cannot read property 'apply' of undefined
    at tryCatcher (/Users/thomas/Desktop/project/node_modules/bluebird/js/main/util.js:26:22)
    at ret (eval at <anonymous> (/Users/thomas/Desktop/project/node_modules/bluebird/js/main/promisify.js:163:12), <anonymous>:11:39)
    at wrapper (/Users/thomas/Desktop/project/node_modules/lodash/index.js:3592:19)
    at Context.<anonymous> (/Users/thomas/Desktop/project/test/lodash-fsextra-partial.js:113:14)
    at callFn (/Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runnable.js:266:21)
    at Test.Runnable.run (/Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runnable.js:259:7)
    at Runner.runTest (/Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runner.js:390:10)
    at /Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runner.js:473:12
    at next (/Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runner.js:315:14)
    at /Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runner.js:325:7
    at next (/Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runner.js:260:23)
    at Immediate._onImmediate (/Users/thomas/.nvm/versions/io.js/v2.2.1/lib/node_modules/mocha/lib/runner.js:292:5)
    at processImmediate [as _immediateCallback] (timers.js:371:17)

Here's the code to produce the error:
var Promise = require("bluebird")
var _ = require("lodash")

var lib = {}

lib.dummy = function(path, encoding, cb){
  return cb(null, "file content here")
}

Promise.promisifyAll(lib)

var readFile = _.partial(lib.dummyAsync, "path/hello.txt", "utf8")

readFile() // throws error

You're using lodash incorrectly. You're looking for .bind and not _.partial.
Here is a fixed example: http://jsfiddle.net/z1hgo3g5/
Please in the future ask support questions in the appropriate channels.

Thanks @benjamingr

Any time :)


Create a template to deploy/run code for 3rd party developers

The stimela interface is mentioned as an issue example for a system to adapt it with more algorithms. see.: https://github.com/ratt-ru/Stimela

[ ] Define an interface
[ ] Make sure the interface can be used for imaging for emma's team

Not actionable. Feel free to reopen.


custom metrics_path

custom metrics_path can be used as a weak auth method and other purpose
prometheus support
# The HTTP resource path on which to fetch metrics from targets.
[ metrics_path: [<path>](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#path) | default = /metrics ]

some other exporter supports metrics_path
https://github.com/prometheus/exporter-toolkit/pull/147
https://github.com/DLR-SC/repository-synergy/blob/115e48c37e659b144b2c3b89695483fd1d6dc788/data/readme_files/prometheus.snmp_exporter.md?plain=1#L50
https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/d865b6e7c113dcad1cbb3259eb7cb08855a48fb7/receiver/simpleprometheusreceiver/examples/federation/otel-collector-config.yml#L8
https://github.com/albertodonato/prometheus-aioexporter/blob/main/README.rst#exporter-command-line

custom metrics_path can be used as a weak auth method and other purpose
prometheus support
# The HTTP resource path on which to fetch metrics from targets.
[ metrics_path: [<path>](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#path) | default = /metrics ]

some other exporter supports metrics_path prometheus/exporter-toolkit#147 https://github.com/DLR-SC/repository-synergy/blob/115e48c37e659b144b2c3b89695483fd1d6dc788/data/readme_files/prometheus.snmp_exporter.md?plain=1#L50 https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/d865b6e7c113dcad1cbb3259eb7cb08855a48fb7/receiver/simpleprometheusreceiver/examples/federation/otel-collector-config.yml#L8 https://github.com/albertodonato/prometheus-aioexporter/blob/main/README.rst#exporter-command-line

https://github.com/syepes/network_exporter/pull/59

https://github.com/syepes/network_exporter/pull/59


option to omit the C wrapper

RE e315799
You've noted in your video that you couldn't figure out how to omit the C wrapper.
Doesn't the following work?
77 SDL-RWops-Pointer  usage pointer.

           call 'SDL_RWFromConstMem' using
               by reference ground-asset-data
               by value ground-asset-data-size
               returning SDL-RWops-Pointer
           end-call
           call 'IMG_LoadTexture_RW' using
               by value renderer SDL-RWops-Pointer 1
               returning ground-texture
           end-call

Note: obviously it is quite longer so a wrapper makes sense in any case - the nearest you'd get to that in COBOL would be writing a user-defined-function; the result would be a wrapper invoked as:
           move function loadTextureData (ground-asset-data, renderer)
               to ground-texture

To pass variable lengths you'd use 77 texture-data pic x any length. for the data on the function's LINKAGE, then pass  by value function length (texture-data) in the CALL.

Thanks for the info! I'll try to look into it soon.


Handle relative paths in kubeconfig

Addresses: https://github.com/kelproject/pykube/issues/130 from the original project.
Per k8s documentation (https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/#file-references), if a relative path is specified in kube config, it should be resolved relative to the kubeconfig file, not (as is currently implemented) from the cwd.
Before:
luke@Lukes-MacBook-Air pykube % git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
luke@Lukes-MacBook-Air pykube % python3 -c 'import pykube; pykube.HTTPClient(pykube.KubeConfig.from_file("~/.kube/config"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/luke/work/pykube/pykube/http.py", line 204, in __init__
    self.url = self.config.cluster["server"]
  File "/Users/luke/work/pykube/pykube/config.py", line 188, in cluster
    return self.clusters[self.contexts[self.current_context]["cluster"]]
  File "/Users/luke/work/pykube/pykube/config.py", line 151, in clusters
    BytesOrFile.maybe_set(c, "certificate-authority")
  File "/Users/luke/work/pykube/pykube/config.py", line 239, in maybe_set
    d[file_key] = cls(filename=d[file_key])
  File "/Users/luke/work/pykube/pykube/config.py", line 256, in __init__
    "'{}' file does not exist".format(filename)
pykube.exceptions.PyKubeError: 'certs/ndmad1-ca.pem' file does not exist
luke@Lukes-MacBook-Air pykube % python3 -c 'import pykube,os; os.chdir("/Users/luke/.kube"); pykube.HTTPClient(pykube.KubeConfig.from_file("~/.kube/config"))'
luke@Lukes-MacBook-Air pykube %

After
luke@Lukes-MacBook-Air pykube % git checkout handle_relative_paths_in_kubeconfig
Switched to branch 'handle_relative_paths_in_kubeconfig'
luke@Lukes-MacBook-Air pykube % python3 -c 'import pykube; pykube.HTTPClient(pykube.KubeConfig.from_file("~/.kube/config"))'
luke@Lukes-MacBook-Air pykube % python3 -c 'import pykube,os; os.chdir("/Users/luke/.kube"); pykube.HTTPClient(pykube.KubeConfig.from_file("~/.kube/config"))'
luke@Lukes-MacBook-Air pykube %

Note that if PykubeConfig is created via a serviceaccount, there is no change to behavior (since there is no kubeconfig file to find)
luke@Lukes-MacBook-Air pykube % kubectl -n sandbox run --generator=run-pod/v1 --limits=cpu=200m,memory=512Mi -it hello-world-$USER --image techops-docker.maven.dev.tripadvisor.com/utils/pykube-upstream-tester:0.1 -- /bin/sh
If you don't see a command prompt, try pressing enter.
/ # python3 -c 'import pykube; pykube.HTTPClient(pykube.KubeConfig.from_service_account())'
/ #

Fixed linting and re-pushed

Thanks for the PR! We could change it to use pathlib.Path (Python 3+) instead of "old style" os.path.

We could change it to use pathlib.Path (Python 3+) instead of "old style" os.path.

Sure, looking now

It looks like there are a number of reference to os.path in config.py; do you want me to

Change only the references that os.path that I introduced
Change all references to os.path in this PR
Leave it as is and follow up this PR with one that converts to pathlib

I'm fine doing any of those, I just know some people like to keep PRs single-purpose while others are OK w this sort of refactoring coming along for the ride.

Looking into this a bit more, I think 3 is the way to go, since you'll probably want to change filename to filepath throughout the whole object for consistency, right? I started to work on this here, is this what you're looking for? https://github.com/lukemassa/pykube/commit/0395eb13f5e30e72fc4958803acbbc7dfa90e296

@hjacobs let me know which way you want to go with this, like I said I'm fine with any of the approaches


[BEAM-11289] [Python] Integrate Google Cloud Recommendations AI functionality

Integrate Google Cloud Recommendations AI functionality

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

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[x] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[x] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

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

Thanks a lot @pabloem - I'll address those and push again.
Quick question regarding the failing imports - do you have any pointers why the package doesn't get picked up?

can you rebase this PR? It has some failures from dataframes project, but the rest of the PR does not have any other failures : )

there's the Docs failures, but those are tricky and we can address them little by little

@pabloem addressed the comments we discussed :)

Run Python PreCommit

Run Python 3.8 PostCommit

can you rebase to fix lint errors?

Run Python 3.8 PostCommit

Is it possible this broke PythonLint precommit? It's been failing since this went in. Weirdly it's causing mypy to complain about BigQuery:
10:49:13 apache_beam/testing/load_tests/load_test_metrics_utils.py:51: error: Module 'google.cloud' has no attribute 'bigquery'  [attr-defined]
10:49:18 Found 1 error in 1 file (checked 784 source files)
10:49:20 error: mypy exited with status 1

Perhaps due to the new dependency?


[WFCORE-5254] Fix domain-management module OSHs that are populating t…

…he runtime with data from the operation instead of the Resource tree
https://issues.redhat.com/browse/WFCORE-5254

StaticDiscoveryAddHandler and DiscoveryOptionAddHandler seem don't fit in this category. They work upon placeholder resources, which doesn't have a model associated.

@yersan I think your instinct to file a JIRA about those handlers is a good one; at least a minor priority task to look into them. That code is pretty unusual and it's good to make it clean to avoid future bugs introduced by maintainers. At worst the task might result in adding some comments to explain why the code does what it does.
This kind of thing is generally a minor thing; it only matters in edge cases involving composite ops where more than one step alters the relevant part of the model. Then the 'operation' object would not be showing the true configuration.

StaticDiscoveryAddHandler and DiscoveryOptionAddHandler details will be tracked on https://issues.redhat.com/browse/WFCORE-5281

@bstansberry thanks


added default withContext() impl on MtAmazonDynamoDbContextProvider

Pull Request Test Coverage Report for Build 194

0 of 5 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.3%) to 85.919%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/com/salesforce/dynamodbv2/mt/context/MtAmazonDynamoDbContextProvider.java
0
5
0.0%

Totals

Change from base Build 191:
-0.3%

Covered Lines:
1379

Relevant Lines:
1605

💛  - Coveralls

Jeremy's taking care of this in his PR.


remaining work to improve structured load

Outstanding issues left over from #2241 ...

[x] support pseudo-levels somehow
[ ] check that some 'other' header words are static as expected

i.e. same within all fields of one phenomenon
e.g. LBCODE, LBVC, LBFC

[ ] >2d orographies coming out of PP files (time-dependent)
[ ] failure to merge scalar coord from one file with vector from another
[ ] publish performance evaluation data on any of these changes+enhancements

(Don't necessarily need to fix all of these at one time, or for 1.12)
NOTE #2278 now contains the improvements we do want in 1.12 release

Additional ideas, not yet accepted as required ...

[ ] Add to documentation : a link into the test code like this,  providing an example of how to modify a load callback for use with structured loading
[ ] add additional results processing to correct differences between 'fast' and 'normal' loading.  There are basically three key areas of difference we "might" tackle ...

dimension ordering
ordering (direction) of coords (notably, pressure)
which are Dim and which Aux coords (notably, time and vertical)

additional results processing to correct differences between 'fast' and 'normal' loading

This was suggested in discussion with users, but I believe is not appropriate for 1.12 milestone.
So I'm deferring this : #2278 covers

support pseudo-levels somehow

#2274 provides a simple solution
This could still be improved on, but it is not clear whether that is necessary.  See ticket for account of possible shortcomings

Issues wanted for 1.12; moved into #2278 :

check that some 'other' header words are static as expected
2d orographies coming out of PP files (time-dependent)

Review as-of 2017-10-20
Various outstanding issues relating to structured loading ...

#2278 "Structured-load improvements for release 1.12 "
as noted above, still not all dealt with
#1953 "year zero in 360 day valid"
#1525 "Fast-FF loading handles realisation wrong"  (actually applies to pseudo-level too)


Please add this adapter to latest

Hi, can you please add your adapter to ioBroker? it would be very nice :-)
https://github.com/ioBroker/ioBroker.repositories

Preperation is done. After Test of v1.0.0, this version is added to stable


Easier navigation to "favorite" flows

It is common to want to save three or four flows for replays, such as JSON POST requests, for frequent use when using MITMProxy for web application debugging or analysis. The application, however, may be generating a lot of other traffic. This makes it difficult to find or navigate to the "favorite" flows.
Currently, the best solution is to write the desired flows to a file, clear the screen, and reload the flows. This can become quite cumbersome, and it is very inconvenient to add another saved flow to the file.
There are several possibilities. The easiest would be to allow vim-like navigation to a specific flow number by pressing a hotkey, then typing the flow number. A more complete option would be to allow flows to be marked as a "favorite" This would place a visual marker on the flow, and enable additional navigation options, such as "next favorite flow" and "previous favorite flow". Additionally, adding a "favorite flows" option to the "write flows to file" submenu would allow for an easy way to persist the "favorite" flows across clears, or the "Clear All Flows" command could default to not deleting favorite flows.
Overall, these features would vastly improve the experience of using MITMProxy for web application debugging, especially for debugging of applications which make frequent requests to REST endpoints.

This was actually rather easy to implement. I created functionality for toggling a mark on flows and persisting those flows across clears and submitted a pull request here: https://github.com/mitmproxy/mitmproxy/pull/624
If this is popular, I can work on extending this functionality a bit more, but what I have so far has been a lifesaver for the project I'm working on right now.

I've merged @drahosj's change that implements this. Thanks!


Argument for disabling the mailing service within the registration endpoint

example dev.thehub-aubg.com/api/hackathon/register?disable_mailer=true

deployed to master -> register?testing=true


CUDA-Team: improve user experience

Improve user experience
This issue tracks the epic-level work to improve the user experience of interacting with CUDA-related software in Nixpkgs.

[ ] https://github.com/NixOS/nixpkgs/issues/232422
[ ] https://github.com/NixOS/nixpkgs/issues/232426
[ ] https://github.com/NixOS/nixpkgs/issues/232427
[ ] https://github.com/NixOS/nixpkgs/issues/232428

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/cuda-team-roadmap-and-call-for-sponsors/29495/1

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/cuda-team-roadmap-update-2023-08-29/32379/1

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/community-calendar/18589/103


Change CI to test on python 3.9 only

Removes python 3.10 from python-version since some of our dependencies do not support python 3.10 at this time.

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@c7e5818). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #20   +/-   ##
=======================================
  Coverage        ?   35.10%
=======================================
  Files           ?       10
  Lines           ?      339
  Branches        ?        0
=======================================
  Hits            ?      119
  Misses          ?      220
  Partials        ?        0

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 c7e5818...644f182. Read the comment docs.


Use an enum for the internal state of AnyMessageStorage.

Reduces the risk of every getting into poorly defined state.

Trying to support having more than one of these set would gonna be tricky as each place we check the state, we'd have to get the orders "just right" from a preference pov, etc.  So just going to the true state seemed like a better approach to keep the code simple.


bug fix

Switched phase from radian to degrees and fixed update param.

Awesome!
Could this problem be avoided with using unit-bearing quantities here?


Unable to test with custom (own) dataset

Hello,
Thanks for the very much useful source. I have tested the source with a sample dataset. But unable to test with my own dataset.
Configured the topic name and frame_id as it in the sample dataset. But once running bag file getting continuous error as below. Could anyone please suggest fix this issue?
terminate called after throwing an instance of 'gtsam::IndeterminantLinearSystemException'
what():
Indeterminant linear system detected while working near variable
7061644215716937728 (Symbol: b0).

Working Platform:
Ubuntu 18.04
GTSAM: 4.0.2
Regards,
Ajay

Check this one out https://github.com/TixiaoShan/LIO-SAM/issues/165#issuecomment-1000247782


Should embed_tokens.weight and lm_head.weight be frozen in stage1 and stage 2

In stage1 and stage2 these two weights are trainable. And the layer name is "llama_model.model.embed_tokens.weight"  and  "llama_model.lm_head.weight"
But it seems that stage3 not load these two weights correctly, as the layer name are "llama_model.base_model.model.model.embed_tokens.weight" and "llama_model.base_model.model.lm_head.weight" in stage3

Thank you for your interest and for bringing up this issue. So this is indeed a bug, but fortunately has a minor influence. We actually updated the code three weeks ago and trained the system again into a new checkpoint.
You can use the new codes and download new checkpoints. Thanks!


Minimum multiplicity of lists to be corrected back to the initial values

Agment statement requested for minimum multiplicity of 0.
Now as When statement has been added, minimum multiplicity of 0 is accepted again.

Minimum multiplicities changed back to initial values.


Enable JUnit test configuration in Delta Lake

GitOrigin-RevId: c91b34b677f993ee257d99d7092b76820b233654
After this PR, Delta Lake will have the ability to run JUnit tests in SBT.
This PR passed tests by JavaDeltaTableSuite.java, DeleteJavaSuite.java and UpdateJavaSuite.java

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: marmbrus:white_check_mark: ZhitongDB:x: brkyvzYou have signed the CLA already but the status is still pending? Let us recheck it.

Great, finally tests passed. Will merge this soon.


ObserverSystem cannot be an ExclusiveSystem

Bevy version 0.14
A function that can be used with an Observer that takes an ExclusiveSystemParam will panic at runtime when invoked.
#[derive(Event)]
struct Foo;

fn main() {
    App::new()
        .add_plugins(MinimalPlugins.set(ScheduleRunnerPlugin::run_once()))
        .observe(|_: In<Trigger<Foo>>, _: &mut World| {
            println!("Hello, World!");
        })
        .add_systems(Update, |mut commands: Commands| {
            commands.trigger(Foo);
        })
        .run();
}

This will panic when using Commands::trigger or World::trigger even though in either case I would expect exclusive world access at the point of invocation. Looking slightly deeper, this is likely because Trigger holds a &'w E: Event rather than owning the event such that it is decoupled from the world.
The panic produces the error:

thread 'main' panicked at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/exclusive_function_system.rs:99:9:
Cannot run exclusive systems with a shared World reference

And its backtrace (RUST_BACKTRACE=1):
stack backtrace:
   0: rust_begin_unwind
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/panicking.rs:74:14
   2: <bevy_ecs::system::exclusive_function_system::ExclusiveFunctionSystem<Marker,F> as bevy_ecs::system::system::System>::run_unsafe
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/exclusive_function_system.rs:99:9
   3: bevy_ecs::observer::runner::observer_system_runner
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/observer/runner.rs:409:9
   4: bevy_ecs::observer::Observers::invoke::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/observer/mod.rs:192:13
   5: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/ops/function.rs:294:13
   6: core::iter::traits::iterator::Iterator::for_each::call::{{closure}}
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/iter/traits/iterator.rs:815:29
   7: <hashbrown::map::Iter<K,V> as core::iter::traits::iterator::Iterator>::fold::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.14.5/src/map.rs:4749:13
   8: hashbrown::raw::inner::RawIterRange<T>::fold_impl
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.14.5/src/raw/mod.rs:3880:23
   9: <hashbrown::raw::inner::RawIter<T> as core::iter::traits::iterator::Iterator>::fold
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.14.5/src/raw/mod.rs:4151:18
  10: <hashbrown::map::Iter<K,V> as core::iter::traits::iterator::Iterator>::fold
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.14.5/src/map.rs:4747:9
  11: core::iter::traits::iterator::Iterator::for_each
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/iter/traits/iterator.rs:818:9
  12: bevy_ecs::observer::Observers::invoke
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/observer/mod.rs:204:9
  13: bevy_ecs::world::deferred_world::DeferredWorld::trigger_observers_with_data
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/deferred_world.rs:368:9
  14: bevy_ecs::observer::trigger_event::trigger_event
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/observer/trigger_event.rs:61:13
  15: <bevy_ecs::observer::trigger_event::TriggerEvent<E,Targets> as bevy_ecs::world::Command>::apply
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/observer/trigger_event.rs:20:9
  16: bevy_ecs::world::command_queue::RawCommandQueue::push::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/command_queue.rs:182:25
  17: core::ops::function::FnOnce::call_once
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/ops/function.rs:250:5
  18: bevy_ecs::world::command_queue::RawCommandQueue::apply_or_drop_queued::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/command_queue.rs:272:26
  19: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/panic/unwind_safe.rs:272:9
  20: std::panicking::try::do_call
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/std/src/panicking.rs:557:40
  21: ___rust_try
  22: std::panicking::try
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/std/src/panicking.rs:521:19
  23: std::panic::catch_unwind
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/std/src/panic.rs:350:14
  24: bevy_ecs::world::command_queue::RawCommandQueue::apply_or_drop_queued
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/command_queue.rs:265:26
  25: bevy_ecs::world::command_queue::CommandQueue::apply
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/command_queue.rs:100:13
  26: <bevy_ecs::world::command_queue::CommandQueue as bevy_ecs::system::system_param::SystemBuffer>::apply
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/command_queue.rs:327:9
  27: <bevy_ecs::system::system_param::Deferred<T> as bevy_ecs::system::system_param::SystemParam>::apply
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/system_param.rs:1040:9
  28: <(P0,P1) as bevy_ecs::system::system_param::SystemParam>::apply
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/system_param.rs:1456:19
  29: bevy_ecs::system::commands::_::<impl bevy_ecs::system::system_param::SystemParam for bevy_ecs::system::commands::Commands>::apply
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/commands/mod.rs:115:13
  30: <(P0,) as bevy_ecs::system::system_param::SystemParam>::apply
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/system_param.rs:1456:19
  31: <bevy_ecs::system::function_system::FunctionSystem<Marker,F> as bevy_ecs::system::system::System>::apply_deferred
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/function_system.rs:542:9
  32: bevy_ecs::schedule::executor::multi_threaded::apply_deferred::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/schedule/executor/multi_threaded.rs:704:13
  33: core::ops::function::FnOnce::call_once
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/ops/function.rs:250:5
  34: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/panic/unwind_safe.rs:272:9
  35: std::panicking::try::do_call
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/std/src/panicking.rs:557:40
  36: ___rust_try
  37: std::panicking::try
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/std/src/panicking.rs:521:19
  38: std::panic::catch_unwind
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/std/src/panic.rs:350:14
  39: bevy_ecs::schedule::executor::multi_threaded::apply_deferred
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/schedule/executor/multi_threaded.rs:703:19
  40: <bevy_ecs::schedule::executor::multi_threaded::MultiThreadedExecutor as bevy_ecs::schedule::executor::SystemExecutor>::run
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/schedule/executor/multi_threaded.rs:240:23
  41: bevy_ecs::schedule::schedule::Schedule::run
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/schedule/schedule.rs:386:9
  42: bevy_ecs::world::World::try_run_schedule::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/mod.rs:2743:55
  43: bevy_ecs::world::World::try_schedule_scope
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/mod.rs:2676:21
  44: bevy_ecs::world::World::try_run_schedule
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/mod.rs:2743:9
  45: bevy_app::main_schedule::Main::run_main::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.14.0/src/main_schedule.rs:227:25
  46: bevy_ecs::world::World::resource_scope
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/mod.rs:1886:22
  47: bevy_app::main_schedule::Main::run_main
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.14.0/src/main_schedule.rs:225:9
  48: core::ops::function::FnMut::call_mut
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/ops/function.rs:166:5
  49: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
             at /rustc/8bfcae730a5db2438bbda72796175bba21427be1/library/core/src/ops/function.rs:294:13
  50: <Func as bevy_ecs::system::exclusive_function_system::ExclusiveSystemParamFunction<fn(F0) .> Out>>::run::call_inner
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/exclusive_function_system.rs:218:21
  51: <Func as bevy_ecs::system::exclusive_function_system::ExclusiveSystemParamFunction<fn(F0) .> Out>>::run
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/exclusive_function_system.rs:221:17
  52: <bevy_ecs::system::exclusive_function_system::ExclusiveFunctionSystem<Marker,F> as bevy_ecs::system::system::System>::run::{{closure}}
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/exclusive_function_system.rs:111:23
  53: bevy_ecs::world::World::last_change_tick_scope
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/world/mod.rs:2215:9
  54: <bevy_ecs::system::exclusive_function_system::ExclusiveFunctionSystem<Marker,F> as bevy_ecs::system::system::System>::run
             at .cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0/src/system/exclusive_function_system.rs:103:9

Hmm. Naively, moving the triggering event into the observer would mean that we can't respond to it from multiple observers, which is definitely undesirable.
The workaround here is to use a custom command or maybe a DeferredWorld, but this definitely feels like it should be possible. Maybe we should do something like resource_scope to split the world borrow safely?

I think this is on purpose; we don't want observers to have exclusive World access, but only DeferredWorld access, to prevent structural changes to the world.
I don't remember the exact reason, maybe it's related to nested triggers/observers? @james-j-obrien would know better

This is intentional for two main reasons:

Observers are run in the middle of insert/remove operations where there are outstanding pointers that could be invalidated through use of &mut World.
Invoking observers is a 1-to-many mapping which means that you would be able to invalidate the indexing structure while we are traversing it.

While theoretically it is possible to do enough shuffling of memory to allow this the perf (due to having to re-index into data structures rather than holding references/pointers) and complexity costs would be immense. You could also easily end up with really deep recursion stacks from indirectly invoking observers inside other observers.

Is it possible to ensure this fails at compile time then rather than runtime? Or at the very least, making a note in the documentation (assuming I didn't miss an existing note.)


Insert valid url on empty string

Hi there,
For some reason my values are not getting "clean'ed". In my schema I have:
 videoLink: {     type: String,     regEx: SimpleSchema.RegEx.Url,     label: 'The url of the file.',     optional: true},
But when I insert it into the collection I still get a insert valid url error.
How can I fix this?

Closing old issues. Please comment if this is still an issue and should be reopened.


Add options to adjust the length of song and artist

Blocked on pwittchen/spotify-cli-linux#28
(This currently builds on top of #1 . If #1 gets merged I'll rebase this, so it only includes the second commit. Or we can just use this PR and drop #1)

It's not compatible with the latest version of the spotify-cli-linux, so I'm closing it.

Would you consider to merge this PR if adapted to the current spotify-cli-linux version (in addition to the necessary changes in spotify-cli-linux)? Or shouldn't I bother? 😄

I honestly wouldn't like to have too many customizations in such simple scripts because it may make them harder to use and cumbersome ;).


Cookie name not set correctly

Describe the bug
The cookie has the name of fastapiusersauth and not as configured.
To Reproduce
cookie_authentication = CookieAuthentication(secret=SECRET, lifetime_seconds=86400, name="AnewName")

Thanks,
bert

The argument to set the cookie name is cookie_name, not name: https://fastapi-users.github.io/fastapi-users/configuration/authentication/cookie/#configuration
The name argument is to set the internal name of the authentication class (mainly useful in case of several authentication methods).


Fix order of input from critcmp stdout

As discussed here, currently the output mixes up the base and change results. This should fix that behavior.

I think this requires to re-compile everything.

I think this requires to re-compile everything.

Do you mean re-compiling the dist/index.js? I did the changes and the ran npm run build, so I think that should be fine.


Support Mistral Nemo

🚀 The feature, motivation and pitch
Support all kernels including fused linear CE. https://huggingface.co/mistralai/Mistral-Nemo-Instruct-2407/blob/main/config.json
Alternatives
No response
Additional context
No response

I think this is already supported since we patched mistral already https://github.com/huggingface/transformers/blob/main/src/transformers/models/mistral/modeling_mistral.py


Automated Package Upgrade

:tada: This PR is included in version 25.3.32 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Kanye West diss against Taylor Otwell - for no reason at all

This issue is related to the marketing aspect of the framework.
Kanye West dissed Taylor Otwell in his track "Famous"
https://youtu.be/Q821mNXNw-I?t=26s
The related verse begins at 27 seconds.
It's clear that Kanye is talking bs here, because he never promoted Laravel anywhere.
We should make a plan to respond with all the power of the community!
Any ideas?

Just insufferable. Adding dumb video "for fun" on top of unendurable night club rap doesn't make the result any more bearable…


[Feature Request]: add effect on mentioned section

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description

in above section when the image is clicked its width is increased but not when it is hovered.
Use Case
i would like to add the effect to preview an image which will be easier for user to decide if he/she want to click on it or not.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[ ] I'm a VSOC'24 contributor
[X] I have starred the repository

@Rajput-xv u are assigned .but there is some recent changes in the image slider now . so please update your branch before contributing.


Update Coq Nix Toolbox and remove hydra-battles overlay.

Now, we use a version of nixpkgs that knows about the new LibHyps dependency.

I should have tested exactly the file that I would be submitting to nixpkgs because now I discovered that I made a mistake and we will still need an overlay here until this is fixed in nixpkgs.


fix(engine): DownloadChapterImageInfo not changed to finished

Codecov Report

Merging #48 (eade58b) into master (d6c9b95) will not change coverage.
The diff coverage is 100.00%.

 Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


generate TS files with // @ts-nocheck  at the top by default

Is your feature request related to a problem? Please describe.
our tsconfig is set to flag unused variables as TS errors

front-end/src/pages/bulk-users-import-page/users-import-details/operations/fetchReusableImportMappings.codegen.tsx(6,3): error TS6133: 'UsersCsvImportModelFragment' is declared but its value is never read.
--
403 | front-end/src/pages/bulk-users-import-page/users-import-details/operations/fetchReusableImportMappings.codegen.tsx(11,3): error TS6133: 'UsersCsvImportModelFragmentDoc' is declared but its value is never read.

graphql codegen sometimes generates files that have unused imports

Describe the solution you'd like

I would like if the generated TS files were not checked by default-this saves time on big projects and it doesn't make sense to check generated files. The fact that these files are generated correctly is checked by the tests in this repo. It doesn't need to be checked by TS compiler again.
Describe alternatives you've considered

you can use the existing https://graphql-code-generator.com/docs/plugins/add but most people will never set it up until they start having issues, so it would make sense to add it by default in all typescript plugins
Additional context

I can create a separate bug issue for the imports being in the TS file, but it is not as big of a priority for me.

I think we need to discuss that, since we tried to avoid those additions until now (like with linters). Mainly because this could be solved with add plugin.
@ardatan @kamilkisiela what do you think?

Only if it's behind a flag to enable it back on demand

Hey @capaj as @dotansimha suggested it makes sense to use the add plugin and add this following way. If this is a very common use-case in community, people adding +1 or replying in comments, considering there isn't much demand it makes sense to just use the plug-in instead of maintaining a config option.
generates:
  path/to/file.ts:
    plugins:
      - add:
          content: '// @ts-nocheck'
      - typescript

I do think that in v3 it might be interesting to add it as default somehow, might make the default and initial experience of codegen a bit nicer, like @capaj is suggesting

but most people will never set it up until they start having issues, so it would make sense to add it by default in all typescript plugins

he just like me fr 😭


[bug-fix] Call transfer_batch_to_device in DDPlugin

What does this PR do?
This PR moves transfer_batch_to_device from ddp_sharded to ddp_plugin in on_before_forward

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together? Otherwise, we ask you to create a separate PR for every change.
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[ ] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified; Bugfixes should be including in bug-fix release milestones (m.f.X) and features should be included in (m.X.b) releases.

Did you have fun?
Make sure you had fun coding 🙃

So a couple of things:
on_before_forward is moving towards hook based functionality across the plugins. This I think is preferred and in the original PR we moved from move_to_device to on_before_forward. It allows the plugins to decide what logic is appropriate before the forward function.
We should not enforce move to device. This wouldn't work in cases where custom distributed accelerators need to move device differently imo. It should be up to the plugin to do what's necessary. Also when using DDP we do not need to manually move tensors to the appropriate device?

Hello @tchaton! Thanks for updating this PR.

In the file pytorch_lightning/plugins/ddp_plugin.py:

Line 169:41: W292 no newline at end of file

@tchaton can you have a look at the above comment? I don't think we should merge this.

Since in Lightning we only ever use the DDP with a single device (in each subprocess), then calling this hook will work (I can help test). However it is not applicable for the general way pytorch DDP can work and it can not be done the same way for the other modes (DP/DDP2).

Hey @rohitgr7,
I have added a test. Seems to work fine.
Best,
T.C

Hey @rohitgr7,
I have added a test. Seems to work fine.
Best,
T.C

Thanks @tchaton!
As Adrian said, this will work for single process/single device, but may not work with DDP2 or if device ids are specified. Could you add a test to check if this is the case? DDP2 on one machine boils down to DP.

Thanks @tchaton!
As Adrian said, this will work for single process/single device, but may not work with DDP2 or if device ids are specified. Could you add a test to check if this is the case? DDP2 on one machine boils down to DP.

does it fix https://github.com/PyTorchLightning/pytorch-lightning/issues/2350?

does it fix https://github.com/PyTorchLightning/pytorch-lightning/issues/2350?

does it fix #2350?

Only for DDP.

does it fix #2350?

Only for DDP.

update the docs too?
https://github.com/PyTorchLightning/pytorch-lightning/blob/dd442b6d335a5553961e7904cd9454b738cb72cd/pytorch_lightning/core/hooks.py#L541-L546

update the docs too?
https://github.com/PyTorchLightning/pytorch-lightning/blob/dd442b6d335a5553961e7904cd9454b738cb72cd/pytorch_lightning/core/hooks.py#L541-L546

update the docs too?
https://github.com/PyTorchLightning/pytorch-lightning/blob/dd442b6d335a5553961e7904cd9454b738cb72cd/pytorch_lightning/core/hooks.py#L541-L546

Great catch ! Done !

update the docs too?
https://github.com/PyTorchLightning/pytorch-lightning/blob/dd442b6d335a5553961e7904cd9454b738cb72cd/pytorch_lightning/core/hooks.py#L541-L546

Great catch ! Done !

Can you update the CHANGELOG? (after #5378 is merged)

Can you update the CHANGELOG? (after #5378 is merged)


fix(langchain): return exports in langchain runnables module patch

Patch methods need to return moduleExports like the other ones, just this one seems to have missed it as a typo

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


Enemy skins

Could you add an option to change all enemy skins to default?
I find it really helpful vs certains hard to see skins.
Thanks for the work.

I don't do private cheats, if this feature is requested by everyone, I will do it.


Experiment #3: Antenna array geometry and and gain/phase response calibration

Once we have a coherent array, we need to calibrate the gain and phase mismatches due to array geometry (antenna placement, etc...) and antenna manufacturing defects.  The typical way to do this is in a faraday cage, with a robot arm that moves around the antenna element, determining gain and phase response at each point on a hemisphere around the antenna element.  This procedure is costly, so Sören has pioneered a technique to use GPS signals to provide "serendipitous sampling" of the hemisphere above an antenna element.  Because we know the direction of arrival of each GPS signal, we can use these serendipitous signals as sampling points on the hemisphere, and use the received gain and phase as a (relative) calibration measurement, taking antenna 1 as the arbitrary reference point.  From this information, we can build a machine learning model to estimate the gain and phase mismatch of antenna elements (relative to antenna 1) across the entire hemisphere.
To perform this experiment, we must collect coherent data with at least 4 antenna elements for at least 2.5 hours, with a good view of the sky, to provide a full sampling of the hemisphere above the antennas.  This dataset will give us answers to the following questions:

Is it possible to calibrate the antenna geometry and gain/phase mismatch per element from nothing but GPS signals?  (So far, simulations look very promising)
Is it necessary to have a truly coherent system, or can we bundle individual channel offsets into the slowly-varying phase offsets we already learn for thermal expansion?
What is the time period necessary to capture over in order to truly calibrate the system?  The longer we capture, the more points are sampled, as the satellites inch across the sky.
What is the accuracy we can obtain through this technique?  We should be able to verify by comparing the known direction of arrival of a signal (obtained from decoding the incoming GPS signal) against the calculated direction of the signal obtained from analysis of the incident phases on our antenna elements.

@zsoerenm I have so far been imagining that we are going to perform phase calibration on our XTRXs by sharing clocks (#55), doing over-the-air calibration (#56) or sacrificing half of our receive channels, etc...  But do you think it's possible we might be able to use uncalibrated (and slowly-varying) phase offsets with your new group calibration ML model?  If our ML model can normalize out the phase variations due to thermal expansion, I see no reason it could not normalize out phase variations due to clock drift, as long as it's a slow enough change over time that it can be disambiguated from actual incoming signals.
What do you think?

Yes, the ML model can calibrate slowly varying gain and phase mismatches. They should at least be coherent during the integration of the CDMA code of GNSS signals, which is at minimum 1 ms.  If we allow 1° of deviation between the channels during the integration, that corresponds to maximal frequency deviation of 2.8 Hz. Over the time of 8 hours this is still highly oscillating function and the current implementation of the ML model can not estimate it.
Other than that, we probably want to integrate for longer times to increase the SNR (e.g. for 1 s). That corresponds to a maximal frequency deviation of 2.8e-3 Hz. Over the time of 8 hours this results into roughly 500 oscillations, which is still fairly large. I guess we could adapt the ML model in such a way that it can cope with oscillating gain and phase mismatches, too.


issue193 Replace 404 Not Found with 410 Gone for unknown LRA

Signed-off-by: xstefank<EMAIL_ADDRESS>resolves #193

+1, thanks @xstefank


Instance uniforms not available for particle shaders

Godot version
4.1rc2
System information
Fedora, RX 590
Issue description
instance uniforms are unavailable for particle process material (instance uniform as per-node, not per-particle).
**this is blocking particle improvement work on Godot. help :< **
Steps to reproduce
convert a process shader to shader, add "instance" to any uniform, observe error

Minimal reproduction project
see above.

Related to https://github.com/godotengine/godot/issues/62943.

Uh-oh. Seems like this is more complex than anticipated for process shader, since instance params need to be somewhat differentiated from rendering instance params. I wonder how that's handled for multiple materials :thinking:


Generated headers and CMake install

    @trondhe @jschwe

I have a question about the usage of this feature. Suppose I have a C++ library my_lib that depends on the cxx_bridge_target, which uses this feature to generate. Currently, the generated headers are placed under ${CMAKE_CURRENT_BINARY_DIR}/corrosion_generated directory, and with some additional sub directory path like cxxbridge/${cxx_target}, which I have to read the corrosion code to figure out.
If my C++ library my_lib needs to be exported and installed for external consumption, I wonder how corrosion users are expected to setup the project for my_lib so that the generated cxx bridge related headers can be installed and consumed by my_lib users. Do you have any guidance on this? Thanks.
Originally posted by @niyue in https://github.com/corrosion-rs/corrosion/issues/244#issuecomment-1306504123

It looks like this is what corrosion_install was meant for, however it currently only seems to support installing executable files and the rest is not implemented.
As for how you can do it in the meantime:
I would have a look here: https://cmake.org/cmake/help/latest/command/install.html#installing-files and probably also file-sets if you use at least CMake 3.23: https://cmake.org/cmake/help/latest/command/target_sources.html#file-sets

On the corrosion side I think it would make sense to define a header fileset on CMake >= 3.23 for the generated headers.

As far as a user of the corrision_add_cxxbridge have access to ${cxx_target} then it can add all necessary install rules.
The reason why I think we should not add any install rules into corrision_add_cxxbridge is that we don't not if user want to export this headers. The headers could be internal for the project.
@jschwe I think what we should do is set a property on ${cxx_target} which tells where it is generated headers are placed.
set_target_properties(${cxx_target}
   PUBLIC
        CORROSION_HEADER_DIR ${generated_dir}/include
)

Thanks so much for the prompt reply.

It looks like this is what corrosion_install was meant for

This is what I was looking for initially, and as you said, the implementation is incomplete yet.

it would make sense to define a header fileset on CMake >= 3.23 for the generated headers.

we should do is set a property on ${cxx_target} which tells where it is generated headers are placed

Something like these solutions will be great.

In my case, I am okay with CMake >= 3.23 and I did some web search previously and it seems header fileset is the latest CMake solution for such problem
either having some target property or allowing users to specify a directory for header generation can help I think

It will be great if we can come up with a canonical solution in corrosion and add some documentation for this kind of usage so that users can simply follow the instructions to do it. CMake is already too hard for many people (at least for me :() and any guess during the process will make this process much harder

There is another installation related issue which I think might be related with this issue (let me know if I need to open a new issue for it). If I try to use my_lib (see above) in another program my_app, during linking my_app, linker (ld under macOS 12) will report error like:
ld: library not found for -lmy_cxx_bridge_target-static

Here my_cxx_bridge_target is the target I specified when calling corrision_add_cxxbridge function, and it seems my_cxx_bridge_target-static is an internal target introduced by corrosion within this function, and this my_cxx_bridge_target-static target is marked as INTERFACE_LINK_LIBRARIES for the my_cxx_bridge_target (I think it is this line https://github.com/corrosion-rs/corrosion/blob/b921fd09155c05255a6b0df6d9901f919ce81b6b/cmake/Corrosion.cmake#L605). So when linking against my_cxx_bridge_target, the my_cxx_bridge_target-static will be linked. However, this target may require export/install to be linked.
I am not completely sure what the best approach for addressing this issue, do you think if this should be addressed in corrosion or if this should be done in corrosion users' side? If it should be done by corrosion users, what could be the recommended way to do it? Thanks.

The reason why I think we should not add any install rules into corrision_add_cxxbridge is that we don't not if user want to export this headers. The headers could be internal for the project.

There probably was a misunderstanding here - I was not proposing to add any install rules directly from corrosion. AS you said this should be up to the user.

@jschwe I think what we should do is set a property on ${cxx_target} which tells where it is generated headers are placed.

In CMake >= 3.23 this is what the HEADERS FileSet type is intended for and corrosion could create such a fileset and add the headers via target_sources( target PUBLIC FILESET corrosion_<target>_header HEADERS) . CMake would then automatically set the target properties HEADER_SETS, HEADER_DIRS  and update INCLUDE_DIRECTORIES (among others).
For older CMake versions providing a property to read is one solution, but I guess we could also just document where the files are generated too, since the path is pretty simple and unlikely to change.

It will be great if we can come up with a canonical solution in corrosion and add some documentation for this kind of usage so that users can simply follow the instructions to do it.

Definitely - the documentation of corrosion can certainly be improved greatly. I've been wanting to add an mdbook style documentation, so we don't have everything in one long readme and can add more examples without bloating the readme, but haven't had the time.

There is another installation related issue which I think might be related with this issue

Please open a new issue for that. It's probably not related to the new cxxbridge integration but rather an existing problem that hasn't surfaced because there are no tests using install inside a project and apparently not so many users either.


Add Python Environment setup

Include a general overview of setting up the vanilla python environment from scratch.  Include setting up the IDE as well.

Closing this in favor of #64. This issue must be implemented under the how-to/setup/python.rst file


Add dropExtension support

We're using css-modules as part of the dojo 2 widget system but we import our .css files without an extension such that webpack can resolve to the .json file instead when building.
It would be beneficial to add support to typed-css-modules to drop the input file extension for this purpose.
ie.
inputFilePath: path/to/file.css
outputFilePath: path/to/file.d.ts

Have raised a pull request with tests to address this: https://github.com/Quramy/typed-css-modules/pull/22


Rename block types?

https://github.com/iotaledger/iota-core/issues/467

FYI: TIP-46 was updated to the new block structure.

Closed by https://github.com/iotaledger/iota-sdk/pull/1626


Implement Sweet Donnel Hill

Quite sure this should be able to be done more eloquently. :P

Ideally this needs to be done as a single effect.  Also ideally it would just work on the list of current known keywords, which we shouldn't have to duplicate in too many places.
Pretty sure @ystros will agree, but feel free to say otherwise :)

Yep. Also ability.effects.removeKeyword() doesn't exist. :)

I would recommend creating a new removeAllKeywords effect (in addition to the removeKeyword effect that's missing). You could literally implement it like you have here for now, it'll just be shoved in a more appropriate place:
removeAllKeywords: function() {
    return [
        this.removeKeyword('Ambush'),
        this.removeKeyword('Insight'),
        this.removeKeyword('Intimidate'),
        this.removeKeyword('Pillage'),
        this.removeKeyword('Renown'),
        this.removeKeyword('Stealth'),
        this.removeKeyword('Terminal'),
        this.removeKeyword('Limited')
    ]
}

Ideally you can pull out the ValidKeywords constant in basecard.js into a commonly accessible file and map that here. Not sure it's worth doing quite yet (and think there's an argument for creating a richer Keyword class to factor out some of the behaviour associated with keywords, instead of just having a list of string names)

I'm 99.5% sure that someone will forget to update both places when there's a new keyword added :)
(I'm not 98% sure that it wont happen because i've just said that)


Remove "stablehlo" from "#stablehloadd" links

The "stablehlo" part of spec sections and spec permalinks is redundant.
It's a StableHLO spec, so it is reasonable to assume that it specs
StableHLO ops.

Force merging because changes in StablehloOps.td are documentation only.


Server closes connection before sending data

I have a very simple file server using Aiohttp:
import os.path
from os import listdir
import asyncio
from aiohttp import web
import aiohttp_jinja2
import jinja2

@aiohttp_jinja2.template('template2.html')
@asyncio.coroutine
def get(request):
  root = os.path.abspath(os.path.dirname(__file__))
  files = [file_name for file_name in listdir(os.path.join(root,'files'))
                    if os.path.isfile(os.path.join(root, 'files', file_name))]
  return {'files': files}

if __name__ == "__main__":

   app = web.Application()
   aiohttp_jinja2.setup(app, loader=jinja2.FileSystemLoader('/root/async'))

   app.router.add_route('GET', '/', get)
   app.router.add_static('/files/' , '/root/async/files')

   loop = asyncio.get_event_loop()
   f = loop.create_server(app.make_handler(), '<IP_ADDRESS>', 8080)
   srv = loop.run_until_complete(f)
   print(' serving on ', srv.sockets[0].getsockname())
   try:
    loop.run_forever()
   except KeyboardInterrupt:
    pass

When I test it using siege tool with, for example, such command:
siege -c 1000 -b -t 60 http://<IP_ADDRESS>:8080/files/megabytes15.test

It raises a lot of exceptions like this:
socket.send() raised exception

And the amount of data transferred is very small. I assume that the socket closes before the file is fully sent to the user. I would be very appreciated for some suggestion. Thank you in advance! UPD:
template2.html
<!DOCTYPE html>

<title>Aiohttp Test Server</title>

List of files:

{% for item in files %}

{{ item }}

{% endfor %}

/root/async directory contains template2.html and server script file(code mentioned at the start). /root/async/files directory contains some dummy files of 15b, 15kb and 15mb sizes.
UPD: the exception is not risen for small files.
UPD: This exception is raised from connetion_lost function of web.py:
def connection_lost(self, exc):
        self._manager.connection_lost(self, exc)
        super().connection_lost(exc)

I've made my own investigation. Appeared that siege sends a get request with "Connection: close" header". This works fine for the same functionality, written on Tornado framework.
I've changed the "Connection: close" header to "Connection: Keep-Alive". Now there is no problem with "socket.send() raised exception", but siege throws Segmentation fault.
I assume that aiohttp, on most connection executes directive "Connection: close" first and than trying to send data to already closed socket. Need to figure out where relevant code is located.

@oicnysa thanks for investigation. I filed an issue in asyncio: python/asyncio#248

Thanks. I've read by your post in asyncio. Will try to patch by myself, but I'm not so familiar with aiohttp code. So maybe if you will have some time, you could describe more detailed, where "code to patch" situated.

@oicnysa good fix requires changes in asyncio: we need for new API.
If people will agree with me I'll fix asyncio code. Or maybe somebody will guess better solution than I see now.
Dirty fix should add yield from asyncio.sleep(0) into static file handler, but I dislike it. The way slows down downloading of all files, that's why I don't want to fix aiohttp only.
To get rid of annoying prints (socket.send() raised exception is not exception actually but log warning record) you may do follow trick:
from asyncio import constants
constants.LOG_THRESHOLD_FOR_CONNLOST_WRITES = 1000000  # some big number

It will disable logging.
I still did not investigated why siege tool don't want to work with aiohttp server though. Looks like It gets answer unsupported by siege and terminates connection instantly. As result you see a lot of logging warnings.

I think it is because I've tried it on virtualbox(maybe it couldn't handle so many sockets). Now I've managed to test aiohttp with siege and Connection: Keep-Alive on more powerful machine(Dell PowerEdge R200). But the results were bad comparing to Tornado  and siege with "Connection: Close".
Tornado had 2143 successful transactions and 96.88% availability, but aiohttp had only 267 successful transactions and 78.99% availability. But when running this test with smaller files like 15 kb and 10 seconds for test, aiohttp is faster.

Tornado has more complex static files handling: it supports RANGE and content caching like LAST-MODIFIED and so on.
More important, Tornado has 64Kb chunks size but aiohttp used to have 8Kb.
In fresh aiohttp masher I've increased chunk size to 64Kb  (but for modern machines it's maybe still too small value, 256Kb or even 1Mb would be better).
Anyway, for static files the best way is to use proxy server like nginx.

Thanks for information Andrew!

I've tried master version and it is performing very well.


Disallow setters for known mutable property types

We should at least disallow it on the parameters object for artifact transforms. We could also do it for other instances of work configuration.
For tasks we would need to deprecate the possibility first and then we can remove it in a future major version.
Types affected:

[ ] ConfigurableFileCollection
[ ] Property
[ ] DomainObjectCollection

We should do the same deprecation for Property types, as they are also things that should be mutated via methods on the object instead of using setters on the parent type.

It's the same for Provider too.  Maybe we should have a marker type for all immutable-but-configurable properties?
I think it's:

Provider
Property (and children)
FileCollection, FileTree
ConfigurableFileCollection, ConfigurableFileTree
DomainObjectCollection (and children)

I think there may be some one off things too (but I'm thinking more for Task things)

We discussed this, and in the first round we'd like to limit the scope to types that are already mutable in-place, because the setter can be removed without having to change the getter to preserve the mutability of the type that owns the property itself.
For properties with immutable types like FileCollection the change is breaking. It might make sense to introduce warnings that result in breaking changes in 6.0 instead. I'll create an issue for this.

It's a good point about DomainObjectCollection though, added it to the issue description.

Actually, what is the recommendation on using DomainObjectCollection vs ListProperty and SetProperty?


Please upload it to Mozilla's addons and Chrome's Webstore.

Please upload it to Mozilla's addons and Chrome's Webstore.  I believe many will appreciate it.
I've been tried many extensions, auto pager, autopagerize, page zipper. and many of them. I ended up with autopagerize userscripts version for years.
And I just discovered your works yesterday. It's working great in Firefox, Chrome, Opera and Vivaldi.
Thank you very much.

I thought about it previously and decided not to. Maybe at some point in the future...

I also want to ask from you.
I tried to install it manually into Vivaldi, but I do not know the reason but I could not install it because I got a manifest error.
Or I want some means to install from this page. It is difficult manually.

I didn't test in in Vivaldi but It's Chrome-based so should work theoretically. Try removing lines that show you errors from the manifest.

I tray folder install.
この拡張機能をインストールしようとしたときに、次の警告がありました。
Unrecognized manifest key 'applications'.
Unrecognized manifest key 'developer'.

@shiro2peppers let us use separate issue. The problem is not related to this one. I will move my answers there.


add_to_changedebug: command not found

$ setver changelog
$HOME/.basher/cellar/bin/setver: line 116: add_to_changedebug: command not found

setver v1.14.4 - by Peter Forret<EMAIL_ADDRESS>

Fixed in 1.15.1


Develop regex capability to search for string in Freecen2Place name

This is the core requirement to support a number of string search capabilities

@geoffj-FUG what is the minimum size of the search string? 2 or 3 characters? Clearly 1 is too few.

Kirk
I think we could go for 3. Two is pointless as it will bring up too many options.
Geoff
From: Kirk Dawson<EMAIL_ADDRESS>Sent: Sunday, February 14, 2021 2:27 AM
To: FreeUKGen/FreeCENMigration<EMAIL_ADDRESS>Cc: geoffj-FUG<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [FreeUKGen/FreeCENMigration] Develop regex capability to search for string in Freecen2Place name (#1140)
@geoffj-FUG https://github.com/geoffj-FUG  what is the minimum size of the search string? 2 or 3 characters? Clearly 1 is too few.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1140#issuecomment-778641157 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFPREWTBIAMPZUFHUC3S62R6RANCNFSM4XSI6TSA .  https://github.com/notifications/beacon/AKCPIFP22AWOJUUCCLHPUITS62R6RA5CNFSM4XSI6TSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFZUR6BI.gif

OK minimum of 3 it is


Enable WriteCore feature for storage

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.Storage


remove hidden attribute from cluster flags and related code

Proposed Changes

Unhides cluster flags from server subcommand and removes related unused code.
Types of Changes

Unhide server subcommand flags.
Verification

Linked Issues
https://github.com/rancher/rke2/issues/856

Further Comments

We should probably delete https://github.com/k3s-io/k3s/blob/master/pkg/cli/cmds/nocluster.go and drop the !no_etcd tag from https://github.com/k3s-io/k3s/blob/master/pkg/cluster/etcd.go. I checked through the codebase and we're not using the no_etcd build tag either here or in RKE2.

dont merge until we have an explanation for why this flag was dropped https://github.com/rancher/rke2/issues/856#issuecomment-815167532

@galal-hussein can you confirm that these were unintentionally hidden when attempting to hide the etcd-only related flags (--disable-apiserver, --disable-controller-manager, etc)?

@galal-hussein can you confirm that these were unintentionally hidden when attempting to hide the etcd-only related flags (--disable-apiserver, --disable-controller-manager, etc)?

Yes I can confirm that they were unintentionally hidden along with the disable cluster flags


Added logic to ARP spoof the network with multiprocessing/multithreading

Fixed #119

A running example of the previous implementation of ARP spoofing in IoT inspector (03/18/2022)
Target list: a list of devices discovered by IoT inspector, this grows slowly
[.x, .y, .z, .a, .b, .c, .1]
White list: a list of devices that are allowed to be spoofed from the target list
[.x, .y, .z,]
In the current implementation, .1 does not get added to the white list. It’s forcefully added to whitelist, so white list: [.x, .y, .z, .1]
For each device in the target list:

.x

    For each in white list:
		.y <- .x is at | .x <- .y is at (iot-inspector’s mac)
		.z <- .x is at | .x <- .z is at (iot-inspector’s mac)
		.1 <- .x is at | .x <- .1 is at (iot-inspector’s mac)

.y

	For each in white list:
		.x <- .y is at | .y <- .x is at (iot-inspector’s mac)
		.z <- .y is at | .y <- .z is at (iot-inspector’s mac)
		.1 <- .y is at | .y <- .1 is at (iot-inspector’s mac)

.z

	For each in white list:
		.x <- .z is at | .z <- .x is at (iot-inspector’s mac)
		.y <- .z is at | .z <- .y is at (iot-inspector’s mac)
		.1 <- .z is at | .z <- .1 is at (iot-inspector’s mac)

.a skipped because it’s not whitelisted
.b skipped because it’s not whitelisted
.c skipped because it’s not whitelisted
.1 skipped because it’s not whitelisted

New approach:
Target list: a list of devices discovered by IoT inspector, this grows slowly [.x, .y, .z, .a, .b, .c, .1]
White list: a list of devices that are allowed to be spoofed from the target list [.x, .y, .z,]
In the current implementation, .1 does not get added to the white list. It’s forcefully added to whitelist, so white list: [.x, .y, .z, .1]
For each device in the white list:

.x

		.y <- .x is at (iot-inspector’s mac)
		.z <- .x is at (iot-inspector’s mac)
		.1 <- .x is at (iot-inspector’s mac)

.y

		.x <- .y is at (iot-inspector’s mac)
		.z <- .y is at (iot-inspector’s mac)
		.1 <- .y is at (iot-inspector’s mac)

.z

		.x <- .z is at (iot-inspector’s mac)
		.y <- .z is at (iot-inspector’s mac)
		.1 <- .z is at (iot-inspector’s mac)

.1

		.x <- .1 is at (iot-inspector’s mac)
		.y <- .1 is at (iot-inspector’s mac)
		.z <- .1 is at (iot-inspector’s mac)


Warnings are not logged even when setting warning_level to VERBOSE

What's the issue?
If I set the closure compiler flag warning_level to VERBOSE, those warnings don't show up anywhere when using this plugin.
How do we reproduce the issue?
Try to compile any code that should work but also produce a warning. For example:
console.log(document.getElementById(1));

With warning_level=VERBOSE, I'd expect to see the following:
JSC_TYPE_MISMATCH: actual parameter 1 of Document.prototype.getElementById does not match formal parameter
found   : number
required: string at line 1 character 36
console.log(document.getElementById(1))
                                    ^

Additional context
It seems like the problem occurs here: https://github.com/ampproject/rollup-plugin-closure-compiler/blob/0.6.1/src/compiler.ts#L57-L62
The plugin only errors if exitCode is not 0, but then it doesn't do anything with stdErr, which is where the warnings are.
Wish list
What would be really nice is if the plugin surfaced the warnings and also transformed the line/col numbers back to the original source files via the source maps. I do something similar here, and it's super helpful when debugging.

Quite interesting.
Thank you for the bug report, I'll attempt to resolve this in the next week or so.

I've run into this as well. During development I'd love to use settings like this:
{
  compilation_level: 'ADVANCED',
  warning_level: 'VERBOSE',
  jscomp_warning: '*',
}

Started a branch here: https://github.com/ampproject/rollup-plugin-closure-compiler/tree/error-reporting
Initial look indicates these warnings are not being exposed by closure-compiler-npm.

Opened a separate issue for the "wish list" item which will require parsing the output of CC warnings.


fix issue #127

Jenkins job istio/presubmit passed

Jenkins job istio/presubmit passed

This breaks the e2e-smoke test. How do we we pass in the istioctl url now ?

Fixed e2e-smoke test with PR https://github.com/istio/istio/pull/131


Add a direct link from ETMoses front-end to ETmoses Wiki

As discussed in https://github.com/quintel/etmoses/issues/893, a direct link from the ETMoses app to the documentation on the ETMoses Wiki would be very helpful. @MarjoleinSchwachofer and I came up with the suggestion of adding an 'Information' item to the menu bar like we have in the ETM front-end.

As @ChaelKruip rightfully commented on this suggestion, it would be more in line with the style of the other menu items to turn the 'Information' item into a menu as well. I propose to start with the following menu items:

Information

About Quintel Intelligence (linking to quintel.com)
Documentation (linking to github.com/quintel/etmoses/wiki)

We can expand the menu later with things like partners, etc.
What do you think of this idea, @MarjoleinSchwachofer , @dennisschoenmakers , @antw, @AlexanderWirtz and @ChaelKruip ?

Good idea. In my view an important item under information is a direct link to how to use section. I think this should be a specific item, as documentation  can also be viewed as background information. What do you think?

What do you think?

I like it. The Information menu item would then look like this (I also re-arranged the menu items).

Information

How to use (linking to https://github.com/quintel/etmoses/wiki/How-to-use)
Documentation (linking to github.com/quintel/etmoses/wiki)
About Quintel Intelligence (linking to quintel.com)

Any objections?

Any objections?

No, great idea!

Assigning @grdw as he can implement this a million time quicker than I can ;)

This has been implemented on the Beta-server. Thanks, @grdw !


Add property updates to loaders

It's currently impossible to declare properties on the results of resources loaded with loaders. For example:
<three-mesh>
    <plane-geometry />
    <mesh-basic-material>
        <!-- I want to set the texture's anisotropy to 32, for example, but can't do so declaratively -->
        <texture-loader src="/example.png" attach="map" />
    </mesh-basic-material>
</three-mesh>

Update so that this behaves as expected:
<three-mesh>
    <plane-geometry />
    <mesh-basic-material>
        <!-- Any non-`src` and non-`attach` attribute should be set on the loaded resource -->
        <!-- The loaded resource itself should also be the element's `.instance` rather than the loader - we can set the loader to a new property `.loader` -->
        <texture-loader src="/example.png" attach="map" anisotropy="32" />
    </mesh-basic-material>
</three-mesh>

Done in #73


[core] Fix streaming read dv table

Purpose

Linked issue: close #xxx

Tests

API and Format

Documentation

Also fix batch read for deletion vectors table too.


[Docs] Deploying Designs

Current State
This page is missing content - https://docs.layer5.io/meshmap/tasks/designs/deploying-designs/
Desired State
Mastering Meshery Learning Path content or Meshery Docs content can be reused (copied and pasted) here.

Contributor Guide and Resources

📚 Instructions for contributing to documentation

Layer5 documentation site and source

🎨 Wireframes and designs for Layer5 site in Figma (open invite)
🙋🏾🙋🏼 Questions: Layer5 Discussion Forum and Layer5 Community Slack

Hi @leecalcote, could I contribute to this as my first issue?
I'm just trying to get familiar with the community and have already set up a local development environment for the project.
In case there's already someone working on this, could you point me to other similar issues as a first-time contributor?

@sparshagl, sure. You might parlay with @Alero-Awani.
@Alero-Awani, the clock is ticking.