Wrong decoding of unprintable characters in text editor mode

I was in text editor mode and copy/pasted in a base64 encoded string that was an encoded JPG file. When decoded then reopened in Hex Editor mode, I was expecting it to start with FF D8 FF, but instead, it started with several instances of EF BF BD, the REPLACEMENT CHARACTER as encoded in UTF-8.
Manual decoding resulted in the expected FF D8 FF at the beginning of the file, so this appears to be a bug in decoding unprintable characters while in text editor mode.
To reproduce:

Copy this text snippet into a text editor window in VS Code with the base64 extension installed (it is a 1x1 JPG file):

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgKCgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkLEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wAARCAABAAEDAREAAhEBAxEB/8QAFAABAAAAAAAAAAAAAAAAAAAABf/EABQQAQAAAAAAAAAAAAAAAAAAAAD/xAAVAQEBAAAAAAAAAAAAAAAAAAAFBv/EABQRAQAAAAAAAAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/AEwiEf/Z

Select all, and run the Base64 Decode command.
Select all, and run the Base64 Encode command.

Expected result:

The encoded text should be equivalent to the text entered earlier.

Actual result:

The encoded text is different from that which was entered. Decoding the newly-encoded text yields a binary result that begins with four instances of the "REPLACEMENT CHARACTER" UTF-8 sequence.

Other notes:
About Visual Studio Code:
Version: 1.89.0 (Universal)
Commit: b58957e67ee1e712cebf466b995adf4c5307b2bd
Date: 2024-05-01T02:10:10.196Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin x64 23.4.0
Extension version: v1.0.0
Also reproducible on Linux x64 6.7.12-amd64.

It looks like a bug in VS Code hexeditor.
Steps to reproduce without using the base64 extension:

create a new text file with some text in it

open the file in hex editor mode and replace the text with some hex bytes

save and close the hex editor
get back to the text file and add a text and save

open the file in hex editor mode again

hex bytes are corrupted with EF BF BD ...

Still as a workaround you can use base64 extension in hex mode (hex decode your base64 string and modify and hex encode again).
In the future, we can add a hex editing mode for base64 extension, as a nice-to-have feature.


feat: make minimal init location more flexible and configurable

I need to customize the min_init path for a testing setup for one of my plugins.

@rcarriga this should be good to go now.

Perfect, thanks again :smile:


Why the expiry time of Firebase custom auth token is limited to max 1Hr(3600sec) ?

exp   The time, in seconds, at which the token expires. It can be at a maximum 3600 seconds later than iat.

I'm doing a chat application using Firebase. where I need to listen for incoming messages most of the time. If auth token expires every hour, its difficult for me to maintain the valid session all the time :(
In Legacy Firebase system, token expiry time was too flexiable; where we can adjust TTL value from 1Hr to as many years!! Never expire option was also there!
Why the current Firebase API, is forcing the client to refresh the Auth token every hour?
Also, I couldn't verify the Auth session length at client side,
In Firebase 9.0.0 API, how to check the user has valid Auth session or not?
Kindly help me on this.Thanks in advance!

@Karthi-R if you are using the Android SDK you should not have to worry about token expiration.  The auth and database SDKs talk to each other and the token is automatically refreshed every hour.  This should all be invisible to your application.
Are you having some problem where this is not the case?

@samtstern; thanks for your reply!
After the token expired, internally SDK itself trying to refresh the token. but its always failing with below error. As I'm using custom Authentication, SDK won't know my server endpoint to fetch new token (I guess).
D/ConnectionRetryHelper: Scheduling retry in 398ms
D/PersistentConnection: pc_0 - Trying to fetch auth token
D/PersistentConnection: pc_0 - Error fetching token: An internal error has occured. [ Internal error. ]
D/PersistentConnection: pc_0 - Scheduling connection attempt

In Firebase SDK, I couldn't find any API to check the token validity. If I know that token is expired, I can do the token refresh manually.
So I'm planning to maintain "last-token-fetch-time" info, so that I can refresh the token manually after one hour.
Kindly let me know, if there is any better way to handle this.

@Karthi-R this is a known issue in Firebase Authentication that a small number of developers are seeing, sorry about that!  I will get back to you with a workaround as soon as I have one.
Also as you can see on the status page Authentication currently has one other known issue that makes the SDK not production ready.  You can continue to develop your Android app with Firebase but we recommend not releasing with Authentication until that issue is resolved.

@samtstern Thanks for your update!

Hi,
I've migrated from the legacy firebase to google-firebase. I've semi-private information the access to which was being controlled using tokens with a large expiry time. This has become impossible with the current limitation.
Is there any plans of making the expiry time flexible. I'm using custom authentication as well.
Ideally the validity of the token has to be left to the token provider in case of custom authentication. Security needs are different for different applications. That's the whole point of having a custom authentication. I can't understand the rationale behind limiting the expiry for one hour.
Please help me comprehend it.
Thanks,

Same issue here. Hope it will get fixed soon.

@Karthi-R @sowdri Finally made it work. It is all about configuration problem. You have to add you SHA-1 to firebase database. You can follow this documenatation. Easy way to get SHA-1 key here
It should supposed to be documented.

@iammert Are you doing custom Authentication ?

I am using Facebook and MailPassword authentication. @Karthi-R

@iammert
If we use default Auth providers like (Google, Facebook, Email..), updating "SHA-1 key" in firebase console would enable Automatic token refresh. (Its working fine as you said)
But in custom authentication, Firebase SDK need to contact 3rd party server to fetch new token.
Here only SDK is failing to refresh the token!

Oh seriously, why did you add this limitation ! I have a server which produces tokens for other server users to use for at least several months. Now I should build a service to create tokens every hour ?

@samtstern I'm running head on into this problem.  This timeout restriction is really terrible for IOT use cases.
I have a few hundred IOT devices that I am trying to safely upload data from.  An ideal way to do this is to generate tokens that last about a year for each device: using their owner's UID, but signed with "claims" containing the device serial number.
In Firebase, this makes it easy to secure each device's database access: any individual device that misbehaves can be restricted to write-access in its own "/$userid/$auth.deviceid" path.
However, with this timeout hard-limit, there is absolutely no way that I can see to make this work, other than:

having each user either store their password on each device
querying an entirely separate database to generate the tokens (at which point why even use firebase?)
have each user create dozens of accounts for each of their IOT devices.

I'm really at a loss on how to handle this when transitioning from the v2 API.  Anyone over there have any ideas?

While the token expires in one hour, that's just how long you have to use that token to authenticate.  Once you've called authWithCustomToken successfully, you stay logged in forever (until you sign out explicitly) so you should be able to get devices to have a long-lived authentication session without minting long-lived custom tokens.

Thanks very much for the suggestion @samtstern!
I tried this, but unfortunately, it seems like the session is not cached if the device reboots or the app gets restarted.  Is this supposed to be the case?  Alternatively, is there a way to force the authentication to be preserved across hard resets?

@psigen on an Android device the session is cached in the SharedPreferences of your application.  It should have the same lifecycle as that does, which should definitely persist across device reboots.  Unfortunately you can't persist across hard resets.

Ok, I might be accidentally clearing SharedPreferences as part of an autoupdate process.  Thanks for the info, I think I should be able to make this work!

Ok for the following reasons I am going to close this issue:

Original poster has not been involved in 21 days
@psigen has a potential workaround to go try
This issue tracker is really meant to deal with issues with the quickstarts and not general product feedback
I have shown the team this thread and they are taking all of your feedback under consideration

If anyone here experiences further issues trying to use code in this repo, please open a new issue so we can discuss those in isolation.  Thanks to all of you for your great feedback and patience!

I'm seeing this issue too, is this really not going to be fixed?

Yeah this is kind of crazy, why not just allow custom expiration?

Hi!!
I have a questions.
I am making an app and in ionic3 and angular 4 and I need that my apikey never to expire because when  my app is uploaded so people can download it, it will fail because my apiKey expires.
How can I do that? It is possible?
Thanks for all

@MariCarmenBaenaSopra that's a usage question outside the scope of this quickstart and you've appended it to a closed issue. It's unlikely to get any attention here. Try our community channels instead.

Locking this conversation as it's unrelated to the quickstart. Please file feature requests here.


NATIVE-604: Add release notes docu

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword NATIVE.

ready for merge


chore: ci checks and git hooks

Explanation
This PR adds some ci checks and enables pre-push and commit message checks for local development.
In addition, I added dependabot file to create PR for dependency updates automatically.
Details are below:

[x] Add prettier, linter, type and tests check for PR and master
[x] Add pre-commit, pre-push git hooks
[x] Add dependabot
[x] Add commit message linter

More Information
Closes #74
Closes #94
Closes #95
Screenshots/Screencaps
N/A
Manual Testing Steps
N/A
Pre-Merge Checklist

[x] PR template is filled out
[ ] IF this PR fixes a bug, a test that would have caught the bug has been added
[x] PR is linked to the appropriate GitHub issue
[x] PR has been added to the appropriate release Milestone

+ If there are functional changes:

[ ] Manual testing complete & passed
[ ] "Extension QA Board" label has been applied

PR template source from github.com/MetaMask

@gurrpi thanks! I added you fixes and changed failing test (it's because nock doesn't support new fetch for node v18).


Resizable entity height can't be changed after width

Steps to reproduce:

Create a project with an entity layer
Create an entity with Resizable X and Resizable Y
Place that entity in a level
Change its Width to 32. Notice the change.
Change its Height to 32. Notice there's no change.
Reset width/height to 16.
Edit Height to 32. Notice the change.
Edit Width to 32. Notice the change.

This is a weird one... Why does the order matter here? I'll dig into this sometime soon.

closed with #146


Rewrite fails to disambiguate when only one option is valid

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Check that your issue is not already filed.
Reduce the issue to a minimal, self-contained, reproducible test case. Avoid dependencies to mathlib4 or std4.

Description
Rewrite fails to disambiguate when only one option is valid
Context
theorem add_succ : true = true := rfl

open Nat

#check add_succ -- Nat.add_succ
#check (add_succ : true = true) -- _root_.add_succ

