Unable to cancel PickBuffer() in neovim

To  reproduce:

Start vim with no open buffers.
Call PickBuffer() and observe the pick interface empty as expected.
Try Ctrl C to exit.
Try Ctrl D to exit.
Observe neither works as expected.

I can't reproduce this with the latest pick.vim, the latest pick, on vim 7.4.944`.

Can you produce this with a minimal .vimrc? That only loads pick.vim?

Thanks for trying to reproduce @teoljungberg. It didn't occur to me to mention I'm using neovim. Apologies.
I cannot reproduce with latest pick.vim, pick, and vim 7.3.
With nvim 0.1.0-dev,
❯ nvim -u NONE -c 'source ~/.config/nvim/bundle/pick.vim/plugin/pick.vim' -c 'call PickBuffer()'

reproduces. This seems to be a problem with neovim (maybe how it handles async operations?), and not my configuration.
Would you agree? Any advice beyond filing an issue with neovim?

If memory serves me well, pick.vim doesn't work at all in neovim. I think it's due to how they've changed how ":!" and ":system()" works. @calleerlandsson knows more about that than I do.

Teo Ljungberg

On 4 dec. 2015, at 22:06, Jeffrey Horn<EMAIL_ADDRESS>wrote:
Thanks for trying to reproduce @teoljungberg. It didn't occur to me to mention I'm using neovim. Apologies.
I cannot reproduce with latest pick.vim, pick, and vim 7.3.
With nvim 0.1.0-dev,
❯ nvim -u NONE -c 'source ~/.config/nvim/bundle/pick.vim/plugin/pick.vim' -c 'call PickBuffer()'
reproduces. This seems to be a problem with neovim (maybe how it handles async operations?), and not my configuration.
Would you agree? Any advice beyond filing an issue with neovim?
—
Reply to this email directly or view it on GitHub.

Hey @jrhorn424, thanks for reporting this!
Unfortunately, I'm not very familiar with neovim since I don't use it. Could you try the same thing using a program similar to pick? Some examples are selecta and fzf.
If we can fix this issue in pick, I'd be happy to do so.

I just tried selecta with https://github.com/michaelavila/selecta.vim in nvim 0.1.0-dev. It works as expected. If I may hazard a guess, the difference in behavior might be due to the stated difference in goals for pick:

pick serves the same purpose as selecta but is faster and utilizes the alternate screen terminal feature to not leave choices on screen after the program finishes execution.

I'll try with fzf next, but I've been having trouble getting it installed and working in vim using pathogen.

When using fzf and fzf.vim with same nvim, calling Buffers to display an (empty) buffer list through fzf, I am able to exit as expected with either ESC or RET or Ctrl C.

Thanks for testing, @jrhorn424! It seems like the use of the alternate screen doesn't work in neovim.
When running pick inside of Vim, the use of the alternate screen is automatically disabled when the VIM environment variable is defined. Maybe neovim doesn't define this? Pick's use of the alternate screen can also be disabled explicitly using the -X option. Could you try that by adding the following to you vimrc?
let g:pick_executable = "pick -X"

If this works, could you paste any non-sensitive output of running :!env inside of neovim? Maybe there's an environment variable we could look for to detect running inside neovim?

nvim -u NONE -c 'source ~/.config/nvim/bundle/pick.vim/plugin/pick.vim' -c 'let g:pick_executable = "pick -X"' -c 'call PickBuffer()'

Still experiencing the issue. Here's some :!env:
SHELL=/usr/local/bin/zsh
TERM_PROGRAM=iTerm.app
TERM=xterm-256color
VIMRUNTIME=/usr/local/Cellar/neovim/0.1.0/share/nvim/runtime
NVIM_LISTEN_ADDRESS=/var/folders/1y/r5c46zcx2w17khhdnbd841l00000gn/T/nvim4rmRUo/0

Everything else seems unrelated (ruby, gcc options, etc etc).

For the hell of it, tried this:
export VIM=$(which nvim)

nvim -u NONE -c 'source ~/.config/nvim/bundle/pick.vim/plugin/pick.vim' -c 'let g:pick_executable = "pick -X"' -c 'call PickBuffer()'

No luck.

I'm sorry this isn't working properly.
Since I'm not a neovim user myself, I won't be able to maintain support for it. If anyone figures this out I'd be very happy to review your PRs both to pick.vim and pick.

I understand. Thanks for your help! 😄

I think this may have been related to: https://github.com/calleerlandsson/pick/pull/178
I can with a fresh install of nvim and the latest version of pick call pick.vim and open a file. There are a few odd behaviours (like the UI not updating all the time on navigating with the arrow-keys). But atleast its usable.
I tried this command with:
nvim -v: 0.1.7
pick -v: 1.5.3
nvim -u NONE -c 'source ~/.vim/bundle/pick.vim/plugin/pick.vim' -c 'let g:pick_executable = "pick -X"' -c 'call PickBuffer()'

This also does not work with the support of vim 8's :terminal support.


Align the graphs vertically

The UI shows the graphs in multiple columns. This makes it hard to read the regressions, because you have to visually jump horizontally and attempt to align the metric variations. See also https://github.com/ocurrent/current-bench/issues/247
It would probably work better if the graphs were full width, such that the vertical alignment is always correct. The height of the graphs could be smaller to not loose on information density.
See https://ziglang.org/perf/ for an example, where the x-axis is also using time and not just evenly spread commits (otherwise a big regression followed by a quick fix can be given too much importance in the timeline!)

Sure, the time as x-axis is only a suggestion! But it comes with its own challenges with the graph library ^^

Closed in #320


Add support to generate TypeResolvers

Motivation
For the Delivery Client creation, it is possible to provide TypeResolver, that is mapping content types fo the models (classes).
These models could be generated by the model-generator tool, that automatically generates models for the project (documentation).
Current status
There is no way, how to easily generate the skeleton for TypeResolvers to avoid the current busy-work.
It would be great to have implemented in that generator a possibility to generate the type resolver too.
Proposed solution
Creating a single file with that exports an array of all the necessary TypeResolvers would avoid the current busy-work.
Some example

Mind the moduleResolution parameter for generation can influentce how the modules are imported and exported and also codeType parameter (https://github.com/Enngage/kentico-cloud-js/tree/master/packages/model-generator#configuration)

import { TypeResolver } from 'kentico-cloud-delivery';
import { Actor } from './actor.class';
import { Movie } from './movie.class';

const TypeResolvers = [
  new TypeResolver('actor', () => new Actor()),
  new TypeResolver('movie', () => new Movie())
];

module.exports = {
  TypeResolvers
}

I have tried to make it more clear - @ChristopherJennings  - could you take a look if I got it right? :-)

The links to https://github.com/Enngage/kentico-cloud-js/tree/master/packages/model-generator and https://github.com/Enngage/kentico-cloud-js/tree/master/packages/model-generator#configuration are both 404s.

Hi @Pr0methean, where did you find these links? Yeah, the link you sent is the correct one.

@Enngage They're in this issue's description.

Next version of the SDK removed type resolvers as it favors interfaces instead of classes for reduced size & complexity. This change makes this issue obsolete.


Warning due to supported source version 'RELEASE_7' from annotation processor

I get this warning during compilation while using the SDK with JDK 1.8:
Supported source version 'RELEASE_7' from annotation processor 'com.microsoft.azure.management.apigeneration.LangDefinitionProcessor' less than -source '1.8'.
In the readme, prerequisites include "A Java Developer Kit (JDK), v 1.7 or later".
Is there a reason for having this restriction in place? If not can it be removed?

Java 7 has been EOL since April 2015!! Surely this needs updating to Java 8 ASAP given that the latest release was done in May 2017 (version 1.1.0)

If you’re currently running Java apps on-premise or with other JDKs, consider moving it to Zulu on Azure for continued support and maintenance.
For more info:
https://azure.microsoft.com/en-us/blog/microsoft-and-azul-systems-bring-free-java-lts-support-to-azure/

Hi,
As you recommended, I moved to the Zulu JDK. However I already have the warning, with both JDK 8 and 11.
What can I do, I really appreciate to set the  flag in the maven compilation options.
Thanks!

@selvasingh, can you help us with this case with Zulu? It is in the context of the Azure SDK for Java

@jacqueslorentz do you mean you meet the warning in Zulu JDK 8? Or you meet it in Oracle / Open JDK 8?
And can you share your code snippet about it? I cannot compile any maven project with this error in Oracle JDK 8.

I use the Zulu JDK 8 and 11, for two distinct projects and I have this warning with both, with this maven plugin configuration in my pom.xml:
...
<build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.8.1</version>
                    <configuration>
                        <release>${java.version}</release>
                        <showWarnings>true</showWarnings>
                        <!--<failOnWarning>true</failOnWarning> CANNOT COMPILE WITH IT-->
                    </configuration>
                </plugin>
                ...
           </plugins>
      </pluginManagement>
</build>

We need to use the Zulu JDK to match with Azure Pipelines environnement.

Same warning here !
I use Zulu JDK 11 with spring-boot-azure-starter current version.
Any solution ?

The azure-annotations hard code to support RELEASE_7, will fix later (many dependency need to upgrade).
Now, this warning could only be ignore.

fix in 1.29.0


Update readme with pre-trained models on svs and demonstration

Noted that I also add a line for the license issue of pre-trained model usage. Some databases, specifically for singing voice, have non-commercial requirements for not only datasets but also pre-trained models. After I inquiry about some of the lawful issues, it would be better that we add a disclaimer there.

Thank you for your updating!
Very cool demo :)


opsdroid: 0.23.0 -> 0.24.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for opsdroid is: "An open source chat-ops bot framework"
meta.homepage for opsdroid is: "https://opsdroid.dev"
meta.changelog for opsdroid is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

/nix/store/il1qfa74jjx4sabqvn46kqg127zskch2-python3.9-opsdroid-0.24.1/bin/opsdroid passed the binary check.

/nix/store/il1qfa74jjx4sabqvn46kqg127zskch2-python3.9-opsdroid-0.24.1/bin/.opsdroid-wrapped passed the binary check.

2 of 2 passed binary check by having a zero exit code.

0 of 2 passed binary check by having the new version present in output.

found 0.24.1 with grep in /nix/store/il1qfa74jjx4sabqvn46kqg127zskch2-python3.9-opsdroid-0.24.1

found 0.24.1 in filename of file in /nix/store/il1qfa74jjx4sabqvn46kqg127zskch2-python3.9-opsdroid-0.24.1

