Any chance to update dependencies like Guzzlehttp from 6 to 7 ?

Hi,
I'm trying to use your package.
It works great on its own but unfortunately I can't use it with my CRM which is using Guzzlehttp ^7.*
So I have a conflicted version because qonto-php use Guzzlehttp ^6.*
Do you plan to update the package ?

App\Log->error('Call to undefined method GuzzleHttp\\Utils::chooseHandler()
Error: Call to undefined method GuzzleHttp\\Utils::chooseHandler() in vendor/guzzlehttp/guzzle/src/functions.php:61

Regards,

I'm busy for the moment. But I accept Pull requests :)


bug: The edgy.nvim extra must be imported before the outline.nvim extra to work properly.

Did you check docs and existing issues?

[X] I have read all the LazyVim docs
[X] I have searched the existing issues of LazyVim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
v0.10.0-dev-2488+g5d4e1693c
Operating system/version
Windows 11
Describe the bug
Currently extras are ordered in the lazyvim.json file such that the ui.edgy extra can never be ordered before the editor.outline extra. My guess is that lazyvim.plugins.extras.ui.edgy needs to be added to the prios table with a sufficient priority to order it above editor.outline.
Steps To Reproduce

Add ui.edgy and editor.outline in Edgy Extras.
See the following warning: LazyVim The edgy.nvimextra must be **imported** before theoutline.nvim extra to work properly.

Expected Behavior
If ui.edgy is imported via lazyvim extras it should always be ordered before editor.outline if that ordering is required.
Repro
-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  "folke/LazyVim",
  -- add any other plugins here
}
require("lazy").setup({
  spec = {
    -- add LazyVim and import its plugins
    { "LazyVim/LazyVim", import = "lazyvim.plugins", version = "*" },
  }
}, plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Now open neovim, wait for lazy.nvim to bootstrap and install plugins, go to Extras, enable ui.edgy and editor.outline, then restart neovim.
This is the resulting lazyvim.json file.
{
  "extras": [
    "lazyvim.plugins.extras.editor.outline",
    "lazyvim.plugins.extras.ui.edgy"
  ],
  "news": {
    "NEWS.md": "2123"
  },
  "version": 2
}

Wow you're fast! Thanks @folke 😄

Sorry I don't understand how to correct this issue. I unloaded UI.EDGE, and reloaded and no matter what to do, I still have this one. It is now warning not error. Below is warning msg and all my extras

Sorry I don't understand how to correct this issue.

I had this issue today too too. With a recent update there was an autofix included and it fixed this issue without me doing anything. So this should be fixed I think.


killed units on runways

Hello, is there any way to clean the runways after a wee while of any ground unit it´s been destroyed on them? It´s preventing the CAP and AWACS flights to do their task. Not worried about the crater as they are repaired in an hour. But the killed units stay till the mission is restarted. Thank you

DCS does not provide a way of clearing wreckage at the current time. This was requested a few times over the years but ED has yet to address the issue.
For now the only way to clear wreckage is to restart the server.


Deploys to preview deployment from main branch

Hi,
For some reason the action stopped deploying for the production version and only creates preview deployments.
What we are doing is triggering the deployment with the following trigger:
on:
  push:
    tags:
      - "deploy"

And we are doing the tag push to the main branch.
In the end, we get a preview deploy and not a production one.
Here's our deployment yaml: https://github.com/Vonage/vivid-3/blob/main/.github/workflows/deploy.yml

+1 I'm getting the same from the the CLI and the interface in deno deploy just says PENDING

OK, so I've noticed that when I deploy via deployctl I need to promote my deployment to production before I am able to see it. That could indeed be the intention and it works for me. FIXED FOR ME

Hi,
Is this issue still happening? If so, can you check the production branch configuration for your project in the Deploy dashboard, and make sure it's main?


RDS 2.0

Soon, the new version of RDS standard will start to be integrated. It's backwards-compatible, but adds additional subcarriers to increase data throughput. It will have many new features: https://en.wikipedia.org/wiki/Radio_Data_System#RDS_2.0.
Will you implement it when the specifications are released?

As soon as I get example data!

Will reopen when at least one station transmitting RDS 2.0 can be received.

Seems German public broadcaster NDR is testing RDS2.0, see http://radioforum.foren.mysnip.de/read.php?8773,1427903
I've asked the user to get in contact with you.

There is now one station in Italy using RDS2.0, see https://www.rundfunkforum.de/viewtopic.php?p=1655588#p1655588 (incl. mpx recording).
The 66.5 kHz carrier transmits the station logo (says the encoder manufacturer)
The normal RDS is
$ redsea -r 192000 -f 53c5_rds2.wav
{"di":{"artificial_head":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"compressed":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"dynamic_pty":true},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"14A","other_network":{"pi":"0x53C5","tp":true},"pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"3A","open_data_app":{"app_name":"RadioText+ (RT+)","oda_group":"12A"},"pi":"0x53C5","prog_type":"Pop music","tp":true}
{"country":"it","group":"1A","has_linkage":false,"pi":"0x53C5","prog_type":"Pop music","tp":true}
{"di":{"stereo":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"artificial_head":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"compressed":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"dynamic_pty":true},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ps":"GIOCONDA","ta":false,"tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"debug":["TODO 10A"],"group":"10A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"di":{"stereo":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"artificial_head":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"clock_time":"2022-05-06T18:10:00Z","group":"4A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"clock_time":"2022-05-05T18:10:00-01:00","group":"4A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"di":{"compressed":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"dynamic_pty":true},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ps":"GIOCONDA","ta":false,"tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"di":{"stereo":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"artificial_head":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"compressed":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"dynamic_pty":true},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ps":"GIOCONDA","ta":false,"tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"12A","pi":"0x53C5","prog_type":"Pop music","radiotext_plus":{"item_running":true,"item_toggle":0},"tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"di":{"stereo":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"artificial_head":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"compressed":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"di":{"dynamic_pty":true},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ps":"GIOCONDA","ta":false,"tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"2A","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"14A","other_network":{"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true},"pi":"0x53C5","prog_type":"Pop music","tp":true}
{"group":"1A","has_linkage":false,"language":"Unknown","pi":"0x53C5","prog_type":"Pop music","tp":true}
{"di":{"stereo":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}
{"group":"3A","open_data_app":{"app_name":"RadioText+ (RT+)","oda_group":"12A"},"pi":"0x53C5","prog_type":"Pop music","tp":true}
{"di":{"artificial_head":false},"group":"0A","is_music":true,"pi":"0x53C5","prog_type":"Pop music","ta":false,"tp":true}

https://www.rundfunkforum.de/download/file.php?id=10485&mode=view
This is the spectrum and a first try with Rdsspy and its new RDS2 extension.

I hope I can record an MPX when I will be on the Adriatic sea in September.

This is an (error-free) MPX recording of that station recorded near Udine (UD), Italy on 98.5 MHz from Transmitter Porzus.
Seems one cycle is around 1 min, so I've cut my initially 10 min recording to 4 min.
Please note the timestamp is not the original recording time.
gioconda_20230915_udine_192khz_mono_4min.txt
https://we.tl/t-njT2T4kkGp
I found out that the broadcaster is using this kind of RDS encoder: https://pira.cz/rds/p164man.pdf
The author of many RDS hardware and also RDSSpy (Jan) wrote to me,

the RDS2 is dead, there's no support at all in the receivers, moreover
the station logo has been unexpectedly removed from final standard.
That Italian station uses some of the PIRA RDS encoder, they're sending
logo on the additional carrier but this has no effect at all. That
function has been implemented for potential future use but now I'm
almost sure that there's no future related to this.

Althought in this document from 2016, the RDS Forum still wrote about Logo implementation up to a size of 12 kB.
https://www.rds.org.uk/2010/pdf/R16_055_1.pdf
And in one of the latest publications on https://www.rds.org.uk/2010/pdf/Position paper 23_01 RDS2 - Frequently Asked Questions.pdf the RDS Forum are still mentioning it.
There is a preview of the (very expensive) PDF: https://www.techstreet.com/products/preview/2566513
Annex E (page 33) seems to describe it anyway.

Awesome research!
It's sad that RDS2 never took off. It would be nice to implement in redsea anyway, possibly, if someone ever wants to take a look at these rare data streams.
I'm just wondering how the output would look like. Pictures aren't very suitable for JSON printout. Maybe the user could give a special command-line switch to enable RDS2, and then another switch to point to a directory where to save these files?

Hi!
The pics will be very small so probably not much problem in having them and
other binary stuff encoded in BASE64. RDS2 har great potential but was
sadly much too late to the market.
Kind regards
// David
On Sat, Sep 16, 2023 at 9:28 PM Oona Räisänen @.***>
wrote:

Awesome research!
It's sad that RDS2 never took off. It would be nice to implement in redsea
anyway, possibly, if someone ever wants to take a look at these rare data
streams.
I'm just wondering how the output would look like. Pictures aren't very
suitable for JSON printout. Maybe the user could give a special
command-line switch to enable RDS2, and then another switch to point to a
directory where to save these files?
—
Reply to this email directly, view it on GitHub
https://github.com/windytan/redsea/issues/32#issuecomment-1722299296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AELU6KLKHEAL6CAIBHSJCG3X2X4XBANCNFSM4CS7VSAQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

This is the picture, 8.45 kB.

Why couldn't RDS2 take off
The only encoder that I know supports is is Jans Pira, maybe we should start loobying with Hans to add it into his Stereo Tool
as for a decoder, even RDSSpy doesn't seam to support it (at least the public free version doesn't), I saw a video once, but thats it
as for receivers, well if almost no station is using it, no wonder no receiver will support it
This needs to be somehow changed (I don't know how, but I would realy loved for RDS2 to take off), RDS2 is way better then DAB, it gives FM new life, it adds extra goodies that enhance the expirience (I know a lot of people will disagree with me and I will loose what I love anyway, but why can't audio be transmitted to out ears in analog way.... whyy)
I mean if people adopted DAB+ why cannot RDS2 have the same future?
If anyone wants the standard, I have it and can send it to anyone that asks for it

Please note that some countries will need the extended features of RDS2 (character sets, new lower frequency).
Yes, you are missing the files.dll in Rdsspy. Please copy it from Magic RDS folder.
But due to lack of time I was focusing in recording the file, so I can't tell you if Rdsspy can decode it live or just with wave files.

Hi!
Maybe I can provide some enlightenment about the development of RDS2 and
the slow takeup reasons. I was involved in RDS-Forum from 2014 to 2022 and
kept track of possibilities for the Swedish Radio. The majority of
receivers are placed in cars. In Sweden a car has an average lifetime of
about 17 years which makes adaptationrate very slow. The national radio in
Sweden are also already using the upper part of some of the channels with
DARC (https://www.windytan.com/2013/11/broadcast-messages-on-darc-side.html).
The standardisation process was also very slow in a landscape where many
stations are contemplating the choice of to go for DAB only/mixed/not at
all.
The only big player I've seen made any effort to actually have done
something with RDS2 is Radio France. They had a working concept running in
2016 and continued  (ex
https://www.radioworld.com/global/radio-france-displays-rds2-file-transfer).
There's also a lack of open reference implementation of the standard that
probably could have helped the process forward.
One basic implementation of the extended carriers:
https://github.com/Anthony96922/MiniRDS
Kind regards,
// David
On Sun, Sep 17, 2023 at 1:02 AM veso266 @.***> wrote:

Why couldn't RDS2 take off
The only encoder that I know supports is is Jans Pira, maybe we should
start loobying with Hans to add it into his Stereo Tool
as for a decoder, even RDSSpy doesn't seam to support it (at least the
public free version doesn't), I saw a video once, but thats it
as for receivers, well if almost no station is using it, no wonder no
receiver will support it
This needs to be somehow changed (I don't know how, but I would realy
loved for RDS2 to take off), RDS2 is way better then DAB, it gives FM new
life, it adds extra goodies that enhance the expirience (I know a lot of
people will disagree with me and I will loose what I love anyway, but why
can't audio be transmitted to out ears in analog way.... whyy)
I mean if people adopted DAB+ why cannot RDS2 have the same future?
If anyone wants the standard, I have it and can send it to anyone that
asks for it
—
Reply to this email directly, view it on GitHub
https://github.com/windytan/redsea/issues/32#issuecomment-1722335876,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AELU6KKQETFANQXRFN2SZCLX2YVXPANCNFSM4CS7VSAQ
.
You are receiving this because you commented.Message ID:
@.***>

@andimik I copied files.dll and curl.exe from Magic RDS to RDS Spy (latest 1.08 version), although RDS Spy can see the plugin when I click on it nothing happens
I also tried to run rds spy which is built in Magic RDS and same thing (maybe I should run it from Magic RDS menu itself or something
RDS Spy has an option called Enable RDS2 tunneling but I am not sure what that does (tunnel the 67khz stream somewhere, but where and how to acsess it)

@windytan
Oona, it seems that Finnish station
Järviradio uses additional carriers, but it is not sure, if this is RDS2.
https://www.rundfunkforum.de/viewtopic.php?p=1749186#p1749186

It's at least in Haapavesi on 89.7 MHz.
I guess you live in or near Helsinki, the station can be found on 103.1 MHz there.

Thanks for the heads-up. Here the station doesn't seem to have additional subcarriers unfortunately.
Since this is still at an idea phase, and it would be kind of complicated at this point in the development to support RDS2, I've made a brainstorming discussion thread.

There are other stations, but in Australia.

49B1_-_2024-05-18_12-56-44.zip

Acceptance criteria for PR (see discussion):

User can enable RDS2 feature with --rds2
If enabled,

redsea looks for additional subcarriers
some RDS2 subcarrier metadata (chosen by developer's judgement) is displayed as JSON
hex output should be kept RDS Spy compatible

Developer should design how this JSON info is tied to existing RDS1 JSON groups (if at all), based on the RDS2 documentation
There's a basic test that runs in CI
Build shows green


Handling minor versions messages of protocols

Yesterday's Working Group discussions about the handling of minor versions of protocol message types suggests we need to formalize the rules we want Aries agents to follow to enable a generally simpler update process when protocols change. One where we can avoid the "Community Update Process" as much as possible.
How about this approach:

Minor versions can only include the addition of new fields and the continued semantic meaning of existing fields. When a change violates those conditions, a new major version is required.

An Aries agent must be able to handle the receipt of any minor version within a single major version. E.g. an agent that handles the 1.3 message should be able to handle any 1.x message.

Any fields not recognized in a message are silently ignored. Thus, an agent that supports version 1.2 can receive a 1.4 message and process it using the 1.2 handling, ignoring any added v1.3 and v1.4 data items. Of course, that also means ignoring fields incorrectly put into the message.

If an agent chooses to respond to a discover feature message, the agent should respond with the latest version that the agent fully supports (e.g. 1.2 in the previous example).

When sending a response, an Aries agent should always respond with the latest version of the message that it supports.

Aside: Note that a message received and a message sent in response will use different versions, so there can be no such concept of responding to the "same version as was sent". For example, currently in RFC 0036, all the messages are v1.0 except Proposal which is at v1.1. There is no "0036 RFC v1.1 protocol".

Are those reasonable requirements?  Is there something missing in this?  Is this documented already in RFCs?  I confess I didn't really search for it...
Thanks

I agree on point 2 with @dhh1128. Agents should handle newer dot releases by ignoring unknown fields per point 3, but requiring that they support older dot releases should not be a requirement.

@TelegramSam Could you explain why an agent need not be able to handle an earlier dot release of a message? They may respond with a later version of the message, but they should be able to accept and process the earlier version, shouldn't they?  Without that, independently upgrading agents becomes very difficult.  Am I missing something?
@dhh1128 - thanks for the notes. As I wrote that I knew that you would have a better handle on what is already there. I'll check out the semvar RFC and think about anything else that might be needed in the notes.

Could you explain why an agent need not be able to handle an earlier dot release of a message? They may respond with a later version of the message, but they should be able to accept and process the earlier version, shouldn't they?

A number of HTTP-dependent processes are written for HTTP 1.1; if you ask them to interact per HTTP 1.0 rules, they decline. HTTP 1.1 introduced keep-alives (a new header, analogous to a new DIDComm field). This is an added field, so to speak, and would require just a minor update per our semver rules, because if you send such a header to an HTTP 1.0 server, the server doesn't complain; it just ignores it. But if the server sends back an HTTP 1.0 response and closes the socket, and it's dealing with a client that really wants 1.1, there can't be a requirement that the more advanced client like it or that it continue to interact in that degraded mode. Maybe it's a client that needs to reuse sockets, so the 1.0 featureset doesn't give it enough performance.
As another example, I believe (though I could be wrong) that it is common to implement JPEG support against version 1.02 of the standard, without ever implementing support for 1.0.
It has to be a valid behavior for someone to implement 1.1 support without also implementing 1.0 support. If I were writing a client, I would prefer implementing both in most cases, but we ought not to use the word "MUST" to mandate this behavior of all DIDComm talkers. Supporting 1.7 cannot mean you are required/guaranteed to support 1.6 (thought we hope that will often be the case).

Thanks - those are good examples and they make sense. Agree with the SHOULD
and perhaps we would even want, from time to time, to add guidance
about not supporting earlier versions. But that would be use case specific.
Good stuff.
On Mon, Feb 3, 2020 at 11:19 AM Daniel Hardman<EMAIL_ADDRESS>wrote:

Could you explain why an agent need not be able to handle an earlier dot
release of a message? They may respond with a later version of the message,
but they should be able to accept and process the earlier version,
shouldn't they?
A number of HTTP-dependent processes are written for HTTP 1.1; if you ask
them to interact per HTTP 1.0 rules, they decline. HTTP 1.1 introduced
keep-alives (a new header, analogous to a new DIDComm field). This is an
added field, so to speak, and would require just a minor update per our
semver rules, because if you send such a header to an HTTP 1.0 server, the
server doesn't complain; it just ignores it. But if the server sends back
an HTTP 1.0 response and closes the socket, and it's dealing with a client
that really wants 1.1, there can't be a requirement that the more advanced
client like it or that it continue to interact in that degraded mode. Maybe
it's a client that needs to reuse sockets, so the 1.0 featureset doesn't
give it enough performance.
As another example, I believe (though I could be wrong) that it is common
to implement JPEG support against version 1.02 of the standard, without
ever implementing support for 1.0.
It has to be a valid behavior for someone to implement 1.1 support without
also implementing 1.0 support. If I were writing a client, I would prefer
implementing both in most cases, but we ought not to use the word "MUST" to
mandate this behavior of all DIDComm talkers. Supporting 1.7 cannot mean
you are required/guaranteed to support 1.6 (thought we hope that will often
be the case).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hyperledger/aries-rfcs/issues/407?email_source=notifications&email_token=AAHYRQVRM5775CC263532CLRBBU35A5CNFSM4KN37JS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKVB4OI#issuecomment-581574201,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHYRQQLMCAAVRBMMBNU3Z3RBBU35ANCNFSM4KN37JSQ
.

--
Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)
*Schedule a Meeting: *https://calendly.com/swcurran
https://calendly.com/swcurran

I was going through this to figure out if there were changes to be made.  I would like to suggest that we take a couple of the sub-documents in the 0003-protocols folder out of this RFC as follows:

template.md is now in the root as 000-template-protocol.md and so should be removed
semvar.md should be it's own RFC - the things not obvious that were discussed above would be added to that.
uris.md should be put into the 0020-message-types RFC - which needs to be cleaned up to remove the DID resolution text
roles-participants-etc.md could be left as is or better, moved into the README.md
state-details.md - could be left as is or better, moved into the README.md

Any objections to make those changes.  Happy to do a PR, but it's a lot and wanted to be sure that people didn't object.
@TelegramSam @dhh1128

The first bullet is already done in #412, because it was suggested on a community call where 412 was discussed and made a precondition of 412 being accepted. It's a little more involved than just deleting template.md; a number of hyperlinks have to be updated, and the material about adopted messages needed a new home.
Other than that, I have no objection. (The breakout into separate docs is a pattern we haven't used a lot, which may be why Stephen says putting material into the main README.md is better. However, I'm not sure we have consensus on giant README.md's being better. I am reserving judgment. Whichever path is taken, I'll cheerfully vote to merge.)

Item 1 is already documented: https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/semver.md
Item 2 is a reasonable requirement for agent makers to impose on themselves, but is not a reasonable requirement for the community to impose on anybody. We should use "SHOULD" when describing it.
Item 3 is an absolute requirement. It is strongly implied by our documented semver rules, and it is mentioned as an explicit requirement in RFC 0011 Decorators: "Entities that handle messages should treat all unrecognized fields as valid but meaningless, and decorators are no exception. Thus, software that doesn't recognize a decorator should ignore it." I suggest that we change this language from "should" to "MUST", and that we put the same rule in the semver doc, plus in the protocol RFC near where message types are formally described, and also in RFC 0067 DIDComm Best Practices.
Items 4 and 5 are explicitly discussed in the semver doc, under "Version Negotiation". It is more nuanced than the rules you suggest. I recommend reading that content and then seeing if you still want the rules as you proposed them.

I'm in favor of the described changes here.

I was going through this to figure out if there were changes to be made. I would like to suggest that we take a couple of the sub-documents in the 0003-protocols folder out of this RFC as follows:
* template.md is now in the root as 000-template-protocol.md and so should be removed

* semvar.md should be it's own RFC - the things not obvious that were discussed above would be added to that.

* uris.md should be put into the 0020-message-types RFC - which needs to be cleaned up to remove the DID resolution text

* roles-participants-etc.md could be left as is or better, moved into the README.md

* state-details.md - could be left as is or better, moved into the README.md

Any objections to make those changes. Happy to do a PR, but it's a lot and wanted to be sure that people didn't object.
@TelegramSam @dhh1128

I'm also aligned with these changes.

Question about this.  What should happen if I receive a given minor version, I fully support that minor version, and I discover some unexpected fields in the message?   My first reaction was to say that we should silently or with a problem-report tell the other side we are ignoring those fields.  Is that correct?

It is ALWAYS the case, no matter what versioning stuff is happening, that unexpected fields should be ignored. Sending a problem report might be a good best practice, but IMO is not required. (I can think of some security reasons not to send one, sometimes.)

OK - so my thought was correct.  Sounds good thanks.  I'll probably do a clarification PR to RFC 0003 to make that clearer.

Added PR #527 to address.


Bug when computing Hessian Inverse

Hello, I'm trying to compute the matrix inverse of the hessian.
It doesn't seem to be related to the hessian specifically because it also doesn't work when composing with a single grad.
from jax import vmap
from jax import grad,jit
import jax.numpy as jnp
import numpy as np
import jax

def jaxbug():
    def L( x ):
        return jnp.sum(x*x)

    def Hessian( x ):
        M = jax.hessian(L,0)(x)
        return M

    def HessianInverse( x ):
        M = jax.hessian(L,0)(x)
        invM = jnp.linalg.inv(M)
        #works in simple cases  replace above with
        #invM = np.linalg.inv(M)
        return invM

    X = 3.0*np.ones((2),dtype="float32")

    print("Hessian")
    print(Hessian(X))

    print("Hessian Inverse")
    print( HessianInverse(X) )

def jaxbug2():
    def L( x ):
        return jnp.sum(x*x)

    def grad( x ):
        M = jax.grad(L,0)(x)
        return M

    def gradInverse( x ):
        M = jax.grad(L,0)(x)
        invM = jnp.linalg.inv(M)
        #works in simple cases replace above with
        #invM = np.linalg.inv(M)
        return invM

    X = 3.0*np.eye((2),dtype="float32")

    print(" grad")
    print(grad(X))

    print(" grad Inverse")
    print( gradInverse(X) )

#jaxbug()
jaxbug2()

The above code crash with the following error stack :
python3 jaxbug.py
 grad
[[6. 0.]
 [0. 6.]]
 grad Inverse
2021-01-12 22:05:33.201453: E external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED
2021-01-12 22:05:33.201497: W external/org_tensorflow/tensorflow/stream_executor/stream.cc:1455] attempting to perform BLAS operation using StreamExecutor without BLAS support
2021-01-12 22:05:33.201538: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_client.cc:1809] Execution of replica 0 failed: Internal: Unable to launch triangular solve for thunk 0x133a1330
Traceback (most recent call last):
  File "jaxbug.py", line 56, in <module>
    jaxbug2()
  File "jaxbug.py", line 53, in jaxbug2
    print( gradInverse(X) )
  File "jaxbug.py", line 42, in gradInverse
    invM = jnp.linalg.inv(M)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/_src/numpy/linalg.py", line 336, in inv
    a, lax.broadcast(jnp.eye(a.shape[-1], dtype=lax.dtype(a)), a.shape[:-2]))
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/api.py", line 371, in f_jitted
    return cpp_jitted_f(*args, **kwargs)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/api.py", line 284, in cache_miss
    donated_invars=donated_invars)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1229, in bind
    return call_bind(self, fun, *args, **params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1220, in call_bind
    outs = primitive.process(top_trace, fun, tracers, params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1232, in process
    return trace.process_call(self, fun, tracers, params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 598, in process_call
    return primitive.impl(f, *tracers, **params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/interpreters/xla.py", line 572, in _xla_call_impl
    return compiled_fun(*args)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/interpreters/xla.py", line 830, in _execute_compiled
    out_bufs = compiled.execute(input_bufs)
RuntimeError: Internal: Unable to launch triangular solve for thunk 0x133a1330
2021-01-12 22:05:33.259843: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/local_device_state.cc:68] Error when closing device: Internal: stream did not block host until done; was already in an error state
2021-01-12 22:05:33.260070: W external/org_tensorflow/tensorflow/stream_executor/stream.cc:275] Error blocking host until done in stream destructor: Internal: stream did not block host until done; was already in an error state

2021-01-12 22:05:33.201453: E external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED
It would seem that you didn't install jaxlib GPU version
Could you follow the installation guide to install jaxlib GPU support?
https://github.com/google/jax#installation

2021-01-12 22:05:33.201453: E external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED
It would seem that you didn't install jaxlib GPU version
Could you follow the installation guide to install jaxlib GPU support?
https://github.com/google/jax#installation

I'm actually guessing this is the GPU wheel, but for some reason the GPU support failed to initialize. Can you try running with the environment variable TF_CPP_MIN_LOG_LEVEL=0 set and share the logs?

I'm actually guessing this is the GPU wheel, but for some reason the GPU support failed to initialize. Can you try running with the environment variable TF_CPP_MIN_LOG_LEVEL=0 set and share the logs?

Thanks,
I am indeed using the GPU wheel,
It seems there is some problem initializing the cublas library even though it was opened successfully :
2021-01-12 22:46:56.292552: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcublas.so.11
2021-01-12 22:46:56.428850: E external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED

I'll try tomorrow to redo a fresh cuda install / jax / tensorflow.
Full log :
TF_CPP_MIN_LOG_LEVEL=0 python3 jax
jaxbug.py  jaxlag.py
(venvtf2.4)  TF_CPP_MIN_LOG_LEVEL=0 python3 jaxbug.py
2021-01-12 22:46:54.122286: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcudart.so.11.0
2021-01-12 22:46:54.183076: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcudart.so.11.0
2021-01-12 22:46:54.442500: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:168] XLA service 0x2b45390 initialized for platform Interpreter (this does not guarantee that XLA will be used). Devices:
2021-01-12 22:46:54.442544: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Interpreter, <undefined>
2021-01-12 22:46:54.459841: I external/org_tensorflow/tensorflow/core/platform/profile_utils/cpu_utils.cc:112] CPU Frequency:<PHONE_NUMBER> Hz
2021-01-12 22:46:54.460353: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:168] XLA service 0x2ae4160 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2021-01-12 22:46:54.460373: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Host, Default Version
2021-01-12 22:46:54.461884: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcuda.so.1
2021-01-12 22:46:54.499487: I external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:941] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-01-12 22:46:54.499900: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:168] XLA service 0x284a150 initialized for platform CUDA (this does not guarantee that XLA will be used). Devices:
2021-01-12 22:46:54.499919: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): GeForce GTX 960M, Compute Capability 5.0
2021-01-12 22:46:54.500235: I external/org_tensorflow/tensorflow/compiler/xla/pjrt/nvidia_gpu_device.cc:119] XLA backend allocating<PHONE_NUMBER> bytes on device 0 for BFCAllocator.
2021-01-12 22:46:54.500368: I external/org_tensorflow/tensorflow/stream_executor/tpu/tpu_platform_interface.cc:74] No TPU platform found.
Hessian
[[2. 0.]
 [0. 2.]]
