Git asks for credentials twice

Issue Type: Bug

Commit locally
Try to sync to a remote repository
Put in username and password once
VSCode asks for the username and password again

Log output after putting in the credentials the first time, and cancelling the second:
> git pull --tags origin master
> git show :src/player_controller.rs
From https://github.com/JMS55/roguelike
 * branch            master     -> FETCH_HEAD
> git push origin master:master
> git show :src/player_controller.rs
remote: Repository not found.
fatal: Authentication failed for 'https://github.com/JMS55/roguelike.git/'

VS Code version: Code 1.39.2 (6ab598523be7a800d7f3eb4d92d7ab9a66069390, 2019-10-15T15:33:40.634Z)
OS version: Linux x64 5.3.7-301.fc31.x86_64

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (8 x 1965)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwareoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: disabled_softwareskia_deferred_display_list: disabled_offskia_renderer: disabled_offsurface_synchronization: enabled_onvideo_decode: unavailable_offviz_display_compositor: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
1, 2, 1

Memory (System)
7.68GB (0.81GB free)

Process Argv
--unity-launch

Screen Reader
no

VM
0%

Extensions (5)

Extension
Author (truncated)
Version

better-toml
bun
0.3.2

vscode-icon-theme
jtl
1.6.5

git-graph
mhu
1.17.0

rust
rus
0.7.0

tabnine-vscode
Tab
2.1.11

(1 theme extensions excluded)

I am experiencing this too, especially when I change directories. Both Putty and linux terminal do not ask me to input my password more than once to log in, and never when I change to a directory while within my account.
Log output when I tried to log in and it prompted me for my password twice. Both times I typed in my correct password.
[14:12:46.926] Running script with connection command: ssh -T -D 41945 -o ConnectTimeout=15 MYSERVERNAME bash
[14:12:46.926] Install and start server if needed
[14:12:47.183] > Password:
[14:12:47.183] Got some output, clearing connection timeout
[14:12:47.184] Showing password prompt
[14:12:54.207] Got password response
[14:12:54.208] "install" wrote data to terminal: ""
[14:12:54.214] >
[14:12:54.280] > Password:
[14:12:54.280] Showing password prompt
[14:13:00.401] Got password response
[14:13:00.402] "install" wrote data to terminal: ""
[14:13:00.443] >
[14:13:02.979] > redacted: running

Can you show me a screenshot of the dialog which asks for credentials?

Got it. VS Code doesn't have a secure API to store credentials so we don't do it. I suggest you set up a credential manager such as https://github.com/Microsoft/Git-Credential-Manager-for-Windows

I'm sorry if I wasn't clear the first time. When I say that VSCode asks for credentials twice, I mean that when I want to sync my repo, it asks for it once, then immediately asks for it again right afterwards, even though I just gave it my info. Not giving it a second time causes the whole operation to fail. The issue isn't that it doesn't remember my info, it's that it asks for it twice for one operation. Additionally, VSCode used to save the info so long as I kept the window open. Was that removed?

The sync operation is actually a pull and a push, that's why there are two prompts for auth. Not really sure why this broke for you, but VS Code was never saving the credentials. Maybe you had a storage credential helper configured and that stopped working all of a sudden?


Added new make target for validating swagger file.

Added a new validate-swagger make target.

» make validate-swagger
swagger validate ./swagger.yml
2021/06/09 15:54:20
The swagger spec at "./swagger.yml" is valid against swagger specification 2.0
2021/06/09 15:54:20
The swagger spec at "./swagger.yml" showed up some valid but possibly unwanted constructs.
2021/06/09 15:54:20 See warnings below:
2021/06/09 15:54:20 - WARNING: spec has no valid path defined


Changelog of rules

Is there somewhere that the new rules are recorded in a changelog, like which version of VS/C#/SDK they came out in? It's hard to know when there's been new rules to add them to existing projects to keep them up to date.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4f19aa22-56d1-ff22-a410-e5e0b6a80e6d
Version Independent ID: 012968d3-07d2-5c37-fa3d-e3561eff8681
Content: Code style language rules - .NET
Content Source: docs/fundamentals/code-analysis/style-rules/language-rules.md
Product: dotnet-fundamentals
GitHub Login: @gewarren
Microsoft Alias: gewarren

For the .NET SDK, there's a changelog here.


Export functions

Thanks for all the comments -- have been a little busy, so pushing changes I have so far.  Point by point:

Make func_factory private or change func_factory to be methods of BasisFunction subclasses (change _basis.pyx).
Added both func_factory and func_string_factory as methods of subclasses

Support SmoothedHingeBasisFunction (for smoothed models) - see section 3.7 (Degree of continuity) of Friedman, 1991(see README.md for reference) for details.
This is done, and added to the tests

Unit test for export_labelled_coefficients
Removed this function for now.  Do you have an idea for testing?  Maybe just hardcoding in the correct coefficients.

Match names for unit tests and the functions they test
Done

Update doc string for export_python_string to indicate it returns a string
Done

Maybe change name of export_python_model to export_python_function?
Good idea.  These functions are really in preparation to export a string in C.

Does this support the constant term?
It supports ConstantBasisFunction, if that's what you mean.

Add function_name argument to export_python_model
I documented this a little better in the export_python_string method, but for export_python_model, I'm not sure what function_name would do.

Move all this export related code into its own module, export.py. I think it will be easier to read and think about that way.
Good idea, also added test/test_export.py

Thanks! Is this ready for merge as far as you're concerned?  If so, I'll give it a more detailed look and try to merge it.

Yes I think it is ready to merge.

Thanks, looks good.  Just merged it.


Double quotes contained items are not adding