directory tree listing: https://gist.github.com/d54815ecf70672de4ae66cebc2ce43c9

du listing: https://gist.github.com/9b949fda7bb1692d030170c4ac5d3d46

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
0 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
opsdroid

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/il1qfa74jjx4sabqvn46kqg127zskch2-python3.9-opsdroid-0.24.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A opsdroid https://github.com/r-ryantm/nixpkgs/archive/c13a639ae113e4b54438f7691e2d98134a0b55b2.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/il1qfa74jjx4sabqvn46kqg127zskch2-python3.9-opsdroid-0.24.1
ls -la /nix/store/il1qfa74jjx4sabqvn46kqg127zskch2-python3.9-opsdroid-0.24.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

opsdroid

Maintainer pings
cc @fpletz @globin @willibutz @lheckemann for testing.

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

1 package built:

opsdroid


Virtualbox Driver Documentation misses options implemented

hi,
it seems documentation of Virtualbox Driver misses documentation about the implemented option:
https://github.com/docker/machine/blob/master/drivers/virtualbox/virtualbox.go#L236
i'd be happy to make a PR if i'm not wrong about it :)

@xinity You're right. This was added in #3124. Indeed I forgot to add some docs.


removed unreachable code (duplicated return)

Thank you!

@daniel-faber #6 and #7 have been merged and release on NPM as 0.0.9. Thanks for cleaning up the code!


404 in README.md

Link to TheMatrix in Performance section of README.md returns a 404.
Is this the right link?

The Matrix is deprecated, this should be removed from the README


Resolve conflict during rename

Resolve name resolution conflicts during a rename session just like Roslyn for C#/VB does. Identifiers can have a different meaning before and after a rename refactor. And in some very special cases the errors can not be identified instantaneously, only at runtime.
By the way, the new rewritten language service is really cool, using Roslyn was an excellent choice, very well done!