inv Hessian
2021-01-12 22:46:55.455978: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcusolver.so.11
2021-01-12 22:46:55.924679: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcudart.so.11.0
2021-01-12 22:46:56.292552: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcublas.so.11
2021-01-12 22:46:56.428850: E external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED
2021-01-12 22:46:56.428895: W external/org_tensorflow/tensorflow/stream_executor/stream.cc:1455] attempting to perform BLAS operation using StreamExecutor without BLAS support
2021-01-12 22:46:56.428929: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_client.cc:1809] Execution of replica 0 failed: Internal: Unable to launch triangular solve for thunk 0x143463e0
Traceback (most recent call last):
  File "jaxbug.py", line 58, in <module>
    jaxbug()
  File "jaxbug.py", line 29, in jaxbug
    print(jnp.linalg.inv(h))
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/_src/numpy/linalg.py", line 336, in inv
    a, lax.broadcast(jnp.eye(a.shape[-1], dtype=lax.dtype(a)), a.shape[:-2]))
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/api.py", line 371, in f_jitted
    return cpp_jitted_f(*args, **kwargs)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/api.py", line 284, in cache_miss
    donated_invars=donated_invars)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1229, in bind
    return call_bind(self, fun, *args, **params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1220, in call_bind
    outs = primitive.process(top_trace, fun, tracers, params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1232, in process
    return trace.process_call(self, fun, tracers, params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 598, in process_call
    return primitive.impl(f, *tracers, **params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/interpreters/xla.py", line 572, in _xla_call_impl
    return compiled_fun(*args)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/interpreters/xla.py", line 830, in _execute_compiled
    out_bufs = compiled.execute(input_bufs)
RuntimeError: Internal: Unable to launch triangular solve for thunk 0x143463e0
2021-01-12 22:46:56.484537: I external/org_tensorflow/tensorflow/stream_executor/stream.cc:4977] [stream=0x2c5dcd0,impl=0x2a3b600] Internal: stream did not block host until done; was already in an error state
2021-01-12 22:46:56.484629: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/local_device_state.cc:68] Error when closing device: Internal: stream did not block host until done; was already in an error state
2021-01-12 22:46:56.484847: I external/org_tensorflow/tensorflow/stream_executor/stream.cc:4977] [stream=0x2c5dcd0,impl=0x2a3b600] Internal: stream did not block host until done; was already in an error state
2021-01-12 22:46:56.484858: W external/org_tensorflow/tensorflow/stream_executor/stream.cc:275] Error blocking host until done in stream destructor: Internal: stream did not block host until done; was already in an error state