Rasing the Issue
Uncaught Error: Syntax error, unrecognized expression: option[value="1 1/2""]

Duplicate of #485
@apraveenkumar1197 see the fix in PR #664. You'll have to manually apply that change to your bootstrap-tagsinput.js file, since this repo is unmaintained. (or find a fork that has applied it already) (or fork it yourself and apply that change)


Display changesets by release type

Currently we go:
## 2.1.0

- [patch] Allows passing --public flag for publishing scoped packages [159c28e](https://bitbucket.org/atlassian/atlaskit-mk-2/commits/159c28e)
- [minor] Changes changelogs to be opt out rather than opt in [f461788](https://bitbucket.org/atlassian/atlaskit-mk-2/commits/f461788)

without caring about the order of release notes, or precedence. To get more readable changelogs, we should do something like:
## 2.1.0
### Minor

- Allows passing --public flag for publishing scoped packages [159c28e](https://bitbucket.org/atlassian/atlaskit-mk-2/commits/159c28e)

### Patch

- [minor] Changes changelogs to be opt out rather than opt in [f461788](https://bitbucket.org/atlassian/atlaskit-mk-2/commits/f461788)

Suggestion by @timleslie

Released as of @changesets/cli 1.0.1


JupyterLab/Local pipeline execution fails with "Expected token < in JSON ..." for long running tasks

Describe the issue
See steps below. I was only able to always reproduce this on ODH, but not locally.
To Reproduce
Steps to reproduce the behavior:

In ODH launch JupyterHub and choose in the spawner dialog the s2i-lab-elyra:vX.Y.Z image
Git clone https://github.com/elyra-ai/examples.git
Open the NOAA pipeline.
Run the pipeline locally.

There is no error logged in the Jupyter console. The web browser indicates that the POST https://jupyterhub-1-0-9-test.ptitzler-odh-442dbba0442be6c8c50f31ed96b00601-0000.sjc04.containers.appdomain.cloud/user/iam%23ptitzler@us.ibm.com/elyra/pipeline/schedule?1618515969761  request fails with status code 504, returning this message text:

504 Gateway Time-out

The server didn't respond in time.
`

which causes the JSON parser error.
Expected behavior
A clear and concise description of what you expected to happen.

The front end should catch processing errors.
Not sure to what extend the front end can provide a meaningful message since it doesn't know whether the back-end sent "garbage", whether the backend timed out and the long running request is still processing.
Insights why this always happens on ODH/JupyterHub/JupyterLab but not locally. The "long running job" completed within a few minutes and didn't seem to be taking longer than usual.

Deployment information
Describe what you've deployed and how:

Elyra version: 2.2.1
Installation source: official container image s2i-lab-elyra:v0.0.7
Deployment type: Open Data Hub

I was unable to reproduce the issue running that container image locally:
docker run -p 8888:8888 quay.io/thoth-station/s2i-lab-elyra:v0.0.7 jupyter lab --ip=<IP_ADDRESS> --port=8888 --notebook-dir=/tmp

Perhaps JupyterHub is imposing some sort of timeout limit? Just a random guess ...

@ptitzler do you know how long it takes for the response to timeout? I'm guessing this is on the ingress level

@bourdakos1 - 30 seconds on the dot

@akchinSTC this smells like a default kubernetes/openshift timeout that could probably be configured away, but we should probably find a different solution. I don’t think we should have a request open for longer than 30seconds. We should try to find a way to better handle long running submissions/runs

I think if we move to something like websockets we shouldn't run into a timeout issue and could get richer information about the progress of the runs

the deployment on openshift doesn't appear to have any ingresses or routes configured in the odh project/namespace, so it's probably using some global default. Short term, going to see if a quick config change will do the trick, but agree with

We should try to find a way to better handle long running submissions/runs

From https://jupyterhub.readthedocs.io/en/stable/reference/config-reference.html
## Timeout (in seconds) before giving up on a spawned HTTP server
#
#  Once a server has successfully been spawned, this is the amount of time we
#  wait before assuming that the server is unable to accept connections.
#  Default: 30
# c.Spawner.http_timeout = 30

Turns out the default timeout for routes happens to be 30 seconds as well and needs to be increased.

Development TODO: add error handling for non-success status codes.

I am seeing this error when I attempt to run in our Kubernetes Z2JH environment. If run the container that has Elyra installed (same thats used in the k8s cluster) it works. I am seeing a 403 error in the browser console at the elyra/pipeline/schedule?1657211511533 endpoint.


Loading Solid-Auth

13:58:20.372 localhost/:1 Failed to load https://solid.community/.well-known/openid-configuration: The 'Access-Control-Allow-Origin' header has a value 'https://localhost:4200' that is not equal to the supplied origin. Origin 'http://localhost:4200' is therefore not allowed access. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I assume I need to either change the header or get a cert, but shouldn't localhost be an exception?

@willemneal what were you trying to do when you received this error?

After launching server I tried to sign in.
On Mon, Oct 1, 2018, 10:39 James Martin<EMAIL_ADDRESS>wrote:

@willemneal https://github.com/willemneal what were you trying to do
when you received this error?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Inrupt-inc/generator-solid-angular/issues/3#issuecomment-425932194,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABah7KkhBeMq9-0kbfHCowppZ-Bj0Vraks5ugikLgaJpZM4XBFIZ
.

Interesting.. I don't see that same error locally. Which provider are you using to log in?

Solid.community
On Oct 1, 2018 13:02, "James Martin"<EMAIL_ADDRESS>wrote:
Interesting.. I don't see that same error locally. Which provider are you
using to log in?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Inrupt-inc/generator-solid-angular/issues/3#issuecomment-425984425,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABah7KbzZA88652m_C7jZLoNN-YaCbZCks5ugkq3gaJpZM4XBFIZ
.

I just tried installing this on a fresh box, and didn't see either of the errors you mentioned (CORS or otherwise), or any warnings either. Is there any other information you can provide so I can look into it?
I've tried it on MacOS and Windows 10 on Chrome. Looks like Edge/IE has some issues still but not the ones listed here.

Closing this as I do not plan to investigate this issue at the moment. Feel free to reopen if the issue persists.


Uppercase is not recognized

Hi there, great workflow action!
I have noticed that when we use uppercase Clubhouse ticket names, the action doesn't pick those up. For example:
### Features

ch1234 Shiny New Thing <---- that's OK
[ch9876] Bug In Disguise <---- that's OK
CH1234 Shiny New Thing <---- that's NOT reconigzed
[CH9876] Bug In Disguise <---- that's NOT reconigzed

Hey @fabioknoedt apologies for the really slow reply here. This should be fixed in today's release.

@kuritz that's great! thanks!


First attempt at making parsing more flexible in types

Makes the claims an interface.
https://github.com/dgrijalva/jwt-go/issues/64

I think this is the best solution I've seen for this issue.  I have a couple concerns:

While this change appears to be backwards compatible, changes to the Claims interface would not be.  What's the likelihood it will change frequently?  When adding more claims for example.
This puts more of the parsing and validation burden on the developer.  It opens up opportunities for mistakes that cause vulnerabilities/unexpected behavior.  See the difficulty coming up with an ideal method signature as an example.

Neither of these are insurmountable, but they deserve consideration.

Actually, this is not backward compatible as the type of Claims has changed.  One other side effect of this is existing users will have to type check Claims everywhere they use it.

One way to address the Claims interface would be to make it a generic Valid() bool. While this would push more of the validation burden onto the developer, this is already the case, as the developer is already forced to make validation considerations in the keyfunc.
I think there are two levels of validation going on here: Token level validation (e.g. hash alg checks, kid) and claims level validation (e.g. exp and nbf). Maybe there is a solution that deals with that difference better.
I don't really have a good suggestion for maintaining backwards compatibility. This seems to be a active question within the go community right now. I think that the validation questions raised here will fundamentally break the api no matter the solution. :(

I agree, you're definitely going to be breaking backwards compatibility with this change. However, that's what major version bumps are for!
I ran with @crxpandion suggestion of using a more generic interface, if you look at the PR #73 it isn't as complete, in that the tests haven't been updated, but it shows the other method of accomplishing this. Perhaps in a way that will be easier to be backwards compatible in the future.

Getting close to landing #73, which is based on this.


Compatibility with IntelliJ IDEA 14

Running Intellij Ultimate Idea 14.1.5 and i get this incompatibility error:
Plugin 'Protobuf Support' is incompatible with this installation

I would really like to use this awesome plugin. Is it not compatible with Intellij 14 ?

Plugin is compatible with IntelliJ IDEA 2016.1 and higher versions. Originally I did not plan to support older versions.
There are two reasons why I decided to support this version and higher:

Starting from IDEA 2016.1 I could use Java 8 for development.
This is the version that I was using when I started this project.

As plugin gets more and more popular, I think it definitely makes sense to support older IDEA versions too.
It should not be hard to rewrite all code using Java 6 (or 7 - need to check what JDK is bundled with IDEA).
Following modules should be rewritten using Java 6 in order to make plugin for IDEA 14:

this project
https://github.com/protostuff/protostuff-compiler
https://github.com/kshchepanovskyi/jetbrains/tree/gradle-integration (maybe)

If somebody is willing to help, I will gladly accept pull requests :)

I will give it a shot. Will make a pull request after work.

Ok, let's do it.
I just checked IDEA 14 release notes, code should be rewritten using Java 6 language.
You can start from plugin code.
In order to simplify things, I will extract generated lexer and parser code from https://github.com/protostuff/protostuff-compiler to separate project, so that we do not need to move whole protostuff-compiler to Java 6 (streams are used heavily there).

It does make sense to rewrite protostuff-compiler dependency using Java 6 as well (as I have maven plugin there - there is no guarantee that all users have Java 8). I hope I will finish it in a couple of days.

@rpirsc13 I've just made all changes needed for IDEA 14 support, please checkout branch 13x, build it and try it out :)

Please report all problems that you find here.
I hope we will finish testing on this week, so I will make a public release after that.

Released in https://github.com/protostuff/protobuf-jetbrains-plugin/releases/tag/v0.6.0

Download statistics shows that there are not so many users who use old IDEA versions:
13 ... 15:

2016.1+:

I decided to cancel my original plan to support IDEA 13 in the new releases.


Feature request - Array/concat

https://lodash.com/docs/4.17.15#concat

how to push my code ?

Since this can be easy done with [...array1, ...array2] there is no need to add this.

ok  fill is be need ?  https://lodash.com/docs/4.17.15#fill

I thought it was exactly the same as lodash

If the function can be easily replaced by native JS functions it makes no sense to include this.
See: https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore?tab=readme-ov-file#_fill


A way to specify build-dependencies

Pipenv might need a way to specify built-dependencies and tooling packages that need to be installed in order for pipenv to do it's job correctly. Even a pyporject.toml is not sufficient, because you'd have to pass pip the option --no-use-pep517 in order to install build dependencies and then have pip build from setup.py the old-fashioned way.
Example
In my company we use a wrapper around setuptools to simplify writing setup.py scripts for our packaging. Let's call this wrapper stwrapper.
A typical setup.py would look like this:
# setup.py for "package-that-uses-stwrapper-in-its-setup-py"
from stwrapper import setup

setup(
   name='package-that-uses-stwrapper-in-its-setup-py',
   # ... some more arguments
)

Where the function stwrapper.setup parses arguments, does some extra work and then calls the real setuptools.setup. Effectively, the stwrapper package is sort of a built dependency for us.
Lets say we have the following Pipfile:
[dev-packages]
stwrapper = "*"
package-that-uses-stwrapper-in-its-setup-py = { path = ".", editable = true, requires=["stwrapper"] }

and do a
pipenv lock --verbose

then, with the current version of Pipenv, we get:
Traceback:
...
pipenv.patched.notpip._internal.exceptions.InstallationError: Command "python setup.py egg_info" failed with error code 1 in '.'

Because stwarpper is not installed at the time pipenv tries to parse the setup.py of package-that-uses-stwrapper-in-its-setup-py. That is even the case, when stwrapper is installed in the system's python installation. Pipenv wants to have it inside the new virtual environment it creates. It's a Catch-22.
Our current workaround is to let pipenv create the virutal environment. Then do a pipenv run pip install stwrapper inside it and then the pipenv lock. That way it works.
Another, better workaround will be possible one https://github.com/pypa/pip/pull/6370 is merged into pip. Then the behavior of pip-option --no-use-pep517 will be to install requirements specified in a pyproject.toml and proceed with pre-pep517 installation using setup.py.
Possible Solutions
1.) Pipenv gets an equivalent to setup_requires in setup files or requires=[...] in pyproject.toml's [backend] section that is global or we use the existing one that is currently only used for python_version:
   [requires]
   python_version = "2.7"
   stwrapper = "*"

   [packages]
   ...

2.) Pipenv uses the system python's installation of stwrapper (I'm aware of the --site-packages option but that may have unwanted side effects).
3.) Specify a per-package requires, i.e.
[packages]
mypackage = { version="2.0.1", requires=['stwrapper', 'gitpython'] }

4.) Pass --no-use-pep517 to pip for certain packages (similar syntax to 3.) and use that feature in conjunction with pyproject.toml for these packages
[packages]
mypackage = { version="2.0.1", pip_options=['--no-use-pep517'] }

5.) Specify an order/priority of package installation, so that the dependency is fullfilled when the dependent package is being installed/
Scope
I guess the problem applies to all projects that use non-standard-libaray packages in their setup.py files and/or use setuptools entry points to modify its behavior. You can not put such dependencies in the Pipfile, because they are needed for successfully locking.
Related Issues

https://github.com/pypa/pipenv/issues/2274
https://github.com/pypa/pip/pull/6370
https://github.com/pypa/pipenv/issues/1760

The canonical way is to fix packaging metadata in package-that-uses-stwrapper-in-its-setup-py (in other words, the package maintainers should be responsible to fixing this, not the packaging tools).
I believe the canonical way now is to enable build isolation (PEP 517), and leverage against PEP 518 (which is available in pip 19.x):
[build-system]
requires = ['setuptools', 'wheel', 'stwrapper']

Well but if you do a local install (pip install -e .), the package metadata is not accessible until the local setup.py is run. But it cannot be run, because in the virtual environment stwrapper is not yet isnstalled.

They are already implemented, and supported by pip and setuptools.

Okay, I just learned that the build-system solution, does not work in case of editable installs.
See PEP 517:

This PEP [517] originally specified another hook, install_editable, to do an editable install (as with pip install -e). It was removed due to the complexity of the topic, but may be specified in a later PEP.
Briefly, the questions to be answered include: what reasonable ways existing of implementing an 'editable install'? Should the backend or the frontend pick how to make an editable install? And if the frontend does, what does it need from the backend to do so.

Passing options down to pip like this
[dev-packages]
mypackage = { path = ".", editable = true, pip_options=["--no-use-pep517"] }

seems to have been discussed here https://github.com/pypa/pipenv/issues/287

I wonder if this can be fixed more simply by passing --no-use-pep517 during the retry phase of installation.

Since https://github.com/pypa/pip/pull/6370 will implement a editable mode is not supported for pyproject.toml-style projects [...] you may pass --no-use-pep517 [...] for pip, Pipenv could look for that output and retry with --no-use-pep517. I so no reason not to.

@techalchemy What do you think about this, should the change require a PEEP? I’ll submit a fix if that’s not necessary.

Any work done yet?

What is the current status of this issue?

The more I use pipenv, the more I'd like to pass pip-options on a per-package basis (i.e. no. 4 of my proposed solutions).
@uranusjr @kenneth-reitz @techalchemy @nateprewitt

This seems like a potential good idea.

Is there any progress here? When is the next release scheduled? At least this seems straight forward to implement:

Since pypa/pip#6370 will implement a editable mode is not supported for pyproject.toml-style projects [...] you may pass --no-use-pep517 [...] for pip, Pipenv could look for that output and retry with --no-use-pep517. I so no reason not to.

Btw. passing options down to pip generally seems to be a good idea because otherwise, locking fails on Windows for packages like pycurl, because they try to build but require some additional options (see: https://github.com/pycurl/pycurl/blob/master/setup.py#L388):
    def configure_windows(self):
        # Windows users have to pass --curl-dir parameter to specify path
        # to libcurl, because there is no curl-config on windows at all.
        curl_dir = scan_argv(self.argv, "--curl-dir=")
        if curl_dir is None:
            fail("Please specify --curl-dir=/path/to/built/libcurl")

I agree this would be a good idea, someone just needs to write up a proposal (if you've done this already just point me at it)
essentially there's no disagreement about whether this should exist, more just no clear picture of how it should look if we are going to implement it.  I don't have any particular uses for it so I would probably have a hard time designing the interface.  For instance, would it just be an additional key in the Pipfile entry? What would it say?
That would be outlined in a PEEP as a PR to the peeps/ directory with a new number just saying the basics and following the templates that some of the other enhancements in there have followed.  Just outline the desired behavior and how it should look, plus if there are any concerns or considerations that might make this hard to implement.  Ideally, we want this to solve as general a case as possible so we don't have to reimplement this a bunch of different ways
Hope that provides a good path forward on this

As I said, I'd be happy with something like this:
[dev-packages]
mypackage = { path = ".", editable = true, extra_pip_options=["--no-use-pep517", "--retries=10"] }

But I do not know whether it's consistent with how other things work in pipenv. Also I have no idea wow to write a PEEP properly. And there is the question of how to handle it if pipenv would pass an argument to pip and it's also specified in extra_pip_options. Should the extras overwrite pipenvs setting? Should it be the other way arround? Should we get an "overwriting pip option" error? Should we get an error and have the option to just "prefer extras"  or "prefere pipenv options"?


Documentation

People can't use this if it isn't documented ... gotta do some of that.

https://github.com/jolynch/mit-tab/wiki


ServiceFabric Issues with ASP.NET Core 2.0 - WebApp/WebAPI

I'm getting the following error for ServiceFabric when using an ASP.NET Core 2.0 WebAPP ?
Unhealthy event: SourceId='System.RA', Property='ReplicaOpenStatus', HealthState='Warning', ConsiderWarningAsError=false.
Replica had multiple failures in_Node_2 API call: IStatelessServiceInstance.Open(); Error = System.MissingMethodException (-2146233069)
Method not found: 'Void Microsoft.AspNetCore.Hosting.IWebHost.Start()'.
at Microsoft.ServiceFabric.Services.Communication.AspNetCore.AspNetCoreCommunicationListener.OpenAsync(CancellationToken cancellationToken)
at Microsoft.ServiceFabric.Services.Runtime.StatelessServiceInstanceAdapter.d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.ServiceFabric.Services.Runtime.StatelessServiceInstanceAdapter.d__14.MoveNext()

I hit the same issue and had to fall back into WCF - were you able to resolve this issue?

Yes, I to resolve use kestrel and aspnet core preview 3 (myget feed) the issue is the Start method had been removed by the aspnet core team, but they have since re-implemented it after I logged an issues with them about the breaking change which was unintentional.


Android 12(Api Level 31): TfLiteGpuDelegate Invoke: GpuDelegate must run on the same thread where it was initialized.

Hi, Guys.
After upgrade my android os to version 12, I use latest version of this plugin and I launch tflite in isolation.
It throws this error:
TfLiteGpuDelegate Invoke: GpuDelegate must run on the same thread where it was initialized.
E/tflite  (20055): Node number 64 (TfLiteGpuDelegateV2) failed to invoke.
E/flutter (20055): [ERROR:flutter/runtime/dart_isolate.cc(1111)] Unhandled exception:
E/flutter (20055): Bad state: failed precondition
E/flutter (20055): #0      checkState (package:quiver/check.dart:74:5)
E/flutter (20055): #1      Interpreter.invoke (package:tflite_flutter/src/interpreter.dart:150:5)
E/flutter (20055): #2      Interpreter.runForMultipleInputs (package:tflite_flutter/src/interpreter.dart:190:5)
E/flutter (20055): #3      Classifier.predict (package:myai/ai/tflite/mobilenet/object/classifier.dart:179:19)
E/flutter (20055): #4      IsolateHelper.entryPoint (package:myai/ai/helper/isolate_helper.dart:51:30)
My code:
final gpuDelegateV2 = GpuDelegateV2(
    options: GpuDelegateOptionsV2(
      isPrecisionLossAllowed:true,
      inferencePreference:TfLiteGpuInferenceUsage.preferenceSustainSpeed,
     inferencePriority1:TfLiteGpuInferencePriority.minMemoryUsage,
      inferencePriority2:TfLiteGpuInferencePriority.auto,
      inferencePriority3:TfLiteGpuInferencePriority.auto,
    )
);
var interpreterOptions = InterpreterOptions()..addDelegate(gpuDelegateV2);
_interpreter = interpreter ??
   await Interpreter.fromAsset(
       MODEL_FILE_NAME,
        options: interpreterOptions
    );
Anyone faced such problem? Any suggestions how to fix it?

Haven't tried the GpuDelegate yet but it sounds like some issue related to isolates. Isolates in flutter cannot communicate with one another, i.e. they are stateless. If you launch your inference in an isolate different from the main thread, it won't have access to the GpuDelegate.
Either you register the delegate with the other [inference] isolate or try to establish communication towards the GpuDelegate on the main thread (probably hard). There exists this plugin for communication between isolates: https://pub.dev/packages/isolate_handler
Good luck!

@tahesse  Thanks for your reply. I fixed it, I reduced the target sdk version to older version, it works fine, on the latest version does not work. I used isolates but on new version it requires the instances of tensorflow and app should be in same thread. What do you think on new Android 12 is it bug or not?

Tbf, I haven't tested it with the newest version. At this point, I'm not sure if the library is still maintained.

Has someone solved the problem?
TfLiteGpuDelegate does not work for me in Android 12, in previous versions it works fine for me, the problem is that Google Play will require that apps target API level 31 (Android 12) or higher.


Gs threshold arted

(1) Convergence threshold of GS calculation was applied to ARTED side. The keyword "convergence" already prepared by GCEED side got to be available now in ARTED side. Then, new option, convergence="rho_dne" was introduced (as default: density difference divided by electron number, same as Octopas software). After this merge, the "rho_dne" option is going to be implemented also in GCEED side. (These changes are based on discussion with Noda-san and IMS members).
The other small changes are
(2) addition of subroutine to check bad/unavailable input keywords/options combination. Currently only one thing is added. I recommend developers to add the bad input combinations to be user friendly software.
(3) tiny change of format of standard log to be better looking.

Thank you for your contribution, @ayamada224 san.
I checked that the "rho_dne" mode works properly and reproduces previous results in ARTED part.
So I approve this pull request.


Sporadically get KeyError: 'user' for send message client

Description
Hi All,
I have a simple slack bot that lets the folks in the office know if the bathroom is in use through a simple controller circuit on a breadboard. I do get an error as follows:-
Traceback (most recent call last):
  File "sendMessage.py", line 33, in <module>
    apiCall(content)
  File "sendMessage.py", line 14, in apiCall
    channel=message["user"],
KeyError: 'user'

I've been trying to recreate the error but I've been unable to. Sometimes it happens within the first few minutes of execution, at other times it occurs days later. I'm even questioning if this is a real error or if it's a figment of my imagination.
What type of issue is this? (place an x in one of the [ ])

[ ] bug
[ ] enhancement (feature request)
[x] question
[ ] documentation related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Bug Report
Filling out the following details about bugs will help us solve your issue sooner.
Reproducible in:
slackclient version: uncertain
python version: python 3
OS version(s): Debian for raspberry pi
Steps to reproduce:

Expected result:
smooth runtime without error, and happy bathroom goers
Actual result:
Sporadically crashing script, and bathroom goers being more pissed than they intend to get.
Attachments:
Logs, screenshots, screencast, sample project, funny gif, etc.
from sense_hat import SenseHat
from time import sleep
from gpiozero import Button
import random
sense = SenseHat()

red = (255, 0, 0)
green = (0, 255, 0)
blue = (0, 0, 255)
yellow = (255, 255, 0)
black = (0,0,0)
white = (255, 255, 255)
arr = [red, blue, green, yellow, white]
message = "Occupied"

speed = 0.03

button = Button(21)

while True:
    while button.is_pressed
         # Define some colours
        B = (102, 51, 0)
        b = (0, 0, 255)
        S = (205,133,63)
        W = (255, 255, 255)

        # Set up where each colour will display
        steve_pixels = [
        B, B, B, B, B, B, B, B,
        B, B, B, B, B, B, B, B,
        B, S, S, S, S, S, S, B,
        S, S, S, S, S, S, S, S,
        S, W, b, S, S, b, W, S,
        S, S, S, B, B, S, S, S,
        S, S, B, S, S, B, S, S,
        S, S, B, B, B, B, S, S
        ]

        # Display these colours on the LED matrix
#Colour style config: steve
        sense.set_pixels(steve_pixels)

    sense.clear()

from gpiozero import Button
import time
import json
import re
from slackclient import SlackClient

button = Button(21)

slack_client = SlackClient("xoxb-YeOldSlackKey")
user_list = slack_client.api_call("users.list")

def apiCall(content):
    slack_client.api_call("chat.postMessage",
                          channel=message["user"],
                          text=content,
                          as_user=True)

for user in user_list.get('members'):
    if user.get("name") == "peebot":
        slack_user_id = user.get("id")
        break

if slack_client.rtm_connect():
    while True:
        while button.is_pressed:
            for message in slack_client.rtm_read():
                if "text" in message and message["text"].startswith("<@%s>" % slack_user_id):
                    content = "Someone is in the shower toilet"
                    apiCall(content)
        for message in slack_client.rtm_read():
            if "text" in message and message["text"].startswith("<@%s>" % slack_user_id):
                content = "The shower toilet is free"
                apiCall(content)

It doesn't look like message is being passed into apiCall
Try passing it into that method
def apiCall(message, content):
    slack_client.api_call("chat.postMessage",
                          channel=message["user"],
                          text=content,
                          as_user=True)

and calling it with both items, like so:
apiCall(message, content)

Thanks @Roach , Will give it a whirl today and let you know what becomes of it today.

Hi @Roach, just tried your suggestion, and got 3 errors from running and monitoring it over a period of just over an hour, (like an hour and 15 minutes) and I got 3 different errors:
First: ndMessage.py Fatal Python error: Inconsistent interned string state. Aborted
Second: segmentation fault
Third: "Traceback (most recent call last)":
File "sendMessage.py", line 34, in
apiCall(message, content)
File "sendMessage.py", line 15, in apiCall
channel=message["user"],
KeyError: 'user'
I'm still lost on the first anf the 3rd error.

@Malcolm-Movement did you ever figure this out? I wasn't able to reproduce in my test app 🤔

No Actually, plus the project was tabled for a while since the christmas rush kicked in unfortunately. Might get the chance to look at it again in December. Will update you then.

Does anyone encounter this issue with v2.x series? If not, please allow me to close this issue after waiting for responses for a few weeks. We're no longer actively working on the v1.x series. We appreciate your understanding. 🙇

As this project hasn't been actively supporting v1 for a while, please allow us to close this issue now.
The current latest stable version is v2.9.3. Here is the migration guide to v2 series. Also, we're going to release v3 soon: https://slack.dev/python-slack-sdk/
Both newer major versions should provide more stable implementation for this use case. It'd be appreciated if you could try newer versions. We hope the newer version resolves your issue.


[SR2022]: 2022-02-03 Competition date announcement

Body
todo
Media
No response
Category
Current Comp Cycle News

Lets get ready to robot! The official dates for our competition are out now. #srobo #stem #srobo2022 #robotics
For more information: https://studentrobotics.org/events/sr2022/competition/

Replaced event link with blog link


[Bug] Error JsonSchema import output

Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
The json schema file a.schema.json
{
    "$id": "https://example.com/monaco.manifest.schema.json",
    "$schema": "https://json-schema.org/draft/2020-12/schema",
    "title": "Dynatrace Monitoring as Code Manifest File",
    "type": "object",
    "properties": {
        "manifestVersion": {
            "type": "string",
            "description": "The schema version this manifest conforms to - e.g. 1.0"
        },
        "projects": {
            "type": "array",
            "description": "The projects grouped by this manifest",
            "items": {
                "type": "object",
                "properties": {
                    "name": {
                        "type": "string",
                        "description": "The name of this project"
                    },
                    "type": {
                        "type": "string",
                        "description": "Optional Type of this project. Default: Simple",
                        "oneOf": [
                            {
                                "const": "simple",
                                "description": "A simple project, directly containing configuration. Default."
                            },
                            {
                                "const": "grouping",
                                "description": "A grouping project, containing several sub-projects."
                            }
                        ]
                    },
                    "path": {
                        "type": "string",
                        "description": "Optional filepath of the project relative to the manifest.yaml location. Defaults to name"
                    }
                },
                "required": [
                    "name"
                ]
            }
        },
        "environmentGroups": {
            "description": "The Environment groups to which projects in this manifest are deployed",
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "name": {
                        "type": "string",
                        "description": "The name of this environment group"
                    },
                    "environments": {
                        "description": "The environments in this group",
                        "type": "array",
                        "items": {
                            "type": "object",
                            "properties": {
                                "name": {
                                    "type": "string",
                                    "description": "The name of this environment"
                                },
                                "url": {
                                    "description": "The URL of this environment",
                                    "type": "object",
                                    "properties": {
                                        "type": {
                                            "description": "Optional Type of URL definition.",
                                            "type": "string",
                                            "oneOf": [
                                                {
                                                    "const": "value",
                                                    "description": "URL directly defined in the 'value'. Default."
                                                },
                                                {
                                                    "const": "environment",
                                                    "description": "URL defined by an environment variable name in 'value' to read from."
                                                }
                                            ]
                                        },
                                        "value": {
                                            "type": "string",
                                            "description": "The value of the URL, based on type either an URL or environment variable name"
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
    },
    "required": [
        "manifestVersion",
        "projects",
        "environmentGroups"
    ]
}

2. What did you expect to see? (Required)
The right KCL schema output
3. What did you see instead (Required)
"""
This file was generated by the KCL auto-gen tool. DO NOT EDIT.
Editing this file might prove futile when you re-run the KCL auto-gen generate command.
"""

schema MonacoManifestSchema:
    """
    MonacoManifestSchema

    Attributes
    ----------
    manifest_version : str, required
        The schema version this manifest conforms to - e.g. 1.0
    projects : [items], required
        The projects grouped by this manifest
    environment_groups : [items], required
        The Environment groups to which projects in this manifest are deployed
    """

    manifest_version: str
    projects: [items]
    environment_groups: [items] # items is not defined.

schema Url:
    """
    The URL of this environment

    Attributes
    ----------
    type : str, optional
        Optional Type of URL definition.
    value : str, optional
        The value of the URL, based on type either an URL or environment variable name
    """

    type?: str
    value?: str

4. What is your KCL components version? (Required)

KCL v0.7.0 version

This issue can be aligned with the implementation in the kcl-lang/kcl-openapi repo. Here is an example:

This issue can be aligned with the implementation in the kcl-lang/kcl-openapi repo. Here is an example: [image]

👌 I will fix it soon


Feedback: threaten.md

"march down" "march down"
Capitalization
Y/Y
You don't have any links out of this room.

You fixed the wrong capitalization. Now you have two issues! :dizzy_face:


Fix permission denied when running hach/release.sh

The nightly release is failing with permission denied error when running ./hack/release.sh
Proposed Changes

Fix permission denied on hach/release.sh
chmod +x ./hack/release.sh

/lgtm
/approve


[Agenda Item] Engagement across regions

Overview:

Are there any ways we can increase engagement in new geographies?

Related topic: The type of agenda item you want to propose.

[ ] Governance: New project
[ ] Governance: Other
[ ] Process
[x] External Engagement
[ ] Technology
[ ] Other

Related working groups:

[x] Community
[x] Open Source
[x] Policy
[x] Standards
[x] Oversight Committee

Related issues or discussions:
Please list all related issues so that we can see the originating conversation, e.g. #10 or https://github.com/Green-Software-Foundation/discussions/discussions/5
More information:

Could we run shorter 15 minute sessions for say asia pacific, or ask people to input into the agenda beforehand?

Main thing I’m thinking was to run short meetings for the area with less engagement, e.g. Asia pacific/europe timezones, the day before or after
Let the bulk of people dictate the biggest meeting

This has been added to the new onboarding form so this issue can be closed: https://greensoftware.foundation/onboarding/

@adamj89 - Recommends additional meet up groups - review gaps and recommendations with new project manager.


add login page

login page for users.

@aashkaaaaaa
Thank you for raising this issue. I've reviewed it, and it seems that no further action is needed at the moment. If you have any additional issues, feel free to reach out. To keep our issue tracker organized, I will be closing this issue.


Show legend in viewer

For example, what colors correspond to what score

This has long stayed in the back of my mind.
It would be easily done by adding the colorbar as a separate element.
For example, predictions could have their colorbar, model differences would have their own, etc, and depending on the choice, the colorbar would update with the appropriate one.
If you have a better alternative, let me know :D.


Auto Build Marlin - command not found: platformio

I am new to compiling my own firmware. I am now trying to build Marlin <IP_ADDRESS> for the SKR Mini E3 V1.2 using the custom configuration supplied by the Marlin GitHub. I have used VSCode to compile Marlin versions 2.0.7 and <IP_ADDRESS> for the same board. Both compiled beautifully using the Auto Build Marlin and the Platformio plugins. I am doing the same thing as before but now I keep receiving this error:
platformio run -e STM32F103RC_btt_512K ; echo "done" >/var/folders/08/p81zkj6x7l7gq17dsxv4pxrh0000gn/T/ipc
stevewise@Steves-MacBook-Pro Marlin-2.0.x % platformio run -e STM32F103RC_btt_512K ; echo "done" >/var/folders/08/p81zkj6x7l7gq17dsxv4pxrh0000gn/T/ipc
zsh: command not found: platformio
stevewise@Steves-MacBook-Pro Marlin-2.0.x %
I have uninstalled everything and reinstalled several times with no success. I was able to get a successful build by going into project tasks in Platformio and doing the build from there. I apologize in advance if I am doing something stupid but I can't figure out what is wrong. I have searched the internet but with no success. Thanks for your help.

Same problem!
echo "done" >/var/folders/kh/9r2ycv7921lgg6q7t7twmsym0000gn/T/ipc
zsh: command not found: platformio

I have also noticed this error when doing the update in PlatformIO.
Updating platformio/contrib-pysite            2.38.201019 @ ~2.38.0              [Incompatible 2.39.201019]
I removed the folder ".platformio/penv" and then updated again but with the same error. Not sure if this helps.

I just got the same message! There must be a problem with the new update of platform.io...

Anyway I can build and upload. Sometimes is not uploading fine but repeating the process it works.
You have to go to the left vertical menu and click on the Platformio icon, then choose the file, in may case is env:melzi_optimized, @slwise in your case should be env:STM32F103RC_btt_512K. Click it and you will see below it build, upload and more options.
I hope this will help!

Anyway I can build and upload. Sometimes is not uploading fine but repeating the process it works.
You have to go to the left vertical menu and click on the Platformio icon, then choose the file, in may case is env:melzi_optimized, @slwise in your case should be env:STM32F103RC_btt_512K. Click it and you will see below it build, upload and more options.
I hope this will help!

This seems like a question for the platformio extension/team https://github.com/platformio/platformio-vscode-ide/issues


(PUP-3774) Use gpasswd when making group membership changes in a user resource

Previously, the useradd provider would set all of a user's groups at
once using usermod. This had a couple of problems when a user came
from a non-local PAM source

The user could potentially not exist in /etc/passwd. This would
simply cause usermod to fail.

The user could be in a group that's not considered valid by the
usermod command (especially a group that contains a space in its
name).

The new implementation uses gpasswd to modify the user/group
mappings only as needed. This means Puppet will completely ignore any
existing groups when adding a user to a new group, and will be able to
modify local group mappings even if the user comes from a different
PAM source.
Validation will still fail if Puppet is asked to make changes to a
user/group mapping when the group has spaces in it, as that is not a
valid operation with gpasswd (no local group would have such a name)

Typo in the commit f8324ad subject, should be PUP-3774

@joshcooper bah. Fixed

CLA signed by all contributors.

Needs to be retargeted at either 4.10.x, 5.3.x, or master


Generate parameters from yaml

Signed-off-by: Tyler Weaver<EMAIL_ADDRESS>Here is a minimal conversion to using generate_parameter_library for parameters. I didn't use any of the functionality for validation but this can easily be added.

Is there a way to add a generic namespace here that can be determined at runtime? The parameters for IK plugins actually come in the form robot_description_kinematics.<group_name>.<param_name> (i.e. for the panda arm, the solver mode is robot_description_kinematics.panda_arm.mode, so none of the parameters here are actually being retrieved from kinematics.yaml.
btw, sorry for the delay on this--been pulled into a lot of debugging recently.

I think that is a misuse of namespaces and a poorly designed interface. Is there a reason you might have multiples of bio_ik in the same ros node that need to have separate namespaces for the parameters?
Remember that in ROS 2 parameters are per-node and not part of some global parameter server.

We'd need to make that change in MoveIt then, as it reads kinematics.yaml and sets those parameters.
The only possible use case I can think of is computing IK for multiple arms simultaneously, but if they're a part of the same group then you'd only need one bio_ik instance.


[BUG] Inconsistent Node Driver Population in Rancher v2.7.3 with k3s Cluster Leading to rke2 Installation Failures

Rancher Server Setup

Rancher version: 2.7.3
Installation option: Helm Chart

Kubernetes Cluster and version: k3s (v1.25.9+k3s1)

Information about the Cluster

Kubernetes version: v1.25.9+k3s1
Cluster Type: Local (HA 2 Nodes with MySQL)

User Information

Role of the user logged in: Admin

Describe the bug
When activating a node driver, the driver is not consistently populated to all nodes under <rancherdomain>/assets/*. Refreshing the /assets/* path sometimes shows all activated drivers, and sometimes they are missing. This issue leads to rke2 installation failures if the installation hits the incorrect node four times, causing the job installing the nodes to fail.
To Reproduce

Install k3s and Rancher following the official documentation. (setup lb)
Activate the OCI node driver.
Navigate to <rancherurl>/assets/.
Press F5 to refresh the page; the docker-machine-driver-oci is sometimes present and sometimes not.

Result
The node drivers are not consistently published to /assets/* on every node.
Expected Result
The node drivers should be published to /assets/* on every node consistently.
Additional context
The issue is not exclusive to the OCI driver; the Hetzner driver has the same problem. Other drivers have not been tested.

We're seeing same issue with Nutanix Custom Node Driver and have documented findings in following issue which was discovered last August on Rancher 2.6.6 - https://github.com/rancher/rancher/issues/38481#issuecomment-1540893657


Open azure bot resource modal

@luhan2017 please confirm PR with @benbrown to ensure that template selection screen logic is acceptable before merging to main please.

Original design

Original dialog issue is here: https://github.com/microsoft/BotFramework-Composer/issues/7230


Add config option to customise the distance between particles

Hello,
I have a server, and I use WESV to see what I'm selecting with WorldEdit.
However, one of my friend use MCPE, so I also use Geyser. The problem is that there are too many particles for the selection viewing, so his game is crashing when he try to select something.
What I want is to be able to change the amount of particles, with a command or a config file.
Thanks in advance

This is a good idea!  I'll implement it when I get some time.

I never worked with Java (and I still don't know how Git works..), but I will try!

I watched your code, I might be able to fix the problem by myself (if I understand how I'm supposed to compile, Gradle isn't really user-friendly).
What have to be done :

Modification of your particle library
Modification of the plugin

As soon as I'm on my computer I'll clone both repos to try.


Support breaking changes to the Projects API preview

GitHub Announcement:
https://developer.github.com/changes/2017-09-01-breaking-changes-to-projects-api-preview-and-webhooks-date-format/
To resolve this issue, it appears that unit tests will need to be updated for the time parsing functions that process webhook payloads. It is possible that the new format is already supported, but it is more likely that the parsing format needs to be changed slightly.
I personally think that it might be nice to support both formats (old and new) in the code base with a "TODO" to remove support for the old format once it is no longer being sent by GitHub, but this is completely up for discussion and I don't have my heart set on this. (One nice serendipity of this would be that no breaking changes would be made to the API.)
Thank you in advance for contributing to this open source project!
Your assistance is greatly appreciated.

"TODO" to remove support for the old format once it is no longer being sent by GitHub

But GitHub only sends at most one format at a time, never both. We can opt-in to the new format earlier by using a preview header. The date the list is when the old format will stop being available and will become the default even without the preview header.
So if you want to to support old format while having the new format, we'd have to compute the old one locally.
I'd prefer a more instantaneous change. People will need to change their code eventually regardless. If they want to wait, they can use an older version of go-github for a while longer. There's very little benefit in allowing people to use old format with latest version of go-github, it just delays the inevitable.

If I understand correctly, GitHub is only changing the format of their webhook timestamps... and our API returns time.Time anyway, so I'm thinking/hoping that no API from a Go standpoint will be broken... but I could be wrong.

Ah, indeed. We're likely using our Timestamp type that handles both.
That's great, lucky us! :)

Great! Please assign to me.

Interestingly, the created_at and updated_at fields for Projects are populated in exactly the same way as for timestamps in the rest of the API. Perhaps for this reason, there is no test covering the irregular timestamp format.
I'll add a unit test covering the timestamp format after the change, although, logically, it shouldn't make any difference, because all the timestamp logic is handled by the json package right here:
https://github.com/google/go-github/blob/12126fbfe000a09047ebdeb2b5160be3af88ab9e/github/github.go#L458

@e-beach You're probably already aware, but we already have some unit tests for Timestamp type in timestamp_test.go file, so that's where new unit tests would go. Thanks. :)

I was ignorant, thanks!

The revised timestamp format is already covered by the tests in timestamp.go:
https://github.com/google/go-github/blob/12126fbfe000a09047ebdeb2b5160be3af88ab9e/github/timestamp_test.go#L15-L19
Based on this, I don't believe any changes to code/tests need to be made to cover the change.
We could add a test to cover the format currently returned by the Projects API, which contains milliseconds, e.g.,"2017-08-24T15:56:15.000Z".

The revised timestamp format is already covered by the tests in timestamp.go ... Based on this, I don't believe any changes to code/tests need to be made to cover the change.

Sounds good. Thanks!

We could add a test to cover the format currently returned by the Projects API, which contains milliseconds, e.g.,"2017-08-24T15:56:15.000Z".

That sounds like an improvement. Want to send a PR for that? Mention in the test case where the value comes from (in this case, some Projects API endpoint).

I know this is a closed issue, but just for completeness, I wanted to include the latest GitHub Developer's API announcement:
https://developer.github.com/changes/2017-10-02-breaking-changes-to-projects-api-preview-and-webhooks-date-format/
Once again, this should not affect anything.
Carry on.  :smile:


Custom filter lambda

Here's an implementation following #526.
In brief, this allows for the following syntax instead of overriding apply_filter on a resource.
filter :custom, with: -> (records, value) { records.custom(value) }

Based on the feedback from that issue, there are a couple things which may still need to be addressed.

[x] Consider renaming the :with option to :apply
[x] Consider adding an additional option for a :verify lambda

@iamvery I like your two suggestions. I think adding the :verify lambda makes sense, and if we have that then renaming the :with lambda to :applyseems most consistent.

:+1: I have a very similar feature implemented in a Concern for my resources, it results in more readable code than the standard apply_filter way

Alright, I've updated the PR, addressing the two above tasks. I'm not sure how I feel about the :verify option. I think that's somewhat due to having not even known about it before. I noticed it's not covered in the readme. The interface for that method (and specific return value) makes it feel internal to me.
What do you think of the code here?

@iamvery Thanks for doing this. I'm not sure how I feel about the :verify option either. I don't like the format of the specific return, and it seems like we should allow for verify on relationship filters as well. I'll see if I can refactor the underlying code into something better and maybe the new filter option will then be cleaner.

I added the filter_verify branch (https://github.com/cerebris/jsonapi-resources/tree/filter_verify) with some changes that I think simplify the verify option a bit and will still be backwards compatible. Let me know what you think.

Looks good! I think I'll take a closer look and try rebasing those changes into the PR for continuity. Does that sound good? (might be a bit before I can roll that in)

@iamvery I could just create a PR which would pull both sets of changes in if you are good with that. That should be the easiest solution.

I added a few comments to commits on your branch. Hopefully I'm not overstepping by taking on this code review style. 😯

Hopefully I'm not overstepping by taking on this code review style.
Not at all. In fact I appreciate the comments and extra review.

Should I go ahead and close this in favor of #555?


mingw: no-comp option breaks build (tested with 1.0.2e and 1.1.0-pre1/pre2)

1.0.2e
mingw32-make[4]: Entering directory 'C:/w/openssl'
Cannot export COMP_CTX_free: symbol not defined
Cannot export COMP_CTX_new: symbol not defined
Cannot export COMP_compress_block: symbol not defined
Cannot export COMP_expand_block: symbol not defined
Cannot export COMP_rle: symbol not defined
Cannot export COMP_zlib: symbol not defined
Cannot export COMP_zlib_cleanup: symbol not defined
Cannot export ERR_load_COMP_strings: symbol not defined
collect2.exe: error: ld returned 1 exit status
Makefile.shared:279: recipe for target 'link_a.cygwin' failed
mingw32-make[4]: *** [link_a.cygwin] Error 1
mingw32-make[4]: Leaving directory 'C:/w/openssl'

Live log:
32-bit
64-bit
1.1.0-pre1 and 1.1.0-pre2
mingw32-make[4]: Entering directory 'C:/w/openssl'
Cannot export COMP_CTX_free: symbol not defined
Cannot export COMP_CTX_get_method: symbol not defined
Cannot export COMP_CTX_get_type: symbol not defined
Cannot export COMP_CTX_new: symbol not defined
Cannot export COMP_compress_block: symbol not defined
Cannot export COMP_expand_block: symbol not defined
Cannot export COMP_get_name: symbol not defined
Cannot export COMP_get_type: symbol not defined
Cannot export COMP_zlib: symbol not defined
Cannot export COMP_zlib_cleanup: symbol not defined
Cannot export ERR_load_COMP_strings: symbol not defined
collect2.exe: error: ld returned 1 exit status
Makefile.shared:268: recipe for target 'link_a.cygwin' failed
mingw32-make[4]: *** [link_a.cygwin] Error 1
mingw32-make[4]: Leaving directory 'C:/w/openssl'

Live log:
32-bit
64-bit

Problem remains in OpenSSL 1.1.0-pre2.

Problem appears valid (and even a potentially important one), but doesn't seem to be picked up by devs, so closing.

please re-open; a week is not a long time.

Thanks for pinging in! Reopened.

If compression will be disabled by default in 1.1.0, this Issue seems unimportant.

yes, i guess you're right.  sorry for the churn.  thanks for your patience.


Code Ticket pages (order & thank you page)

create components for ticket pages
create and place components in line with design

3 Aug: Issue closed


Refresh Contributors every Week

Currently, we download the list of contributors for the credits once (and then never again). That should change, the logic here should also save when the contributors list was downloaded - and fetch it again, if it's too old.

Would it be easier to ship this (like Ghost core) as a static list, when built?

Think I agree with John here. We can just keep that list of contributors saved into a JSON file that's rebuilt on major/minor version changes.

Seems sensible to me.

I have an almost working version of this. Just trying to work out some broken tests.

If you're not already, it's probably worthwhile to use the exact same process as used in the main Ghost project for this. We have an npm package to pull the contrib metadata as part of the build process.


Add Supports for Custom Labels for all signoz defined services

Added Support for Custom Labels, so users can add labels as per requirements, Intended to fixes #395 .

@weastel Thanks for the PR contribution 🎉


Dev setup

Add icons for various supported ides
Add file loader to assets to display
Use webpack-dev-server with live reloading in dev mode for faster development experience
Convert main process to be trans-piled via webpack

Let's remove all *-light.png files.
👍


Uncaught TypeError: _this.notificationEl.querySelector is not a function

[Enter steps to reproduce:]

...
...

Atom: 1.17.2 x64
Electron: 1.3.15
OS: Ubuntu 16.04.2
Thrown From: particle-dev package 0.1.21
Stack Trace
Uncaught TypeError: _this.notificationEl.querySelector is not a function
At /home/leo/.atom/packages/particle-dev/node_modules/atom-package-deps/lib/view.js:22

TypeError: _this.notificationEl.querySelector is not a function
    at /packages/particle-dev/node_modules/atom-package-deps/lib/view.js:22:58

Commands
     -1:43.7.0 core:confirm (input.hidden-input)
  3x -1:25.7.0 core:backspace (input.hidden-input)
     -1:23.4.0 core:confirm (input.hidden-input)
 19x -1:08.6.0 core:backspace (input.hidden-input)
     -1:04.1.0 core:confirm (input.hidden-input)
     -0:09.3.0 particle-dev:append-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
     -0:09.3.0 particle-dev:update-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)
     -0:09.3.0 particle-dev:append-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-dark-syntax.theme-one-dark-ui)

Non-Core Packages
console-panel 0.2.1
particle-dev 0.1.21
particle-dev-complete 1.0.1
tool-bar 1.1.0

I get this error when I try to install the linter-gcc package for Atom.

This might be caused by an old version of atom-package-deps package. We'll update it and release the packages using it.

We've updated this dependency. @bu5hm4nn does this issue persist?

@suda Unfortunately it does persist. I can install linter-gcc but when I reopen Atom the error pops up again.

Could you paste the contents (including the stacktrace) of the error here? The sources mentioned in the original issue shouldn't exist anymore.

[Enter steps to reproduce:]

Install particle-dev
Install linter-gcc

Atom: 1.18.0 x64
Electron: 1.3.15
OS: Mac OS X 10.12.5
Thrown From: particle-dev package 0.1.23
Stack Trace
Uncaught TypeError: _this.notificationEl.querySelector is not a function
At /Users/Nethanja/.atom/packages/particle-dev/node_modules/atom-package-deps/lib/view.js:36

TypeError: _this.notificationEl.querySelector is not a function
    at /packages/particle-dev/node_modules/atom-package-deps/lib/view.js:36:62

Commands
     -0:16.9.0 particle-dev:update-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-light-syntax.theme-one-light-ui)
     -0:16.9.0 particle-dev:append-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-light-syntax.theme-one-light-ui)
     -0:16.8.0 particle-dev:update-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-light-syntax.theme-one-light-ui)
     -0:16.8.0 particle-dev:append-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-light-syntax.theme-one-light-ui)
     -0:16.8.0 particle-dev:update-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-light-syntax.theme-one-light-ui)
     -0:16.8.0 particle-dev:append-menu (atom-workspace.workspace.scrollbars-visible-always.theme-one-light-syntax.theme-one-light-ui)

Non-Core Packages
atom-beautify 0.30.3
console-panel 0.2.1
language-particle 0.3.5
linter-gcc 0.7.1
particle-dev 0.1.23
particle-dev-cloud-functions 0.1.1
particle-dev-cloud-variables 0.1.1
particle-dev-complete 1.0.2
particle-dev-libraries 0.2.19
particle-dev-profiles 0.2.1
particle-dev-release-notes 0.53.2
tool-bar 1.1.0

Hmm I did a fresh install of particle-dev packages, then installed linter-gcc and got Uncaught TypeError: _this.notificationEl.querySelector is not a function but originating from linter-gcc. It seems to be a known issue and I created a PR that should fix it. Until then you can first install linter package in Atom/Particle Dev App to make this message go away.


Add license header to files

Updated the PR.
CC: @soccerGB @ionutbalutoiu

This PR is good to go. It adds the Microsoft Apache2 license header to some files missing this.


fix(history): back button with preventDefault in $stateChangeStart causes history to be overwritten #1525

preventDefault() in the event $stateChangeStart causes history to be overwritten when the back button is clicked #1525
Fixed by changing the update routine for 'defaultPrevented' updates. The update trigger now uses a string instead of a bool argument to distinguish 'read', 'defaultPrevented' and normal update events.
When using the back button is this scenario the $location.url(location) method is omitted so the history does not get overwritten anymore. The orginal scenarios ar not effected by this fix.

The file  release/angular-ui-router.js contains changes generated by grunt. As this is a generated file, these changes can of course be ommited. the src files refelect the changes and seem to be working with every test I did. The previous and next buttons seem to be working very well now. I hope these changes get accepted.

When using prteventDefault() in $stateChangeStart, a back navigation caused an update trigger which caused the history to be overwritten by $location.url(location). The trigger already knew that $stateChangeStart was defaultPrevented but the update trigger did not distinguish this event from the normal update where 'read' was false.
I changed the boolean in the update trigger to a string argument so the 'defaultPrevented' update trigger can be distinguished from a 'read' or normal trigger. All seems to be working as should.
I updated the documentation of the source

I'm not seeing a test that fails against the existing code to actually prove the issue.

Also, this PR is pretty messy, even aside from the changes to build files: http://prjs.radify.io/#/angular-ui/ui-router/pulls/2835

Ok, I will add the test which will prove the existing code is failing. Also I will cleanup this pr.
The issue is very clear. When using event.preventDefault in $stateChangeStart, the history gets overwritten when using the back button. So only back navigation is working and forward navigation gets disabled because of this.
This fix, fixes this and back and forward navigation will work as intended


Gave errors - Module not found: Error: Can't resolve './additions' upon module bundling

I was trying to make your package work with angular and faced problems.
Please see initial discussion at stackoverflow.
I saw another issue in your repo which was related to webpack, which you said you will take a look later. It might fix that issue as well, since angular uses webpack.
I and a friend from reddit community tried and arrived at this fix (basically he found the fix)
My repo is now working with angular 9 (latest version). I am familiar with angular but the fix was done by another community user. will you please pull my repo and take a look.
Awesome work.
Looking forward for the fix.

I am adding his comments and highlighting what may be relevant to you.
I included citation.js in the angular.json file so citation would be included as an asset and not compiled with typescript. Can we make the package compile with Typescript.
On the component I used window.require instead of an import or plain require again because I didn't want typescript trying to compile citation-js. I saw at the top of citation.js it included an implementation of require.
Those were the two necessary changes to get it working. I also used async and await because angular will complain in the console if you don't. I assigned output to document.body.innerHTML so you can see the rendered results instead of seeing html in the console.

I saw at the top of citation.js it included an implementation of require.

That is probably an artifact of Browserify, which I use to make browser builds, so I think only one of the two points has to be solved?

Can we make the package compile with Typescript?

I would love that, but I don't really know much about Typescript (or Angular). The JSON problem seems to solved on StackOverflow but you mention some other issues. What else is going wrong?

I also used async and await because angular will complain in the console if you don't.

Fetching web resources synchronously requires a synchronous XMLHttpRequest, which are deprecated. I think the browser was complaining about that? Anyway, there's not much I can do about that. There's probably some way to run asynchronous code in Angular in a nicer way, right?

Bottomline is that it does not play well with Typescript compiler. It is not an issue related to the package. Just that people have to jump some hoops to get it working.
async-await are pretty common these days. No worries at all. The stack-overflow post was created before I wrote to you. I modified the stack overflow post as following:

citation-js package however has been developed with Browserify and does not like Typescript compiler. It does not play well with Webpack, which is the default bundler for Angular. So to use it with angular:
On the component I used window.require instead of an import or plain require again because I didn't want typescript trying to compile citation-js. I saw at the top of citation.js it included an implementation of require, which may be a browserify artifact. So bottomline is disable typescript compilation by including it in the assets.

You may close this issue.


Geo add expandable results

Add an expandable table column to the execution window to allow users to check the execution result sample row

Under each row, there should be another expandable sub-tables based on the number of the sink the execution has

Each "view result" component will have one sample row and the number of rows count as the visible information

Add an expandable table column to the execution window to allow users to check the execution result sample row

Under each row, there should be another expandable sub-tables based on the number of the sink the execution has

Each "view result" component will have one sample row and the number of rows count as the visible information

@zuozhiw and @Xiao-zhen-Liu can you please provide your reviews on this PR?

please test if mysql has the collection name but it is already deleted from mongo, can you check what is the behavior and can you fix it if any error is thrown.


Add Cloud Run Action

Will be adding a PR to add infrastructure shortly

Closing to push to a non-fork branch


Sam 1806 make tolerances more consistent

Consistently use the powerflow tolerance throughout the battery issue to mitigate issues caused by inconsistent tolerances. Results of the parametric run after changes:

See https://github.com/NREL/SAM/issues/1806 for test file. See https://github.com/NREL/ssc/pull/1132 for history on powerflow tolerance.
Test changes for grid outage and resilience code were required to accommodate tighter tolerances. Reported resilience metrics have decreased due to changing tolerance from 2 W to 0.005 W.

@brtietz Does this fix https://github.com/NREL/SAM/issues/1806?

Yes, thanks for the reminder. Just closed that issue.
From: Paul Gilman @.>
Sent: Wednesday, July 24, 2024 10:38 AM
To: NREL/ssc @.>
Cc: Mirletz, Brian @.>; Mention @.>
Subject: Re: [NREL/ssc] Sam 1806 make tolerances more consistent (PR #1182)
CAUTION: This email originated from outside of NREL. Do not click links or open attachments unless you recognize the sender and know the content is safe.
@brtietzhttps://github.com/brtietz Does this fix NREL/SAM#1806https://github.com/NREL/SAM/issues/1806?

Reply to this email directly, view it on GitHubhttps://github.com/NREL/ssc/pull/1182#issuecomment-2248459348, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABKGHYE2E7XAYZ3LVUEFBHLZN7J6JAVCNFSM6AAAAABK7B3SZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBYGQ2TSMZUHA.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


Scroll to top of Collections Artworks Grid after Applying Filters

https://artsyproduct.atlassian.net/browse/FX-1921
#trivial

The implementation looks okay, but it feels a little jarring in the gifs! I wonder if we can make it slower? Nicole might have some animation specs/ideas. Maybe we can ease it?

The implementation looks okay, but it feels a little jarring in the gifs! I wonder if we can make it slower? Nicole might have some animation specs/ideas. Maybe we can ease it?

Actually just posted a video in Slack of what it looks like with and without the animation just as you noted this!

Nice!! Looks awesome 😍!


JacocoRunner script: update for Jacoco 0.8.11 and Bazel 7.0.2

rules_scala has issues with coverage on JDK 21.
Bazel has solved this in https://github.com/bazelbuild/bazel/issues/20845 by upgrading Jacoco and ASM.
Added option to build JacocoRunner for Bazel 7, the version with fix will be used with Jacoco interface changes.
Jacoco upgraded to 0.8.11 (including the Jacoco/Bazel branches used for that).

Will update this PR with latest learnings. Bazel 7.1.0 is the first version that includes the Bazel fix that I branched off from, so better to use a release (will use 7.1.1).

Even though Bazel 7.1.0 seems to solve the original issue that motivated this upgrade, that release does not have the Jacoco and ASM upgrade when using it for building the jacocorunner.

Even though Bazel 7.1.0 seems to solve the original issue that motivated this upgrade, that release does not have the Jacoco and ASM upgrade when using it for building the jacocorunner.

So I'll leave the Bazel branch as is.


[BEAM-5994] Fix condition which allows to publish metrics

Quick fix of condition.

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

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[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.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v5.5 to before v5.15.5",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9786b65bc61acec63f923978c75e707afbb74bc7",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4f8e469a2384dfa4047145b0093126462cbb6dc0"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "9786b65bc61acec63f923978c75e707afbb74bc7",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "4f8e469a2384dfa4047145b0093126462cbb6dc0",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15.5 by commit 4f8e469a2384dfa4047145b0093126462cbb6dc0, it was introduced in version v5.5 by commit 9786b65bc61acec63f923978c75e707afbb74bc7. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1002305


How to use tracking and profiling hook?

Hi, I don't understand how to you profiling hook, all the time I've got errors can someone explain to me how it should works?

Hi @HyperScypion Please elaborate  your query with complete details. Like what solution are you trying and where did you encounter the error. And finally, what are the errors. Thanks

Hi @HyperScypion Can you update on the above comment. Thanks!

As we see lack of activity on this issue. We are closing it. Thanks!


Sourcemap a couple of lines off

I am experiencing that the generated sourcemap by Webpack is a few lines off compared to the source.  As soon as I disable your plugin, the lines are aligned again. Could it be related to issue #9? I am combining your plugin with TypeScript compilation.

I boldly moved away from your plug-in towards the ng-annotate-loader. This loader seems to work. Using the following Webpack config:
`loaders: [
...
{ test: /.ts$/, loaders: ['ng-annotate', 'ts-loader'] },
...
}

Thanks for reporting, cveld. I'll take a look this weekend and see what's wrong.
I chose to use a plugin over a loader because the loader added more compilation time for a huge project, but if the loader works for you there is nothing wrong with it.

I noticed this as well, but only when I use devtool value of 'source-map' or 'inline-source-map'.  The line numbers are correct if I use 'eval-source-map', however with this route it appears that breakpoints on the constructor and $onInit are not honored.
FWIW, I encounter the same issue with ng-annotate-loader

That suggests that it's a problem with ng-annotate rather than something we can do - unfortunately this plugin only passes on sourcemaps blindly


Cancelled Orders with isActive subscription

SELECT *
FROM "Orders" o
INNER JOIN "Subscriptions" s ON o."SubscriptionId" = s.id
WHERE s."isActive" IS TRUE
AND o."status" = 'CANCELLED'

Looks related to PayPal in most cases.

No cases yet but it looks like this can happen with disputes:

https://github.com/opencollective/opencollective-api/blob/f73119dc179e383dc2729203e7e46c2bb045bd7b/server/paymentProviders/stripe/webhook.ts#L409
https://github.com/opencollective/opencollective-api/blob/f73119dc179e383dc2729203e7e46c2bb045bd7b/server/paymentProviders/stripe/webhook.ts#L581

Actually, this is the expected behavior: we're now handling PayPal cancelations asynchronously in many cases. To achieve that, we mark the order as cancelled then the cron/hourly/70-cancel-subscriptions-for-cancelled-orders.ts job picks them up for actual cancellation.
However, it looks like the job has been failing lately, probably because of an issue with OCNZ that I wanted to investigate this week but wasn't able to due to their PayPal account being protected behind a 2FA sms.

I'll check that and will improve the script to make sure it continues if one cancellation fails.


changing system-type in vcr cassete to the new format FlashedSystems/svc

Physical-storage system_type was changesd in autosde from svc to FlashSystems/SVC. miq dynamicly imports the names of the system-types from autosde so no changes are needed in miq code, except for the rspec vcr-cassetes that save the nave svc which is no longer supported.
vcr where modified to FlashSystems/SVC

So the change here is in the http response, is this dealing with a change in the server-side api?  Was there a bump to the server-side API version also?  Does the current gem handle the new and old versions of the API (it would appear not)?

Backported via https://github.com/ManageIQ/manageiq-providers-autosde/pull/103

@llivne A conflict occurred during the backport of this pull request to morphy.
If this pull request is based on another pull request that has not been marked for backport, add the appropriate labels to the other pull request. Otherwise, please create a new pull request direct to the morphy branch in order to resolve this.
Conflict details:
diff --cc manageiq-providers-autosde.gemspec
index d63ad44,617f7c7..0000000
--- a/manageiq-providers-autosde.gemspec
+++ b/manageiq-providers-autosde.gemspec
@@@ -18,7 -18,7 +18,11 @@@ Gem::Specification.new do |spec
    spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
    spec.require_paths = ["lib"]

++<<<<<<< HEAD
 +  spec.add_dependency "autosde_openapi_client", "~> 1.0.0"
++=======
+   spec.add_dependency "autosde_openapi_client", "~> 1.1.0"
++>>>>>>> 4113aaf... Merge pull request #99 from Autosde/fix_storage_system_specs
    spec.add_dependency "typhoeus", "~> 1.4"

    spec.add_development_dependency "manageiq-style"
diff --cc spec/models/manageiq/providers/autosde/inventory_spec.rb
index 648646e,9e820da..0000000
--- a/spec/models/manageiq/providers/autosde/inventory_spec.rb
+++ b/spec/models/manageiq/providers/autosde/inventory_spec.rb
@@@ -12,16 -15,24 +12,25 @@@ describe ManageIQ::Providers::Autosde::
      end

      # expected that refresh will bring all components
++<<<<<<< HEAD
 +    expect(ems.physical_storages).to_not be_empty
 +    expect(ems.physical_storage_families).to_not be_empty
 +    expect(ems.physical_storages.first.physical_storage_family).to eq(ems.physical_storage_families.find_by(:name=>'svc'))
++=======
+     expect(ems.physical_storages).to_not(be_empty)
+     expect(ems.physical_storage_families).to_not(be_empty)
+     expect(ems.physical_storages.first.physical_storage_family).to(eq(ems.physical_storage_families.find_by(:name=>'FlashSystems/SVC')))
+
+     expect(ems.storage_resources).to_not(be_empty)
+     expect(ems.storage_resources.first.physical_storage).to(eq(ems.physical_storages.first))
++>>>>>>> 4113aaf... Merge pull request #99 from Autosde/fix_storage_system_specs

 -    expect(ems.storage_services).to_not(be_empty)
 -    expect(ems.cloud_volumes).to_not(be_empty)
 +    expect(ems.storage_resources).to_not be_empty
 +    expect(ems.storage_resources.first.physical_storage).to eq(ems.physical_storages.first)

 -    expect(ems.cloud_volumes.first).to(be_instance_of(ManageIQ::Providers::Autosde::StorageManager::CloudVolume))
 +    expect(ems.storage_services).to_not be_empty
 +    expect(ems.cloud_volumes).to_not be_empty

 -    # wwpn candidates
 -    expect(ems.wwpn_candidates.count).to(eq(2))
 -    first_candidate = ems.wwpn_candidates.find_by(:ems_ref => first_wwpn)
 -    expect(first_candidate).to(have_attributes(
 -                                 :candidate        => first_wwpn,
 -                                 :physical_storage => ems.physical_storages.find_by(:ems_ref => ems_ref)
 -                               ))
 +    expect(ems.cloud_volumes.first).to be_instance_of(ManageIQ::Providers::Autosde::StorageManager::CloudVolume)
    end
  end

Backport PR is #127


Use spatial offset after a press of a button which is mapped to the touchpad as the touchpad's axis

This was inspired by Bungpiece's comment here: https://github.com/cboulay/PSMoveService/issues/161
It allows you to hold down whichever button on the PS Move controller you've mapped to the Vive controller's touchpad and then move the controller around to emulate moving your finger around on the touchpad. This happens relative to the controller's orientation at the time the button was pressed -- so point the PS Move's sphere ahead of you when pressing the button if you're using an app's feature where the touchpad's y axis maps to forward and back (e.g. world navigation) and point it at the ceiling if you're using a feature where it maps to up and down (e.g. menu navigation).
With this feature, Windlands and Tilt Brush are now playable, and it should be possible to change weapons in Space Pirate Simulator.
To turn this on, add "use_spatial_offset_after_touchpad_press_as_touchpad_axis" : true to the psmove section in steamvr.vrsettings. To set its intensity, add "meters_per_touchpad_units" : [value] to the same section. (I've got it set to 0.225.)

Thanks again for the touchpad work @YossiMH! Much appreciated. The change looks good overall. There is one small tweak I commented on, but it can come later. I can merge the PR now unless you really wanted to make the change then I can wait. Either way I'll try to put out a release this Friday with your change.


Rides that didn't happen - Issue linking siri rides to gtfs rides

I wanted to use the absence of a link between gtfs ride to a siri ride (siri_ride.gtfs_ride_id is null) to categorize this planned ride as a ride that did not happen.
As far as I understand from the data model, this hypothesis makes sense (of course that there are other cases in which there is siri data and the ride did not happen \ finish successfully, but I wanted to start with the easiest case).
But when verifying the data, I noticed gaps between the siri ride counts to the siri rides I found unlinked.
This is the flow I checked on Eged's line 470:
-- how many rides did and did not happen per day
select date_trunc('day', gr.start_time), sr.id is null didnt_happen, count(*) from gtfs_route
    join gtfs_ride gr on gtfs_route.id = gr.gtfs_route_id
left join  siri_ride sr on gr.id = sr.gtfs_ride_id
where
gr.start_time > '2022-12-10 00:45:00.000000' and gtfs_route.line_ref=7005 and gtfs_route.operator_ref=3
GROUP BY date_trunc('day', gr.start_time), sr.id is null

Output -

Now I zoomed in to the 12.12.22 which seemed to have 5 missing rides-
-- how many gtfs rides happened in a specific date
select count(*) from gtfs_route
         join gtfs_ride gr on gtfs_route.id = gr.gtfs_route_id
where line_ref=7005 and operator_ref=3 and date='2022-12-12'

-- how many siri rides happened in a specific date
select count(*) from siri_route
         join siri_ride sr on siri_route.id = sr.siri_route_id
where line_ref=7005 and operator_ref=3
and date_trunc('day', sr.scheduled_start_time) = '2022-12-12'

Both returned 39, meaning that probably all the planned rides did happen (maybe in different timings than expected?).
Than, I went looking at the ETL code that updates siri_ride.gtfs_ride_id (open-bus-stride-etl/open_bus_stride_etl/siri/update_rides_gtfs.py)
I manually ran the query.
A subtraction of all the siri ride ids that did have gtfs relation from all the siri rides that day, gave me the unlinked ids -
{‘26074926’, ‘26077170’, ‘26094950’, ‘26100800’, ‘26106606’}
ETL Verification
Running the ETL query that links by route_gtfs_ride_id returns no results because siri_ride.journey_gtfs_ride_id is not null
select gtfs_route.date, *
from siri_ride
         -- we search for both options (comment out one when executing) -
         -- join gtfs_ride on gtfs_ride.id = siri_ride.journey_gtfs_ride_id
         join gtfs_ride on gtfs_ride.id = siri_ride.route_gtfs_ride_id
         join gtfs_route on gtfs_route.id = gtfs_ride.gtfs_route_id
    and gtfs_route.date = '2022-12-12'
    and siri_ride.journey_gtfs_ride_id is null
where siri_ride.id in ('26074926', '26077170', '26094950', '26100800', '26106606') -- rides that did not connect well
-- where siri_ride.id in ('26064288', '26065379') -- ride that are connected

Running the ETL query that links by journey_gtfs_ride_id returns no results either because for some reason in that case the gtfs_route.data is '2022-12-13'
select gtfs_route.date, *
from siri_ride
         -- we search for both options (comment out one when executing) -
                join gtfs_ride on gtfs_ride.id = siri_ride.journey_gtfs_ride_id
--          join gtfs_ride on gtfs_ride.id = siri_ride.route_gtfs_ride_id
         join gtfs_route on gtfs_route.id = gtfs_ride.gtfs_route_id
--     and gtfs_route.date = '2022-12-12'
--     and siri_ride.journey_gtfs_ride_id is null
where siri_ride.id in ('26074926', '26077170', '26094950', '26100800', '26106606') -- rides that did not connect well

@OriHoch I'd very much like your help to understand the full flow of this ETL and specifically - what are the differences between journey_gtfs_ride_id and route_gtfs_ride_id and why when we link only when one of them is valid?

Might not be related, but as another sanity, I tried a simple comparison of the counts, and the results are weird (sometimes there are more siri rides than gtfs)
-- compare counts only
select date_part('dow', gtfs.date) day_of_week, gtfs.date, gtfs.count, siri.count, gtfs.count - siri.count missing_rides from
(select gtfs_route.date date, count(*) count from gtfs_route
         join gtfs_ride gr on gtfs_route.id = gr.gtfs_route_id
where line_ref=7005 and operator_ref=3
and gtfs_route.date > '2022-12-10'
group by gtfs_route.date) AS gtfs
join (
select date_trunc('day', sr.scheduled_start_time) date, count(*) count from siri_route
         join siri_ride sr on siri_route.id = sr.siri_route_id
where line_ref=7005 and operator_ref=3
and date_trunc('day', sr.scheduled_start_time) > '2022-12-10'
group by date_trunc('day', sr.scheduled_start_time)) AS siri
on siri.date=gtfs.date;

Output -

Maybe the drivers had some spare time 😅

@OriHoch I'd very much like your help to understand the full flow of this ETL and specifically - what are the differences between journey_gtfs_ride_id and route_gtfs_ride_id and why when we link only when one of them is valid?

journey_gtfs_ride_id - matches gtfs_ride.journey_ref to siri_ride.journey_ref here
route_gtfs_ride_id - is more complex, it looks for matching operator_ref, line_ref, route_id and date, then looks at siri_ride.scheduled_start_time matched with gtfs_ride.start_time in a few intervals of minutes here

regarding linking - we prefer the journey_gtfs_ride_id as it's more exact based on the journey_ref... I don't remember why I added the other method, I guess I found some rides which didn't match based on journey_ref.

this ETL depends on a lot of other data from SIRI and GTFS, so there could be different places which cause the mismatch in rides. I suggest to go back to the source raw SIRI/GTFS data and try to match those rides there.

one more point to take into account when looking for missing data is if all the relevant data was loaded for the given times. If there was an error in the MOT interfaces or in our ETL you might see missing data for rides that did happen..
I started working on adding DB tables that show this but didn't finish.
However, there are some tables which show this data -

siri_snapshots - each scrape of MOT SIRI is shown there, recently they had some problems so you can see a lot of missing rows between 2022-12-23 11:59:37.199626 and 2022-12-24 15:41:51.211535
gtfs_data - shows the status of gtfs data processing for each date
gtfs_data_task - shows the status of gtfs etl tasks processing for each date

@OriHoch I'd very much like your help to understand the full flow of this ETL and specifically - what are the differences between journey_gtfs_ride_id and route_gtfs_ride_id and why when we link only when one of them is valid?

journey_gtfs_ride_id - matches gtfs_ride.journey_ref to siri_ride.journey_ref here
route_gtfs_ride_id - is more complex, it looks for matching operator_ref, line_ref, route_id and date, then looks at siri_ride.scheduled_start_time matched with gtfs_ride.start_time in a few intervals of minutes here

regarding linking - we prefer the journey_gtfs_ride_id as it's more exact based on the journey_ref... I don't remember why I added the other method, I guess I found some rides which didn't match based on journey_ref.

So I took a specific siri ride that didn't match (26074926) and if we look at it's journey_ref (2145383_121222) we can see that it is not unique for some reason (we're looking in the raw data to find if we can find this duplication there as well)

For some reason, the one that's related to the 12.12 siri_ride is the gtfs_ride from the 13.13, even though I see you do filter by date -
https://github.com/hasadna/open-bus-stride-etl/blob/6b1fc4a504fc7c927b6ab0b9cd45bb47d41dd920/open_bus_stride_etl/siri/update_rides_gtfs.py#L57
Do you have any idea why would it happen?

If I try to manually join siri_rides to gtfs_ride using the same reformatting you do in the ETL, I see that only 10 out of 39 siri rides in that day link based on the journey_ref. Meaning that the majority are linked based on the route_gtfs_ride_id.
select * from siri_route
         join siri_ride on siri_route.id = siri_ride.siri_route_id
         left join gtfs_ride gr on split_part(siri_ride.journey_ref, '-', 4) || '_' || split_part(siri_ride.journey_ref, '-', 3) || split_part(siri_ride.journey_ref, '-', 2) || substr(split_part(siri_ride.journey_ref, '-', 1), 3) = gr.journey_ref
where line_ref=7005 and operator_ref=3
and date_trunc('day', siri_ride.scheduled_start_time) = '2022-12-12'

If I take of of the journey refs from the siri rides that didn't match, they indeed don't match to any existing gtfs_ride
select * from gtfs_ride where journey_ref like '3871134_121222' -- zero results

Update: after more research, we found out that  route_gtfs_ride_id is more accurate than journey_gtfs_ride_id (the opposite of the current logic).
I'm currently trying to fix the ETL, these are the changes I'm doing -

Add a new column (setting the others to deprecated) which will be the only one updated by the ETL and set gtfs_ride_id (We'll need to manually set gtfs_ride_id once to apply this chage).
Removing the interval match as we found out it is unnecessary

@OriHoch would like your help here regarding how to test this (I will open a PR later on)-
Besides having a side script to validate the logic, I tried to load a sample db locally and play with the new queries I'm using but I'm not sure this is hermetic enough for such a big change..
Specifically, I'm worried about edge cases regarding edge-hours
-- a few hundreds every day
select count(1), gr.date from gtfs_ride
join gtfs_route gr on gtfs_ride.gtfs_route_id = gr.id
where date_trunc('day', gtfs_ride.start_time) != gr.date
group by gr.date
order by gr.date desc

I think the gtfs_date filter can be removed, we have other filters on scheduled_start_time / ride start_time which are enough (both contain also the date). The only logical problem I can think of is that we might have the same ride multiple times from different gtfs_dates (possibly with different ride start_times?).
Regarding testing, I don't see a problem to test on production.. given that current data is also not accurate

wdym by "same ride multiple times from different gtfs_dates"? aren't gtfs_rides created daily?
If you mean that there could be 2 gtfs rides scheduled to the exact same start_time, I agree that it can happen in reality, and on that case, I think it can be a bit tricky to handle (match each siri ride to a different gtfs and not both to one of the gtfs_rides randomally), but I'm not sure how much it happens and therefore how much we care about this edge case.
Regarding testing, how about first adding the internal column, and then after more validations that I'll do on the entire dataset we'll move the FQ to point on my new column?

wdym by "same ride multiple times from different gtfs_dates"? aren't gtfs_rides created daily?

yes but the process of getting and processing the gtfs data is complex, it's not a simple download for a specific date, so need to try to make as few assumptions as possible about the correctness of the data as possible.. the gtfs date is just the date when we downloaded the data, so what happens if for example the MOT data was not updated at a given day? Or if we missed a download day? We try to handle all these situations but just need to take into account that there might be problems..

Regarding testing, how about first adding the internal column, and then after more validations that I'll do on the entire dataset we'll move the FQ to point on my new column?

sounds good

BTW, do you know how the current syntax you used for updating works if there is more than 1 match?

you need to make sure there is only 1 match.. if there is more then 1 match it will work but you can't know for sure which match will be used for the update