Could you please schedule this issue to a milestone as soon as possible?
This issue is really critical because it makes the rename feature insecure and risky. We already had troubles with it in the production code (see issue #17670).
Also I think it should have the bug label as well.
Thanks in advance.

We're transitioning to LSP so this functionality can be provided in a language-agnostic way


X Ray Image Query: Deprecate the Simplified Camera Specification

I don't normally make tickets for these but this one strikes me as a bit more important and perhaps worthy of some discussion.
The X Ray Image Query provides two camera specifications. The Simplified Camera Specification is more restrictive than the Complete Camera Specification. The query will use the simple camera specification if any of the simple camera specification arguments show up.

The simple camera specification is worse than the complete one. It is easier to use, but do we really want new users to be using it?
When you use the get default query parameters function, you get a python dictionary that contains defaults for the simple and complete camera specs. If you don't manually remove the simple camera arguments from it, you are forced into using the simple camera spec even though you have arguments for the complete one, because the query defaults to the simple spec. How best to solve this?
I propose we make the complete camera specification the default.
I propose we remove the simple camera spec from the default arguments.
I propose we remove simple camera spec from the docs.
I propose we leave the simple camera spec as an option in the code but do not advertise it.

We won't actually deprecate it, we just won't advertise it and if you get the default properties then don't include the simple camera options.


Update Leiningen example

I found it quite confusing that the readme doesn't mention that the maven package has to be first created in Bintray.
Additionally, usage of environment variables for configuration should be encouraged so that secrets don't get stored anywhere.

@jbaruch Thanks!


net/http/httputil: ReverseProxy does not strip all hop-by-hop headers

What version of Go are you using (go version)?
1.6

What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build436466338=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="0"

What did you do?
I created a basic reverse proxy:

package main

import (
	"log"
	"net/http"
	"net/http/httputil"
)

func main() {
	log.Fatal(http.ListenAndServe(":80", &httputil.ReverseProxy{
		Director: func(req *http.Request) {
			req.URL.Scheme = "http"
			req.URL.Host = "admin-monolith"
		},
	}))
}

Then I sent this HTTP request to the proxy (based on an example in the HTTP/2 spec):
GET / HTTP/1.1
Host: server.example.com
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: abcdef...

What did you expect to see?
According to the Connection header, HTTP2-Settings is a hop-by-hop header, so I expected that the proxy would strip this header before forwarding the request.

What did you see instead?
The HTTP2-Settings header (but not the Upgrade) header was not stripped but was forwarded to the backend server.

Stripping hop-by-hop headers was implemented in #2735, but only headers explicitly mentioned in RFC 2616 are removed.
The relevant quote from RFC 7230, section 6.1 is this:

A proxy or gateway MUST parse a received Connection header field before
a message is forwarded and, for each connection-option in this field,
remove any header field(s) from the message with the same name as the
connection-option, and then remove the Connection header field itself
(or replace it with the intermediary's own connection options for the
forwarded message).

The same requirement was included in RFC 2616, section 14.10.

Should the values be comma-separated, like your example:
Connection: Upgrade, HTTP2-Settings

Or, space-separated as mentioned in https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Connection#Directives?

The list should be separated by comma (with optional additional white-space).
The # construct is described in section 7.

Thanks for the link. The above CL assumes the tokens are separated with commas with optional white-space.

@siadat @bradfitz shouldn't we copy the headers as the next for loop is doing?

Thanks! See https://golang.org/cl/28493
I also added a check to make sure the original request headers are not modified.

Should these entries be scrubbed from the response headers (like the hop-by-hop headers) as well?


Make beforeInsert & beforeRemove events cancelable

Currently it's not possible to preventDefault on the beforeInsert and beforeRemove events because they are not cancelable - https://developer.mozilla.org/en-US/docs/Web/Events/Creating_and_triggering_events#triggering_built-in_events
cc @dabroz

Thanks!


Document 'resin deploy'

We need resin deploy documented as an alternative to git push, probably in https://docs.resin.io/learn/deploy/deployment/#how-to-deploy and/or any other relevant section

This has since been fixed.


🐛 Bug Report: Backstage Github auth is not working.

📜 Description
We have installed backstage 1.24.0 with minimal plugin installation, We are trying to configure github authentication using githubapp as well github Oauth. But we are getting Login failed, user profile does not contain an email.
As part of troubleshooting we have followed this PR issue raised https://github.com/backstage/backstage/issues/23748 and updated the below files
Update app-config.yaml
Update packages/app/src/App.tsx
Update packages/backend/src/index.ts
Update examples/org.yaml to change "guest" to my GH username
App.tsx
const githubAuthCfg: SignInProviderConfig = {
  id: 'github-auth-provider',
  title: 'GitHub',
  message: 'Sign in using GitHub',
  apiRef: githubAuthApiRef,
  enableExperimentalRedirectFlow: true,
};

const app = createApp({
  apis,
  components: {
    SignInPage: props => <SignInPage {...props} auto providers={['guest', githubAuthCfg]}  />
  },

app-config.yml
auth:
  experimentalExtraAllowedOrigins: [ 'http://<IP_ADDRESS>:3000' ]
  environment: development
  providers:
    github:
      development:
        clientId: <My-Client-ID>
        clientSecret: <My-Client-Secret>
        signIn:
          resolvers:
            - resolver: emailMatchingUserEntityProfileEmail
            - resolver: emailLocalPartMatchingUserEntityName
            - resolver: usernameMatchingUserEntityName
  # Enable guest login (for development only)
  enableLegacyGuestToken: true

org.yml
---
# https://backstage.io/docs/features/software-catalog/descriptor-format#kind-user
apiVersion: backstage.io/v1alpha1
kind: User
metadata:
  name: selvan-ra
spec:
  memberOf: [guests]
---
# https://backstage.io/docs/features/software-catalog/descriptor-format#kind-group
apiVersion: backstage.io/v1alpha1
kind: Group
metadata:
  name: guests
spec:
  type: team
  children: []

👍 Expected behavior
Login failed, user profile does not contain an email
👎 Actual Behavior with Screenshots

👟 Reproduction steps
settings->Authentication Providers -> choose GitHub->sign in
📃 Provide the context for the Bug.
No response
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

Even after modifying this still the same issue. Can you helps me with further investigation. Due to this we are unable to proceed further implimentation

please remove the first 2 resolvers and keep only usernameMatchingUserEntityName:
        signIn:
          resolvers:
            - resolver: usernameMatchingUserEntityName

you need to pick the resolver that makes sense for your use case as described in https://backstage.io/docs/auth/github/provider/#configuration. Since the resolvers are used in order, emailMatchingUserEntityProfileEmail was the first one used, which requires the email of your users to be ingested in the users entities.
I've opened https://github.com/backstage/backstage/pull/24726. I hope it clarifies things.

The problem appears when a GitHub don't have configured the public email in his profile and his emails are marked as "Keep my email addresses private".
To solve that the user need:

Go to configure Public profile and select a "Public email". Save changes
If the email is not selected and you se the alert "You have set your email address to private. To toggle email privacy, go to email settings and uncheck "Keep my email address private.""
Go to email settings and uncheck option "Keep my email addresses private".

This error also occurs when you don't have the User kind populated in the catalog. Don't forget add the githubOrg (Groups, Users) provider additional to the github provider (Repositories).
To avoid the undefined email problem with users with private addresses, invert the resolver evaluation to match the username first and the email after in the auth.providers.github.<env>
resolvers:
  - resolver: usernameMatchingUserEntityName
  - resolver: emailMatchingUserEntityProfileEmail
  - resolver: emailLocalPartMatchingUserEntityName


Allow for matrix input

Allow the input X in fit(model, X, y) to be either a table or a matrix of appropriate element type (Count for multinomial and Continuous for gaussian)

cc @josephdavids. As your head is in this space already, can you review this please?


Create "Time Start" component

Use data from Time Start and Time End selectors to populate slider for user to view changes
Reference roadmap in #443

Superseded by https://github.com/hytest-org/hytest/issues/518.


Account for Camunda Modeler 5 changes.

Hello, Valentin from Camunda here.
With Camunda Modeler 5.0.0 we are making some changes to how we handle plugins.
First off, our docs have moved here https://docs.camunda.io/docs/components/modeler/desktop-modeler/plugins/.
In short, plugins now work for cloud bpmn-js diagrams, and will automatically be picked up without any changes.
If your plugin does not make sense on (or isn't yet compatible with) cloud diagrams, you'll have to use the new plugin registration helper functions that were shipped in https://github.com/camunda/camunda-modeler-plugin-helpers v5.0.0 - i.e replacing registerBpmnJSPlugin with registerPlatformBpmnJSPlugin - to opt out. Note that this will be breaking.
Otherwise, if it would conceptually work on cloud, and functionally there's nothing platform specific in your code, you don't have to do anything. Although I recommend testing using one of our recent modeler builds to make sure the application does not crash.
I'm only going to raise one issue across the sharedchains org, but this applies to all plugins.
Feel free to ask anything about this 😄. If you come across any problems please relay them back to us as soon as possible.

Hello @Skaiir ! I just started in these days to update our plugins, I made a new branch for v5.0.0 here, feel free to check it out!
I tried to replace registerBpmnJSPlugin with registerPlatformBpmnJSPlugin and make some combinations, if it works on Platform, it doesn't work on Cloud (giving me an error) and viceversa. There is no way I can make this plugin available on both platform and cloud?
Also, I have some problems with the new properties panel. I tried to update it following the bpmn-js-example but I have a preact error that I don't understand.
Could you suggest me the right direction?

If you want the plugin available on both platform and cloud, just keep using registerBpmnJSPlugin and the latest versions of Modeler will pick the plugin up for both :)
I'll have a look into the properties panel stuff a little later today.
Can you provide your error below?
All the best,
Val.

Sure! When I have my  registered Properties Provider enabled and I just select an element I receive this error
preact.module.js:1 Uncaught (in promise) TypeError: Cannot read property 'is' of undefined
    at R (preact.module.js:1)
    at A (preact.module.js:1)
    at O (preact.module.js:1)
    at R (preact.module.js:1)
    at A (preact.module.js:1)
    at O (preact.module.js:1)
    at R (preact.module.js:1)
    at A (preact.module.js:1)
    at O (preact.module.js:1)
    at A (preact.module.js:1)
<!--StartFragment-->

  | R | @ | preact.module.js:1
-- | -- | -- | --
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | R | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | R | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | (anonymous) | @ | preact.module.js:1
  | w | @ | preact.module.js:1
  | Promise.then (async) |   |
  | x | @ | preact.module.js:1
  | y.setState | @ | preact.module.js:1
  | o.__c.o.__ | @ | hooks.module.js:1
  | (anonymous) | @ | index.esm.js:249
  | k | @ | hooks.module.js:1
  | (anonymous) | @ | hooks.module.js:1
  | P | @ | hooks.module.js:1
  | setTimeout (async) |   |
  | n | @ | hooks.module.js:1
  | requestAnimationFrame (async) |   |
  | (anonymous) | @ | hooks.module.js:1
  | a.options.diffed | @ | hooks.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | R | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | R | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | R | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | R | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | O | @ | preact.module.js:1
  | A | @ | preact.module.js:1
  | (anonymous) | @ | preact.module.js:1
  | w | @ | preact.module.js:1
  | Promise.then (async) |   |
  | x | @ | preact.module.js:1
  | y.setState | @ | preact.module.js:1
  | o.__c.o.__ | @ | hooks.module.js:1
  | g | @ | index.esm.js:1341
  | e | @ | index.esm.js:1361
  | (anonymous) | @ | EventBus.js:519
  | Ne._invokeListener | @ | EventBus.js:371
  | Ne._invokeListeners | @ | EventBus.js:352
  | Ne.fire | @ | EventBus.js:313
  | en.select | @ | Selection.js:106
  | (anonymous) | @ | SelectionBehavior.js:99
  | (anonymous) | @ | EventBus.js:519
  | Ne._invokeListener | @ | EventBus.js:371
  | Ne._invokeListeners | @ | EventBus.js:352
  | Ne.fire | @ | EventBus.js:313
  | s | @ | InteractionEvents.js:94
  | f.<computed> | @ | InteractionEvents.js:173
  | (anonymous) | @ | index.esm.js:359

<!--EndFragment-->

Hello @Skaiir , I tried to move my code on the new panel properties example and everything works, it's probably a problem with the latest version of Camunda Modeler that needs to be recompiled. Thank you very much!


updated paw (3.0.7)

Changes to a cask
Editing an existing cask

[x] Commit message includes cask’s name (and new version, if applicable).
[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.

hrm, checksum failed. gonna close this and figure out what changed.


Simon Says Puzzle Implementation

Due Date
February 5th, 2024
Priority
High
Description
Implement the simon says puzzle
Associated Requirement*
P1-P7

Closed due to duplicate.


Bug: Cannot Change Root Node Type on New Inherited Scene from Imported .glb file

Tested versions

Reproducible in 4.3-beta3 [b75f0485ba15951b87f1d9a2d8dd0fcd55e178e4]

System information
Windows 11 - Godot v4.3.beta3.official Vulkan 1.3.278 - Forward+
Issue description
I've imported some assets from blender, into Godot 4.3-beta3. I imported the .glb files, and then created a new inherited scene. In the new inherited scene, you do not have the option to change the node type.

Steps to reproduce

Add a .glb file to a brand new project.
Right click on it, create new inherited scene.
On the root node, right click, there is no option to change the type. But there is in 4.2

Minimal reproduction project (MRP)
bugexample.zip

Iirc, then the root node type is defined in the import settings, this might be why

You can't change the root type of an inherited scene, by design, see:

https://github.com/godotengine/godot/pull/90536

Closing as this is intended behavior, and communicated via the fact that there's no such menu, see also:

https://github.com/godotengine/godot/issues/91842


[GraphQL] Mutation is not ready yet?

Mutation has the same implementation as Query?

my mistake, query indeed is correct even for mutation, seems both query and mutation has exactly same implementation, not sure what is the rational behind having 2 separate methods?


Fix race conditions by improving the refresh management

Right now we have a bunch of race conditions in container and image state.
For instance:
docker start foo
docker ps

start will proxy the start request to the node then return to the client.
The engine will emit a start event, which will trigger a refresh by the Engine
In between steps 1 and 2, if a client emits a ps at the right time, it will see foo as stopped even though it's running

To mitigate that, we could add a Container.Refresh() function (which in turn would call c.Engine.refreshContainer(c.id). That function would get called by every proxy that makes write calls to the engine (start, stop, ...) but not read calls (inspect).

Hint: Look for retry and docker wait in integration tests to find the workarounds we implemented.
The hacks should be removed from integration when testing the proposed changes.


fix pip failing in virtualenv under SCL

When a virtualenv is created from an SCL python installation, that python binary needs to be runnable for commands in that virtualenv to work. At present this will fail if there is not a matching version of libpython installed in a system path. (Example: python3 is installed via SCL on a system without any version of python3 installed in the base system.) scl enable among other things, sets LD_LIBRARY_PATH, and thus needs to be invoked when running pip. exec_prefix should always be empty when SCL is not in use, so this should be a safe change.

Possibly this is the issue in #234 as well


Add meta-data to disable adid collection

https://qiita.com/Nkzn/items/326ad03e358b5d3fbafc

Thanks for quick review!
I migrated CircleCI 1.0 to 2.0 and fixed it. Let me merge.


fix: Error message on tribute page when user not connected to wallet

Follow up on this comment:
https://github.com/SporosDAO/sweat-token/pull/142#issuecomment-1256254383

Done via #142


luci-mod-admin-full: fix connection lookup_queue

I notice that in the connection tab the lookup array keep checking all the entities everytime and adds to the dns_cache list only the resolved ones. This looks wrong as it's very unluckily that an addr thats not resolved in this instance gets resolved in the next one. This change how the dns_cache list works. We put in it every tried addr even if not resolved. Also this fix some error if for some reason the page doesn't receive the right data.
Signed-off-by: Ansuel Smith<EMAIL_ADDRESS>

The resolver on the backend has a hard timeout limit which means that entries later in the queue are less likely to get resolved on the first attempt, hence the infinite retries.
We likely should fix that by trying each item three times or so

Why not reduce the number of entities to check then ? (too much request?)

@jow- i changed this to check 3 times the same entities then removes it...

@jow- currently the connection table is broken... i also fixed this when you have time take a look at this too...


Spotlight view dimensions are not correct for all devices

Describe your issue here.

Steps to reproduce

Open home page

Expected behaviour
only first card should be under spotlight

i already fixed this issue, by showing spotlight on first card only. and already test in 3 different version of android. can i make a PR?

Sure. Please create a PR @mursyidah


Update path to runtime functions in API documentation

This PR updates the location of CUDA runtime functions in the API docs to their new location in cupy_backends

On second look, this is probably not the correct approach. I see now that it should probably stay as cupy.cuda.runtime. For some reason I currently, get the following warnings, though:
WARNING: [autosummary] failed to import 'cupy.cuda.runtime.deviceGetLimit': no module named cupy.cuda.runtime.deviceGetLimit
WARNING: [autosummary] failed to import 'cupy.cuda.runtime.deviceSetLimit': no module named cupy.cuda.runtime.deviceSetLimit
WARNING: [autosummary] failed to import 'cupy.cuda.runtime.ipcCloseMemHandle': no module named cupy.cuda.runtime.ipcCloseMemHandle
WARNING: [autosummary] failed to import 'cupy.cuda.runtime.ipcGetEventHandle': no module named cupy.cuda.runtime.ipcGetEventHandle
WARNING: [autosummary] failed to import 'cupy.cuda.runtime.ipcGetMemHandle': no module named cupy.cuda.runtime.ipcGetMemHandle
WARNING: [autosummary] failed to import 'cupy.cuda.runtime.ipcOpenEventHandle': no module named cupy.cuda.runtime.ipcOpenEventHandle
WARNING: [autosummary] failed to import 'cupy.cuda.runtime.ipcOpenMemHandle': no module named cupy.cuda.runtime.ipcOpenMemHandle

The warnings I saw were just called by having a residual runtime.so in the cupy/cuda/ folder. Once I removed that the warnings went away.


3316: Filter out 400 and 404 response codes from telemetry logs

#3316 prevent logging of 400 and 404 responses

Hi @chenriksson, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

@xavierdecoster Moved registration to OwinStartup;
@skofman1 @joelverhagen Changed filter to mark 400/404s as successful to filter from failed requests only

Opened issue #3401 for ServerCommon feedback


Simplify atan2_

Instead of having two branches with nearly identical code, a mutable variable is used.
This leads to much more concise code.

That is simpler. I use similar code in other repos, so this should be extra-useful.

Oh, this looks like it won't have the same results. Before, one branch defined a = ax / ay and the other defined a = ay / ax, which I only noticed because the PRed implementation always divides by ay, even if it is 0.0. I'll see what I can do to keep the spirit of the changes while also maintaining the same results. I'll double-check this first, just in case I don't need to revert.

Using a JUnit test:
Assert.assertEquals("Failed on iteration " + i + " with x=" + x + ", y=" + y, (Math.atan2(y, x) * 0.5 / Math.PI + 1.0) % 1.0, TrigTools.atan2(y, x), 0.001);

I get this test failure on the second test (the first checks atan2_(0.0f, 0.0f)):
java.lang.AssertionError: Failed on iteration 1 with x=11.580078, y=5.0429688
Expected :0.0653679988305087
Actual   :-1.1383031606674194

That's definitely off by a lot, especially considering this should return values in the 0.0 to 1.0 range. I should have the code back to its original state in a minute or two.


Sum of Left Leaves

Description
Given the root of a binary tree, return the sum of all left leaves.
Fixes #2415
Replace #2415 with the issue number which is fixed in this PR
Input: root = [1]
Output: 0
Checklist:

[ ] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have created a helpful and easy to understand README.md
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

@Ayush7614 Bhaiya read code


A better payload

This is a version of the previous pull request but with some bug fixes.  I think it's ready for submission now.

I'll resend this, as I included something in it accidentally :(

I'll resend this, as I included something in it accidentally :(


Are *.gem files cached for 30 minutes or indefinitely?

The gem dependencies from https://rubygems.org are cached for 30 minutes, so if you bundle again before that, you can successfully bundle without an Internet connection:

It's not clear to me what exactly happens.

Gem dependencies (what depends on what - the metadata) is cached for 30 minutes. Cached gems (*.gem files) are cached indefinitely.
Gem dependencies (that is, gems, as a dependency of a gem is another gem) is cached for 30 minutes. *.gem files disappear after 30 minutes.

Can you clarify here or, better yet, in the documentation itself?

Gemstash has saved my life. Fastly seems to have a problem recently at DigitalOcean/Gitlab.com CI runners and Gemstash helped the situation. Thanks for your great work.

What gets cached is the former option.
We cache the metadata for 30 minutes, gems are immutable, therefore they are cached indefinitely.
How could that be written in the documentation to make it clearer?
Glad to help you both with GL and Gemstash :)

I would phrase it like this:

Gem files (*.gem) are caches indefinitely. The gem dependency metadata are cached for 30 minutes, so if you bundle again before that, you can successfully bundle without an Internet connection.

@Nowaker I committed this change but set you as the author: 339d84a246ac637664e1079c7e542860e508baa8
If you are ok with this, I'll create a PR for it :smile:

@smellsblue All is fine, thank you. :)


Grunt tasks broken

I'm running into all sorts of problems getting dist to build. Running ./node_modules/.bin/grunt dist fails. Once I fix an issue, another one crops up.

jshint would fail, so I updated to the latest grunt-contrib-jshint
jshint ran, but several errors in lib/loglevel.js, so I fixed them
Now phantomjs won't run in task jasmine:requirejs

I tried updating all dependencies to the latest versions. Now I'm not getting an error, but PhantomJS times out with a message saying there may be an async test that never finishes.
Would really help if git clone ...; npm install; grunt dist just worked...
Also it would be nice if it didn't depend on grunt being installed installed globally. I suggest adding "dist": "./node_modules/.bin/grunt dist" to the package.json scripts and building with npm run dist.

Sorry for the delay! Totally agree this should work. Now fixed, and I've added npm aliases for everything too, using a local grunt. For me clone -> install -> npm run dist now all works reliably. Let me know if you (or anybody else!) has any other trouble with this.


DCC validity check: Wrong entry rules for Malta

Avoid duplicates

[X] Bug is not mentioned in the FAQ
[X] Bug affects both Android and iOS, for specific issues / questions that apply only to one operating system, please raise them in the respective repositories:

Android repository
iOS repository

[X] Bug is not already reported in another issue

Technical details

Device name: Not important
iOS/Android version: Not importan
App version: Not important

Describe the bug
The DCC entry validity check uses wrong rules for Malta. It rejects all certificates as invalid if they are older than 90 days, however, according to https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en the validity period of 270 days is binding.
Malta also states that the 270 days is actually the rule (see https://deputyprimeminister.gov.mt/en/health-promotion/covid-19/Documents/Standards_vaccine_certificate_validity_100322_clean.pdf).
Steps to reproduce the issue
Should be clear, you have to use a certificate of a person which is older than 18 years.
Expected behaviour
Malta should have rules which complies with the actual rules set by the country.
Possible Fix
Relay this to Malta.
Additional context
Is there any good place to report such issues? The CWA repos seem to be the wrong place, IHMO.

Unfortunately MT has not the prod BR as test data uploaded but you can see the latest uploader. But I'm not sure if this repo is the correct one for an issue
https://github.com/eu-digital-green-certificates/dgc-business-rules-testdata/tree/main/MT

@thomasaugsten
I just need an advice where to report such issues then, where they not only lay around without being touched but where Malta actually takes a look at the problem.

@Ein-Tim
I can reproduce this issue with a 2/2 vaccination certificate. It is failing rule VR-MT-0010 (1.0.0) on CHECK VALIDITY FOR TRAVEL on CWA Android 2.19.1. See https://timokoenig.github.io/eu-dcc-rules/?ruleset=eu-dcc-rules&country=MT&rule=VR-MT-0010 for the rule.
"EN: Verification Datetime must be less than 90 days after vaccination of 2nd dose for age >18"
With a 3/3 booster vaccination certificate, the test passes for Malta and I get a green tick.
You should probably revise your problem description if you can confirm that a 3/3 certificate works.

IHMO

I translate to IMHO.

My advice is to use the dgc busines rules testdata repo and tag the person which created the test data for MT.

@thomasaugsten
Issue opened: https://github.com/eu-digital-green-certificates/dgc-business-rules-testdata/issues/105
I'll close this issue here now, however, if there is no feedback in the next 2 weeks, I'll reopen it.

@Ein-Tim
Did you try with a 3/3 certificate?
Was it rule VR-MT-0010 (1.0.0) which failed for you? You did not mention this rule in https://github.com/eu-digital-green-certificates/dgc-business-rules-testdata/issues/105. A screenshot might have been helpful.

@MikeMcC399
I'll extend the report later this evening, I'm quite busy, sorry!

@Ein-Tim
The rules are aligned to https://deputyprimeminister.gov.mt/en/health-promotion/covid-19/Pages/travel.aspx
For Adults aged 18 years and over:

primary schedule  with last dose administered not more than 3 months previously OR
primary schedule1 and booster with last dose of booster administered not more than 9 months previously

@MikeMcC399
So you think the rules Malta has on https://reopen.europa.eu/de/from-to/DEU/MLT are wrong?

@Ein-Tim

So you think the rules Malta has on https://reopen.europa.eu/de/from-to/DEU/MLT are wrong?

I think I misread the information. The text I quoted was only for "A valid vaccine certificate issued by the Maltese Authorities is defined as follows: " Unfortunately the page is not well formatted.
Go ahead and see what the Maltese representative has to say. I think you are right that a EU 2/2 vaccination certificate should be sufficient for 270 days, except if it is a Maltese certificate, in which case a booster may be necessary, so they would need to add this exception for EU non-Maltese vaccination certificates to their rules.

@Ein-Tim

I see that https://github.com/eu-digital-green-certificates/dgc-business-rules-testdata/issues/105 has been closed.

An important part of this exchange is that it highlights there is no clear support path for issues with EU travel rules. That would be another issue though.

An important part of this exchange is that it highlights there is no clear support path for issues with EU travel rules. That would be another issue though.

Yep, I'm getting in touch with @dslmeinte to find a solution for this problem.

As always: Thanks for all your support, Mike! I really appreciate it! 👍


Modify generated web worker sw.js

Hello there,
just wanted to know if there's a way to modify (add event listener and callbacks ) to the generated sw.js. I mean before generating it such as we don't have to re modify it after every build

Hi @F-Moody
To enable events, use the ServiceWorker option.
For available events, see the runtime events config.

Hi,
thanks for the answer, i get that but what i'm wondering is where should i put the code for that event?

@F-Moody In your clients entry point, where you install (require('offline-plugin/runtime').install()) the service worker.
See the example code here

Great, thanks for the kindness!

@F-Moody no problems. Thanks for using this plugin. Will close this issue now.


Exception when loading data into server

I was loading data into the FHIR server (16 concurrent requests) and got this exception:
System.InvalidOperationException: Operations that change non-concurrent collections must have exclusive access. A concurrent update was performed on this collection and corrupted its state. The collection's state is no longer correct.
   at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
   at System.Collections.Generic.Dictionary`2.ContainsKey(TKey key)
   at Microsoft.Health.Fhir.Core.Features.Definition.SearchParameterDefinitionManager.UpdateSearchParameterHashMap(Dictionary`2 updatedSearchParamHashMap) in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Core\Features\Definition\SearchParameterDefinitionManager.cs:line 124
   at Microsoft.Health.Fhir.Core.Features.Definition.SearchParametersHashUpdatedHandler.Handle(SearchParametersHashUpdated notification, CancellationToken cancellationToken) in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Core\Features\Definition\SearchParametersHashUpdatedHandler.cs:line 26
   at MediatR.Internal.NotificationHandlerWrapperImpl`1.<>c__DisplayClass0_0.<Handle>b__1(INotification theNotification, CancellationToken theToken)
   at MediatR.Mediator.PublishCore(IEnumerable`1 allHandlers, INotification notification, CancellationToken cancellationToken)
   at Microsoft.Health.Fhir.Core.Features.Search.Registry.SearchParameterStatusManager.EnsureInitialized() in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Core\Features\Search\Registry\SearchParameterStatusManager.cs:line 145
   at Microsoft.Health.Api.Modules.InitializationModule.<>c__DisplayClass2_0.<<Configure>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.Health.Fhir.Api.Features.Context.FhirRequestContextAfterAuthenticationMiddleware.Invoke(HttpContext context, IFhirRequestContextAccessor fhirRequestContextAccessor) in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Api\Features\Context\FhirRequestContextAfterAuthenticationMiddleware.cs:line 36
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.Health.Fhir.Api.Features.Context.FhirRequestContextBeforeAuthenticationMiddleware.Invoke(HttpContext context) in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Api\Features\Context\FhirRequestContextBeforeAuthenticationMiddleware.cs:line 45
   at Microsoft.Health.Fhir.Api.Features.ApiNotifications.ApiNotificationMiddleware.PublishNotificationAsync(HttpContext context, RequestDelegate next) in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Api\Features\ApiNotifications\ApiNotificationMiddleware.cs:line 63
   at Microsoft.Health.Fhir.Api.Features.ApiNotifications.ApiNotificationMiddleware.PublishNotificationAsync(HttpContext context, RequestDelegate next) in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Api\Features\ApiNotifications\ApiNotificationMiddleware.cs:line 90
   at Microsoft.Health.Fhir.Api.Features.ApiNotifications.ApiNotificationMiddleware.InvokeAsync(HttpContext context, RequestDelegate next) in D:\repos\fhir-server\src\Microsoft.Health.Fhir.Api\Features\ApiNotifications\ApiNotificationMiddleware.cs:line 52

Is this on startup? The stack trace might suggest that SearchParameterStatusManager.EnsureInitialized() is being called multiple times

The exception was not on startup. I had been loading data for some minutes.

There is a fix out for handling concurrent calls to SearchParameterDefinitionManager.UpdateSearchParameterHashMap in the above PR. Theoretically this situation should arise only if EnsureInitialized is called twice on the SearchParameterStatusManager (which is not expected). I tried to repro this issue locally in order to understand the root cause. I ingested data at the rate of ~16 concurrent requests (using both CosmosDb and SQL as backing data stores) multiple times but did not run into this exception. I also checked our test and release environment logs and haven't seen this exception.

CLosing as we can't reproduce and have a PR to address the symptom


Add formater and linters via trunk.io

@Ardi028 trunk is free for open-source, so we shouldn't have an issue deploying it here.
https://trunk.io/pricing

I was actually looking for a linter to add to the project before, but I didn't know of any good ones, trunk is pretty great! 🎉
I have 2 small concerns:

I noticed that in the trunk.yaml file there were a few different linters enabled, do we want all of those enabled or do we only want "black" ?
I am a bit anxious to format any .md files because I have noticed that in the past when I was editing .md files and had prettier enabled on vscode it would change the formatting on save and the .md files would have issues.

Great, that you like it.
I am open to suggestions here, which formaters and linters to use and how there settings are.
These are the suggested ones, for the files we have present in the repo.
I would want some kind of formatig for all files in the repo.
The main issue of dealing with different formatig styles is agnostic of language.
So, that is for me a big plus for using trunk, that it manages all the different linters/formaters.
For your concerns about .md files, I think we should def. have some kind of formating for them.
How that looks like, we can decide.
I am sure, that we can adjust the settings, that it doesn't destroy the files.
Also if you are using vscode, trunk has a vscode extension that you can use.
I don't use vscode, so not useful for me, but it probably makes things smooth for you.
I am using old school emacs ;)

I definitely want more than just black.
Basically,
    - git-diff-check
    -<EMAIL_ADDRESS>    -<EMAIL_ADDRESS>    -<EMAIL_ADDRESS>    -<EMAIL_ADDRESS>    -<EMAIL_ADDRESS>
Are extermely helpful for me in most cases.
Especially, actionlint saves me a lot of time debugging workflows.
And the other are helpful too, even as I don't work as much with them.

That makes sense!


Looks like unit tests are not working using travis

Hello, I noticed something wrong about your unit tests playing on Travis :
If you click on the "passed" badge you can see on travis (https://travis-ci.org/drewm/mailchimp-api) that tests fails on PHP 5.4, 5.5 and 5.6 (because of a missing .env file) and are passing on PHP 7, 7.1 and 7.2.
But if you go on the job page where test passes (example https://travis-ci.org/drewm/mailchimp-api/jobs/308344530) you can see "No tests executed!".
Your test badge is hence displaying a false "passing".

They're set in the Travis environment directly. From the build output just now:
Setting environment variables from repository settings
$ export MC_API_KEY=[secure]
$ export MC_LIST_ID=[secure]

Yep, see that, its working now for PHP 5.4, 5.5 and 5.6. You know why tests are not playing on PHP 7+ versions ?


No moving object in first level

Make a moving object in the first level to show that physics are calculated each frame.

Added a block that goes back and forth along a set path.

Object can go through player


Allow for transforms

Most PyTorch datasets allow for transforms being applied to them. This might be very useful here too, for example, to transform the spike times into discrete spike trains. For an example see: https://pytorch.org/tutorials/beginner/data_loading_tutorial.html

Solved by #2

Solved by #2


[MM-47481] Remove Unread Channels From Channels Switcher

Summary

Removes the unreads section from the channel switcher. Only recent channels are listed with unread channels retaining the bolded formatting.
Ticket Link

MM-47481
Checklist

[x] Has UI changes

Device Information
This PR was tested on:

iPhone 14 Pro, iOS 16
Pixel 5, Android 13

Screenshots

iOS

Android

Release Note

NONE

@jfrerich gentle ping on this 🙂

Thanks @mylonsuren! So excited for this to get in

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/26119
https://circleci.com/gh/mattermost/mattermost-mobile/26118

Artifact links:
https://output.circle-artifacts.com/output/job/465f8d1d-60b6-455c-897a-7e0aa07f224b/artifacts/0/tmp/artifacts/Mattermost_Beta.apk
https://output.circle-artifacts.com/output/job/3c8b131f-1666-4682-93cd-be3da5bf4f06/artifacts/0/tmp/artifacts/Mattermost_Beta.ipa


feature: Support for Markdown text highlight using == e.g. ==I'm a highlighted text==

Is your feature request related to a problem? Please describe.
Sort of. Obsidian.nvim supports text highlighting using == pairs, as it seems to be the case as well for Obsidian, Quilt, iA Writer, HackMD, Typora to name a few. This converts toward <mark>I'm a highlighted text</mark>.
In order to benefit from this awesome plugin of yours, it's preferable to disable Obsidian.nvim ui module. Since your plugin does not yet support the highlighting syntax, this surface a regression if we turn off Obsidian.nvim ui module.
The highlight option in Markdown is super valuable for folks using a markdown wiki as their Second Brain and practicing Progressive Summarization
Describe the solution you'd like
The solution I would see is the support for the ==highlighted text== syntax. A configuration could be:
require('render-markdown').setup({
    highlight = {
        enabled = true,
        background = 'RenderMarkdownHightlightBg'
        foreground = 'RenderMarkdownHightlight'
    },
})

You may have a much better and straightforward approach.
Describe alternatives you've considered
Tried to follow this Stackoverflow thread answer without luck
Additional information
No response

Duplicate of: https://github.com/MeanderingProgrammer/render-markdown.nvim/issues/173
I rely completely on tree-sitter to do the heavy lifting of getting relevant sections of the buffer to add decorations to. This has the upsides of being fast, well defined, and easy to use, but comes with the downside that if I can't pull the node directly I'm probably not going to add it to the plugin. Custom parsing is just not something I want to include in this plugin for my own sanity.
Since the == syntax is not part of github flavored markdown it's not included in the tree-sitter parser. If it gets added at some point I can add this feature.
I get it's a kind of regression and the feature feels like it would be simple to add, but that's unfortunately just not the case, at least currently.
I do include a custom_handlers implementation of this feature that you can try out in your config in the original issue, it's by no means perfect but might work well enough.

Oh thank you so much, I knew you would have a much better and straightforward approach.
The custom_handlers you produced works well if the highlighted text is contained on the same line. As I do wrap text that exceeds 80 characters width (for readability), if I want to highlight across the wrapped lines then it's unfortunately not working.
I'm unfortunately not really familiar with the Lua language and the treesitter framework. Would this be an easy patch to the handler to enhance the capture of the highlight across multiple lines?
I believe that this handler would be a nice addition to your Custom handlers page, as it is not yet crowded with recipes as well as this is already the second time you are asked about this, and more over that as long as treesitter markdown grammar implementation does not support it, it is super valuable asset.
Thank you for the support so far

It's not super straightforward. Once you have the text from local text = vim.treesitter.get_node_text(root, buf)
You would run the pattern match directly on the text rather than splitting to each line. Then you would need to do some offset calculation based on the range returned from calling find.
It gets tricky since you have to find offset from nearest line boundaries as well as the number of lines covered to figure out the start / end row / column.

I played around with a multi-line version and came up with this:
require('render-markdown').setup({
  custom_handlers = {
    markdown = {
      extends = true,
      parse = function(root, buf)
        local marks = {}

        ---@param row { [1]: integer, [2]: integer }
        ---@param col { [1]: integer, [2]: integer }
        ---@param conceal? string
        ---@param hl_group? string
        local function append(row, col, conceal, hl_group)
          table.insert(marks, {
            conceal = row[1] == row[2],
            start_row = row[1],
            start_col = col[1],
            opts = { end_row = row[2], end_col = col[2], conceal = conceal, hl_group = hl_group },
          })
        end

        local text = vim.treesitter.get_node_text(root, buf)
        local top_row = root:range()

        ---@param index integer
        ---@return integer, integer
        local function row_col(index)
          local lines = vim.split(text:sub(1, index), '\n', { plain = true })
          return top_row + #lines - 1, #lines[#lines]
        end

        ---@type integer|nil
        local index = 1
        while index ~= nil do
          local start_index, end_index = text:find('(=)=[^=]+=(=)', index)
          if start_index ~= nil and end_index ~= nil then
              local start_row, start_col = row_col(start_index - 1)
              local end_row, end_col = row_col(end_index)
              -- Hide first 2 equal signs
              append({ start_row, start_row }, { start_col, start_col + 2 }, '', nil)
              -- Highlight contents
              append({ start_row, end_row }, { start_col, end_col }, nil, 'DiffDelete')
              -- Hide last 2 equal signs
              append({ end_row, end_row }, { end_col - 2, end_col }, '', nil)
              index = end_index + 1
            else
              index = nil
            end
        end

        return marks
      end,
    },
  },
})

I played around with a multi-line version

This works like a charm :1st_place_medal:. Thank you so much! You saved my day here. I hope this will benefit more people down the line :pray:.
It may be worth to include it among your examples/recipes of custom handlers, this remains obviously your call :wink:
Thank you again so much!

This is now handled natively by the plugin after: https://github.com/MeanderingProgrammer/render-markdown.nvim/commit/d6a82d70765aa238b7ea48d257a1d57a92501423

Oh thank you so much for this addition :heart:
I just gave it a try, highlighting some french text with accents, and it behaved weirdly. Just as if accents were left out of the column tracking or something. It's getting worse as we move the cursor away for the line. I attached a video capture of this in the hope that it give you a better visual representation of what I mean.
https://github.com/user-attachments/assets/bb9a1733-05ac-4fc0-9e0c-f3183828477d
Here is the text used for the attached video capture if you want to give a try at fixing this:
Un jour Cosette se regarda par hasard dans son miroir et se dit : Tiens ! Il lui semblait presque qu’elle était jolie. Ceci la jeta dans un trouble singulier. Jusqu’à ce moment elle n’avait point songé à sa figure. Elle se voyait dans son miroir, mais elle ne s’y regardait pas. Et puis, on lui avait souvent dit qu’elle était laide ; Jean Valjean seul disait doucement : Mais non ! mais non ! Quoi qu’il en fût, Cosette s’était toujours crue laide, et avait grandi dans cette idée avec la résignation facile de l’enfance. Voici que tout d’un coup son miroir lui disait comme Jean Valjean : Mais non ! Elle ne dormit pas de la nuit. — Si j’étais jolie ? pensait-elle, comme cela serait drôle que je fusse jolie

Ah, thanks, messed up the usage of displayed width vs. byte width. Should be fixed after: https://github.com/MeanderingProgrammer/render-markdown.nvim/commit/3a319cdbefebf0079a7012dab6b1bfc18ca5b97f.

Just tried the fix. It works! Thank you so so much :trophy:


WICKET-5827 Allow to apply multiple Javascript / CSS compressors (wicket-6.x)

Allow multiple ICssCompressors and IJavaScriptCompressors
CssUrlReplacementCompressor

Linked JIRA ticket: https://issues.apache.org/jira/browse/WICKET-5827

This PR has been integrated. Thanks a lot @martin-g
For more information see:
https://issues.apache.org/jira/browse/WICKET-5827?focusedCommentId=14320747&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14320747


Write security invariants for every component

For assistance on the audit, every component should have a list of invariants / assumptions for use and for every function. For example, the Owner component's list would include:

The root storage key is not used for any other data.
Only the owner will ever be able to call own_renounce_owner, own_propose_owner.
Only the account most recently proposed (by the current owner, via own_propose_owner) will be able to call own_accept_owner.
After own_accept_owner has been called, the formerly "proposed owner" will become the owner, and the former owner will be removed. There will not be a "proposed owner".
Et cetera.

This list should appear in the module level documentation comments for each component.

Taking a look at some of the components, I've observed that only few contracts expose external functions and even fewer have in-variants. For e.g.

Owner - multiple invariants - docs added in #75
Rbac - no external functions - no visible invariants in default trait implementations
Pause - one external function - no visible invariants in default trait implementations
Migrate - one external function - User needs to provide migration implementation

Is the current audit only about documenting invariants for external functions?

@twitu Good point. It should be about invariants for all functions, regardless of externality.


Fix #46, Support Loading of Assembly Instructions

Adds support for loading assembly instructions from a file, string or a byte array.
Adds support for loading this into the memory.

Leaving the WIP tag on this. Will tag as ready for review when working.

Fixes #52
The actual opening of a file will be left up to the user, but list file now works and is in the JSON format


Incorrect construction of RecordException

In case of broken .record file there is an attempt of creating RecordException object:
https://github.com/daohu527/cyber_record/blob/83656db63ab90be1e6104a12de07fef6fd3eb6eb/cyber_record/reader.py#L268
but it has overrided init function without accepting additional arguments:
https://github.com/daohu527/cyber_record/blob/83656db63ab90be1e6104a12de07fef6fd3eb6eb/cyber_record/record_exception.py#L19
I suggest, that RecordException class should be left empty:
class RecordException(Exception):
    pass

@IvDmNe Yes, you are right, I want to create a custom exception to prompt the error message. You can submit a PR to fix it!


test: behaviors-message_on_lock_failure (2024-02-07 23:15:24.162790+00:00)

automatic test cleanup


Update index.html

@jmlopez2332   thanks for making your first contribution, I will be merging your Pull Request, also look at the issues so that you can get a chance to win a limited community Swag from me.
If you like the project and Repo please give it a star and Follow me on Github (would be appreciated)

@jmlopez2332  try this year for Hacktoberfest and have a look at the updated repo and contribute.
HAPPY HACKING


Topologically incorrect GeoJSON data makes pipeline application crash

This was reported by Michael. We should use some tool to check the topology and give a reasonable warning about it.

Solution candidate: https://pypi.org/project/geojson-rewind/


Update SIKART links

SIKART appears to have new URLs. Point URLs to  https://recherche.sik-isea.ch/de/sik:person-{ID}

works again, maybe temporary glitch


mbedtls_ssl_handshake crash (PSRAM unicore + memw workaround) (IDFGH-3068)

Code to reproduce is based on a modified https_mbedtls example from esp-idf:
https://github.com/szmodz/esp-idf/commits/mbedtls_crash
The code always ends up causing a WDT timeout sooner or later (timeout set to 60s) in UNICORE mode. CONFIG_MBEDTLS_HARDWARE_xxx are disabled, but it doesn't really matter.
Seems to be MUCH more stable with dupldst rather than memw workaround (not sure if it's completely stable though - too soon to tell). No other changes were made, and the effect on stability is obvious.
Perhaps it would be a good idea to also supply newlib and sdk libs compiled with dupldst?
The handshake is using nonblocking sockets and resets the WDT, so I don't think it should ever exceed the 60s timeout. That, plus it seems stable (so far) with dupldst.
It's a pretty intensive load, but that way the problem can be reproduced quickly. It also occurs under normal load conditions, but not as often. I noticed it in my actual application code.

Development Kit:     ESP32-DevKitC (but also custom hardware with ethernet)
Kit version (for WroverKit/PicoKit/DevKitC): v4
Module or chip used:  ESP32-WROVER-B
Build System:         Make
Compiler version (run xtensa-esp32-elf-gcc --version to find it): 2020r1
Operating System:     macOS
Using an IDE?: No
Power Supply:         USB (custom HW has external power)

example output:
E (116633) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (116633) task_wdt:  - https_get_task (CPU 0/1)
E (116633) task_wdt:  - https_get_task (CPU 0/1)
E (116633) task_wdt:  - https_get_task (CPU 0/1)
E (116633) task_wdt:  - https_get_task (CPU 0/1)
E (116633) task_wdt: Tasks currently running:
E (116633) task_wdt: CPU 0: https_get_task
E (116633) task_wdt: Aborting.

abort() was called at PC 0x400d2e04 on core 0
0x400d2e04: esp_task_wdt_init at /Users/szmodz/xxx/esp-idf/components/esp_common/src/task_wdt.c:213

Backtrace:0x40087359:0x3ffb1350 0x400877dd:0x3ffb1370 0x40095c11:0x3ffb1390 0x400d2e04:0x3ffb1410 0x40082e8e:0x3ffb1430 0x400953a8:0x3fff2210 0x400e817e:0x3fff2220 0x400e8a17:0x3fff2240 0x400e8b1a:0x3fff2270 0x400ddab1:0x3fff2290 0x400de16b:0x3fff2320 0x400df2ba:0x3fff24c0 0x400eace9:0x3fff2650 0x400eaeaf:0x3fff26c0 0x400da5c1:0x3fff26f0 0x400d72e5:0x3fff27b0 0x400d7304:0x3fff27d0 0x400d732a:0x3fff27f0 0x400d4eb4:0x3fff2810
0x40087359: print_illegal_instruction_details at /Users/szmodz/xxx/esp-idf/components/esp_system/port/panic_handler.c:73

0x400877dd: esp_system_abort at /Users/szmodz/xxx/esp-idf/components/esp_system/system_api.c:68

0x40095c11: abort at /Users/szmodz/xxx/esp-idf/components/newlib/abort.c:46

0x400d2e04: esp_task_wdt_init at /Users/szmodz/xxx/esp-idf/components/esp_common/src/task_wdt.c:213

0x40082e8e: _xt_lowint1 at /Users/szmodz/xxx/esp-idf/components/freertos/xtensa/xtensa_vectors.S:1105

0x400953a8: strrchr at /builds/idf/crosstool-NG/.build/HOST-x86_64-apple-darwin12/xtensa-esp32-elf/src/newlib/newlib/libc/string/strrchr.c:38

0x400e817e: mbedtls_internal_aes_decrypt at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/aes.c:961

0x400e8a17: mbedtls_aes_crypt_xts at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/aes.c:1246 (discriminator 3)

0x400e8b1a: mbedtls_aes_crypt_xts at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/aes.c:1222

0x400ddab1: ecp_normalize_jac at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ecp.c:1105

0x400de16b: ecp_normalize_jac_many at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ecp.c:1173

0x400df2ba: mbedtls_ecp_curve_info_from_tls_id at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ecp.c:490
 (inlined by) mbedtls_ecp_tls_read_group_id at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ecp.c:953

0x400eace9: mbedtls_ecdsa_read_signature_restartable at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ecdsa.c:834

0x400eaeaf: mbedtls_asn1_write_len at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/asn1write.c:58

0x400da5c1: ssl_write_client_key_exchange at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ssl_cli.c:3160
 (inlined by) mbedtls_ssl_handshake_client_step at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ssl_cli.c:3586

0x400d72e5: mbedtls_ssl_handshake_free at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:8837

0x400d7304: mbedtls_ssl_handshake_free at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:8866

0x400d732a: mbedtls_ssl_handshake_free at /Users/szmodz/xxx/esp-idf/components/mbedtls/mbedtls/library/ssl_tls.c:8893

0x400d4eb4: https_get_task at /Users/szmodz/xxx/esp-idf/examples/protocols/mbedtls_crash/main/https_mbedtls_example_main.c:202

Thanks for reporting, we will look into.  @szmodz

updated the test code - noticed a bug, but I don't think it's relevant to the problem.

maybe related: https://github.com/espressif/esp-idf/issues/5112

@iggr @Spritetm
Shouldn't the memw fix look something like this (volatile fix by jcmvbkbc)?
https://github.com/szmodz/gcc/commits/esp_based_on_8_2_0
Currently testing with the above example, seems to work much better, will leave it a while.

I've also pushed a modified version of the nop fix (not tested).
Note the dupldst fix turned out not to be completely stable in my application (I think I know why).

Can you expand a bit more on what you tried to fix in those modifications? I can reverse engineer them from your code probably, but if you can write down a line or two, that's probably faster.

@Spritetm mostly the crashes as described in the linked example. You can reproduce them, right?
Mostly i think this is a bug:
https://github.com/szmodz/gcc/blob/9ec9bb29ecbc935015e487ae4d9397a8976099e7/gcc/config/xtensa/xtensa.c#L2338
It doesn't matter if the store is volatile, as the memw is inserted before the store, not after. I indicated this in a comment. I think the assignment last_hiqi_store=insn should be unconditional.
https://github.com/szmodz/gcc/blob/9ec9bb29ecbc935015e487ae4d9397a8976099e7/gcc/config/xtensa/xtensa.c#L2342
Without the volatile fix there's actually a bug here. The're won't be any memw before the (8 or 16 bit) load, and it won't work as expected (unprotected store-load sequence). I also think the volatile test should be inside if (store_insn) , store_insn=NULL should be executed in case of volatile loads, as the load itself should provide the barrier.
Other changes mostly aimed at improving readability and preventing some redundant memws. Do you really need two memws for a 8/16 bit store near an unconditional jump?

@igrr @Spritetm the original nop-based workaround has a bug too.
insns_since_store is incremented only here:
https://github.com/espressif/gcc/blob/9ec9bb29ecbc935015e487ae4d9397a8976099e7/gcc/config/xtensa/xtensa.c#L2297
it should also be incremented here:
https://github.com/espressif/gcc/blob/9ec9bb29ecbc935015e487ae4d9397a8976099e7/gcc/config/xtensa/xtensa.c#L2292
if (attr_condjmp == CONDJMP_UNCOND) {
...
} else {
insns_since_store++
}

So in some cases, not enough nops get inserted, which presumably causes problems.
I actually tested my version of the nop workaround with neoniousTR's original test case, and it seems to work ok?
https://github.com/szmodz/gcc/blob/3d06d4d9451bcc14f9af63e95d83741231269347/gcc/config/xtensa/xtensa.c#L2269

pre-built linux toolchain:
https://github.com/szmodz/gcc/releases/tag/2020r1-fixed
I've also made a minor forced-push to the repo.

Wait, doesn't the esp32 have a 7 stage pipeline? it says so in the DS.
The nop patch seems to assume a 5 stage pipeline.

Yes, it does, but at that time experiments showed that the first two stages (or the last two, or the first and the last; I don't know exactly) seemingly weren't involved in the load/store inversion.

Also, a bit late perhaps but I can verify the bug and the fact that this is likely a PSRAM bug. On my ESP32 ECO1, the program hangs; on an ESP32 ECO3, the program continues to run and crashes eventually, possibly because an out-of-memory error.
Wrt the bugs: they indeed look like valid fixes/optimizations to me. Unless you think there's more work to be done there, we can take them and run them through our paces in our CI system. It's not perfect (as seemingly it didn't catch the previous bugs in the code) but it should at least tell us if there's some bug the mods may tickle.

Good to go I suppose. I didn't touch the dupldst workaround though, similar issues still apply.
ECO3 crash - was that with the original https_mbedtls example, or with the modified mbedtls_crash?

I don't think there are any memory leaks in mbedtls_crash. It's been running for days with the fixed memw workaround. I added printing of free internal and external RAM just now and it also looks ok.

The ECO3 crash was with your modified code. As far as I can see, it spins up a lot of threads creating a TLS connection in parallel, so I assumed it would be an out-of-memory error.

It does spin up threads, but the connection is closed as soon as the TLS handshake is done, it doesn't download any actual content.
Should probably investigate. I'm not getting any crashes with the fixed toolchain:
https://github.com/szmodz/gcc/releases/download/2020r1-fixed/xtensa-esp32-elf.tar.xz

It could possibly be an Internet speed thing. If the connection is made fast enough, the tasks end pretty soon and they don't 'heap up'. My connection here isn't that great, and as such the tasks do get the chance to all be active at the same time, which presumably leads to the out-of-memory condition.

The TLS handshake is actually CPU bound. It always takes around 1s to complete.
I also noticed this:
https://github.com/espressif/esp-idf/commit/3feffdfe0305a2c886b130971b9e6aee990c5b65
or it might be related to the volatile bug (fixed in the patched toolchain):
https://github.com/espressif/esp-idf/issues/5112

Also, the number of tasks is a constant 15. Each has an infinite loop.

updated the example to include free memory information:
https://github.com/szmodz/esp-idf/tree/mbedtls_crash
the updated example is running 23 hours (fixed toolchain), no crashes / hangs so far.

Made a change to the patch. Don't ask me why it matters, but it does.
https://github.com/szmodz/gcc/commits/2020r1-fixed

@szmodz Hi! https://github.com/szmodz/esp-idf/tree/mbedtls_crash is 404 Could you show the example?

@antmak it's back up.
https://github.com/szmodz/esp-idf/tree/mbedtls_crash


Fix find unsafe regexp.

Negation [^...] refers to everything in square brackets, to negate \w, use \W.

I don't really understand how the regexp was unsafe. The regexp was copied from the Python 3 standard library. Can you provide a few examples that are problematic?

My bad.


filter function for Instagram Hashtag

is it possible to add a filter function for Instagram Hashtag, such as filter out some key words to make the subscription more relevant.

You can try FilterBridge


Cooldown persistence

This pull request merges into main the ability to persist the state of cooldowns

This PR is at a stable state. Simply need to test loading and then should be able to finally merge

Closes #4


Cannot stream and query in parallel

I'm trying to do the following. I have one big (~1M rows) table that I want to stream (using .stream()). Then, for each of the rows I get, I use the accountId field and then query 1 other table by this accountId. I want it to work "in parallel, while streaming". So, on each row I get from the stream I invoke a callback function, in which I execute query like select * from Table2 where id = "<my id here>".
Expected behaviour: streaming goes in parallel with these queries in the callback. So, for example, I can see my console.log AFTER inner query is done.
Actual behaviour: inner queries do not finish executing until streaming is fully finished (all 1M rows). I can't say at this point why - and this is my main question in this issue.
Important note that streaming is done on Table1 and inner query is on Table2 (so, different tables).
Yes, I DO use pool and get connection from the pool. Also tried to open many connections in preparation step and just give it to my stream and queries (like, "manual pooling"), but same results.
I connect to locally installed MySQL on Mac (installed with brew install mysql).
If it's not enough info - I can provide a minimal reproduction repo, since it's important for me to understand and resolve this.
ps: BTW, I've tried the same script on mysql2 package, which claims to be API-compatible. I've got exactly same behaviour as with mysql package.

As long as you are using a separate connection to make those queries during the streaming on the first connection, the only thing I can think of is there is locking happening on the database itself.
Can you provide instructions on how to reproduce the issue? We can help to see why it is happening and narrow down if the issue is (a) with your code (b) with this module (c) with the mysql server or (d) something else.
Based on the description alone I would lean toward either (a) or (c), though if you are certain you are using separate connections it would sound likely to be (c)

Closing due to inactivity.


Markdownify some pages.

A few wording tweaks, but generally just html->markdown.
Weird thing I noticed: projects/checks.html doesn't exist on my local jekyll, but projects/checks/index.html does. May need an emergency PR to fix that depending on what github's jekyll builder does with this.

I'm genuinely angry that git ignored the fact that I 'git mv'-ed those files to try to keep their histories intact. Sigh.

On the plus side, the checks page looks cleaner.


[main] Add kernel-drivers-gpu package

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Summary

What does the PR accomplish, why was it needed?
We were discarding/not packaging any of our built gpu driver kernel modules. Add them back in as a new kernel subpackage.
Change Log

Add kernel-drivers-gpu package

Does this affect the toolchain?

YES
Associated issues

https://microsoft.visualstudio.com/OS/_workitems/edit/41518258

Test Methodology

pipeline run


Can't install PowerShell

Brief description of your issue

I can't install PowerShell due to duplicate IDs. I think this might in part be due to PowerShell core changing name to PowerShell (I may be wrong). In part this is related to #292 but due to the duplicate IDs I see no way of selecting the desired package. as -v <version number> seems to be ignored
Steps to reproduce

Run winget install powershell returns:

Expected behavior

PowerShell 7.0.1 installed
Actual behavior

Multiple apps found matching input criteria. Please refine the input.
Name               Id                           Version
---------------------------------------------------------------
PowerShell         Microsoft.PowerShell         7.0.1
Powershell Core    Microsoft.Powershell         7.0.0
PowerShell-Preview Microsoft.PowerShell-Preview 7.1.0-preview.3

Attempting to specify the desired version via winget install PowerShell -v 7.0.1 gives the same output
Specifying the Id rather than the Name via  winget install Microsoft.PowerShell -v 7.0.1 once again just produces the list
Environment
[winget --info]
Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.18363.836
Package: Microsoft.DesktopAppInstaller v1.0.41331.0

@TomBrien Thanks for reporting this problem. However, I'd recommend closing this issue as this problem has been reported multiple times already:

#133
#282
#301

What you are looking for as an immediate solution is the --exact (-e) parameter until the user experience of the winget commands has been improved.

My bad. cheers

I'm seeing the same issue
C:\Users\emarq.REDMOND\Downloads\ICM> winget install --name PowerShell --id Microsoft.PowerShell
Multiple apps found matching input criteria. Please refine the input.
Name               Id                           Version
---------------------------------------------------------------
PowerShell         Microsoft.PowerShell         7.0.1
PowerShell-Preview Microsoft.PowerShell-Preview 7.1.0-preview.3
C:\Users\emarq.REDMOND\Downloads\ICM> winget install --name PowerShell --id Microsoft.PowerShell -v "7.0.1"
Multiple apps found matching input criteria. Please refine the input.

@ebmarquez This issue has already been closed and a solution can be found in my reply above as well as in the issues that I've linked to.


[AERIE-1692] Connect Step Simulation to the scheduler

Tickets addressed: AERIE-1692
Review: By commit
Merge strategy: Merge (no squash)

Description
In the first commit, the IncrementalSimulationDriver is fixed:

the exit condition in simulateSchedule has been changed: it does not only wait for all tasks to be finished but also all the events that might be immediately/instantly triggered by these activities (changing the value of a register for example). This bug has been found after running a test involving the banananation mission model.
a private method has been added to simulate until a certain time, without new activities. This method is used to generate simulationResults up to a certain time.

Second commit is making the duration getters return Optional so it is cleaner from the outside.
Third commit is adding a SimulationFacade member to SimResource to prepare for changes in 5th commit.
Fourth commit adds the possibility of passing a SimulationFacade to the Problem ctor as there can be a need for a SimulationFacade defined outside the Problem, when building a problem P2 from another problem P1 for example as goals defined in P1 are referencing resources from the simulation facade contained in P1.
Fifth commit is the actual connection between step simulation and scheduling : 1) replace simulatePlan in SimulationFacade by incremental operations simulateActivity and removeActivityFromSimulation 2) resources are updated only when necessary depending on the queried time domain in addition to the current validity of simulation results making the simulation of empty plans at initialization now useless.
Sixth commit is removing the SimulationDriverFacade whose role is handled by SimulationFacade.
Seventh commit is removing the last traces of the merlinsight jar from the gradle file after merge with #63.
Verification
Scheduler tests, including MerlinsightTests (that require the AerieLander mission model), were run successfully.
Documentation

Check the step simulation engine for accuracy.
Future work

Caching for resources: when querying SimulationResults, it would be great to be able to query them only for a certain time window. Then, querying the simulation results could also become more incremental.
Using a dependency graph to avoid triggering simulation only to get back simulation results

The plan is to merge #54 before this PR, so that @adrienmaillard can rebase onto it.

@mattdailis looks like #54 is marked as "do not merge"

@mattdailis looks like #54 is marked as "do not merge"

Yes - you're right. I marked it with that because although it has two approvals, I haven't tested a key piece of its functionality yet. In particular, I want to make sure I got the JAR loading logic correct for the new SchedulerPlugin. I'm working on testing that right now, and if it works I'll remove the label and merge that PR :+1:

Ahh got it, good thinking!


bftpd: 4.8 -> 4.9

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/bftpd/versions.
These checks were done:

built on NixOS
ran /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/bin/bftpd -h got 0 exit code
ran /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/bin/bftpd --help got 0 exit code
ran /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/bin/bftpd -v and found version 4.9
ran /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/bin/bftpd --version and found version 4.9
ran /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/bin/bftpd -h and found version 4.9
ran /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/bin/bftpd --help and found version 4.9
found 4.9 with grep in /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9
directory tree listing: https://gist.github.com/f0a3568c5073cae5ff7e99964b767161

cc @7c6f434c for review

Success on x86_64-linux (full log)
Attempted: bftpd
Partial log (click to expand)
moving /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/man to /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/share/man
shrinking RPATHs of ELF executables and libraries in /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9
shrinking /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/sbin/bftpd
gzipping man pages under /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/share/man/
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/sbin
patching script interpreter paths in /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9
checking for references to /build in /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9...
moving /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/sbin/* to /nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9/bin
/nix/store/22swhqg3b1j8jxnlnndb9d4rhx5ajaam-bftpd-4.9

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: bftpd
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: bftpd
Partial log (click to expand)
moving /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9/man to /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9/share/man
shrinking RPATHs of ELF executables and libraries in /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9
shrinking /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9/sbin/bftpd
gzipping man pages under /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9/share/man/
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9/sbin
patching script interpreter paths in /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9
checking for references to /build in /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9...
moving /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9/sbin/* to /nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9/bin
/nix/store/zz1333nl5jfypvslxfvpk655r3fwb75h-bftpd-4.9


Changing the User ID starts a new session in the server

As opposed to the Web & iOS SDKs, when updating the user ID during a visit and sending a new event, the idvisit of that event is greater than the idvisit of the last event that the same user has created.
The Web & iOS SDKs conform the fingerprint concept that Matomo uses to stitch 2 visit with different user_ids.
The Android SDK does not conform as it only sends the required event parameters at the *very first event of the visit (via the Tracker::injectInitialParams).
The solution would be very easy, simply move the following 3 lines from the Tracker::injectInitialParams to the Tracker::injectBaseParams.
trackMe.trySet(QueryParams.SCREEN_RESOLUTION, mDefaultTrackMe.get(QueryParams.SCREEN_RESOLUTION));
trackMe.trySet(QueryParams.USER_AGENT, mDefaultTrackMe.get(QueryParams.USER_AGENT));
trackMe.trySet(QueryParams.LANGUAGE, mDefaultTrackMe.get(QueryParams.LANGUAGE));

With that being said, was there a reason that those parameters where not included in the Tracker::injectBaseParams to begin with? If not, I would be happy to provide a PR with the aforementioned solution.

The overlying reason to split up the injection was to reduce network traffic, but I wasn't aware of the  fingerprinting mechanism when implementing that.
Can we come up with a better solution than to just inject these parameters into every event so we can still try to prevent unnecessary traffic? Maybe once after the id has changed?

We can add a simple AtomicBoolean flag to the Tracker object, and raise it when setUserId is called. Then in the following call to the track method we could check that flag after the call to injectBaseParams and if it's raised inject the "deviceParams" and lower the flag.
What do you think @d4rken ? (I ran a little test and seems to be working fine now)

Yes you're right, that would be a problem.
OK this is still simple, what if we use the same code you used to lock a new session event at the top of the queue?
After the call to Tracker::tryNewSession in the Tracker::track(TrackMe) method, we will check if it was not a new session, then was the userId updated. We do that by comparing the received trackMe.get(QueryParams.USER_ID) to the member mLastEvent.get(QueryParams.USER_ID).
If they are different, set the mSessionStartLatch to 1, await, inject the Device Info params, and release.
Maybe I should change the name of the mSessionStartLatch to mCriticalInsertToEventQueueLatch or something like that.

That would work but the code might be too complicated for my taste.
I'll have a look at the synchronization code again later, I think we can simplify the whole track method by synchronizing on the Tracker instance, if we then synchronize the methods to change the user id, we should be good. Currently trying to remember why i implemented the latch based solution... 😁

We do that by comparing the received trackMe.get(QueryParams.USER_ID) to the member mLastEvent.get(QueryParams.USER_ID).

That's a cool idea, saves us an extrar global var. 👍

@NoyGri #210 should fix this, do you agree?
While simplifying the code I also noticed a bug that would cause the session-timeout to not work.

@d4rken yep, looks good to me. Also nicely done with the code cleanup :)

v3.0.3 is available contains the fixes and is on bintray now.
Thanks for teaching me about the server-side stitching 😃


Refactor historic CVE images

Lots of duplication in the current historic CVE images, would be nice to refactor this a bit into a common base image, where version specific changes are then applied as much smaller images, e.g.,
FROM warnet-base-image

# specific fixes with comments

Additionally, it would be nice to document the specific changes for each image. This is with the idea we may need to rebuild/edit these images at some point in the future, so just some good housekeeping to ensure maintainability.
Lower priority for now.

This is with the idea we may need to rebuild/edit these images at some point in the future, so just some good housekeeping to ensure maintainability

The images can be re-built now or any time in the future as they are currently in #498 (simly docker build ...), but I will happily review a PR refactoring commonality out of them if you see value in that.

closed by #539


Ensure all JSON is valid at ingestion time

Merge https://github.com/customelements/v2/pull/118 first


Internal Server error

🐛 The bug
I'm getting this error: GET http://localhost:3000/next_devtools/client 500 (Internal Server Error)
Everything setup as per the pages option, when firing run dev.
🛠 To reproduce
http://localhost
🌈 Expected behavior
To display the panel.
ℹ Additional context
No response

Is There a solution?

facing the same issue

Same problem

Hey @samerkassem82 , I can't seem to reproduce this error, I am using a mac laptop - which os are you on?

I am encountering a similar issue, but I get the following error:
Failed to proxy http://undefined:12883/__next_devtools__/client
Error: getaddrinfo ENOTFOUND undefined
    at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:120:26)
    at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
  errno: -3008,
  code: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'undefined'
}

Is it possible to manually set the address somewhere to resolve this undefined?
"next": "14.2.13"

I use address ip('lo') to get the host, but I don't know why it returns undefined
Currently using localhost as a fallback.


Add support for custom day format in JTCalendarDayView

JTCalendarDayView:122 uses a hard-coded day format of "dd" to display the days of the months in the calendar.
It would be nice if this format could be customized. For example we would like to be able to use "d" instead (no leading 0 for single digit days).
The simplest thing I can think of is to introduce a property on JTCalendarDay to be able to set the day format through [JTCalendarDelegate calendar:prepareDayView:]. The property could be a BOOL indicating if the day should be padded with 0 (default).

I just expose the dateFormatter of JTCalendarDayView, you just have to update the pod.


[POC] [5.6] Allow chaining multiple queue jobs

The code here is a (fully functional) proof of concept, so it's not fully fleshed out and has no tests.

To test, run php artisan queue:chain-table to publish the queue chain table migration. Then run php artisan migrate to actually create the table.  For example:
dispatch([new SomeJob(1), new SomeJob(2), new SomeJob(3)])->chain(
    new RunsAfterOthersHaveCompleted(),
);

All 3 SomeJobs will run in parallel. When they're done, the final one will run.

You can construct these chains as complex as you need them to be. At each step, you can have as many parallel jobs as needed. Here's another example:
dispatch([new SomeJob(1), new SomeJob(2)])->chain(
    [new SomeOtherJob(1), new SomeOtherJob(2)],
    [new YetAnotherJob(1), new YetAnotherJob(2)]
);

The SomeJobs will run in parallel. When done, the SomeOtherJobs will run in parallel. Finally, all YetAnotherJobs will run in parallel.
If you're familiar with JS promises, the above is similar to this:
Promise.all([someJob(1), someJob(2)])
       .then(() => Promise.all([someOtherJob(1), someOtherJob(2)]))
       .then(() => Promise.all([yetAnotherJob(1), yetAnotherJob(2)]));

This PR is a resubmission of #19515, with the race condition fixed.

dispatch([new SomeJob(1), new SomeJob(2)])->chain(
   [new SomeOtherJob(1), new SomeOtherJob(2)],
   [new YetAnotherJob(1), new YetAnotherJob(2)]
);

Would it make more sense to chain calls to ->chain()?
dispatch([new SomeJob(1), new SomeJob(2)])->chain(
    [new SomeOtherJob(1), new SomeOtherJob(2)])->chain(
    [new YetAnotherJob(1), new YetAnotherJob(2)]
);

chaining calls to ->chain() would be more synonymous with the JS Promise example that you referenced....

Holding off on this for now.


Correct spelling of the app name in the Mac plist file

Fixes the broken .app Mac executables.

@ckti rebased