Thanks,
I am indeed using the GPU wheel,
It seems there is some problem initializing the cublas library even though it was opened successfully :
2021-01-12 22:46:56.292552: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcublas.so.11
2021-01-12 22:46:56.428850: E external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED

I'll try tomorrow to redo a fresh cuda install / jax / tensorflow.
Full log :
TF_CPP_MIN_LOG_LEVEL=0 python3 jax
jaxbug.py  jaxlag.py
(venvtf2.4)  TF_CPP_MIN_LOG_LEVEL=0 python3 jaxbug.py
2021-01-12 22:46:54.122286: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcudart.so.11.0
2021-01-12 22:46:54.183076: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcudart.so.11.0
2021-01-12 22:46:54.442500: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:168] XLA service 0x2b45390 initialized for platform Interpreter (this does not guarantee that XLA will be used). Devices:
2021-01-12 22:46:54.442544: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Interpreter, <undefined>
2021-01-12 22:46:54.459841: I external/org_tensorflow/tensorflow/core/platform/profile_utils/cpu_utils.cc:112] CPU Frequency:<PHONE_NUMBER> Hz
2021-01-12 22:46:54.460353: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:168] XLA service 0x2ae4160 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2021-01-12 22:46:54.460373: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): Host, Default Version
2021-01-12 22:46:54.461884: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcuda.so.1
2021-01-12 22:46:54.499487: I external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:941] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2021-01-12 22:46:54.499900: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:168] XLA service 0x284a150 initialized for platform CUDA (this does not guarantee that XLA will be used). Devices:
2021-01-12 22:46:54.499919: I external/org_tensorflow/tensorflow/compiler/xla/service/service.cc:176]   StreamExecutor device (0): GeForce GTX 960M, Compute Capability 5.0
2021-01-12 22:46:54.500235: I external/org_tensorflow/tensorflow/compiler/xla/pjrt/nvidia_gpu_device.cc:119] XLA backend allocating<PHONE_NUMBER> bytes on device 0 for BFCAllocator.
2021-01-12 22:46:54.500368: I external/org_tensorflow/tensorflow/stream_executor/tpu/tpu_platform_interface.cc:74] No TPU platform found.
Hessian
[[2. 0.]
 [0. 2.]]