example (x y : Nat) : x + (y + 1) = (x + y) + 1 := by
  rw [add_succ]
  /-
  ambiguous, possible interpretations
  _root_.add_succ : true = true

  Nat.add_succ : ∀ (n m : Nat), n + succ m = succ (n + m)
  -/

Zulip discussion: https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/ambiguous.20rewrite.20when.20only.20one.20is.20valid. The equivalent in Lean 3 succeeds. Thanks to @kmill for minimising. This showed up in porting the exponential-ramsey project.
Steps to Reproduce
Code as above.
Expected behavior: The rewrite succeeds and closes the goal.
Actual behavior: The rewrite fails.
Versions
Lean (version 4.3.0-rc1, commit https://github.com/leanprover/lean4/commit/baa4b68a71926a722b77d4ec2cba34bfc76cc5aa, Release)
MacOS
Additional Information
None
Impact
Add :+1: to issues you consider important. If others are impacted by this issue, please ask them to add :+1: to it.

NB: This happens with other tactics as well:
/--
error: ambiguous term, use fully qualified name, possible interpretations [_root_.add_succ, Nat.add_succ]
-/
#guard_msgs in
example (x y : Nat) : x + (y + 1) = (x + y) + 1 := by
  apply add_succ

Arguably it’s an issue with #check?

Yes, that's #5873

@b-mehta Was this more of a porting gotcha or are you still interested in seeing this issue fixed?

I'm still interested in seeing this issue fixed, outside of being a regression from Lean 3:

It's confusing behaviour to beginners to see a rewrite fail with error mentioning "ambiguous", when there's not actually an ambiguity.
This came up in mathlib, see eg the linked PR above.
If I write a term in term-mode which has an ambiguity in name resolution, Lean is able (IIUC) to disambiguate in the case that the types are enough to figure it out. So it would be nice if the same were true in rewrites.

NB: This happens with other tactics as well:
/--
error: ambiguous term, use fully qualified name, possible interpretations [_root_.add_succ, Nat.add_succ]
-/
#guard_msgs in
example (x y : Nat) : x + (y + 1) = (x + y) + 1 := by
  apply add_succ

Arguably it’s an issue with #check?

Interestingly, this looks like a new issue with #check - seemingly Kyle didn't see ambiguity in this situation (see the linked zulip thread)

So would you expect that all tactics to try all possible interpretations of a name, and silently use the first that happens to make progress? Or only some of them? Would simp use the first one that it can use, and ignore the others, or all of them?

So would you expect that all tactics to try all possible interpretations of a name, and silently use the first that happens to make progress?

No, but if there is exactly one interpretation which makes sense, I would expect the tactic to use that one, rather than failing with an error that there are multiple possible interpretations. If there are multiple interpretations which make sense, then an "ambiguous, possible interpretations" error is completely fine

Thanks for the (heh) elaboration. My personal opinion is that I find the current behavior, with a clear phase separation between name resolution and tactic execution, more predictable and preferable. But I have noticed that I'm leaning towards more explicitness and less magic than seems to be idiomatic in at least mathlib, so I'll just let that stand and let others call this shot.

And, to add, some more questions that this feature require raises:
Assuming that rewrite [foo] would succeed if foo resolves to multiple names, but exactly one of them can be rewritten with, how does that interact with tactic combinators.

For example, rewrite [foo] <;> rfl – will that work if both foo’s can be rewritten with, but only in one case the the next step closes the goal?
Would rw [foo] behave the same as rewrite [foo] <;> rfl, or differently?
What about tac <;> rewrite [foo]. Does this work if there is a “globally unique” foo that this can be rewritten with, or can every branch make it's own decision? If the latter, what type and docstring is shown when hovering foo?

More generally, if in rewrite [foo] the foo can be understood as “bag of theorems, of which exactly one should may make sense”, then it seems prudent to make that a proper feature of its own, where a name can generally be a bag of theorems, and make good use of that in general. This is what Isabelle does – lemmas foo_or_bar = foo bar is a thing, and often useful. It seems odd if Lean effectively properly supported names-referring-to-sets-of-things, but then only expose it when name resolution is ambiguous due to namespaces.
Actually, we almost already have that feature, in a way, although the syntax is a bit weird:

open _root_ renaming Nat.le_of_lt → foo
open _root_ renaming Int.le_of_lt → foo
open _root_ renaming True.intro → foo

/--
error: ambiguous, possible interpretations ⏎
  True.intro : True
  ⏎
  @Int.le_of_lt : ∀ {a b : Int}, a < b → a ≤ b
  ⏎
  @Nat.le_of_lt : ∀ {n m : Nat}, n < m → n ≤ m
---
error: tactic 'rewrite' failed, equality or iff proof expected
  ?m.5
⊢ True
-/
#guard_msgs in
example : True := by rw [@foo]

(And while you can write open _root_ renaming Nat.le_of_lt → Foo.foo, it doesn't actually add foo to namespace Foo in a way that you can open Foo.)
Anyways, it’s a big design space, and I’d prefer the simplicity of asking the use to be explicit which lemma they want to use.

I think that this doesn't need to have quite so profound of design consequences @nomeata. The question to me is just "should kabstract be considered to be part of elaboration or not"? We have at least a couple examples of it being within the scope of elaboration (the triangle operator and elabAsElim), so it doesn't seem impossible for the product of a rw theorem elaboration to be the theorem and the motive together. This should naturally handle disambiguation in the way Bhavik would want.
Similarly, for apply, if we made it into an app elaborator mode like we'd discussed once in a DM, that too would naturally handle disambiguation.

Maybe I am confused by what you mean, but isn’t_root_.add_succ is a possible interpretation of “add_succ” in this point? It’s an interpretation that happens to make rw fail, but so does rw [mul_succ].
Would you say that Nat.mul_succ is not an interpretation of mul_succ in rw [mul_succ] if that rewrite fails?

More generally, does this closure mean that when I see a message "possible interpretations" in the future, I should not take this as accurate?

I understand this message as “possible interpretations of the name”, which is accurate. It does not mean “possible interpretations of the name for which rewriting succeeds”.
--

to exactly the tactic which is throwing the error.

This is a concept I have qualms with. Many tactics are implemented by elaboration to other tactics. Do you mean “tactic that the user wrote” or “primitive tactic” (whatever that means).
Consider rewrite [thmA_or_thm_B, thm2], where thmA an resolve to thmA or thmB. Assume that both rewrite, but only if thmB was taken, thm2 can apply. Should this, under your design, succeeds as rewrite [thmB, thm2] would, or complain that thmA_or_thmB is ambiguous?
Or similar with rw – is the rfl inside that tactic included or not?

In the future, should I continue to expect inconsistencies like this in elaboration?

Yes, unfortunately. Note that
example (x y : Nat) : x + (y + 1) = (x + y) + 1 := by
  apply add_succ x y

also reports “ambiguous, possible interpretations”.
It seems that term elaboration can and will use type information to resolve ambiguities, and it’s not always clear how much type information is available in a given context. But it seems that’s consistent with other features, like dot notation.

@b-mehta I was just reading the Lean 3 source code, and I don't see anything that indicates that rw was aware of choice nodes. (In Lean 3, parsing and elaboration ambiguities could be represented using "choice nodes". In Lean 4, only parsing has choice nodes.) I also checked how type inference worked for choice nodes, and Lean 3 threw an error in that case, so there are also no features that could have made this disambiguation work that I can see.
Could you please verify that the Lean 3 rw was able to disambiguate in the way you're saying it did? It seems possible that this is all explainable by other differences, and it would be good to be completely sure that there was a disambiguation mechanism that rw was using before continuing the discussion in this direction.

As far as I am aware, lean 3 did not handle this situation any better than lean 4.

I understand this message as “possible interpretations of the name”, which is accurate. It does not mean “possible interpretations of the name for which rewriting succeeds”.

Hmm okay, this is convincing.

Could you please verify that the Lean 3 rw was able to disambiguate in the way you're saying it did?

Huh, looking at my older non-minimised example, the behaviour which I'd originally complained about seems to actually work fine now (and behaves similarly to Lean 3).
...and investigating further, the difference happened in minimisation! The example with pow_succ in the linked zulip thread (seemingly) didn't disambiguate correctly, but does now, and it's because of the protected tag on Nat.pow_succ. Whereas after changing to add_succ, where there's no protected on Nat.add_succ, the situation changes.
(Maybe this means Nat.add_succ should be protected, though?)
So I'm happy to consider this issue resolved. Thanks all!


More examples

We should provide more examples. Especially at least one non-React example.

[x] React
[x] Vanilla JS
[ ] Routing

A huge project example is coming soon :)

Closing this in favor of #159


fix(rate-limits): More improvements with rate-limit handling

:tada: This PR is included in version 1.4.4 :tada:
Your semantic-release bot :package::rocket:


Fix join on arrays of unhashable types and allow hash join on all types supported at run-time

Which issue does this PR close?
None
Rationale for this change
fix potential query failure due to incorrect can_hash result
What changes are included in this PR?

update can_hash
cleanup compute_hashes

Are these changes tested?
Yes, unit tests.
query-based tests are hard to write -- it is unclear how to construct Union or RunEndEncoded types in SQL
Are there any user-facing changes?
yes

query-based tests are hard to write -- it is unclear how to construct Union or RunEndEncoded types in SQL

The way to do so would be via arrow_cast
However, those types don't seem to be supported via arrow_cast yet:
> select arrow_cast(1, 'Union(Union))');
Error during planning: Unsupported type 'Union(Union))'. Must be a supported arrow type name such as 'Int32' or 'Timestamp(Nanosecond, None)'. Error unrecognized word: Union

The other way to do it is to programatically setup the sqllogictest, as is done for map.slt (which didn't have any way to create MapArrays when it was written): https://github.com/apache/datafusion/blob/ac79ef3442e65f6197c7234da9fad964895b9101/datafusion/sqllogictest/src/test_context.rs#L84-L85

This change has two aspects

fixing hash joins on types that are not hashable, but can_hash considered them hashable. This is eg List of something unhashable. I couldn't write a test for this, since types such as listview or ree hit other problems.
unblocking hash joins on types that are actually hashable, but can_hash considered them not hashable. This is not as edge-case'y, for example binary is hashable, but we didn't use hash joins when joining on binary. I added a plan test for this.

@alamb please take another look


About training material

How about translation ( localization , internationalization ) of training-material ?
At least we need main Galaxy  translation coverage more higher.
And tool translation is needed (https://github.com/galaxyproject/galaxy/pull/4251).
I hope that we discuss about traininge-material translation .

Thanks for opening this discussion! It could be great to have translations of the training material.
Do you have in mind a possible solution for the training material?
We need to keep in mind to avoid any redundancy, and the solution must be quite automatic.
Any idea?

@manabuishii @yvanlebras we discussed this issue during our Hackathon in Norwich and wondered how good Google Translate is for your languages?
If possible we would try to make the sentences we use easier to translate for Google translate and Co. Ideally, but I have not found it yet, we could annotate our text in HTML to give Google hints how to translate text.
Do you think this is possible and would help, even if its not a manual high quality translation?

Hi
If you use "class=notranslate" or  tags, content within won't be translated by Google Translate. It an be useful for tools and parameters name, and labels, etc
I hope it helps

@anilthanki awesome! Do you have a reference for this? That is exactly what we need. We could tag our special boxes with this.

Thanks for the update and groovy news !!! If we can try something @anilthanki @bgruening on our side, don't hesitate !!!

@bgruening sure here it is... https://www.w3schools.com/tags/att_global_translate.asp @nsoranzo

@yvanlebras what I would like to know is if you have the feeling that google-translate or similar engines are good enough to translate the training in general. We try as hard as we can to improve it and provide hints to the engine but I guess they need to be at least good in the first place.

@bgruening google-translate was realy not good but it appears to be best now.... so maybe ok... don't know if this can be ok for the training materials... We have to test! Did you want we (Galaxy-E) have a look on it?

Please yes! :)
Would be nice to know if its good`ish and if we should try to enhance the translation by marking paragraphs as non-translatable or other hints.

Currentlly I don't know more useful translation tool than Google Translate .
When I translated some documents were,  we use translation tool after that we proofreading.
We don't use just only google translate to keep quality of documents, checking the quality by Japanese Community Members.
But it's good starting point.
As aspect of translation managing tool, we use Google Docs, but now we try https://hackmd.io/ this is a online collaboration MarkDown editor.

Japanese Translation for 3 tutorials by A-Asai · Pull Request #862 · galaxyproject/training-material · GitHub

It seems you can build a link where you can choose the target language and the page. An example, generated by putting the URL in translate.google.com. Both changing the URL it points to (u=http...) and the language (tl=nl in example) seems to get the desired effect.
https://translate.google.com/translate?sl=auto&tl=nl&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fgalaxyproject.github.io%2Ftraining-material%2Ftopics%2Fintroduction%2Ftutorials%2Fgalaxy-intro-peaks2genes%2Ftutorial.html&edit-text=&act=url

Discussions about that during the last GTN meeting #954:

There is an open PR for a translated tutorial. We all agree it is a good idea, but how do we deal with this? Do we keep a manual translation, do we have some that are manually done, some that are automatic/linked via google translate?
We submitted a proposal for MozFest for automatic translation of community documentation. We will hopefully gather ideas from the community there. But no clear solution?
Berenice tried to 'trick' the API to have it avoid translating specific portions of the page
Gildas notes that google already proposes to translate things whenever your browser is in a different language to the webpage.
Bjoern suggests that we add something on the template to link to the google translate URLs. We need to highlight on the front page that the current system is google translate and you should use.

Translation now integrated as part of #1131 #1143, left open for discussion?

The automatic translation seems to be working well for most cases. If there is still the need for localisation of the materials we should re-open this issue. Thanks y'all!


[20.03] nixos/sudo: default rule should be first

In /etc/sudoers, the last-matched rule will override all
previously-matched rules. Thus, make the default rule show up first (but
still allow some wiggle room for a user to mkBefore it), before any
user-defined rules.
(cherry picked from commit 13e2c75c932adac6a198e35b04e2cb9a1eaf86cf)

Motivation for this change
Backport of https://github.com/NixOS/nixpkgs/pull/87579.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg test sudo


Fixes #1137 - Adding query_image to Neural query

Description
Fixes missing field for query_image in Neural Query. See Neural query.
Issues Resolved

Fixes #1137

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thanks. If you can, please help make sure we don't break it via code generation. I see query_image in https://github.com/opensearch-project/opensearch-api-specification/blob/09824d0d0913a27ed9deeedf71fa4fffb1bed8ff/spec/schemas/_common.query_dsl.yaml#L1238, but I don't see any tests for it. Maybe you can add one into https://github.com/opensearch-project/opensearch-api-specification/tree/main/tests/default?

Thanks. If you can, please help make sure we don't break it via code generation. I see query_image in https://github.com/opensearch-project/opensearch-api-specification/blob/09824d0d0913a27ed9deeedf71fa4fffb1bed8ff/spec/schemas/_common.query_dsl.yaml#L1238, but I don't see any tests for it. Maybe you can add one into https://github.com/opensearch-project/opensearch-api-specification/tree/main/tests/default?

@dblock , I manually added the changes into NeuralQuery in this project. That link that you send me is for another project. How are these projects related ?

Hello @Xtansia & @dblock , I reviewed the existing schema definition and executed the generator.
Before downloading the latest schema the generator executed, but not clases for querying where generated.
After downloading the latest version the generator thrown this error:
[CodeGenerator] FATAL - Unexpected Error
java.lang.IllegalArgumentException: Unknown status code: 204
        at org.opensearch.client.codegen.openapi.HttpStatusCode.from(HttpStatusCode.java:40) ~[main/:?]
        at org.opensearch.client.codegen.openapi.OpenApiElement.lambda$children$2(OpenApiElement.java:115) ~[main/:?]
        at org.opensearch.client.codegen.utils.Maps$EntryMapper.map(Maps.java:68) ~[main/:?]

I tried merging into the original file the Neural definition but then failed becase of the format binary not recognized:
[CodeGenerator] FATAL - Unexpected Error
java.lang.IllegalArgumentException: Unknown format: binary
        at org.opensearch.client.codegen.openapi.OpenApiSchemaFormat.from(OpenApiSchemaFormat.java:28) ~[main/:?]
        at org.opensearch.client.codegen.utils.Functional.ifNonnull(Functional.java:24) ~[main/:?]
        at org.opensearch.client.codegen.openapi.OpenApiSchema.<init>(OpenApiSchema.java:107) ~[main/:?]
        at org.opensearch.client.codegen.openapi.OpenApiElement.lambda$children$3(OpenApiElement.java:116) ~[main/:?]
        at org.opensearch.client.codegen.utils.Maps$EntryMapper.map(Maps.java:68) ~[main/:?]

Since the query_image is a String with a image in Base64 encoded format, seems safe to remove the format.
With that change the generation executed but still have not generated any query related object to check.
Thus I do not see compatibility issues with the schema definition and my change (except that I added a validation to check that at least one of the fields text or image are completed).
Not sure what else, I should check move forward.
Thank you

@dblock , I created this PR in the API specs project.
Hope I do now know how to create a test in that project. If you can give me detailed instructions I can try to help.
Regarding this change for the Java Client what else need to be done to move forward ?
Thank you

@Xtansia , are we good with this changes for this project ?
(I will keep working on the other)


VLC doesn't work on CENTOS6.6

I tried the oldest version on github 2.2.2 and it still errors on a libc version that is too new... we have glibc 2.12 ...

So far I was not successful in compiling it on an older distribution yet.

Trying a build on CentOS 6.0 now

Any news? Good to close?

Oh yes, sorry - the version you released did work on CENTOS6.6 as long
as you don't use GNOME as your DE. Weird huh? XFCE is fine with it and
solves our need. Thanks a LOT!
James Pulver
CLASSE Computer Group
Cornell University
On 07/05/2016 06:36 AM, Baurzhan Muftakhidinov wrote:

Any news? Good to close?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/probonopd/AppImages/issues/67#issuecomment-230444482,
or mute the thread
https://github.com/notifications/unsubscribe/ABVyutni9QK1E5vzRBxQsEyXb8-uFQCrks5qSjOQgaJpZM4IzPCI.


Build a buffer for incoming mesages for PAPA

Is your feature request related to a problem? Please describe.
When a message comes into the papaDuck but the papaDuck is trying to connect to the internet the incoming messages get lost.
Describe the solution you'd like
We need to build some sort of storage/queue where the incoming messages can sit temporarily
Additional context
When I was developing for the DishDuck I came across a problem where it takes a little while before the RockBlock is booted so the incoming messages get lost during that time.

this should be applied to MAMA too, radiolib now provides an interface for "is the lora modem receiving right now" and by checking that before sending via lora we can avoid at least some on-air
collisions.
a first step in this direction would be to define a struct (or even class) that contains everything related to a message/quack.
at the moment all data fields are spread over the Duck class, and functions have interesting assumptions about which fields are valid and contain what at any given time.
there may be some possible tie-in with #88 because one way to go about this could be to keep the data as key-value pairs and using the bytecodes as keys. that way we could avoid translating between "names" and "codes" multiple times during the lifetime of a message.
as in, hold the message in a base format, and have a bunch of "send as lora" or "send as json via mqtt or http" or whatver sinks.

This should be tied in with #99


Boot banner can cut through output of shell prompt

Describe the bug
Whilst testing smp_svr with a build including many overlay files, this was seen at startup on a module:
*** Booting Zephyr OS build v3.2.0-rc2-88-gf7251073c4b6  ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot

ua*** Booting Zephyr OS build v3.2.0-rc2-92-g6030b85f71ce  ***
rt:~$

The boot banner is output part the way through the shell prompt output.
To Reproduce
Steps to reproduce the behavior:
cmake -GNinja -DBOARD=nrf5340dk_nrf5340_cpuapp -DOVERLAY_CONFIG="overlay-shell.conf;overlay-shell-mgmt.conf;overlay-bt.conf;overlay-udp.conf" .. (note: also requires mcuboot for cpuapp and hci_rpmsg for cpunet) then run
Expected behavior
The output of the boot banner to not obscure the shell, and ideally, output before the shell prompt starts
Impact
Annoyance
Environment (please complete the following information):

OS: Linux
Toolchain: Zephyr SDK 0.14.2
Commit SHA or Version used: 6030b85f71ce05a69d6953f265ae1831a6c67548

@nordic-krch Is there any reason CONFIG_LOG_PRINTK isn't enabled by default if logging is enabled and CONFIG_PRINTK is enabled? That avoids this issue

The main reason was that logging behaves differently, especially deferred mode where output is delayed. Imo, CONFIG_LOG_PRINTK=y could be the default but I guess that  we need broader audience to make that decision. Maybe Architecture working group meeting (@carlescufi).

I've just tried enabling CONFIG_LOG_PRINTK on this issue https://github.com/zephyrproject-rtos/zephyr/issues/38947 and it's magically resolved, so it does seem like defaulting to this option when logging is enabled would help with a few bugs

The main reason was that logging behaves differently, especially deferred mode where output is delayed. Imo, CONFIG_LOG_PRINTK=y could be the default but I guess that we need broader audience to make that decision. Maybe Architecture working group meeting (@carlescufi).

Can you please post a PR changing the default @nordic-krch? Then we'll drive the discussion in that PR.

Closing this issue since it's a matter of enabling CONFIG_LOG_PRINTK.


Possible reentrancy issues with hooks in mutate closure

Substrate have some hooks invocation inside mutate calls, this means there will be pending changes in stack which are not accessible by hooks. When hook attempting to read or modify the same values, a lost update will happen.
This could trigger some security issue if the implementer of the hooks did not know this constraint.
One example is the DustRemoval hook on pallet-balances
https://github.com/paritytech/substrate/blob/cff25fbc37c9fc564f8816eefdcd8dce15e1606b/frame/balances/src/lib.rs#L207
It is called in post_mutation
https://github.com/paritytech/substrate/blob/cff25fbc37c9fc564f8816eefdcd8dce15e1606b/frame/balances/src/lib.rs#L604-L611
which is called in try_mutate_exists
https://github.com/paritytech/substrate/blob/cff25fbc37c9fc564f8816eefdcd8dce15e1606b/frame/balances/src/lib.rs#L645-L654
So the DustRemoval cannot do any modification to the maybe_account or lost update will happen.

I read a bit about the previous reentrancy issues in ETH but still can't figure out what you exactly mean by "lost update". Can you elaborate on the scenario above and point out what exactly can go wrong, under which conditions?

Here is a demo https://github.com/paritytech/substrate/blob/0fe33f078cd5242376e575136d0fd2d21d5627c9/frame/balances/src/tests_reentrancy.rs
All the dust should go to account 1, which is a typical usage if 1 is a treasury account.
https://github.com/paritytech/substrate/blob/0fe33f078cd5242376e575136d0fd2d21d5627c9/frame/balances/src/tests_reentrancy.rs#L101-L105
This is a working normal case, 50 dust goes to 1
https://github.com/paritytech/substrate/blob/0fe33f078cd5242376e575136d0fd2d21d5627c9/frame/balances/src/tests_reentrancy.rs#L159-L164
This is a lost update case
https://github.com/paritytech/substrate/blob/0fe33f078cd5242376e575136d0fd2d21d5627c9/frame/balances/src/tests_reentrancy.rs#L174-L178
The transfer send 450 to account 1 and dust removal send another 50 to 1. But because the 450 write happen after the 50 write, so 50 disappears.

Hello @xlc/@kianenigma/Shawn,
Tried first level of analysis,
Observed recursive call at "fn try_mutate_account()" in "fn transfer()" execution sequence.
Looks like local stack object "AccountData" is not in-sync with DB.
Below snapshot captures status of "AccountData" in "fn try_mutate_account()"

So recursive is comming into picture during Dust removal.
As part of initial analysis, tried to do "fn transfer()" without any recursive. to make test function "fn has_reentrancy_issue()" to work.
Plz find draft version in the link https://github.com/paritytech/substrate/pull/7783
Looking for some input on, howto make local object "AccountData" in-sync with DB, under recursive call context.


Suppress update messages during replay

What was changed

When replaying, don't send response messages (Accept/Reject/Complete).
Why?

These messages are redundant during replay - they should only be sent when not replaying.
Checklist

Closes

#1057

How was this tested:

Unit test & features test

Any docs updates needed?

No

Are they merely redundant, or actively incorrect? Either way the change makes sense.

Actively incorrect works. Aggressively erroneous. Wicked busted. Pick your phrasing.


Multi channel system W2100

Implement a Node for Multi Channel System W2100 system

Yeah, go ahead and take out faulthandler. You only need it if you expect to be debugging segmentation faults.
I'm curious, though: could you just call faulthandler.disable() before importing clr? That way it would always be enabled except when pythonnet is used.


Power8 support

Author Name: Bastiaan Visser (Bastiaan Visser)
Original Redmine Issue: 4072, https://dev.opennebula.org/issues/4072
Original Date: 2015-10-19
Original Assignee: Bastiaan Visser

KVM is supported on power8, little changes are required to support it in OpenNebula as well

Original Redmine Comment
Author Name: Carlos  Cesario (Carlos  Cesario)
Original Date: 2016-09-08T13:20:16Z

Bastiaan Visser wrote:

KVM is supported on power8, little changes are required to support it in OpenNebula as well

Hello,
How are doing this request!? Is it already supported!?
best regards,
-Carlos

Original Redmine Comment
Author Name: Carlos  Cesario (Carlos  Cesario)
Original Date: 2016-09-29T16:30:12Z

Hello folks, any info/news about it!?

Original Redmine Comment
Author Name: Ruben S. Montero (@rsmontero)
Original Date: 2016-10-10T16:57:53Z

Can we close this as a duplicate for: http://dev.opennebula.org/issues/3510? What else is needed?

Original Redmine Comment
Author Name: Bastiaan Visser (Bastiaan Visser)
Original Date: 2017-05-08T22:16:54Z

Ruben S. Montero wrote:

Can we close this as a duplicate for: http://dev.opennebula.org/issues/3510? What else is needed?

Definately, i got a test setup workung overriding the EMULATOR attribute does the trick!


Switch to public Travis

https://github.com/serverless/event-gateway/commit/18c25efc21ed4e567d7f7bbf78aa857f9ae2baeb


Target.background() alignment on Target.execute() and misc connection update

@marcbonnici Updated with typo fixed


Maya: add support for Maya 2025

Changelog Description
Adding support to Maya 2025
Additional info
This is adding default values to settings, moving around capture.py to Maya addon (where it should be anyway) and fixing some Qt imports there.

[!NOTE]
Touching pyproject.toml is done just to calm codespell in pre-commit hook because of the TVPaint path.

Testing notes:

Run Maya 2025 and it should work
Run Maya 2024 should work too
Playblasting should work also

QDesktopWidget

It has been removed in Qt6 and thus capture.py would need to be updated.
You will need to use QScreen. I believe we're doing that elsewhere already. For example getting the screen geometry here


Improve French translation

Add uppercase, fix some languages specificities

@Neluji thanks a lot ! First letter uppercase should never be needed as I add them afterward in code.
But anyway thanks a lot !

First letter uppercase should never be needed as I add them afterward in code.

Oh ok I didn't know, as I noticed some expressions that were not uppercased in the app I made them all uppercase 😅


test

Type: Missing
Summary:
test
Details:
test
Resolution:
test
Affected definitions:

blog-plugin c77ac286e4ed7ecf0b8a7f3768d98444d698844a

You can review the change introduced to the full definition at ClearlyDefined.


Fixed a bug in parsing rtf compressed msg files

Status

[ ] In Progress
[x] Ready
[ ] In Hold - (Reason for hold)

Related Issues
fixes: XSUP-17612.
Description
In the related issue, there is an email (msg file) that fails the scripts.
The exception is raised in the code of RTFDE.deencapsulate package that we use to read RTF compressed mails.
It seems like a known problem in the RTFDE.deencapsulate package - link to the open issue. I asked there about the status of a fix.
In the meantime, I used a hack (published in their issue) to temporarily overcome the problem.
Using this hack the file is now parsed successfully (the rtf is parsed to a valid HTML file).
This fix should be temporary - when version 0.0.3 of the RTFDE.deencapsulate package is released we should revert this fix and try to use the updated package instead.
@moishce - Let's discuss the best way to remember to do this.
I wanted to add a unit test with the bug's .msg file, but I couldn't remove the metadata of the file (didn't want to expose the customer's data).
Must have

[ ] Tests
[ ] Documentation

@ShacharKidor Please update the change log

@ShacharKidor Please update the change log

@moishce - Added, thank you.

@ShahafBenYakir - Please force merge the PR.
According to @moishce the error in the pre-commit step is a known error needed to be fixed (not related to this PR).


Create sample SQLite database for the OPEN project

Task to do
Create SQLite DB for one sensor and one season as a sample for ML team to use
Requirements: https://github.com/terraref/reference-data/issues/279
Reason
Makes it easier for data discovery
Result
A SQLite database that can be used as a reference point for further SQLite databases

Currently the code resides at: https://github.com/Chris-Schnaufer/generate_sqlite
Waiting on feedback on database instance: https://drive.google.com/file/d/1VyPtQYcj5xaaB7OUB6UILNd9It3tfgeD/view?usp=sharing


Added fork notice to README

I have forked eight-track to a repo named nine-track. I was unable to gain push permissions for eight-track. I believe this will cause awkward and inefficient workflows as it has in Uber/sublime-phabricator#7. As a result, I have decided to fork out of frustration.
https://github.com/twolfson/nine-track
I have a few features planned for the fork:

Allow data to be sanitized before saving to disk

Useful for scrubbing authentication info on public repos

Handle series-based requests (e.g. make a read, submit an update, read again to verify changes)

Early notes: https://gist.github.com/twolfson/f8848600a71884ee107d

In this PR:

Added list of active forks to README

@twolfson
I've added you as a collaborator of thie repository. Once you accept you should have commit access.

@twolfson
I also added a CONTRIBUTION.md document to this repository in case there is any confusion around how to contribute as a collaborator :)

We should talk about this over email.

So I am sending one =P

As per email thread, I've removed you from the collaborators of this project.
We'll figure out an alternative soon.


fix: bump node-fetch to avoid vulnerability

This PR bumps our node-fetch transitive dependency to avoid a snyk vulnerability.

A CRA adhoc build for this branch was clean.

:tada: This PR is included in version 0.53.1 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 0.2.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Update photo-picker.md

This is the method that worked for me. The original sample gave errors.

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

@DaraOladapo : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @DaraOladapo
Using Forms.Context is not recommended, as it was deprecated a while ago.
I just tried the sample, that the doc links to, and that uses code from the doc, and photo picking worked fine for me on Android. I suspect you are missing some code from your MainActivity class.

Thanks David. I'll take a look at it later.
I found a Nuget Package that worked.


Debug: inline breakpoint is not vertically centered

I noticed that the new inline debug breakpoints do not have the same height as the editor line and as such appear not centered.

There height should depend on the font. Maybe I did not get this correctly, thus assigning to this milestone to investigate and fix.

Fixed via 1f70a46308
Now the inline breakpoint widget has the same size as the editor line height and updates when editor configuraiton changes.


feat: Added Password Generator (Issue #139)

Fix to  Issue #139
===============================

Password generation: The script generates random passwords with customizable length and complexity.
Display the generated password to the user.
Allow the user to specify password length and complexity (e.g., uppercase, lowercase, numbers, special characters).
A user-friendly command-line interface.
===============================

Checklist

[X] I read the contributing guidelines
[X] I structured my project as stated in the contributing guidelines
[X] My project uses dependencies
[X] I starred the repo
[X] I had fun contributing!

Project reviewed and merged.
Thank you @Master-Keshav
Feel free to add more projects.


Port / Build the PoolTogether dApp on Harmony

Description
Port PoolTogether (https://github.com/pooltogether) from Ethereum to Harmony mainnet.
Context
We are looking for a team to port PoolTogether from Ethereum and launch it on Harmony mainnet. This will be a simple way for new users to enter into crypto using it as a stable "savings account" with the chance to earn upside.
As PoolTogether's co-founder Leighton Cusack said on Twitter:
"392 days ago someone deposited $73 into PoolTogether. Yesterday they won $43,760 just by saving their money. This is why @PoolTogether_ will be the on ramp for normal people into DeFi."
Acceptance Criteria
The full PoolTogether dApp is running on Harmony mainnet with all of its functionalities. At least 1,000 users/addresses interact with the dApp.
Reward
$10,000 USD equivalent in ONE tokens.

Winner selected and paid. Thank you, all.


Minor notebook updates

As discussed with @polong-lin last week, couple of minor fixes.
vertex_ai/04 - updated to use df_train for training
vertex_ai/06 - updated to downlevel kfp version to v1 so notebook works as-is

@saeedaghabozorgi @erwinh85 Could you kindly do a final check and merge? TY! This PR from @mandieq  fixes the issues with running the notebooks!


Show error fail when something wrong happend inside the test

When there is an error inside a test it's not been taken as an error

https://stackoverflow.com/questions/22009364/is-there-a-try-catch-command-in-bash

This did not happend before with our assertions but not it does


Implement ongoing license validation of all hosted repositories

Feature Request
Description of Problem:
Rather than relying solely on contribution-time license validation, the Foundation needs to ensure license compliance for all hosted repositories on an ongoing basis.
Potential Solutions:
A spike using https://github.com/fossas/fossa-cli have shared on https://gist.github.com/maoo/40a4f7a9df8315290a1b0c347dd018da
Below the description of a GitHub Action that could deliver a continuous scanning across any GitHub repo (whose build command is supported by fossa.io
Proposal

Build a standard GitHub action that reacts on commits and Pull Requests (PRs) on a given GitHub repository, called FOSSA GitHub Action.

Every time that a commit is pushed or a PR is merged, the FOSSA GitHub Action is triggered, the action

[ ] Invite FOSSA into ODP to validate and groom how this epic should be fulfilled
[ ] Reads a .fossa-licenses.yaml file, containing
-- A list of SPDX IDs called "compatibleLicenses"
-- A list of SPDX IDs called "incompatibleLicenses"
-- A list of strings called "whitelistedLibraries"
-- ... (more will come after the MVP)
[ ] Reads the FOSSA_API_KEY (encrypted) environment variable, containing the key of FINOS account
[ ] Invokes "fossa init" and "fossa report licenses --json", generating a JSON payload with all library and license definitions
[ ] Parses the generated JSON (on step 5) and builds a report with
-- List of libraries with compatible licenses (and the compatible license that applies)
-- List of libraries with incompatible licenses
-- List of libraries with unknown licenses
[ ] Formats the report in Markdown and post on a new github issue. If the action was triggered by a PR, the check will succeed or fail based on the amount of incompatible /unknown licenses found

Proposal have been discussed during ODP meeting in the past, see notes on https://finosfoundation.atlassian.net/wiki/spaces/FDX/pages/1191444497/2019-09-11+ODP+WG+Meeting+notes

Hi @maoo
I've tagged @alphax777 to help groom and prioritise this issue as part of ODP. @alphax777 feel free to tag other FOSSA team members who could potentially help us resolve.
Many thanks 🤜💥🚀
James.

Tracking this activity internally; we can close this issue.


Fix PiPiP storybook page by redefining properties of PiPiP

What

Since upgrading storybook to version 6.5.7 in #1972, the PiPiP component storybook page does not load and times out.
I explored redefining the primaryTile.children ReactNode sub property to primaryTile direct ReactNode property and similarly secondaryTile.children ReactNode sub property to secondaryTile direct ReactNode property.
This fixes PiPiP storybook page. It seems like ReactNode/JSX.Element sub properties don't work in storybook version 6.5.7
Why

https://skype.visualstudio.com/SPOOL/_workitems/edit/2918197
How Tested

See generated chromatic link.
Process & policy checklist

[ ] I have updated the project documentation to reflect my changes if necessary.
[ ] I have read the CONTRIBUTING documentation.

Is this a breaking change?

[ ] This change causes current functionality to break.

I'm afraid I don't quite understand why the changed props fix the original issue. I also think that this PR changes the props for the worse. So, I'd like to understand why it is needed better, and document the reason in the code for posterity.
(I am still hopeful that we don't need to change the props, and that we can instead fix some bug in the story itself)

I'm afraid I don't quite understand why the changed props fix the original issue. I also think that this PR changes the props for the worse. So, I'd like to understand why it is needed better, and document the reason in the code for posterity.
(I am still hopeful that we don't need to change the props, and that we can instead fix some bug in the story itself)

It seems Object properties with React.ReactNode/JSX.Element property do not work in storybook v6.5,7. Would  the prop change in commit  be better?

I'm afraid I don't quite understand why the changed props fix the original issue. I also think that this PR changes the props for the worse. So, I'd like to understand why it is needed better, and document the reason in the code for posterity.
(I am still hopeful that we don't need to change the props, and that we can instead fix some bug in the story itself)

It seems Object properties with React.ReactNode/JSX.Element properties like primaryTile and secondaryTile of PiPiP do not work in storybook v6.5,7. Would the prop change in commit  be better?

Instead of modifying the component to fit storybook, can we create a slim wrapper component within the story (perhaps with the getTile() hack) and display that?

I'm afraid I don't quite understand why the changed props fix the original issue. I also think that this PR changes the props for the worse. So, I'd like to understand why it is needed better, and document the reason in the code for posterity.
(I am still hopeful that we don't need to change the props, and that we can instead fix some bug in the story itself)

It seems Object properties with React.ReactNode/JSX.Element properties like primaryTile and secondaryTile of PiPiP do not work in storybook v6.5,7. Would the prop change in commit  be better?

Instead of modifying the component to fit storybook, can we create a slim wrapper component within the story (perhaps with the getTile() hack) and display that?

Yep, that worked. No internal api changes needed. Thanks!


Option to launch containers with --net=host for Spark compatibility

This might be a highly specialized use case, but I figured I'd file it and see where it goes. I will implement it and keep it in a fork if it doesn't make sense upstream here.
If I want to launch Jupyter Notebook containers that talk to a Spark cluster (not just Spark local mode), the workers on that cluster need to be able to talk back to the launched containers. tmpnb currently configures containers with networking bridged through the docker0 interface (the docker default). When Spark workers try to "phone home" to the Spark driver running in one of these containers:

It has the wrong IP address: the Spark driver communicates its internal Docker IP
Even if it had the right IP, the ports randomly selected by the driver to listen for worker connections are not exposed.

The simplest fix we've found is to launch containers with --net=host, do a bit of port management to ensure there's no conflicts, and ensure that appropriate host firewall rules are set to disallow connections to those containers except by a local proxy and other workers in the cluster. To allow tmpnb to support this mode of operation, I image:

A command line switch to configure orchestrate.py to launch containers with --net=host
Lots of doc on that switch stating the implications of running that way :)
Change in the code path from orchestrate down to the spawner to pass that option
New logic in the spawner to allocate non-overlapping host ports to containers

I'm assuming that linking doesn't solve this problem either?

Lots of doc on that switch stating the implications of running that way :)

Most certainly.

To the best of my knowledge, linking doesn't help because the Spark workers are on altogether separate hosts from the container->notebook->kernel->Spark-drivers.

This was merged.


sdl not avaiable

i got this error when i try to open qemu: qemu-system-x86_64: Display 'sdl' is not available.

Duplicate of #5


Skin changer Save Location

can you tell me where the save of the chinese version is

The save location when opening the app for the first time will capture the game location.


Fix mktemp on Mac OS X

See #7, I've chosen the second approach to make mktemp work on Mac OS X.

Closing in favor of #18
Thanks for your contribution @tobywf! Keep them coming ^^/


How to apply multilingual adaptive card when using rendering SDK?

[Enter feedback here]
I am utilizing rendering SDK. (Android, Java script, iOS)
I want to use multilingual adaptive card, but rendering SDK doesn't support multilingual adaptive card.
I think it is because a data json doesn't work in rendering SDK.
Is there any other way to provide multilingual?
Or do you have a plan to support data json in rendering SDK?

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

ID: 4264cfd8-c15e-8ee8-b83c-9890597e67f8
Version Independent ID: e1ffa3d4-b150-84a2-98f3-4d1bfd543952
Content: JavaScript SDK - Adaptive Cards
Content Source: AdaptiveCards/sdk/rendering-cards/javascript/getting-started.md
Product: adaptive-cards
GitHub Login: @matthidinger
Microsoft Alias: mahiding

This is the lacked feature that makes adaptive card short of "enterprise grade", so to speak. Any plan to catch up?


Test case 837 - Is accessing the register through PCIIO protocl needed? If so, a improvement might be needed.

Found a question and a improvement while debugging the failure below:
 837 : Check Config Txn for RP in HB                  START
    BDF 0xXXXXXXXXXX
       Reading Class code using PciIo protocol failed
       Failed on PE -    0
       PCI_IN_12
       Checkpoint --  1                           : Result:  FAIL

https://github.com/ARM-software/bsa-acs/blob/main/test_pool/pcie/operating_system/test_os_p037.c says the 837 test is for requirement PCI_IN_12, but it looks like we just need to write and read the registers through the ECAM. Is there anything related to PCIIO protocol that I overlooked in PCI_IN_12? If not, should we update the test 837 to match the BSA spec? In other words, I’m not sure if firmware hiding a device is a BSA compliance issue.

if we need to catch the mismatch between ECAM and PCIIO access, I’m thinking about a BSA improvement. When the test runs into a mismatch between ECAM and PCIIO, can BSA continue checking other devices instead of stopping the test? In this case, we will not need to modify and build BSA as you suggested to check other devices.

It seems to me that it is fair for ACS to be comparing PCIe reads/writes from different interfaces (ECAM, PCIO, etc..) that are supported by the UEFI/PCIe standards, and confirm that the data is consistent.
The suggested improvement of BSA reporting the failure and continuing to test other devices make sense.

Changes to reporting the failure and testing other BDFs https://github.com/ARM-software/bsa-acs/pull/79


[SPARK-29586][SQL]changge jdbc method param lowerBound and upperBound DataType

What changes were proposed in this pull request?

changge param dataType
Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

Can one of the admins verify this patch?

Thank you for making a PR, @MrDLontheway .
Could you update the PR description with the reason why we need this change?

The support itself looks nice to me.

We can't change the public API. I think the current API is OK as a shortcut to specify upper/lower bound for integral type column (we can improve the doc). User can specify whatever bound values they want via DataFrameReader.option, right?


Added GET routes for Category

Returning JSON in Insomnia @ http://localhost:3001/api/categories/ & http://localhost:3001/api/categories/:id

All get routes returning corresponding JSON data in insomnia


Faster cubic 01 01 mul

Description
Faster Mul01By01 for cubic extensions.
Saves:

2 muls
4 sub/add
1 mul by non residue

Type of change

[x] New feature (non-breaking change which adds functionality) - Optimisation

How has this been tested?

[x] faster Mul01By01
[x] bn254: test mul 01 by 01
[x] bls12377: test mul 01 by 01

How has this been benchmarked?
This was not benched but it,

For E6 Mul01By01 reduces,

2 E2 muls
4 E2 sub/add
1 mul by non residue

For E3 Mul01By01 reduces,

2 muls
4 sub/add
1 mul by non residue

Checklist:

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] I did not modify files generated from templates
[x] golangci-lint does not output errors locally
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

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

Details about the updates here,
https://github.com/shramee/cairo_bn/commit/fa51da864c63f9de4345903f108dbd184875ff55#diff-2c7236b88c6be3cac67ffcbd5e19ee3fb1a72ce9f8bd1089506a736dbd6d23c6L110

lol that must have been a silly copy-paste I did ^^ Thank you for the catch!

@shramee that looks good, thanks for your contribution to gnark!
You just need to update the circuits stats to pass the CI tests:

Change false to true here https://github.com/Consensys/gnark/blob/1ed22f78eac88c89d10d3be5a7741f6d5cb0ca29/internal/stats/generate/main.go#L15
Run go run main.go in internal/stats/generate
Commit the modified latest.stats file in internal/stats
Change back true to false

Also you would need to sign the Contributor License Agreement. Thanks again!

Done!
Where can I sign the Contributor License Agreement?


Add "Run Tests" to launch.json

Hi,
Some of the tests (via unittest) I want to run locally require specific env variables. These tests also run in CI with different variables, so I would like to set them only locally in vscode. The "Debug Tests" launch.json feature allows me to do that, but only when debugging. I think a "Run Tests" option in launch.json would be really helpful for this.

@ronif this is already available. Here is how you can add env variables to tests. This will work with running tests from the test explorer as well. Give this a try:
        {
            "name": "Test config",
            "type": "python",
            "request": "test", // <--- this is the magic
            "env": {
            // add env variables here
            }
        }

We do need to add this to configuration completion to make it easier to find.

@ronif Ah! Just realized this is for "Run Tests" specifically. The previous comment applies specifically to debugging. We should make sure that if there is a test configuration in launch.json we should just run it under the debugger with noDebug set to true.

Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

Does this apply to the envFile key?

This feature will also allow one to use preLaunchTask while running tests, not just while debugging.

Continuing the previous comment:
... and will also allow one to set PYTEST_ADDOPTS for the coverage counting with custom arguments.
Now the only option at least to enable coverage and do not break debugging exists. It is to add --no-cov to the debug configuration that does not work with some PyTest versions (for example, mine :) ): https://code.visualstudio.com/docs/python/testing#_pytest-configuration-settings

So this is currently just working for test debugging, but not for just running the test with the Testing-Ribbon, right?
        {
            "name": "Test config",
            "type": "python",
            "request": "test", // <--- this is the magic
            "env": {
            // add env variables here
            }
        }

Do I have any other chance to set environment variables before running all tests with the Testing-Ribbon? I'm using Python with Pytest and can now debug tests with the Testing-Ribbon from VSCode, but the config seems not to be used when just running the test, without debugging.

the best option would be set up all of the environment variables you need in a terminal and then launch VS code from there using code . or code <project-dir>

Another solution I found, was just to add an python.envFile to the settings.json:
    "python.testing.unittestEnabled": false,
    "python.testing.pytestEnabled": true,
    "python.envFile": "${workspaceFolder}/.env"

not ideal, because I guess that is now also setting/overwriting the envs for normal debugging, which I defined before in the launch.json file?

@boatcoder This is now changed a bit, try this:
        {
            "name": "Test Config",
            "type": "python",
            "request": "launch",
            "env": {
                "PYTEST_ADDOPTS": "--numprocesses 10 --make-pytest-bail"
            },
            "purpose": ["debug-test"]
        },

@boatcoder This is now changed a bit, try this:
        {
            "name": "Test Config",
            "type": "python",
            "request": "launch",
            "env": {
                "PYTEST_ADDOPTS": "--numprocesses 10 --make-pytest-bail"
            },
            "purpose": ["debug-test"]
        },

what do I need to do for unittest?

My goal is to have a debugging session where I can use "debug test" from a test and be able to set breakpoints in library code.
Adding the "purpose" option helps. However the behavior between regular debugging and with this is different.
When at a breakpoint it doesn't get to the right point in the call stack automatically.
What am I missing here?
        {
            "name": "Debug Tests",
            "type": "debugpy",
            "request": "launch",
            "console": "internalConsole",
            "justMyCode": false,
            "django": true,
            "purpose": ["debug-test"]
        }


lr: 1.2 -> 1.3

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

built on NixOS
ran ‘/nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3/bin/lr -h’ got 0 exit code
directory tree listing: https://gist.github.com/9c7fdd1add06970cc80d3e523d0f4e02

cc @globin for review

Success on x86_64-darwin (full log)
Attempted: lr
Partial log (click to expand)
mkdir -p /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/bin /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/share/man/man1 /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/share/zsh/site-functions
install -m0755 lr /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/bin
install -m0644 lr.1 /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/share/man/man1
install -m0644 _lr /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/share/zsh/site-functions
post-installation fixup
gzipping man pages under /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/share/man/
strip is /nix/store/0fzpxnsanc02i4jsb1yhchjp4p62b2n3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3/bin
patching script interpreter paths in /nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3
/nix/store/kackhk02ql7ykzxafzys3mgawkxgm9is-lr-1.3

Success on aarch64-linux (full log)
Attempted: lr
Partial log (click to expand)
install -m0644 _lr /nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3/share/zsh/site-functions
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3
shrinking /nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3/bin/lr
gzipping man pages under /nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3/share/man/
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3/bin
patching script interpreter paths in /nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3
checking for references to /build in /nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3...
/nix/store/mxr6hxlz9irxpg5s3lplik1b2ag7rlqn-lr-1.3

Success on x86_64-linux (full log)
Attempted: lr
Partial log (click to expand)
install -m0644 _lr /nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3/share/zsh/site-functions
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3
shrinking /nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3/bin/lr
gzipping man pages under /nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3/share/man/
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3/bin
patching script interpreter paths in /nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3
checking for references to /build in /nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3...
/nix/store/ls109sv311n7wqw85kbkqcdwrsqrlca9-lr-1.3


Model persists in Visualizer Window after closing if body is double-clicked

Steps to reproduce

open arm26.osim
double-click skull
File > Close All

Expected result
Navigator and Visualizer Window are both cleared.
Actual result
Navigator is cleared but model remains in Visualizer Window. Not fixed by closing and re-opening Visualizer Window.

Environment and GUI version
AppVeyor artifact OpenSim-bf3e61b9-2018-05-09-win64.exe

This was due to an execption handling messages from visualizer, fix submitted,

Model is now closing.
W10, OpenSim-32ef4769-2018-05-12-win64.exe

Fixed for me as well ... closing.


Clicking Notification results in other dialog window closing

Describe the bug
If a user clicks a dialog notification, another dialog window is closed with exit code 0
To Reproduce
Steps to reproduce the behavior:

Run this example script, and click the notification while the dialog window is open

#!/bin/bash
#set -x

# Dialog bug example

# First call a notification...
/usr/local/bin/dialog --title "Bugs" --message "Better than snakes, I guess..." --notification

# Now call a dialog window
/usr/local/bin/dialog --title "Bugs" --message "Better than snakes, I guess..." --icon "text=🐞"
exitCode=$?
echo "Exit code: $exitCode"

# Observe that if the notification is clicked, the dialog window exits with code 0

Expected behavior
Clicking the notification should not close open dialog windows.
Desktop (please complete the following information):

macOS version 14.5
swiftDialog version <IP_ADDRESS>55 as well as <IP_ADDRESS>58

@BigMacAdmin:
What if you used unique command files?

@BigMacAdmin:
What if you used unique command files?
Does not appear to get around the issue

Ooh good catch. This is an issue in that every instance of dialog watches for notifications. I need to adjust so only instances activated by the notification service responds to notification actions.


New API

Codecov Report

Merging #69 (2e22115) into master (179a586) will increase coverage by 20.32%.
The diff coverage is 82.44%.

@@             Coverage Diff             @@
##           master      #69       +/-   ##
===========================================
+ Coverage   63.41%   83.74%   +20.32%
===========================================
  Files          18       16        -2
  Lines         544      486       -58
===========================================
+ Hits          345      407       +62
+ Misses        199       79      -120

Impacted Files
Coverage Δ

src/access/ext.rs
0.00% <0.00%> (ø)

src/ratelimit/key.rs
46.15% <46.15%> (ø)

src/session/mod.rs
56.00% <56.00%> (ø)

src/core/convert.rs
64.36% <64.36%> (ø)

src/dialogue/mod.rs
71.42% <71.42%> (ø)

src/core/handler/command.rs
75.00% <75.00%> (ø)

src/core/handler/predicate.rs
92.00% <92.00%> (ø)

src/core/dispatcher.rs
94.11% <94.11%> (ø)

src/core/handler/base.rs
94.11% <94.11%> (ø)

src/access/policy.rs
100.00% <100.00%> (ø)

... and 7 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 179a586...2e22115. Read the comment docs.


[Improvement] Upgrade Casper Storage 1.2.0

Is your feature request related to a problem? Please describe.
Upgrade to casper-storage-1.2.0
Affected features:

[ ] Create new account
[ ] View recovery phase

Commit: https://github.com/CasperDash/casperdash-mobile-wallet/pull/156/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519R80


Fix #2100 - function address comparison

Detailed discussion is here: https://github.com/rust-lang/rust/issues/117047

embassy-executor v0.3.1 now released on crates.io, contains this fix.


Set logger levels through handler

Configures logging with a handler. If you only configure a level for your logger, but no handlers, the internal handler is used which is set to output just the message (with no other formatting) at the WARNING  level (see this reference). Currently, this prevents the printing of INFO level loggings to the console (including when using the generate-template flag).
Fixes #208.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 44.561%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
4867

Relevant Lines:
10922

💛  - Coveralls

@lukaspie @domna I could test running the converter locally and everything works fine for me.
I couldn't find any outputs in the Nomad GUI both before and after these changes. And I also couldn't find any call from Nomad to the dataconverter with a logger being passed.

@lukaspie @domna I could test running the converter locally and everything works fine for me.
I couldn't find any outputs in the Nomad GUI both before and after these changes. And I also couldn't find any call from Nomad to the dataconverter with a logger being passed.

Here is the comment on Rubel where he reports that this works in nomad: https://github.com/FAIRmat-NFDI/pynxtools/pull/191#issuecomment-1839535098
However, it looks like he just tested this locally and we still need to pass the logger to the convert function in nomad. @sherjeelshabih Did you also try to pass it to convert in nomad and see if it is then logged in the gui?

@lukaspie @domna I could test running the converter locally and everything works fine for me.
I couldn't find any outputs in the Nomad GUI both before and after these changes. And I also couldn't find any call from Nomad to the dataconverter with a logger being passed.

Here is the comment from Rubel where he reports that this works in nomad: #191 (comment) However, it looks like he just tested this locally and we still need to pass the logger to the convert function in nomad. @sherjeelshabih Did you also try to pass it to convert in nomad and see if it is then logged in the gui?

I changed the way Nomad deals with this. I do not want to have a hot potato being passed around in function arguments. :smile:
I just access the logging object of pynxtool during runtime from Nomad and switch it to what Nomad needs it to work. This way we don't have to change much in our code or add a special check if we are running under Nomad etc.
See this MR on Nomad: https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/merge_requests/1638
Let me know what you think.

@lukaspie @domna I could test running the converter locally and everything works fine for me.
I couldn't find any outputs in the Nomad GUI both before and after these changes. And I also couldn't find any call from Nomad to the dataconverter with a logger being passed.

Here is the comment from Rubel where he reports that this works in nomad: #191 (comment) However, it looks like he just tested this locally and we still need to pass the logger to the convert function in nomad. @sherjeelshabih Did you also try to pass it to convert in nomad and see if it is then logged in the gui?

I changed the way Nomad deals with this. I do not want to have a hot potato being passed around in function arguments. 😄
I just access the logging object of pynxtool during runtime from Nomad and switch it to what Nomad needs it to work. This way we don't have to change much in our code or add a special check if we are running under Nomad etc.
See this MR on Nomad: https://gitlab.mpcdf.mpg.de/nomad-lab/nomad-FAIR/-/merge_requests/1638 Let me know what you think.

That's perfect 👍

LGTM, feel free to merge anytime you guys are happy with it.


Limit concurrent operations for local / sftp backend

What does this PR change? What problem does it solve?
Currently, the local and sftp backend are the only ones which do not limit the number of concurrent operations.
This PR adds a Connections parameter for both backends along with the corresponding limits.
Even though Connections sounds unusual for the local backend, I've kept the name for consistency with the other backends.
Was the change previously discussed in an issue or on the forum?
Partially related to #322 and #2679
Checklist

[x] I have read the contribution guidelines.
[x] I have enabled maintainer edits.
[ ] I have added tests for all code changes. The backends already have a good test coverage.
[ ] I have added documentation for relevant changes (in the manual).
[ ] There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
[x] I have run gofmt on the code in all commits.
[x] All commit messages are formatted in the same style as the other commits in the repo.
[x] I'm done! This pull request is ready for review.

For the local backend the number is essentially the same as the default from the archiver while reading data. SFTP usually has higher IO latency than a local backend so I've chosen a larger number of connections there. The value 5 is just the number that is also used for all other backends.


pkg/cert/providers: add ValidateCertManagerOptions test

Unit test for ValidateCertManagerOptions
part of #3425
Signed-off-by: Eduard Serra<EMAIL_ADDRESS>| Tests                      | [ ] |

Does this change contain code from or inspired by another project?

Did you notify the maintainers and provide attribution?
No

Is this a breaking change?
No

Codecov Report

Merging #3694 (9015eb9) into main (16902d7) will increase coverage by 0.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #3694      +/-   ##
==========================================
+ Coverage   67.39%   67.51%   +0.11%
==========================================
  Files         181      181
  Lines        8772     8772
==========================================
+ Hits         5912     5922      +10
+ Misses       2827     2817      -10
  Partials       33       33

Flag
Coverage Δ

unittests
67.51% <ø> (+0.11%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...icate/providers/certmanager/certificate_manager.go
87.90% <0.00%> (+0.80%)
:arrow_up:

pkg/certificate/providers/config.go
42.20% <0.00%> (+4.54%)
:arrow_up:

pkg/k8s/announcement_handlers.go
77.14% <0.00%> (+5.71%)
:arrow_up:

Continue to review full report at Codecov.

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


GitHub packlage

Not urgent, but there is a fix in this.

This PR enables mvn deploy for operapi and model projects
This PR fixes a bug in the generation of the openapi client. I had thought that the common Default client etc was shared. It is not and there are differences between the two. This generates separate clients and fixes the current kas only code to use the kas clients.

Nice!


Update specs2-core, specs2-mock to 4.12.4-js-ec

Updates

org.specs2:specs2-core
org.specs2:specs2-mock

from 4.6.0 to 4.12.4-js-ec.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.specs2" } ]

labels: test-library-update, semver-minor

Superseded by #414.


Decision process in OpenCMSIS, especially for the spec

Dear all,
I hope I won't appear to be rude and won't offend anybody but at the moment I am not comfortable with the decision process in Open-CMSIS-Pack.
In the weekly forum, we address a list of topics, usually we call for comments but we do no set deadlines nor method to conclude.
And sometimes an issue can just "disappear from the radar" for some time.
Can we improve this way of working to reach conclusions in a more predictable way ?
What I imagine is that in the weekly forum we do a kind of Change Control Board (CCB):

Review the points
If a point deserves more discussion and thinking then I think we should set a deadline for this discussion to happen and maybe also a owner who may summarize what has been discussed when the deadline is met
When the deadline is met, the CCB decides how to conclude the point
If the point is accepted, then we need to decide: is it clear enough and we do nothing more ? Does it deserve an ADR ?
In case an ADR is needed, somebody is appointed to write it within 2 weeks
The ADR is then reviewed and formally approved within 2 more weeks

These ADRs should be publicly available and very short, I guess md format would be perfect.
To be discussed...we can already experiment the decision making process with this proposal :-)

I think A linaro representative involvement could be also interesting being a neutral party

Agreed.  Maybe Bill can help us how other projects organize that.
From: E.Finco @.>
Sent: Tuesday, May 3, 2022 3:48 PM
To: Open-CMSIS-Pack/Open-CMSIS-Pack-Spec @.>
Cc: Subscribed @.***>
Subject: Re: [Open-CMSIS-Pack/Open-CMSIS-Pack-Spec] Decision process in OpenCMSIS, especially for the spec (Issue #119)
I think A linaro representative involvement could be also interesting being a neutral party
—
Reply to this email directly, view it on GitHubhttps://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/issues/119#issuecomment-1116120433, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB7CSGRO3VWOTFIC3ZOECW3VIEVAFANCNFSM5URRWWIA.
You are receiving this because you are subscribed to this thread.Message ID<EMAIL_ADDRESS>IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

I think we can take some examples form here:
https://www.redhat.com/en/blog/understanding-open-source-governance-models
I am in favor of the election process.
My proposal is the following:

The CCB (or Technical Steering Committee) decides that an issue must be studied
A working team is selected and a spokesman presents the conclusions to the CCB/TSC after N weeks
Here 2 things can happen
==> direct adoption of the conclusions
==> no consensus: a Linaro "neutral" representative (Bill?) tries to find a gentlemen's agreement.
If no agreement is found then a vote must happen and I am thinking about a triumvirate:

1 ST representative : can be @iomint
1 NXP representative: David ?
1 ARM representative : Reinhard ?
Nobody can give a blank vote so there is always a decision (at least 2 versus 1)

If the change in the spec is accepted then a PR on the spec is issued by the submitter or somebody appointed to do so

I understand that this might be a problem for ARM who is contributing more for the vanilla tools.
But, here I am talking only about the spec.
When it comes to the code, I think a maintainer should be appointed for each tool and he makes the decision to implement or not if the change is optional. If the change is mandatory, the maintainer can decide when the change is to be implemented.
The change can be implemented by another contributor but the maintainer defines the period when he wants to deal with it.
If the maintainer does not want to accept a mandatory change, then I guess a CCB vote should be required?
For accepting the PRs on the code, the maintainer is the gate keeper.
I guess we may have 3 maintainers:

cpackget : Charles ?
devtools: Daniel ?
cbuild : Daniel ?

This way, I think we can have:

an Electoral approach for governing the spec
a Doer/Founder approach for governing the vanilla tools

@jkrech : can we try to discuss this to elaborate what you want to present next week ?

@fred-r  thanks for the input. I am happy for you to present your proposal next week. What I had prepared for this week was rather focused on the tracking aspect of change requests to make this transparent for everyone. At the same time I will need a bit of time to review your proposal and provide feedback here.

@fred-r, while I think your proposal of gatekeepers per repository make sense, we must ensure that the specification and reference implementation do stay in sync somehow. Therefore it maybe necessary for the Steering Group to resolve resourcing/contributions to the reference implementation as part of change requests.

That's the point where I disagree :-)
To me resources are always a bottleneck and this should not hinder the capacity to specify :-)
If you look at 3GPP (past experience), the spec is usually far ahead of implementation.
If we take a look at something more software oriented : the JavaScript specification evolves regardless of its adoption by the web browsers.
So, I am in favor of decorrelating both aspects.

I'm voting same as @fred-r
I've already shared my mind about Thanks couple of comments (as example [devtools] Promote standalone tools being orchestrated by consumer itself )
To me primary goal on OpenCMSIS initiative is to define / agree on some standard allowing industry to converge on. It will ensure all adopters to enjoy some do facto interoperability. Such is already awesome !
We come then to devtools. I and guess we are all happy to have them. But such are extra helping us to support proof of concept, discussion running real cases, .... devtools are not first guess outcome expectation to me out of OpenCMSIS.
Adding devtools as part of specification approval cycle is leading to slow down the whole process what's a bit a pain.
As extra I would say I'm a bit worried about devtools because at a point they may fulfill some specification lacks promoting some behavior Thanks their implementation becoming under the hood do facto part of the specification. My fear is such is going to lead to issues because my guess is not all OpenCMSIS adopters are going to rely on devtools ...

Couple of comments:
-@fred-r:  Considering how Linaro segment groups (incl Lite that is hosting Open-CMSIS) works, I think you have to consider Linaro as a voting member. I let Bill F comments
-I do think it comes as a surprise: I am also of the opinion of my colleagues to decorrelate the spec from the ref tools implementation. After we can discuss some boundary conditions rules like if something is no supported by any vendors after a given amount of time than it is deprecated (assuming no side effect etc ...)
-The option to have maintainers identified for each tools makes sense.  I think it is a (almost) universal practice for open source projects

I can see that in the project tab the point is tagged as "Accepted" but I did not see anything about how to handle the decision making when no consensus is reached.
So I am not sure we are ready to go to implementation/deployment.
Is there a document explaining all this ? (I can't find it from the project pane)

Proposed Change Board:
https://github.com/orgs/Open-CMSIS-Pack/projects/2/views/1
Agreed Decision Committee Charter:
https://linaro.atlassian.net/wiki/spaces/CMSIS/pages/28717383715/Open-CMSIS-Pack+Decision+Committee+Charter


Added new route for getting user donation by id

Related to https://github.com/podkrepi-bg/frontend/pull/775


[Feature Request] Blacklist a user

Is your feature request related to a problem? Please describe.
I have a user in my discord who keeps using !stop and I can't blacklist them. I have to have the dj role as the normal member role as I would like users to be able to control the volume.
What is your ideal solution to the problem?
To add a !blacklist command that you can use with the users user id to block them from using commands.
How would this feature be used?

get the id of the user
type (prefix)blacklist (id)

Additional Info
No response
Checklist

[X] I have checked the documentation to make sure this feature doesn't already exist
[X] I have searched for similar feature requests
[X] I have confirmed that my requests is not on the list of things that will not be added
[X] I am running the latest version of the bot:

I would really like this feature as well, this would be a very useful feature.


Why is there a certain difference in recurring results？

Except for the inconsistent number of GPUs used, the other configurations are the same. Regarding the known classes, I got similar results to the author. However, on the A-OSE measurement, my results are quite different from those in the paper. Below are my recurring results for the four tasks. I hope the author can answer my question. Thanks!

Please note that other have independently been able to reproduce the results (link). WI is bit noisy, but other metrics should match up. Have you tried scaling the hyper params according to the discussion here?

Hello @JosephKJ @yuandhu I was sucessfully able to reproduce the results and also attached the table for the same

| ResNet-50 | ORE (paper) |   | 56.34 |   | 8234 | 0.02193 | 52.37 | 25.58 | 38.98 |   | 7772 | 0.0154 | 37.77 | 12.41 | 29.32 |   | 6634 | 0.0081 | 30.01 | 13.44 | 26.66
-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
  | ORE (retrained) |   |  |55.86 |  | 6390 | 0.04867 | 52.36 | 25.04 | 38.71 |   | 7635 | 0.0387 | 37.52 | 12.28 | 29.11 | 0.11 | 6151 | 0.0275 | 29.63 | 12.82 | 25.43
  |  | Recall |  | 71.92 |   |   |   | 71.74 | 46.53 | ` |  |   |   | 57.12 | 33.69 | 49.31 | 9.11 |   |   | 51.99 | 36.17 | 48.03

Hello @JosephKJ @yuandhu I was sucessfully able to reproduce the results and also attached the table for the same
ResNet-50	ORE (paper)	 	56.34	 	8234	0.02193	52.37	25.58	38.98	 	7772	0.0154	37.77	12.41	29.32	 	6634	0.0081	30.01	13.44	26.66
 	ORE (retrained)	 		55.86		6390	0.04867	52.36	25.04	38.71		7635	0.0387	37.52	12.28	29.11	0.11	6151	0.0275	29.63	12.82	25.43
 		Recall		71.92		 	 	71.74	46.53	`		 	 	57.12	33.69	49.31	9.11	 	 	51.99	36.17	48.03

thank you

Please note that other have independently been able to reproduce the results (link). WI is bit noisy, but other metrics should match up. Have you tried scaling the hyper params according to the discussion here?

thank for you reply！！I aslo have an another question。
In builtin.py . there are 81 (include unknown)categories in total，why only 80 categories in detectron2/config/defaults.py?
i.e. _C.MODEL.ROI_HEADS.NUM_CLASSES = 80
and when label unknown in detectron2/data/build.py/label_known_class_and_unknown ,the unknown class be labeled with
annotation["category_id"] = total_num_class - 1,whcih is the last categories in known class.I can't understand.
that might be a easy problem ,look forward to your reply again~


Editing templates: when creating property template type lookup, offer a dropdown/typeahead of all the lookups we support

in new version of Sinopia where you can edit templates like resources...
when you create a Property Template with type Lookup, you need to tell Sinopia where to lookup, by adding a URN from here: https://github.com/LD4P/sinopia_editor/blob/master/static/authorityConfig.json
can we instead just provide this list as a dropdown/typeahead for user to select from? rather than them having to go elsewhere to lookup the right URN and possibly mistyping?

This probably requires creating a new authority and changing the input to a Sinopia lookup component.


Extra data filter

Added code in Annotation Search view to filter annotation also by exact key-value in extra data.
Completed with test.

@federicoB I apologize!  I missed this somehow.

@federicoB could you elaborate a bit for me, what is the value of this feature?  What is your use case?

If we want to keep the extra_data as a json blob useful only to the frontend this feature doesn't have much value.
I created this feature for filtering down annotation based on web pages in which they were created.
I just realized that i could use a the uri field for that.
Also if anyone ever wanted to add fields to his annotations and wanted to filter for these, he could extend the model and put the new fields in the common_fields.
So, if you like the solution of __contains and allow to filter the annotations by extra data value, I can change this pull request otherwise you can close it and end it here.

@federicoB yes, use the uri field for filtering annotations by associated page (that's how annotator.js loads them).
The idea is for people to extend the annotation model if they need custom fields for more than just storage and retrieval.   This probably means we should also make the AnnotationSearch view easier to extend so you can customize just the search logic (eventually!).
However, I like the idea of the __contains filter with json formatting, if you can get it to work. (The conversation on StackOverflow made it sound like it could be problematic, but seems like it should work well enough to be useful.)

@federicoB just documenting what we discussed so the PR is marked as changes requested.

Lots of nice lookups methods for JSONFields are available only with PostgreSQL.
I tried the suggested solution from StackOverflow but the lookup fail and the query returns nothing.
I also tried to manually build a string without using json.dump() but no success.

Provided a simple but more performing solution.
Chained __contains lookup for key and value.
This can cause false positives when both key and value are inside a string used only as key or value, or when key and value are present, but in different elements of the dict.
Better than nothing, choose if merge this or wait if someone else find a better solution.

I'm not happy with this solution (the contains matches as written are too general), and have kept the PR open thinking I would get around to revising it myself at some point, but it's been almost 2 years so clearly that's not happening. I'm going to go ahead and close it, sorry.


allow to send database

Cómo lo hago?

In the section "Settings" the possibility to send the Sqlite DB ("Send database file") has been added with the last build.