inv Hessian
2021-01-12 22:46:55.455978: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcusolver.so.11
2021-01-12 22:46:55.924679: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcudart.so.11.0
2021-01-12 22:46:56.292552: I external/org_tensorflow/tensorflow/stream_executor/platform/default/dso_loader.cc:49] Successfully opened dynamic library libcublas.so.11
2021-01-12 22:46:56.428850: E external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_blas.cc:226] failed to create cublas handle: CUBLAS_STATUS_NOT_INITIALIZED
2021-01-12 22:46:56.428895: W external/org_tensorflow/tensorflow/stream_executor/stream.cc:1455] attempting to perform BLAS operation using StreamExecutor without BLAS support
2021-01-12 22:46:56.428929: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/pjrt_client.cc:1809] Execution of replica 0 failed: Internal: Unable to launch triangular solve for thunk 0x143463e0
Traceback (most recent call last):
  File "jaxbug.py", line 58, in <module>
    jaxbug()
  File "jaxbug.py", line 29, in jaxbug
    print(jnp.linalg.inv(h))
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/_src/numpy/linalg.py", line 336, in inv
    a, lax.broadcast(jnp.eye(a.shape[-1], dtype=lax.dtype(a)), a.shape[:-2]))
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/api.py", line 371, in f_jitted
    return cpp_jitted_f(*args, **kwargs)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/api.py", line 284, in cache_miss
    donated_invars=donated_invars)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1229, in bind
    return call_bind(self, fun, *args, **params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1220, in call_bind
    outs = primitive.process(top_trace, fun, tracers, params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 1232, in process
    return trace.process_call(self, fun, tracers, params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/core.py", line 598, in process_call
    return primitive.impl(f, *tracers, **params)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/interpreters/xla.py", line 572, in _xla_call_impl
    return compiled_fun(*args)
  File "/home/username/venvtf2.4/lib/python3.6/site-packages/jax/interpreters/xla.py", line 830, in _execute_compiled
    out_bufs = compiled.execute(input_bufs)
RuntimeError: Internal: Unable to launch triangular solve for thunk 0x143463e0
2021-01-12 22:46:56.484537: I external/org_tensorflow/tensorflow/stream_executor/stream.cc:4977] [stream=0x2c5dcd0,impl=0x2a3b600] Internal: stream did not block host until done; was already in an error state
2021-01-12 22:46:56.484629: E external/org_tensorflow/tensorflow/compiler/xla/pjrt/local_device_state.cc:68] Error when closing device: Internal: stream did not block host until done; was already in an error state
2021-01-12 22:46:56.484847: I external/org_tensorflow/tensorflow/stream_executor/stream.cc:4977] [stream=0x2c5dcd0,impl=0x2a3b600] Internal: stream did not block host until done; was already in an error state
2021-01-12 22:46:56.484858: W external/org_tensorflow/tensorflow/stream_executor/stream.cc:275] Error blocking host until done in stream destructor: Internal: stream did not block host until done; was already in an error state

lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.5 LTS
Release:	18.04
Codename:	bionic

My nvidia driver are up-to-date :
 nvidia-smi
Tue Jan 12 23:39:27 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.27.04    Driver Version: 460.27.04    CUDA Version: 11.2

I cannot easily pin this version number to a previous version but CUDA drivers are backwards compatible
I reinstalled the specific cuda version you specify in the installation (aka cuda 11-0)
sudo apt-get install cuda-11-0
virtualenv -p python3 venvjax
source ~/venvjax/bin/activate
pip install --upgrade pip
pip install --upgrade jax jaxlib==0.1.57+cuda110 -f https://storage.googleapis.com/jax-releases/jax_releases.html
TF_CPP_MIN_LOG_LEVEL=0 python3 jaxbug.py

It doesn't work. Same errors, except it's now loading 11.0 library instead of 11.1.
I also tried with cuda-10-1 and it doesn't work.
Can you please advise ?
Thank you

lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.5 LTS
Release:	18.04
Codename:	bionic

My nvidia driver are up-to-date :
 nvidia-smi
Tue Jan 12 23:39:27 2021
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.27.04    Driver Version: 460.27.04    CUDA Version: 11.2

I cannot easily pin this version number to a previous version but CUDA drivers are backwards compatible
I reinstalled the specific cuda version you specify in the installation (aka cuda 11-0)
sudo apt-get install cuda-11-0
virtualenv -p python3 venvjax
source ~/venvjax/bin/activate
pip install --upgrade pip
pip install --upgrade jax jaxlib==0.1.57+cuda110 -f https://storage.googleapis.com/jax-releases/jax_releases.html
TF_CPP_MIN_LOG_LEVEL=0 python3 jaxbug.py

It doesn't work. Same errors, except it's now loading 11.0 library instead of 11.1.
I also tried with cuda-10-1 and it doesn't work.
Can you please advise ?
Thank you

I tried my code with the cpu version and it works.
I also tried with the gpu version on a  GeForce GTX 1080 Ti, Compute Capability 6.1 and it works.
So the problem for me is only occurring on my laptop with GeForce GTX 960M, Compute Capability 5.0
Don't waste anymore time, I'll close the bug as it's probably just an incompatible device issue, I'll work around it by using cpu and my other machine. Feel free to reopen if you want.
Thanks.

I tried my code with the cpu version and it works.
I also tried with the gpu version on a  GeForce GTX 1080 Ti, Compute Capability 6.1 and it works.
So the problem for me is only occurring on my laptop with GeForce GTX 960M, Compute Capability 5.0
Don't waste anymore time, I'll close the bug as it's probably just an incompatible device issue, I'll work around it by using cpu and my other machine. Feel free to reopen if you want.
Thanks.

I have one other guess: can you show the complete nvidia-smi output? Is the GPU low on RAM?
As an experiment, can you try XLA_PYTHON_CLIENT_PREALLOCATE=false (see https://jax.readthedocs.io/en/latest/gpu_memory_allocation.html ) ?
I've seen cuBlas fail to initialize when it runs out of RAM, and it doesn't always give the best error message when that happens.

I have one other guess: can you show the complete nvidia-smi output? Is the GPU low on RAM?
As an experiment, can you try XLA_PYTHON_CLIENT_PREALLOCATE=false (see https://jax.readthedocs.io/en/latest/gpu_memory_allocation.html ) ?
I've seen cuBlas fail to initialize when it runs out of RAM, and it doesn't always give the best error message when that happens.

@hawkinsp Nice guess +1:
It runs fine on GPU when I use XLA_PYTHON_CLIENT_PREALLOCATE=false
Thanks very much
When I don't use it :
Full log nvidia-smi output, captured at the instant before the crash.
**+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.27.04    Driver Version: 460.27.04    CUDA Version: 11.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  GeForce GTX 960M    On   | 00000000:01:00.0 Off |                  N/A |
| N/A   61C    P0    N/A /  N/A |   1816MiB /  2004MiB |      1%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      1996      G   /usr/lib/xorg/Xorg                 72MiB |
|    0   N/A  N/A      6114      G   /usr/lib/firefox/firefox            1MiB |
|    0   N/A  N/A     20201      G   /usr/lib/firefox/firefox            1MiB |
|    0   N/A  N/A     25428      G   /usr/lib/firefox/firefox            1MiB |
|    0   N/A  N/A     32561      C   python3                          1734MiB**

@hawkinsp Nice guess +1:
It runs fine on GPU when I use XLA_PYTHON_CLIENT_PREALLOCATE=false
Thanks very much
When I don't use it :
Full log nvidia-smi output, captured at the instant before the crash.
**+-----------------------------------------------------------------------------+
| NVIDIA-SMI 460.27.04    Driver Version: 460.27.04    CUDA Version: 11.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  GeForce GTX 960M    On   | 00000000:01:00.0 Off |                  N/A |
| N/A   61C    P0    N/A /  N/A |   1816MiB /  2004MiB |      1%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes:                                                                  |
|  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
|        ID   ID                                                   Usage      |
|=============================================================================|
|    0   N/A  N/A      1996      G   /usr/lib/xorg/Xorg                 72MiB |
|    0   N/A  N/A      6114      G   /usr/lib/firefox/firefox            1MiB |
|    0   N/A  N/A     20201      G   /usr/lib/firefox/firefox            1MiB |
|    0   N/A  N/A     25428      G   /usr/lib/firefox/firefox            1MiB |
|    0   N/A  N/A     32561      C   python3                          1734MiB**

Awesome! We're planning to make XLA_PYTHON_CLIENT_PREALLOCATE=false the default some time soon, which should fix the problem once and for all.

Awesome! We're planning to make XLA_PYTHON_CLIENT_PREALLOCATE=false the default some time soon, which should fix the problem once and for all.

I had the issue that GPU support was dropped if I selected XLA_PYTHON_CLIENT_PREALLOCATE=false or XLA_PYTHON_CLIENT_PREALLOCATE=platform. Thankfully, XLA_PYTHON_CLIENT_MEM_FRACTION=.80 worked. https://jax.readthedocs.io/en/latest/gpu_memory_allocation.html  is an excellent resource if you are struggling with similar problems.


[BUG] nixvimInjections don't seem to work on nightly

Field
Description

Plugin
treesitter

Nixpkgs
unstable

[x] I have read the FAQ and my bug is not listed there.

Description

The nixvimInjections option does not work on nighlty builds of neovim. The extraConfigLua regions do not get properly highlighted as lua code. A minor thing, but I thought it worth to report :)
Minimal, Reproducible Example (MRE)

I'm able to reproduce the behavior with this minimal flake:
{
  description = "A nixvim configuration";

  inputs = {
    nixvim.url = "github:nix-community/nixvim";
    flake-utils.url = "github:numtide/flake-utils";
    nixneovimplugins.url = "github:NixNeovim/NixNeovimPlugins";
    neovim-nightly-overlay.url = "github:nix-community/neovim-nightly-overlay";
  };

  outputs = {
    nixpkgs,
    nixvim,
    flake-utils,
    nixneovimplugins,
    ...
  } @ inputs:
    flake-utils.lib.eachDefaultSystem (system: let
      pkgs-nightly = import nixpkgs {
        inherit system;
        overlays = [
          nixneovimplugins.overlays.default
          inputs.neovim-nightly-overlay.overlay
        ];
      };
      pkgs = import nixpkgs {
        inherit system;
        overlays = [
          nixneovimplugins.overlays.default
        ];
      };
      nixvim' = nixvim.legacyPackages.${system};
      inject = nixvim'.makeNixvimWithModule {
        inherit pkgs;
        module = {
          plugins.treesitter = {
            enable = true;
            nixvimInjections = true;
          };
        };
      };
      inject-nightly = nixvim'.makeNixvimWithModule {
        pkgs = pkgs-nightly;
        module = {
          plugins.treesitter = {
            enable = true;
            nixvimInjections = true;
          };
        };
      };
    in {
      packages = {
        inherit inject;
        inherit inject-nightly;
      };
    });
}

nix run ".#inject" and nix run ".#inject-nightly" for the different versions.
Opening any file with extraConfigLua should show that the nighly version does not properly highlight those regions.

Can confirm this for current nixpkgs-unstable with Neovim v0.10.0.

Should be fixed in #1843

This still doesn't work for me on latest nixvim and nixpkgs.

@zvolin you may be interested in this discussion: https://github.com/nix-community/nixvim/discussions/2093
TL;DR: the injections are working, but can be a little finicky when it comes to whitespace.
Also: ensure you have set plugins.treesitter.settings.highlight.enable = true.

thanks, highlight.enable = true did the job. I think it was working without it few months ago.

thanks, highlight.enable = true did the job. I think it was working without it few months ago.

We used to default to enabling them but changed to respecting plugin defaults as we’ve been refactoring. Treesitter doesn’t enable anything by default apparently.


about Prerequisites for linux

BPF LSM was introduced after linux 5.7, but in README of vArmor shows that kernel version need >= 5.10, cloud you please tell me why?

Thanks for asking. To implement certain policy primitives, we have utilized a mix of bpf2bpf function calls and tailcalls. This feature requires kernel 5.10 or higher on the x86_64 architecture.

@Danny-Wei Thanks for your reply. It is really a nice project to learn BPF LSM.


[WIP][Packaging] Fixing nightly builds

@ursabot crossbow submit -g nightly

@ursabot crossbow submit -g nightly

Codecov Report

Merging #5647 into master will decrease coverage by 7.9%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5647      +/-   ##
==========================================
- Coverage   88.89%   80.98%   -7.91%
==========================================
  Files         868       90     -778
  Lines      107541     8874   -98667
  Branches     1501        0    -1501
==========================================
- Hits        95603     7187   -88416
+ Misses      11573     1333   -10240
+ Partials      365      354      -11

Impacted Files
Coverage Δ

cpp/src/arrow/array/builder_adaptive.cc

r/R/filesystem.R

r/R/list.R

cpp/src/parquet/column_page.h

cpp/src/plasma/test/external_store_tests.cc

cpp/src/arrow/array/builder_decimal.cc

r/src/symbols.cpp

.../thirdparty/flatbuffers/include/flatbuffers/base.h

r/R/record-batch-writer.R

cpp/src/arrow/compute/compute_test.cc

... and 768 more

Continue to review full report at Codecov.

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

@ursabot submit wheel-osx-cp37m

@ursabot crossbow submit wheel-osx-cp37m

@ursabot crossbow submit conda-linux-gcc-py37

@ursabot crossbow submit wheel-osx-cp37m

@ursabot crossbow submit conda-linux-gcc-py37

@ursabot crossbow submit conda-linux-gcc-py37

@ursabot crossbow submit conda-linux-gcc-py37

@ursabot crossbow submit wheel-osx-cp37m

@ursabot crossbow submit conda-linux-gcc-py37

@ursabot crossbow submit wheel-osx-cp37m

@ursabot crossbow submit -g conda -g wheel

@ursabot crossbow submit wheel-win-cp37m

The OSX wheels are failing with a transient upload error, still need to fix the windows ones.

@ursabot crossbow submit wheel-win-cp37m

@ursabot crossbow submit wheel-win-cp37m

The windows wheels are still having linking issues, but without any context it is pretty hard to investigate. Under the Appveyor artifacts we have a faulty wheel.
I'm going to merge the fix for the linux conda packages and osx wheels and handle the remaining windows wheel issue in a separate PR.


Any type API in ffi crate

Codecov Report

Merging #967 (a17f9de) into main (c4ddfdd) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #967   +/-   ##
=======================================
  Coverage   84.33%   84.33%
=======================================
  Files         390      390
  Lines       41210    41210
=======================================
  Hits        34756    34756
  Misses       6454     6454

Continue to review full report at Codecov.

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


Remove webcatalog cask

The WebCatalog cask is broken, because the project has been renamed and abandoned:

Cask installation fails with 404 error for DMG file
https://github.com/webcatalog/webcatalog redirects to https://github.com/quanglam2807/appifier
The Appifier repository states:

The project is no longer under development. Use WebCatalog Lite or Nativefier instead.

Since WebCatalog Lite is not backward compatible, it might be safer to add it under a new name rather than updating this cask.

NOT APPLICABLE:
After making all changes to the cask:

[ ] brew cask audit --download {{cask_file}} is error-free.
[ ] brew cask style --fix {{cask_file}} reports no offenses.
[ ] The commit message includes the cask’s name and version.

Thanks!


reworking HeroRuler to extend Ruler

Reworking HeroRuler to extend the base Ruler class

I'm sorta stilling your thunder here as I just reworked HeroRuler.mjs to EXTEND CONFIG.Canvas.rulerClass.  This part of a FoundryVTT v12 and DragRuler support.  Still working with the DragRuler guy to fix some problems, but you may not need this PR.

no worries, should I delete this PR then?

This is so out of date.  I think this PR should be closed/abandoned.

my bad, thought this was already closed


can't open a new module after closing one

after we load or open a song, if we request to open a new one with the icon (or control+o), it will close the previous one and we start at the intro screen. But we can't open a new song, the buttons don't react to click input. We can't close bintracker either (we must use xkill to kill the window)

if we open a song using the menu, bintracker will crash:

Warning (#<thread: thread472>): in thread: (-) bad argument type - not a number: #f
Call history:

../bt-state.scm:112: scheme#eval
../bt-state.scm:113: bt-types#settings
../bt-types.scm:150: chicken.base#alist-ref
../bt-state.scm:111: g393
../bt-state.scm:149: list-utils#alist-inverse-ref
../bt-state.scm:158: chicken.string#->string
../bt-state.scm:158: chicken.string#string-translate
../bt-state.scm:158: srfi-13#string-upcase
../bt-gui.scm:913: scheme#string-append
../bt-gui.scm:910: ui-modeline-set
../bt-gui.scm:732: coops#slot-value
../bt-gui.scm:732: chicken.base#alist-ref
../bt-gui.scm:733: scheme#string-append
../bt-gui.scm:733: label
../bt-gui.scm:1847: chicken.string#string-split
../bt-gui.scm:1846: g6616	  	<--

Error: uncaught exception: #<condition: (exn type)>
Call history:

../bt-state.scm:25: scheme#string-append
../bt-state.scm:25: scheme#string->symbol
../bt-state.scm:25: scheme#eval
../bt-state.scm:24: g277
../bt-gui.scm:4079: ui-ref
../bt-gui.scm:686: ui-children
../bt-gui.scm:642: coops#slot-value
../bt-gui.scm:687: ui-children
../bt-gui.scm:642: coops#slot-value
../bt-gui.scm:688: chicken.base#alist-ref
../bt-gui.scm:4088: ui-metastate
../bt-gui.scm:4039: coops#slot-value
../bt-gui.scm:3763: coops#slot-value
../bintracker.scm:44: g301
../bintracker.scm:45: pstk#tk-end
../bintracker.scm:46: simple-exceptions#raise	  	<--

Thanks for the report. This might be a bit more difficult to fix.
As a work-around, clicking somewhere on an empty spot in the application window sometimes fixes things when BT doesn't react to input.

do you get the same behavior when open files?
I couldn't get it to work again by clicking this way. I don't have any error message in the terminal.

No, works fine for me. But I have seen this kind of bug before so I have some ideas where to look. I might ask you to try some things later on (probably in a few days), if that's ok with you.

sure

^^ This might solve the issue, not sure.


Update milestones

Lots have been done without any work log, making it difficult to track milestones completion rate.
Issues should be open for all the work requirements, done or undone, so the milestones can be tracked effectively.

Created issues for past work. New code should have open issues first.


wrong public key is being offered when using multiple identities

consider the following config
hosts:
    foo:
        Hostname: hostB
        IdentityFile: ~/.ssh/a
    bar:
        Hostname: hostA
        IdentityFile: ~/.ssh/b

ssh foo/bar leads to Permission denied (publickey). because the wrong public key is being offered
is that my fault, intended behaviour or assh's fault?

Hi @emanelif, thank you for your feedback,
Your configuration file looks good, I need to do some tests to figure out where the issue is

I think #116 fixed this issue too, can you give a try and tell me if both of the issues were addressed ?

I hope I used the correct version. go get -u github.com/moul/advanced-ssh-config/cmd/assh should do it, right?
ssh foo/bar is not working then: Permission denied (publickey).

Yep, go get -u github.com/moul/advanced-ssh-config/cmd/assh will fetch and compile the latest version in your $GOPATH/bin directory, then you need to have $GOPATH/bin in your $PATH or call the binary using its absolute path to be sure to run this version
response to your edit1: :)
response to your edit2: the way assh is working do not requires agent-forwarding (I personnaly disabled it globally for security reasons), assh won't call ssh hosta -- ssh hostb, but ssh hosta -- netcat hostb 22 and use this netcat socket to perform a new ssh connection from the assh hostYep, go get -u github.com/moul/advanced-ssh-config/cmd/assh will fetch and compile the latest version in your $GOPATH/bin directory, then you need to have $GOPATH/bin in your $PATH or call the binary using its absolute path to be sure to run this version
response to your edit1: :)
response to your edit2: the way assh is working do not requires agent-forwarding (I personnaly disabled it globally for security reasons), assh won't call ssh hosta -- ssh hostb, but ssh hosta -- netcat hostb 22 and use this netcat socket to perform a new ssh connection from the assh host

everything works fine now.

perfect :) thank you for your feedbacks


Windows client cannot use major or minor versions larger than 255

https://learn.microsoft.com/en-us/windows/win32/msi/productversion?redirectedfrom=MSDN

What about build metadata? https://semver.org/#spec-item-10
It is ignored by semver but none of our packages are published to registry so that doesn't matter.


Additional APIs in Geocoding and Data Validation

Thank you for taking the time to work on a Pull Request for this project!
To ensure your PR is dealt with swiftly please check the following:

[x] Your submissions are formatted according to the guidelines in the contributing guide
[x] Your additions are ordered alphabetically
[x] Your submission has a useful description
[x] The description does not end with punctuation
[x] Each table column should be padded with one space on either side
[x] You have searched the repository for any relevant issues or pull requests
[x] Any category you are creating has the minimum requirement of 3 items
[x] All changes have been squashed into a single commit

@jbrooksuk Can I get some feedback on this PR? Thanks!

Thank you


Error "topics.0.infoItems.3.details.0._id" is required

Hello,
I can't update anything anymore on my instance of 4minitz.
Finalizing a minute does not work either.
When loading the page, it shows "Error "topics.0.infoItems.3.details.0._id" is required".
The console shows an exception as well:

Any idea how to fix this?

Actually, I noticed the Docker image from the Docker hub is outdated.
Could you please update it, and possibly set up an automatic build?

Hi Hugues,
to bad to hear you are blocked by a 4Minitz bug.
Unfortunately we have not seen this behaviour in years...
The database has a missing mandatory attribute... strange!
As we protect database changes via schema checks, it is unclear how the data could be stored in the DB in a corrupt way...
So let me ask a few questions:

Which 4Minitz version does the about box show?
Which docker image are you using? stable/master or unstable/develop? (The stable image is recommended for production use and it is not at all outdated).
Are you using 4Minitz in production with multiple users - or still testing the setup? (Because in the latter it might be that you restart the backend very often...)
Can you remember any special actions you did before this error occured first? E.g., You where editing a topic or info item or markdown detail - then closed your browser? Or then the backend terminated and restarted? Or where you configuring / restarting the backend while editing in the front end?
The problem is in Topic#1, Sub-Item#4, Markdown-Detail#1.

Is it possible in the front end to delete the problematic detail? To to so: start editing it, then remove all characters, then Hit Ctrl+Enter (CMD+Enter on Mac).
If not: is it possible to delete the problematic Sub-Item#4 of the first topic? To do so, click the "..." three point menu on the Item#4 and try to delete the item.

Hi,
I ran into the same bug just a week ago. Just saw the ticket, maybe what I remember helps.
My version (Docker):
4Minitz v1.5.2 2018-04-18
Branch: master (595d9b45)
What I think (sorry cant remember correctly) I did:

Tried to do a @username somewhere which didnt accepted it. (Maybe where it isnt supposed to work). The error occured.
Could not edit / modify anything. Removing the detail was not possible because it was not shown

Deleting the sub-item worked and resolved the error.
Hope this helps...
Best
Stephan

Trying to answer all the questions :)

version shows: "v1.5.2 2018-04-18, Branch: master (595d9b45)"
using Docker image 4minitz/4minitz:stable from here: https://hub.docker.com/r/4minitz/4minitz. I was thinking it may be outdated because of "Updated 10 months ago", while the Github as a lot of commits since then. Maybe you can clarify this?
Currently using it in production: multiple users, the container was up for a few days before this bug. I do not yet have the details from the user who saw the bug first, but he was editing at that time, and it might be because of a "bad" copy & paste.
I ended up rollbacking a save from the day before, which works fine, but if necessary I saved the corrupted database.

Same problem occours with current version "4Minitz v2.0.0-develop 2020-07-27", latest docker image.
It seems to me like a race condition, when we try to create a new detail. Sometimes the view doesn't switch to the edit view and when we select edit a message is displayed and the detail dissappear. Sometimes only "partly", that means: no date or edit buttons are displayed, but more space is used in the view.


Support Python 3.10

Python 3.10 was released and all accumulated improvements should be released so aiozk will be compatible with the new Python version.

yep, will do it


Diff in range data of Program vs other parsers for leading newline(s)

Eurgh... 😅
I am honestly not sure on what to suggest to address this, but if you take this really simple source (the leading newline is key but not that clear in the codeblock):
Input Code

function foo() {

}

You end up with different range data for the Program node across the different parsers.
Please see: http://astexplorer.net/#/gist/c336be172990d7b467d1ed3dbc1882ee/215640e9e6eece750582ef00b16a884a5c66530a
...and take a look at the different parsers.
I found this when running AST comparison tests between babylon and typescript-eslint-parser (which behaves like espree/esprima) for JS source fixtures.
The diff essentially boils down to the inclusion of the leading newline (or not in the case of babylon):
      "column": 0,
           "line": 1,
         },
       },
       "range": Array [
    -    1,
    +    0,
         28,
       ],
       "sourceType": "script",
       "type": "Program",
     }

I do have the ESTree plugin enabled, so I would theoretically expect to see parity here.

Hey @JamesHenry! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.
If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

Same thing with leading comments:
/* foo */
if (/* bar */  a) {}

It appears Espree, Esprima, Flow and Recast have one view of the world, Acorn and Babylon have another.
Espree:
{
  "type": "Program",
  "start": 0,
  "end": 31,
  "range": [
    10,
    30
  ],
...

Esprima:
{
  "type": "Program",
  "range": [
    10,
    30
  ]
...

Flow:
{
  "type": "Program",
  "range": [
    10,
    30
  ],
...

Recast:
{
    "type": "Program",
    "range": [
      10,
      30
    ],
...

Acorn:
{
  "type": "Program",
  "start": 0,
  "end": 31,
  "range": [
    0,
    31
  ],
...

Babylon:
{
    "type": "Program",
    "start": 0,
    "end": 31,
    "range": [
      0,
      31
    ],
...

It seems the same groupings of parsers hold true for observed differences in TemplateLiteral.quasis location data too...
`42`;

Espree:
{
   "quasis": [{
      "type": "TemplateElement",
      "start": 1, // This combined with the range seems like a bug?
      "end": 3,  // This combined with the range seems like a bug?
      "range": [
         0,
         4
      ],
...

Esprima:
{
   "quasis": [{
      "type": "TemplateElement",
      "range": [
         0,
         4
      ],
...

Flow:
{
   "quasis": [{
      "type": "TemplateElement",
      "range": [
         0,
         4
      ],
...

Recast:
{
   "quasis": [{
      "type": "TemplateElement",
      "range": [
         0,
         4
      ],
...

Acorn:
{
   "quasis": [{
      "type": "TemplateElement",
      "start": 1,
      "end": 3,
      "range": [
         1,
         3
      ],
...

Babylon:
{
   "quasis": [{
      "type": "TemplateElement",
      "start": 1,
      "end": 3,
      "range": [
         1,
         3
      ],
...


fix: do not shutdown server on resize

What kind of change does this PR introduce?
do not process SignalKind::window_change()]

Are you making pr because of DX?


Added route and link for "Delete" function.

In your readme you mention CRUD, but there is no delete. I've used your code as part of a project, and along the way I've added a delete function. I thought you might like to update the template.

Thanks for this! Was still an open issue indeed.
Fixes #26.


[Bug] Parsing behaviors with concurrency takes extremely long when saved with spaces as indentation

The title basically says it all. If I save the same behavior with tabs as indentation, it works fine. I traced it down to https://github.com/pschillinger/flexbe_chrome_app/blob/b040351d91bf6a2aa21b5973f67ea5b1b9810eb6/FlexBE/src/_helper/codeparser.js#L277-L287. It takes ages there when the behavior was saved with spaces as indentation.
I assume that the regex patter cc_definition_pattern needs to be adapted? Bug was probably introduced by faea56748f1c63386c5bb11d438605e8cc8f80db ?

Thanks for pointing that out! The regex pattern actually contains a typo. It still matches the correct sequences, but this typo might cause the performance issue. I will fix it tomorrow, hope this resolves the issue.

I fixed the typo on the develop branch. Can you install this version and check if it also helps regarding the performance for you?

It indeed fixed the performance issue. However, the regex pattern was still wrong, causing it to not recognize the whole ConcurrencyContainer element. Parts of it were instead parsed as private variable.
I created a PR #6 which should fix this issue.

Should be resolved by your fix. Feel free to close this issue if it works for you now.

It did, thanks! Also for the \s hint


Question regarding uses of APIs incompatible with AppWindow and DesktopWindowXamlSource

How certain are we that erroneous uses of APIs incompatible with AppWindow and DesktopWindowXamlSource do not linger in platform XAML or WinUI?
As mentioned here, it is advisable for UWP developers to make their visual layer portable across the windowing hosts with XamlRoot.
I spent a considerable amount of time implementing AppWindow support for secondary views in a WinUI 2 UWP app only to find that hovering over elements in any MenuFlyout on the secondary views and quickly having the mouse pointer exit the flyout (or app) will block input to the entire application until I open the Start menu or ALT-TAB out of it. No exceptions anywhere to be found.
I have reason to believe this issue is present only when leveraging the UWP AppWindow, because it never occurred in the main ApplicationView.
Some more testing indicated that this problem only appears in the V2 styles and does NOT occur in platform XAML or with the v1 WinUI styles enabled.
I would love to contribute a fix for this, but it seems impossible to debug as the v1 and v2 styles look similar enough.

FYI @chingucoding
and
@StephenLPeters (fixed a potentially similar issue found in TeachingTip: https://github.com/microsoft/microsoft-ui-xaml/pull/6807)

It seems like setting:
<x:Boolean x:Key="ThemeShadowIsUsingDropShadows">False</x:Boolean>
in App.xaml fixes the issue completely.
Going to investigate this some more with @chingucoding and I'll open a bug report here to reflect the new information.

@bpulliam fyi


[camera] Zoom functionality for Android and iOS

Description
Adds zoom support to the camera implementations for Android and iOS. It implements the interfaces defined #3312.
This PR is currently still in draft state, as it still depends on:

#3302 General platform implementations being merged.
#3312 Updated camera_platform_interface being published to pub.dev.

Related Issues

flutter/flutter#28694

Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

@googlebot I consent.

@googlebot I consent.

@googlebot I consent.


x/net: slow streaming with http2 due to MaxConcurrentStreams

The k8s go client doesn't behave well since the change in https://github.com/golang/net/commit/1c05540f6879653db88113bc4a2b70aec4bd491f
What happens is that when the client hits the MaxConcurrentStreams of the server any updates after that take very long time (1-2 minutes) so on k8s clusters with constant changes the client can never catch up.
The fix in that commit seems valid, but shouldn't the retry interval can be configurable or provide an option to open a new connection like with the old behaviour.
More on the issue: https://github.com/kubernetes/client-go/issues/456
go version go1.11 linux/amd64

cc @tombergan

I will try to make a reproducible  test, but in the meanwhile some initial input would be useful.

This looks like a dup of https://github.com/golang/go/issues/27044 so I'm closing, but tagging @bradfitz due to the urgency that usually comes with k8s issues.


Add seed commands for CLI

Add commands to create and run seeds from the CLI.
Suggest the following syntax:
migrate create seed [Seed Name]
migrate fresh --seed
migrate up --seed [ optional seed name ]
If it is too difficult to change the method signature for the create action, however, the first command might be
migrate seed create [Seed Name]

Fixed in 4.0.0


Issue with progress bar

I am using just 3 images (or 3 stories you can say) and it shows me 5 progress bars at the top instead of 3.
Is this issue at your end or i'm doing something wrong ??
Please assist me.... :)

Thanks for your PR @Prshant-Sharma !

Thanks for your PR @Prshant-Sharma !


Add support for Hindi

Rohan Sharma is working on this

@andimarafioti waiting :)

@murugancmi support for hindi will be out soon.

@rs545837 good to know

Addressed in PR #82.


client side export slides, gets div by 0 in unique function

CC", begin=5049.5, end=11482.0, width=1600.0, height="1200">]
Traceback (most recent call last):
3: from ../../export_slides.rb:261:in <main>'         2: from ../../export_slides.rb:254:in export_pdf'
1: from ../../export_slides.rb:230:in unique_slides' ../../export_slides.rb:230:in /': divided by 0 (ZeroDivisionError)
If i comment out the unique function,  annotates_slides generate fine.

Hi, thanks for pointing this out, I've just pushed the fix.
I had forgotten these two lines in the code when debugging, you can either pull the fixed version or remove these two lines:
p slides
i = 1/0


chore set cloud_p1 (Doris Cloud Regression) as required

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Save animations

It would be great to have a way not just to save a fixed screenshot of a visualizer but also to record the animation.

We would likely want to use a library, e.g. https://github.com/tapioca24/p5.capture, for this. I think this will be a separate problem for each visualizer type, including even the svg version of p5 vs. regular p5.js.


[BUG]

Versions
PHP version: 7.2
Laravel version: 5.8
Package version: 3.1.11
Description
I am not able to import xls, xlt or any other excel format generated from MacOS. It always throws error
"Reader type bin not found"
The same code works with excels generated from Windows and Linux.
Steps to Reproduce
Create any excel file from MacOs and try to import the excel. After importing I am just printing the data.
Expected behavior:
Should be able to get the data from imported excel.
Actual behavior:
Throws error Reader type bin not found

Please adjust the title to make it descriptive and can you add your code to the issue as well? Thanks!

You are trying to read something with reader type "bin". Make sure you pass the correct reader type.


vue-tsc: After upgrading to v2, a lot of Could not find a declaration file for module ABC.vue errors are reported

After upgrading vue-tsc from 1.8.27 to 2.0.5,  a lot of typescript errors are reported when running
vue-tsc --noEmit -p tsconfig.vitest.json --composite false

in a vue 3.4.21 project.
The errors follow a similar format like this for all bootstrap-vue-next components:
node_modules/bootstrap-vue-next/src/components/index.ts:1:37 - error TS7016: Could not find a declaration file for module './BAccordion/BAccordion.vue'. 'C:/my/project/node_modules/bootstrap-vue-next/src/components/BAccordion/BAccordion.vue' implicitly has an 'any' type.

1 export {default as BAccordion} from './BAccordion/BAccordion.vue'

With vue-tsc 1.8.27, executing the command works without errors.
Strangely, in a pretty project with a pretty similar setup, these errors are not reported.
tsconfig files have the same contents in both projects.
It also happens in CI.
In Visual Studio code, it seems typescript correctly resolves the types as in the IDE, no errors are displayed.
It only happens when executing the vue-tsc command in the terminal.
Do you have any idea how I could further debug where this suddenly comes from?

I have experienced this problem as well and I have narrowed this down in my codebase to the tsconfig.json not including "src/**/*.vue". If I explicitly include all the .vue files this works fine, but if I only want to include the vue files that are traversable from the package index then this fails and no .d.ts files are generated for these files.
In short, this works:
"include": ["src/index.ts", "src/**/*.vue"]

But this doesn't:
"include": ["src/index.ts"]

IMO This is expected, you should include *.vue files if you want them to get type-checked.

IMO This is expected, you should include *.vue files if you want them to get type-checked.

I see where you are coming from, but if those .vue files are reachable from src/index.ts then they should also be included in the compilation as in my understanding, that's how it works for .ts files.
One usecase where this is useful is if you don't want to generate type declarations for components that are part of storybook documentation or that sort of thing. You might be able to exclude using a pattern like "**/stories/*.vue", but I find it's sometimes more logical to use a tsconfig that only includes the root files for your build artifacts so that you are only going to generate type declaration files for files that are reachable from those entry points.
I still view this as a regression since .ts files don't have this limitation and it worked fine in the 1.x release.

Yes, seemed to be a regression

Actually, my tsconfig.json looks like this:
"include": [
    "env.d.ts",
    "shims-bootstrap-vue.d.ts",
    "src/**/*",
    "src/**/*.vue",
    ...
  ],

so I have indeed included "src/**/*.vue".
I'm not sure if you @thebanjomatic encountered this issue with your own .vue files (in your own src directory) but in my case as written in the issue, this occurs for .vue files by the dependency bootstrap-vue-next in node_modules.
But from there, it might be that it is the same case as you described (.vue file referenced from index.ts) that might be causing the issue.
But bootstrap-vue-next also exports types in their `package.json:
...,
"exports": {
    ".": {
      "types": "./dist/src/BootstrapVue.d.ts", // <------------------
      "import": "./dist/bootstrap-vue-next.mjs",
      "require": "./dist/bootstrap-vue-next.umd.js"
    },
    "./dist/bootstrap-vue-next.css": "./dist/bootstrap-vue-next.css",
    "./src/*": "./src/*",
    "./src/styles/styles.scss": "./src/styles/styles.scss"
  },
...

So I'm not sure whether the .vue files should anyway be used.
Additionally, as mentioned, I am wondering why this happens in one project but not in a very similar project with almost identical setup (and tsconfig.json) but I could not figure out what is causing the difference.

@so1ve here is a good example repo to reproduce the regression:
https://github.com/vercel/turbo/tree/main/examples/with-vue-nuxt

I have experienced this problem as well and I have narrowed this down in my codebase to the tsconfig.json not including "src/**/*.vue". If I explicitly include all the .vue files this works fine, but if I only want to include the vue files that are traversable from the package index then this fails and no .d.ts files are generated for these files.
In short, this works:
"include": ["src/index.ts", "src/**/*.vue"]

But this doesn't (and previously did in v1.8.x):
"include": ["src/index.ts"]

Same problem. In version 2.0.4 there are some .dts files missing in my project, but in version 2.0.6 it was normal again.

A:
"include": ["src/index.ts", "src/**/*.vue"]

It works in v1.8.x & v2.0.6
B:
"include": ["src/index.ts"]

It works in v1.8.x.
When I use v2.0.6, there are some vue.dts files missing.
In the meanwhile, vue.dts files of some components can be generated, but the types of emits or slots are lost internally.
The above content is limited to the setup script component.

@so1ve do you have any idea how I could further trace this down what's causing this issue?
I tried to compare it to a second project with almost identical setup but I could not figure out what is causing this on one project but not on another.

Ok, I figured out what caused the issue after the update in my case.
As so often, it was an individual (wrong?!) configuration.
So if anyone else runs into this: I had an import like this in one of my .ts files:
import type { OrchestratedToast } from 'bootstrap-vue-next/src/BootstrapVue.js'

Changing/correcting this to
import type { OrchestratedToast } from 'bootstrap-vue-next'

solved the issue as now, I guess the correct d.ts definitions are used instead of the source.
From my side, this issue can be closed.
But I'm not sure whether you @so1ve want to keep this issue open as you mentioned a regression here so I'm leaving it open for now.

The configuration should behave similarly to the actual TS language server in that way that for all listed files in the "include" all imported files are also implicitly included.
Especially, in a monorepo workspace setup this change is not fixable a huge blocker. Why?
Because, we now need to declare in the "include" all used dependencies explicitly resulting into too many TS/Vue files that are getting checked instead of only checking the actually used dependencies.
This was already broken once in "vue-tsc" and they managed to fix it, but broke it again with the release of v2.
Please fix it again, so we can finally apply the update.

Just checked - this is no longer an issue in the latest version


all: trace unnecessary updates

https://github.com/garbles/why-did-you-update

Not really useful, gives a ton of false negatives.


Fix Boot Splash

Implements the code to show the boot splash on load using RenderingDevice
Does not work on X11 when maximized (this never really worked well, but now it seems to not even show anything), some platform specific hack will be needed there, unrelated to this PR.
Seems to work fine on Windows and likely does on other platforms.

Thanks!


PP-8849: provision signing key

Sets a signing key when a Webhook is created
Provides get endpoint to retrieve signing key at: GET /{externalId}/signing-key
Provides post endpoint to reset signing key at: POST /{externalId}/signing-key
Note: As this changes an existing migration you will need to nuke your database to test locally.

@alexbishop1 I have attempted to address all your comments and force-pushed. Please may you re-review?

@alexbishop1 have force-pushed to address your comments, aside from https://github.com/alphagov/pay-webhooks/pull/28#discussion_r754929476.


Fixes for starting up in development mode

Upgrade libv8 to avoid compilation failure on OS X
Upgrade Spring for compatibility with Bundler 1.11
Fix generating fake game histories from seed data
Populate fake ranks for Ranked mode in seed data

Thanks @mislav! I also changed the dev env login credentials in 5e2a49c4c45f069a0a32348a6ab91d0e3df0b995


Add filter option for AQS data specifically, but make it general

We need a general filter option. First we may want to use this for the AQS data to filter based on the measurement_scale to remove micro sites. But I'm sure there are other applications for this too, so we should make it general. This may be relevant for the aircraft evaluation too.
Maybe something like this in the yaml file:

filter_opt: This could be the expr like '==' below
filter_dict: This could be a dictionary where the keys are columns of the dataframe and the values are a list to accomodate multiple values being selected at once.

We probably just want to add into the code a query option like we have done with the domains.
https://github.com/NOAA-CSL/MELODIES-MONET/blob/0d2ca12e5ec46f4f595ce3e18e1acd680a5534c0/melodies_monet/driver.py#L726-L728
This is just a start it probably would take a bit more time to think of a good format for this, but I don't think it would be too hard.

-Make sure keep the relevant site information from the observations.
-Filter on the number of observations or as a separate yaml structure.
-Two options: one prior to pairing and one during the analysis

In order to do the filtering of Aeronet data I did for Brad Pierce's AGU22 poster, I add the following to my work flow between opening the observations and running the pairing.
# restriction of observations to analysis window specfied in yaml
an.obs['aeronet'].obj = an.obs['aeronet'].obj.sel(time=slice(an.start_time,an.end_time))

# removal of data for sites from the analysis scheme where there are fewer than x% of days reporting data
site_groups = an.obs['aeronet'].obj.groupby('siteid')#,'time'.dt.day)
for label,group in site_groups:
    #pull site, re-group to daily means
    tst = an.obs['aeronet'].obj['aod_550nm'][site_groups.groups[label]].groupby('time.dayofyear').mean().squeeze()
    if len(tst[~np.isnan(tst)]) < .5*len(tst): # filter to if <50% of days at site have data
        an.obs['aeronet'].obj['aod_550nm'][site_groups.groups[label]] = np.nan
        print('removed {}'.format(label))
        print('nobs:',len(tst[~np.isnan(tst)]))

Colin updated to add filtering options. So this is complete.