[shared_preferences] unable to handle corrupt settings

Use case
Sometimes a file corrupts, it just hapens. However shared_preferences completely crashes in this case. This is on its own is not bad, however it provides the application no reasonable action to resolve the situation. The only solution is to crash, and leave the user unable to start the application.
Proposal
shared_preferences should allow for resetting the preferences, which can be used in case of corrupt settings. Optionally, backup/restore functionality would be nice, but this may be out of scope.

See also https://github.com/flutter/flutter/issues/89211

Thanks for the report @JAicewizard

shared_preferences should allow for resetting the preferences,

The linked issue does talk about providing this option, so maybe you can follow-up in that issue for further updates or let us know how your use case / proposal is different to the linked one.

The linked proposal would prevent corruption from happening in certain cases. However corruption can happen in many ways.
This proposal would add ways to resolve corrupt settings, no matter how they happened.
Does this provide enough info?

Thanks for the feedback. Keeping the issue open for team's input on the proposal.

We're using the new SharedPreferencesWithCache and encountered our embedded web app crashing in the deployed web environment. The web implementation uses localStorage to save the preferences which is in use by other web processing. When any preference value is inadvertently changed to not be valid JSON, SharedPreferencesWithCache.create(...) throws an exception which aborted our app's initialization. To recover:
static Future<SharedPreferencesWithCache> initPrefs(Set<String> allowList) {
  final cacheOptions = SharedPreferencesWithCacheOptions(allowList: allowList);
  return SharedPreferencesWithCache.create(cacheOptions: cacheOptions)
    // The main recoverable reason for a failure is bad data - force clear the prefs and try again
    .catchError((_) async {
      await SharedPreferencesAsync().clear(allowList: allowList);
      return SharedPreferencesWithCache.create(cacheOptions: cacheOptions);
    });
}

We use the SharedPreferencesAsync().clear(allowList: allowList) to remove all preferences and try to initialize again. BTW, the allowList is important otherwise functions work against all data in localStorage which is not what is intended.

Here's our exploring how to remove only preferences in error...
...but we decided the resulting code isn't worth it.
@TestOn("chrome")
library;
/// Make sure to run these tests with "flutter test --platform chrome".
/// The above "@TestOn" will only make these tests visible to a web platform,
/// otherwise you get lots of errors.

import 'package:test/test.dart';

import 'package:web/web.dart' as html;
import 'package:shared_preferences/shared_preferences.dart';
import 'package:shared_preferences_web/shared_preferences_web.dart';

/// These tests show Flutter pub package "shared_preferences" version 2.3.2 behavior.
/// It is hoped that the issues shown will have some resolution in later versions :-)

void main() {

  setUp(() {
    /// Testing shared preferences requires injecting a platform implementation.
    /// Here we're explicitly testing the web.
    SharedPreferencesAsyncWeb.registerWith(null);

    /// Set up some "existing" values for testing.
    /// Use of local store functions requires implementation knowledge so any use here of
    /// direct local store access is representing the environment.
    html.window.localStorage.setItem("name", "\"Jason\"");    // Valid JSON strings must be quoted in storage
    html.window.localStorage.setItem("age", "18");

    /// IRL when running in a web environment, there likely will be other values in the local store
    /// that are NOT associated with the Flutter app.
    html.window.localStorage.setItem("NotAPref", "Just a string");
  });

  /// The "allowed" preferences we're using that have "previous" values as initialized above.
  /// Initializing [SharedPreferencesWithCache] needs the options that specify the allow list.
  final allowList = {"name", "age"};
  final cacheOptions = SharedPreferencesWithCacheOptions(allowList: allowList);

  group("Initializing SharedPreferencesWithCache", () {

    /// This is what we expect...
    test('Initialize preferences', () async {
      final prefs = await SharedPreferencesWithCache.create(cacheOptions: cacheOptions);
      expect(prefs.getString("name"), "Jason");
      expect(prefs.getInt("age"), 18);
    });

    /// This test shows what can happen "In Real Life".
    /// Yes, unfortunately the developer chose the key "name" that is also used by something else on the website.
    /// Note that the previous implementation used a "prefix" to make keys unique - now it's up to the developer.
    /// The GitHub issue: https://github.com/flutter/flutter/issues/141575
    /// requests some way to "detect/handle corrupt settings".
    /// Yes, our app is dead now since we initialize the preferences cache during startup.
    /// There is currently no way to recover using [SharedPreferencesWithCache],
    /// we can't initialize it to even call "remove" or "clear".
    test('Initialize preferences IRL', () async {
      /// Something else in the web environment is using local store and unfortunately used the same key name.
      html.window.localStorage.setItem("name", "NotJson");

      /// No we don't "expect" a crash here but for testing purposes this is what we get.
      ///     FormatException: SyntaxError: Unexpected token 'N', "NotJson" is not valid JSON
      expect(SharedPreferencesWithCache.create(cacheOptions: cacheOptions), throwsFormatException);
    });
  });

  /// [SharedPreferencesAsync] can be used to detect and fix the issues...
  group("SharedPreferencesAsync to the rescue", () {

    /// This test group has the stored preference for "name" broken.
    setUp(() {
      html.window.localStorage.setItem("name", "NotJson");    // Override the above setUp and "break" the name value
    });

    test('Name is not valid but age still is', () async {
      final asyncPrefs = SharedPreferencesAsync();
      expect(asyncPrefs.getString("name"), throwsFormatException);
      expect(await asyncPrefs.getInt("age"), 18);
    });

    /// The most straightforward fix is to just clear all known preferences.
    test('Brute force clear all preferences', () async {
      final asyncPrefs = SharedPreferencesAsync();
      await asyncPrefs.clear(allowList: allowList);

      expect(await asyncPrefs.getString("name"), null);
      expect(html.window.localStorage.getItem("NotAPref"), "Just a string");  // AllowList didn't touch other values

      final prefs = await SharedPreferencesWithCache.create(cacheOptions: cacheOptions);
      expect(prefs.getString("name"), null);
      expect(prefs.getInt("age"), null);
    });

    /// It would be nice to get the valid values and remove all others but we can't use these methods.
    test('Can\'t get all the values or even the keys', () async {
      final asyncPrefs = SharedPreferencesAsync();
      expect(asyncPrefs.getAll(allowList: allowList), throwsFormatException);
      expect(asyncPrefs.getKeys(allowList: allowList), throwsFormatException);
    });

    /// Clear only the preferences in error using only the [SharedPreferencesAsync] API.
    /// Walk through the allowList and remove failures. Unfortunately, unless we know the type
    /// of each preference we need to check all type possibilities since there's no "getValue".
    test('Walk through allowList and remove failures', () async {
      final asyncPrefs = SharedPreferencesAsync();

      /// The API has no way to get the value without type so we try them all.
      /// Well the ".getAll" method does give the value but fails as seen above.
      await Future.wait(
          allowList.map((key) => Future.wait([
            asyncPrefs.getString(key).then((_) => 1).catchError((_) => 0),
            asyncPrefs.getInt(key).then((_) => 1).catchError((_) => 0),
            asyncPrefs.getBool(key).then((_) => 1).catchError((_) => 0),
            asyncPrefs.getDouble(key).then((_) => 1).catchError((_) => 0),
            asyncPrefs.getStringList(key).then((_) => 1).catchError((_) => 0),
          ]).then((results) {
            final isValid = results.any((n) => n > 0);
            if (!isValid) {
              return asyncPrefs.remove(key);
            }
          }))
      );

      /// Here we can start [SharedPreferencesWithCache] with the preferences in error removed.
      final prefs = await SharedPreferencesWithCache.create(cacheOptions: cacheOptions);
      expect(prefs.getString("name"), null);
      expect(prefs.getInt("age"), 18);
    });
  });
}


move retrieving of secret key to testable function and test it

The function that retrieves the SECRET_KEY from the environment is moved into a testable function. The function tries to get the key and raises and exception if the corresponding value (the SECRET_KEY) is not found (i.e. None), or the environement is not set up correctly. The conjugated test passes a wrong key to the function and checks if the right exception is raised.

Current coverage is 74.35%

Merging #19 into master will decrease coverage by -2.31% as of 5fa9568

@@            master     #19   diff @@
======================================
  Files            5       5
  Stmts           30      39     +9
  Branches         0       0
  Methods          0       0
======================================
+ Hit             23      29     +6
  Partial          0       0
- Missed           7      10     +3

Review entire Coverage Diff as of 5fa9568

Uncovered Suggestions

+10.27% via contributr/wsgi.py#10...13
+7.71% via ...ntributr/settings.py#40...42
+7.71% via contributr/urls.py#16...18

Powered by Codecov. Updated on successful CI builds.

Coverage does not seem to pick up that I am testing the exception. Odd. Will have to look into that tomorrow.

@tobias47n9e the function you wrote has the same use case as the getenv function in Settings.py
Django will complaint about missing secret key if it is not found, or is None

The function is just there, so we can test that part of the code. The test makes sure that Django does not launch without a secret key (It anyway does, but now we also test for it). But I might have misunderstood your comment.

@tobias47n9e You should just use os.environ.get('SECRET_KEY') as @coolharsh55 pointed out in #17. Its much more idiomatic.
So you would do like:
import os

def get_env_variable(key):
    return os.environ.get(key)

SECRET_KEY = os.environ.get('SECRET_KEY')

Then in the test:
def test_secret_key_missing():
    with pytest.raises(ImproperlyConfigured) as exc_info:
        settings.get_env_variable("non_existing_variable")
    assert str(exc_info.value) == "The SECRET_KEY setting must not be empty."

I am going to close this PR, because testing for the missing key is not that essential.


Please provide the filenames of the models you need.

Invalid model weight name for the text encoder folder, resulting in an error. Please provide the correct filename.

I do not really understand this. Could you provide more information, like your transformers version? pip show transformers
Did you download the model weights on https://huggingface.co/rhymes-ai/Allegro ？

Could you please provide your transformers version? The folder name remains the same as huggingface hub.
Or another way is to directly load the text encoder from https://huggingface.co/DeepFloyd/t5-v1_1-xxl. We didn't change the text encoder.

transformers version is 4.40.1, If you have the same folder name as the one in the huggingface, and the same filename for each model in the folder, you will get an error.

@CHK-0000
Use this and download files in text_encoder folder. Delete any existing files
https://huggingface.co/DeepFloyd/t5-v1_1-xxl


Restructure Provider component tests

Well, in that case, would you mind adding some tests for the Provider? If I see correctly, we have none. In theory, this change shouldn't break anything, but better to be sure than sorry. Perhaps even add those tests in a separate PR to see them passing and then merge here.

https://github.com/mobxjs/mobx-react/pull/739#discussion_r309555674

We have some tests in inject.test.js. I will move them in a separate file, review them, refactor them if necessary and probably write new ones.

https://github.com/mobxjs/mobx-react/pull/739#discussion_r309846431

Looks great, thanks!

@FredyC thank you!


Task labels should be wrapped automatically.

Can be achieved setting Size attribute of the label to "Fit node width" and Configuration attribute to "cropping"


Avoid copying invalid large constant data.

Tensorflow cannot create an operation with a NodeDef larger than 2GB.
(Python Unit Test Case: ConstantTest.testTooLargeConstant)
However, before throwing a meaningful exception, it consumes lots of memory
to copy the invalid input data. This causes std::bad_alloc errors sometimes.
This PR prevents those invalid copying. The allocated memory for the following
testcase decreases from over 4GB into less than 1GB.
bazel-bin/tensorflow/python/constant_op_test ConstantTest.testTooLargeConstant

Can one of the admins verify this patch?

I am not sure expanding the API of make_tensor_proto for this purpose is a good idea, but that's my opinion. Adding josh11b@ and mrry@ for opinions.

I'm fine with this, but the code needs to be wrapped at 80 columns.

I agree with @keveman, it feels weird to inject the error message and the limit. I would add it as a special check in a try catch on the same operation ...
try:
    tensor_proto.tensor_content = nparray.tostring()
catch:
    // check error and check size and if is greater than 2GB raise error.

Agreed, I prefer try/catching rather than adding args to the API.  Otherwise looks great.  Probably worth adding a test of the core functionality (without necessarily creating a 2GiB array)

@vrv . Oh, it's not. We should avoid run the try part.
When you call the following statements, it really consume all memory.
tensor_proto.tensor_content = nparray.tostring()

HI, @Mistobaan and @keveman .
For the injection, the exception message depends on the situation.
For this PR, it's for constant op generation.
For the other code, the error message will be different.

I updated the PR and rebased to the master again.

Remove the added parameter: limit and limit_msg.
Use try statement in constant_op.py instead.
Keep the original behavior (including other ValueError exceptions).
Thank you, @vrv , @keveman , @josh11b , and @Mistobaan .

Hi, @keveman . I updated the code according to your advice. Also, it rebased to the master and passed the test. Thanks.
(By the way, during rebasing, the messages on the code are gone. Sorry for that.)


No map is showing and no  export to Json

Hi,
What is wrong with my code? I'm not seeing a map appearing: https://codepen.io/anon/pen/ZdBdJZ#anon-login
And where is the option to save the output to GeoJSON? I only found a way to load one.

Hi, you're missing the basic leaflet map setup and the tile layer. Please see the leaflet documentation on how to do that.
This library does not provide a way to export to geojson.


Adds Proxy delete and list methods

Adds RPC methods for listing and deleting Proxy objects. Proxy supersedes ProxyIps.
This is part of the proxy ip -> proxy migration.

@prbot approve

,/


fix(ci): remove coveralls in codeclimate upload

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 (+96.8%) to 96.825%

Totals

Change from base Build<PHONE_NUMBER>:
96.8%

Covered Lines:
366

Relevant Lines:
378

💛  - Coveralls


Restarting an extension when that extension's output is selected in the "Output" pane should not change which extension is selected in the "Output" pane.

Current Behavior
Suppose the "Output" pane is visible, and a given extension's output is being viewed.
If the user runs the "Restart" command for that extension (for example, the TypeScript LSP, or the ESLint extension), the selected extension of the "Output" pane changes.
Statement of Issue
If a user restarts an extension and is viewing the output of that extension, they almost certainly will want to see the output of the extension upon restarting the extension.
Proposed Behavior
When restarting an extension, I propose that the selected extension in the "Output" pane remain unchanged.

Open a Workspace that has the ESLint extension enabled (I have also tested this with the TypeScript LSP)
Focus the "Output" pane, then choose ESLint from the dropdown menu
Ctrl+P, then select the "Restart the ESLint server" command

Once this is done, the value of the dropdown menu changes (for me) to the output of "Tasks", which seems to be arbritrary.


Don't use EPOLLONESHOT for the wakeup event.

Types of Changes

Bug fix.

Contribution

[x] I added tests for my changes.
[x] I tested my changes locally.
[x] I agree to the Developer's Certificate of Origin 1.1.

Sorry, it's not immediately obvious what problem is being fixed, do you mind giving a little more context?

EPoll#wakeup only works the first time. The wakeup event is only ever being registered once (in IO_Event_Interrupt_add), so it shouldn't be one-shot.


According to the example this.props.uri is undefined

this.props.source.uri should be the correct path to get the Uri. I also corrected the npm package from react-native-image-cache (thats another package) to react-native-img-cache

@jarandmi Thks for correcting the readme! Could you make it in a separate PR and I will merge it immediately. Regarding the change in index.ts, could you elaborate? It seems to cause a regression on existing code.

@jarandmi This is the readme example that is broken, I will fix it thks!

@jarandmi Closing for now, feel free to re-open.

I would still prefer to use the same syntax as the official <Image / > component. <Image source={ urI: http://.../image.jpg} / >. Then all you have to do to change to this cache component is change the name of the component. Now you also have to change the props.

@jarandmi my issue with using source is that people might do:
<CachedImage source={require("./Image.jpg")} />

Which wouldn't work. Maybe CachedImage should have a pass through for images it doesn't need to cache. What are your thoughts on this?

I see. Yeah, a pass trough would probably be a good idea.
<Image { ...props } /> would probably solve that?


[CARBONDATA-1452] Issue with loading timestamp data beyond cutoff

While generating surrogate for timestamp dictionary column, we are casting the value to int. We are considering only the +ve values for generating dictionary, when the value is out of range,overflow occurs and cyclic rotation happens while casting, in the cyclic rotation there is possibility of getting +ve values in overflow cases too.
Lets say cutoff timestamp is 1970-01-01 05:30:00, so we will be able to load data 68 years from this date, not beyond 68 years
While loading 3007-01-01 00:00:00, dictionary generation will throw bad record exception as converting this data to int is -ve (overflows and cyclic rotation)
But while loading 4016-01-01 00:00:00, dictionary will be generated for this as converting this data to int is +ve (overflows and cyclic rotation)  --> This data is loaded but not as actual value. Different timestamp will be loaded.
This PR has,
(1) Refactoring
(2) Checking overflow

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/564/

@dhatchayani hi, can you provide detail error message? I cannot understand why we should modify this.

@dhatchayani Can you provide more details of this PR.

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/709/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/8/

retest this please

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/723/

LGTM


fixes task's document

Changes
One of the example in the task.md shows serviceAccountName
field at Task specification which is not valid for now.
This patch updates the task's document with correct spec fields.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[ ] Includes tests (if functionality changed/added)
[X] Includes docs (if user facing)
[X] Commit messages follow commit message best practices

See the contribution guide
for more details.

/ok-to-test


Add test for graph state circuit

Summary
Fixes #4349
Details and comments
Added a test by computing the expected unitary from adjacency matrix and comparing that against the circuit produced by GraphState. The expected unitary is computed using Eq. (9) from this paper. The test is general and supports an adjacency matrix for any number of qubits. Due to that, the computation for CZ gates is slightly more involved, as it is generalized to any number qubits and control-target connections. That is done by checking whether the corresponding state has both the control and target in state |1> and assigning -1 to corresponding diagonal elements of an identity matrix.

 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.

Hi @mantcep,
looking into this with @ajavadia we came up with a nice test, that does not require computing the exponentially large unitary and checks the graph state from another point-of-view than the circuit gates. In Section II.B of the paper, the graph state is defined via it's stabilizers (Eq. (7)). (These stabilizers exist because the graph's we're looking at are created with Clifford circuits.)
In Eq. (6) it is defined how to compute these stabilizers. We can also get them from the circuit using
from qiskit.quantum_info import Clifford
Clifford(circuit).stabilizers.pauli.to_label()

If that output matches the stabilizers from Eq. (6) the graph state is correct.
Here's a little snippet on how you could compute the stabilizers via Eq. (6):
from typing import List

def get_stabilizers(A: List[List[int]]) -> List[str]:
    """Returns the stabilizers of the graph state constructed by A.

    Args:
        A: The adjacency matrix of the graph.

    Returns:
        The stabilizers.
    """
    stabilizers = []  # keep track of all stabilizers
    num_vertices = len(A)
    for vertex_a in range(num_vertices):
        stabilizer = [None] * num_vertices  # Paulis must be put into right place
        for vertex_b in range(num_vertices):
            if vertex_a == vertex_b:   # self-connection --> 'X'
                stabilizer[vertex_a] = 'X'
            elif A[vertex_a][vertex_b] != 0:  # vertices connected --> 'Z'
                stabilizer[vertex_b] = 'Z'
            else:  # else --> 'I'
                stabilizer[vertex_b] = 'I'

        # need to reverse for Qiskit's tensoring order
        stabilizers.append(''.join(stabilizer)[::-1])

    return stabilizers

Then the stabilizers should be the same, e.g.
# A = [[1, 1], [1, 1]]
# A = [[1, 1, 1], [1, 1, 0], [1, 0, 1]]
A = [[0, 1, 0, 0, 1], [1, 0, 1, 0, 0], [0, 1, 0, 1, 0], [0, 0, 1, 0, 1], [1, 0, 0, 1, 0]]
graph_state = GraphState(A)
stabilizers = Clifford(graph_state).stabilizer.pauli.to_labels()
ref_stabilizers = get_stabilizers(A)
print(stabilizers)
print(ref_stabilizers)

yields
['ZIIZX', 'IIZXZ', 'IZXZI', 'ZXZII', 'XZIIZ']
['ZIIZX', 'IIZXZ', 'IZXZI', 'ZXZII', 'XZIIZ']

I think it would be good if we could test the graph states with this, what do you think? If you have questions don't hesitate to ask!

Hi @Cryoris,
I must say, this is an elegant solution to say the least! I am sorry that I have not figured this out myself and you had to spend time looking into this. Thank you for the additional background on this topic, I will make sure to study at least the basics of quantum error correction, as I do not know much about stabilizers and Clifford groups.
As for implementing the test itself, would you like me to prepare the code for the test and submit a change to the pull request? If so, would it make sense to include the nice function that you have written into one of the classes?
Finally, I have one more question I am interested in and sorry if it sounds silly. Do you know what is the performance of computing the stabilizers from a circuit as compared to the exponentially large unitary based on the gates?
Thanks again for the guidance!

I must say, this is an elegant solution to say the least! I am sorry that I have not figured this out myself and you had to spend time looking into this. Thank you for the additional background on this topic, I will make sure to study at least the basics of quantum error correction, as I do not know much about stabilizers and Clifford groups.

Don't worry, we're all learning something new every day! I also didn't notice this when I opened this issue. 🙂

As for implementing the test itself, would you like me to prepare the code for the test and submit a change to the pull request? If so, would it make sense to include the nice function that you have written into one of the classes?

Yes you can just update your branch and then the PR will also be updated. I think you could include the code into the class, either as separate function or inside the assertGraphStateIsCorrect.

Finally, I have one more question I am interested in and sorry if it sounds silly. Do you know what is the performance of computing the stabilizers from a circuit as compared to the exponentially large unitary based on the gates?

I'm not quite sure @chriseclectic is the expert on this, but I think we can iterate over all gates and update the stabilizer table so the complexity should be of the order of gates in the Clifford circuit. Here's some more context on Clifford circuits and how they can be simulated efficiently: https://arxiv.org/pdf/quant-ph/0406196.pdf. This is also what's done in Qiskit.

Hi again!
I have updated the branch based on the code you have provided 🙂 Let me know if I should be changing something to make it nicer.
I was thinking that maybe it would make sense to include the function you have provided in the GraphState class to have a specific method for getting the stabilizers. In the end, however, I figured that is probably not necessary, since we can always get the stabilizers using the other method you have shown – Clifford(circuit).stabilizers.pauli.to_label(). So I included your code inside assertGraphStateIsCorrect, since that seemed to make most sense to me.
Thank you again for the valuable input!

Just one more comment I would like to add. In hidden_linear_function.py, there is the following piece of code that checks whether the adjacency matrix is symmetric:
https://github.com/Qiskit/qiskit-terra/blob/968000fd14d43935538fdebb3ef10194940633e1/qiskit/circuit/library/hidden_linear_function.py#L87-L89
I think it would make sense to add that to GraphState as well. Then another test could be added that checks whether this raises an error for a non-symmetric matrix, similar to the following test:
https://github.com/Qiskit/qiskit-terra/blob/968000fd14d43935538fdebb3ef10194940633e1/test/python/circuit/test_library.py#L182-L185
Let me know what you think about this, I would be more than glad to update my branch with this change as well 🙂

I was thinking that maybe it would make sense to include the function you have provided in the GraphState class to have a specific method for getting the stabilizers. In the end, however, I figured that is probably not necessary, since we can always get the stabilizers using the other method you have shown – Clifford(circuit).stabilizers.pauli.to_label()

Another way of getting this can be clifford.to_dict() which gives you a dictionary of stabalizers like:
{'stabilizer': ['+XX', '+ZZ'], 'destabilizer': ['+IZ', '+XI']}

Hi @ajavadia,
Thank you for the input, I will keep this in mind! For the purpose of testing the GraphState, though, I would assume that using Clifford(graph_state).stabilizer.pauli.to_labels() would be fine, right? Otherwise, is there any other input for my pull request or could we proceed with merging that?

@mantcep If you could add the symmetry test that would be great.
I think either way of getting the stabilizers is fine, though the to_dict method is a bit more elegant since it requires less code. I'd say it's up to you!

Hi @Cryoris,
Sure, I will add the check for symmetry and see which method works best for me to get the stabilizers! I think I can get that done quite quickly and will update the branch once it is ready.
Thank you again!

Hi again @Cryoris,
I have added the symmetry check and the corresponding test. Both of these are based on similar implementation in HiddenLinearFunction.
As for getting the stabilizers, I have not made any changes to that. I was not very sure about implementing the phase we get from using the to_dict() method, which, as I understand, corresponds to the phase p in the following:
https://github.com/Qiskit/qiskit-terra/blob/1425ebddce035edac2fc2f96dbde5f89c4da8ae5/qiskit/quantum_info/operators/symplectic/stabilizer_table.py#L31-L34
I hope you do not mind me taking this shortcut here for the purpose of this test.
Let me know what you think about this final commit and whether there are any other changes I should implement before we proceed with merging this 🙂
I am very thankful for your support on my very first contribution! I understand that this is time consuming for you, so I will try to be a lot more independent in the next one!

Thank you, @Cryoris! 🙂


Package install with malformed package name produced unhelpful error message

I ran elm install elm-geometry in PowerShell using Window 10 and got the following error message:
elm.exe: TODO show possible arg configurations
CallStack (from HasCallStack):
  error, called at ui/terminal/src\Terminal\Args\Error.hs:281:13 in main:Terminal.Args.Error

After a couple minutes I realized that I should have written elm install ianmackenzie/elm-geometry instead but I think it would be more helpful if the error message returned was something along the lines of Failed to install package.  I expected the package name formatted as author/package-name.

Thanks for reporting this! On my development build, I am seeing the following error message:
$ elm install elm-geometry
I am having trouble with this argument:

    elm-geometry

It is supposed to be a <package> value, like one of these:

    elm/browser
    elm/core
    elm/parser
    elm/regex

So it looks like it got fixed as part of the infrastructure improvements there. The fixed version should become available once Elm 0.19.1 is released. Thank you for reporting this case!

I think it can be improved a bit more though. I'll give it a shot and get back to you!

Ah, it's a bit tricky. I know if I really start working on it there is a high chance the project will grow a bit larger than makes sense, so I think it makes sense to wait on it for now.


How to visualize the graph?

I follow the instruction and run the code without crash. But I could not find out whether there is a function in the code to visualize the graph. So any hint to reproduce the results of the semantic nodes and the edges?

Hello, we visualize the point cloud by using the PCL libarary, the function is in the PointCloudMapping.cpp, please check the code (The main.cpp has the function but it is commented, try to uncomment these lines, and run the code), thank you.


RFC: Make registration pluggable.

Extract lib/registration.js to live inside of a plugin.  This will allow various configurations for registration.
One specific example that I need/want is to be able to check the service worker after installation to ensure that it matches the running application. This prevents massive self-trollage when developing applications locally where a service worker could have been registered for http://localhost:4200 by project-a, then you switch to project-b and you are completely hosed. I have a working prototype of this in this branch, but if I have a different registration then I would imagine that others may as well.
If there are no objections, I'll extract the current registration system into ember-service-worker-basic-registration and my version into ember-service-worker-project-entangled-registration (naming sucks).

I don't see your PR solving this in a good way.
I wouldn't like it if I had to rewrite the whole registration code manually. I think we should again be able to define some code and then call it when the registration resolves.
For example:
{{USERLAND_CODE}}

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('{{ROOT_URL}}sw.js', { scope: '{{ROOT_URL}}' })
    .then(function(reg) {
      {{RUN_USERLAND_SUCCES_HANDLERS}}
    })
    .catch(function(error) {
      {{RUN_USERLAND_ERROR_HANDLERS}}
    });
}

Later this should be combined with being able to register multiple service workers at different scopes.

Seems good, my PR can easily be modified to provide a addRegistrationSuccessHandler. But it still needs to be a separate tree, which is what the majority of the code actually does...

Yes, I didn't mean to criticise the extra tree, just the way you had to fully write the registration code.

No worries, working on refactoring to allow registration of callbacks.

Awesome!


Need support for mutli-select in tree structure inside a list, tree etc..

Need support for the ability to mutli-select in tree structure inside a list, tree etc.

Hello Team, are we picking this up for review ?

Take a look at ListMultiSelectionMouseController.

Take a look at ListMultiSelectionMouseController.

This would be helpful in other cases @Harbs , but I happen to know that this is for mx emulation components, and although there is an option in the framework there, I'm not sure that that is yet capable. To answer your question, @abharath23, I suspect  this should be after #1227, so let's look at it after that.


test: migrate cfg and check to snapbox

What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:

tests/testsuite/cfg.rs
tests/testsuite/check.rs

All feedback addressed! Thanks :)

Thank you.
@bors r+

:pushpin: Commit 27062476a86e864479ef6bde1828c624b643de4b has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit 27062476a86e864479ef6bde1828c624b643de4b with merge 236f58a0a8e44e743c7f2898e9747aac16f52a1e...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing 236f58a0a8e44e743c7f2898e9747aac16f52a1e to master...


Add CI

Make a github action to run the tests (and check the types) and block on failure.

Definition of done here is that I lock the main branch, have tests running on all PRs and do not allow merges until a green light shows.


Adding 8-bit strings test cases.

:metal: Thank you for all this work! It's awesome!

That was fun, and it's great contributing to Wren! Feel free to ask for help, if you need! :wink:


gzserver: symbol lookup error

gzserver: symbol lookup error: /home/ozkan/mrs_workspace/src/simulation/ros_packages/px4_firmware/build/px4_sitl_default/build_gazebo/libgazebo_mavlink_interface.so: undefined symbol: _ZN8mav_msgs4msgs17CommandMotorSpeedC1Ev
I am facing this error, could you help me get through this error?

Hey, I would need much more information to help you. Are you building an up-to-date version of the system? Are you sure you are not checking out some custom (meaning your's) version of the px4 package? The build passes on our servers. If you just need to use our system, I recommend using singularity images.

Hei, Yes I am using up to date version of the system. I am using px4 when comes with your system not to install px4 firmware again. My problem is fixed somehow while trying to install jmsim simulation environment. Now working fine, thank you.


Update packagist after the redirect

Packagist hasn't been updated after the redirect...

+1

Add the following to your composer.json for a temporary workaround /cc @micc83
    "repositories": [
        {
            "type": "git",
            "url": "git@github.com:klein-framework/klein.php.git"
        }
    ]

@steadweb Unfortunately I can't, I'm relying on dist version as the target machine doesn't comes with Git. :cry:

Ah, you can use https instead and use the --prefer-dist flag with composer.
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/klein-framework/klein.php.git"
        }
    ],

Composer command:
composer install --perfer-dist

Hopefully that should work for you :smile:

Unfortunately no luck.
My composer.json :
{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/klein-framework/klein.php.git"
    }
  ],
  "require": {
    "klein-framework/klein.php": "2.1.0"
  }
}

When I run:
$ php composer.phar update --prefer-dist

I get:
The requested package klein-framework/klein.php could not be found in any version, there may be a typo in the package name.

Revert the change within the require as the package name hasn't changed, it's just the URL :smile: - So you want to require "klein/klein": "2.1.0" not "klein-framework/klein.php": "2.1.0"
Try the following:
{
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/klein-framework/klein.php.git"
    }
  ]
  "require": {
    "klein/klein": "2.1.0"
  }
}

Then run
$ php composer.phar update --prefer-dist

Thank you @steadweb . I din't realize that the composer.json file of the package didn't changed either.

No worries @micc83 :+1:

Sorry about the inconvenience here, everyone.
We'll get this squared away very soon. It's breaking CI builds for me also. :stuck_out_tongue_closed_eyes:

https://github.com/chriso/klein.php should now redirect here.

Just updated the Packagist repo URL :smiley:
https://packagist.org/packages/klein/klein
Again, sorry for the inconvenience. :wave:


Correct the msg IDs of DL_NODE.sync and UL_NODE.sync

p.s. I only modified Lines 1441, 1442, 5231, 5232, 5233, 5240, 5241 of original packet-nfapi.c. I do not know why the diff result of packet-nfapi.c shows lots of difference, although most of them are the same.

It looks like the diff problem of packet-nfapi.c is this: We’ve detected the file encoding as windows-1252. When you commit changes we will transcode it to UTF-8.

Thanks for the submission and identifying the reversed UL / DL Node Sync message IDs.
As you point out on the packet-nfapi.c fine, there are lots of changes that should not be represented in the diff. Could I please ask you to re-submit so that it shows the actual changes as you describe?
I'll be happy to pull this in ASAP then.
Thanks!

Hi, olivbull. We have updated the packet-nfapi.c file. Thank you.


STORM-1458: Add check to see if nimbus is already running.

+1 the CI test failures look unrelated.


fzf: 0.19.0 -> 0.20.0

Motivation for this change
https://github.com/junegunn/fzf/blob/master/CHANGELOG.md#0200
Things done

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

[x] 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 nix-review --run "nix-review wip"
[x] 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.

Notify maintainers
cc @filalex77

@GrahamcOfBorg build fzf


MenuEntrySwapper: added dive-swap for rowboat

Adds option to swap "Travel" to "Dive" when using the rowboat on Fossil Island. I find it useful for doing tasks such as glassblowing underwater to gather seaweed spores.

This already exists as the item literally just below the bottom of your last screenshot: Fossil Island Rowboat Dive


Node stopped accruing rewards

Describe the bug
After node had successfully went online and started earning rewards the status changed to "Online & Queued for Rewards". The node hasn't been earning rewards since.
Expected behavior
Expected to continue to accrue rewards given the node remained online and continuously finalized bundles since joining the network.
Screenshots

Desktop (please complete the following information):
VPS provider: Contanbo
System: 16 cores | 64 GB | 500 GB (100% NVMe) | 1,000 Mbit/s
OS: Ubuntu 22.04
Location: New York
OS: Ubuntu 22.04
Additional context
config.zip

Thank you for reporting! We are investigating this issue

This has been resolved with a recent version release. Thank you for reporting.


Top/bottom positions

Firstly, thanks for a great plugin. Really appreciate your work.
Secondly, I think it would be useful to have positions of top-centre and bottom-centre.

Hi @Tadaz. Thanks for your feedback.
I'll see if I find the time to implement it.


compute Capacity Reservation Group Delete Fails With no Reservations

Hi, I'm using On-demand Capacity Reservation feature and have found an issue with Delete: When I tries deleting the Capacity Reservation Group shortly after (in fewer than 5 seconds) I delete all the reservations in it, it throws an error of still having nested resource in it.
Below is what I tested using Invoke-WebRequest PowerShell command to make the REST API requests. Because it happens only within a short range, I invoked the DELETE in a batch and used GET to check the result. As can be seen below: in the second GET response, capacityReservations is already removed from the CapacityReservationGroup, but the subsequent DELETE still cannot delete it. And I'm only able to invoke the DELETE after about 5 seconds.
PS C:\Users\yicma> Write-Host "`nCapacity Reservation Group before deleting the reservation:`n"
>>
>> (Invoke-WebRequest -UseBasicParsing -Headers $headers -Method "GET" https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma/providers/Microsoft.Compute/capacityReservationGroups/yicma-cap-test?api-version=2021-11-01).Content                                                                                >>                                                                                >> Write-Host "`nDeleting Reservations:`n"                                                                                >>
>> (Invoke-WebRequest -UseBasicParsing -Headers $headers -Method "DELETE" https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma/providers/Microsoft.Compute/capacityReservationGroups/yicma-cap-test/capacityReservations/reserve-0?api-version=2021-11-01).Content
>>
>> Write-Host "`nCapacity Reservation Group after deleting the reservation:`n"
>>
>> (Invoke-WebRequest -UseBasicParsing -Headers $headers -Method "GET" https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma/providers/Microsoft.Compute/capacityReservationGroups/yicma-cap-test?api-version=2021-11-01).Content
>>
>> Write-Host "`nDeleting Capacity Reservation Group:`n"                                                                                >>                                                                                >> (Invoke-WebRequest -UseBasicParsing -Headers $headers -Method "DELETE" https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/yicma/providers/Microsoft.Compute/capacityReservationGroups/yicma-cap-test?api-version=2021-11-01).Content

Capacity Reservation Group before deleting the reservation:

{
  "name": "yicma-cap-test",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/YICMA/providers/Microsoft.Compute/capacityReservationGroups/yicma-cap-test",
  "type": "Microsoft.Compute/capacityReservationGroups",
  "location": "eastus",
  "tags": {
    "a": "b"
  },
  "properties": {
    "capacityReservations": [
      {
        "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/YICMA/providers/Microsoft.Compute/capacityReservationGroups/YICMA-CAP-TEST/capacityReservations/RESERVE-0"
      }
    ]
  }
}

Deleting Reservations:

Capacity Reservation Group after deleting the reservation:

{
  "name": "yicma-cap-test",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/YICMA/providers/Microsoft.Compute/capacityReservationGroups/yicma-cap-test",
  "type": "Microsoft.Compute/capacityReservationGroups",
  "location": "eastus",
  "tags": {
    "a": "b"
  }
}

Deleting Capacity Reservation Group:

Invoke-WebRequest : {"error":{"code":"CannotDeleteResource","message":"Can not delete resource before nested resources are deleted."}}
At line:15 char:2
+ (Invoke-WebRequest -UseBasicParsing -Headers $headers -Method "DELETE ...
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

It looks similar to #18572 and #8137

hi @oriwolman or @TravisCragg-MSFT would you please take a look at this issue?

@myc2h6o Does the deletion succeed after several minutes has passed, or does it continue to fail?

Hi @TravisCragg-MSFT the deletion will succeed after a few seconds.

@myc2h6o Have you tried doing the same via PowerShell or CLI to see if the behavior is the same?

@TravisCragg-MSFT I haven't tried PowerShell or CLI, I only tried REST API.

@TravisCragg-MSFT are you still looking into this issue?

I am following up with our team to fix this delay, or update the error message to state a wait period.

@myc2h6o This failure can occur sometimes if the delete of the Capacity Reservations has not fully synced and you call a delete for the group. When calling these programmatically, a small delay between the nested resource delete and the Reservation Group delete should resolve this issue.


line 63 in the 2nd / 601_11_01.bin crash

On line 63(「うむ！　冬服を見に行こう！」) in the 2nd / 601_11_01.bin file, the game is forcibly turned off.
The same thing happens when you rebuild from the original file.

I seem to be unable to reproduce this issue. What are you using to rebuild the file? STSCTool? because I have rebuilt the file with the lastest release and everything seems to be working fine for me.

Isn't it forced to quit after line 63?
Basically, I am using the program you made.
The script can be replaced only by writing it in a spreadsheet on Google Drive.
Here is my rebuild script file.
https://www.dropbox.com/s/dolslod0ciiydjm/Script.pck?dl=0

I just checked Script_E.pck and it seems to work perfectly fine on my end. Is that file meant to have the issue?

It doesn't seem to be a script problem.
I think I found the problem. Sorry.
I will check and contact you again.
Thank you.

That's fine. If it does end up not being a DALTools issue then feel free to click that Close button. I hope DALTools will help you get want you want done.


Webhooks

@bgruening shouldn't have to tell people "no later than one hour." This should happen automatically. Jenkins should tell users their package(s) are available.
cc @martenson

:)

@martenson is this fixed now?

cargoport has a jenkins webhook now

Awesome! :D

Thanks @martenson


Nix installation

Not really a question about  the layout, but how can i install it as a package in nixos?
I'm just learning to use flakes, sorry

Add this repository to your Flake inputs. My Flake configuration looks like,
{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-23.05";

    home-manager = {
      url = "github:nix-community/home-manager/nixos-23.05";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    owm = {
      url = "github:justinlovinger/owm/master";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    ...
  };

  outputs = {
    nixpkgs,
    home-manager,
    owm,
    ...
  } @ inputs: {
    nixosConfigurations = let
      nixosConfiguration = hostname: system: {
        name = hostname;
        value = nixpkgs.lib.nixosSystem {
          specialArgs = {inherit inputs;};
          inherit system;
          modules = [
            (overlayModule system)
            home-manager.nixosModule
            (./machines + "/${hostname}")
          ];
        };
      };

      overlayModule = system: ({...}: {
        nixpkgs.overlays = [(overlay system)];
        home-manager.users.USERNAME = {...}: {
          nixpkgs.overlays = [(overlay system)];
        };
      });
      overlay = system: (final: prev: {
        owm = owm.defaultPackage.${system};

        ...
      });
    in
      builtins.listToAttrs [
        (nixosConfiguration "HOSTNAME" "x86_64-linux")
        ...
      ];
  };
}

The key points here for owm are the owm input and the overlay containing owm. With that overlay, owm will be added to your package set, so you can use it like any other package in Nixpkgs. You can ignore the Home Manager parts if you are not using Home Manager.


Default select option in exported state

The option Select an option (that appears by default and can't be removed nor changed) should not appear on the options array of a Dropdown field, as it's not an option but a placeholder.

As discussed, we will keep it in there so that we can change it as needed and the consumer of the object will display it appropriately as a placeholder option.


Resolving dependencies to lesser scope is permitted?

Hey i found this behavior on kodein version 6.3.3.
Let say i have an unscoped singleton binding,  that has dependencies to other scoped instance:
bind<ScopedObject>() with scoped(SomeScopeProvider).singleton { ScopedObject() }
bind<UnscopedObject>() with singleton { UnscopedObject(instance<ScopedObject>()) }

The first time i access UnscopedObject is failed as expected.
assertFails("This fail as expected") { kodein.direct.instance<UnscopedObject>() }

Then if i access it on another scope and access it back from unscoped instance, it will always return the first instance created from the scoped.
assertFails("Should be failing, but currently permitted") {
    kodein.direct.on(SomeScope).instance<ScopedObject>()
}

assertFails("Should still be failing, but it will return the previous instance instead") {
    kodein.direct.instance<ScopedObject>()
}

I believe this behavior is not the intended one since it's make scoping behavior less predictable (eg. what if i have a weak referenced scope that could be gone anytime). And it's kinda block us to update our kodein dependencies (we still stuck at version 3).

I'm sure I following your idea here, but here is what I can tell to guide you with scopes.
Here is my context (using 6.4.0)
class ScopedObject {}
class UnscopedObject(val scopedObject: ScopedObject)
object SessionScope : WeakContextScope<String>()

val kodein = Kodein {
    bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject() }
    bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }
}

Accessing unscoped object

    assertFails("This fail as expected") {
       val unscopedObject = kodein.direct.instance<UnscopedObject>()
    }

Sure this will fail because you try to retrieve an unscoped object with rely on a scoped object outside a scope, so it cannot find a scope object as its only bound with a scope.
However, if you do something like:
val unscopedObject = kodein.direct.on("session1").instance<UnscopedObject>()

This won't fail.

Accessing a scoped object

assertFails("Should be failing, but currently permitted") {
       val scopeObject = kodein.direct.on("session1").instance<ScopedObject>()
    }

Of course, this will work, because I'm trying to retrieve a scoped object on a scope. What could go wrong ?

(Re)accessing a scope object

  assertFails("Should still be failing, but it will return the previous instance instead") {
        val scopedObjectWithoutScope = kodein.direct.instance<ScopedObject>()
    }

This will have the same effect as in 1. it will fail because we are outside a scope.
Here my full example:

import org.kodein.di.Kodein
import org.kodein.di.bindings.WeakContextScope
import org.kodein.di.direct
import org.kodein.di.generic.*
import kotlin.test.assertFails
import kotlin.test.assertTrue

val kodein = Kodein {
    bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject() }
    bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }
}

object SessionScope : WeakContextScope<String>()
class UnscopedObject(val scopedObject: ScopedObject)
class ScopedObject {}

fun main() {
    val ex1 = assertFails("This fail as expected") {
       val unscopedObject = kodein.direct.instance<UnscopedObject>()
        println(unscopedObject)
    }
    println("Exception will trying to retrieve scoped object outside the scope\n$ex1")
    println("-----------------------------------------------------------------------------")

   val scopeObject = kodein.direct.on("session1").instance<ScopedObject>()
    println("ScopedObject $scopeObject with scope 'session1'")
    println("-----------------------------------------------------------------------------")

    val ex2 = assertFails("Should still be failing, but it will return the previous instance instead") {
        val scopedObjectWithoutScope = kodein.direct.instance<ScopedObject>()
        println(scopedObjectWithoutScope)
    }
    println("Exception will trying to retrieve scoped object outside the scope\n$ex2")
    println("-----------------------------------------------------------------------------")

    println("Compare the two exceptions: ${assertTrue { ex1.message == ex2.message }}")
}

With my output:
// 1.
Exception will trying to retrieve scoped object outside the scope
org.kodein.di.Kodein$NotFoundException: No binding found for bind<ScopedObject>() with ? { ? }
Available bindings for this type:
        bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject }
Registered in this Kodein container:
        bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject }
        bind<UnscopedObject>() with singleton { UnscopedObject }

-----------------------------------------------------------------------------
// 2.
ScopedObject org.kodein.di.sandbox.scope.ScopedObject@57fa26b7 with scope 'session1'
-----------------------------------------------------------------------------
// 3.
Exception will trying to retrieve scoped object outside the scope
org.kodein.di.Kodein$NotFoundException: No binding found for bind<ScopedObject>() with ? { ? }
Available bindings for this type:
        bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject }
Registered in this Kodein container:
        bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject }
        bind<UnscopedObject>() with singleton { UnscopedObject }

-----------------------------------------------------------------------------
Compare the two exceptions: true

I think i've made some typos on the second part, causing the confusion. Here is my attempt to make full test for above scenario and retested on 6.3.3. I couldn't really tested on 6.4.0 on the time being since it seems it has another error when i build the project.
package com.invoice2go.di

import org.junit.Test
import org.kodein.di.bindings.ScopeRegistry
import org.kodein.di.bindings.StandardScopeRegistry
import org.kodein.di.conf.ConfigurableKodein
import org.kodein.di.direct
import org.kodein.di.generic.bind
import org.kodein.di.generic.instance
import org.kodein.di.generic.on
import org.kodein.di.generic.scoped
import org.kodein.di.generic.singleton
import kotlin.test.assertFails

class KodeinTest {
    val kodein = ConfigurableKodein()

    @Test fun `unscoped object depends on scoped object`() {
        kodein.addConfig {
            bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject(context) }
            bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }
        }

        assertFails("Accessing unscoped object with scoped deps should fail") {
            kodein.direct.instance<UnscopedObject>()
        }

        assertFails("Accessing unscoped object from scope with scoped deps should fail") {
            val instance = kodein.direct.on("Scope").instance<UnscopedObject>()
            println("Successfully retreived $instance: ${instance.dependency.contextName}")
        }

        assertFails("Accessing unscoped object with scoped deps should fail") {
            val instance = kodein.direct.instance<UnscopedObject>()
            println("$instance: ${instance.dependency.contextName}")
        }
    }

    class ScopedObject(val contextName: String)
    class UnscopedObject(val dependency: ScopedObject)

    object SessionScope: org.kodein.di.bindings.Scope<String> {
        val registryMap = mutableMapOf<String, ScopeRegistry>()
        override fun getRegistry(context: String): ScopeRegistry =
                registryMap.getOrPut(context) { StandardScopeRegistry() }

    }
}

Having this kind of output when i run it:
Successfully retreived com.invoice2go.di.KodeinTest$UnscopedObject@3f49dace: Scope

java.lang.AssertionError: Accessing unscoped object from scope with scoped deps should fail. Expected an exception to be thrown, but was completed successfully.

One gotcha that i found is this line of code:
kodein.direct.instance<UnscopedObject>()

Will throw exception saying it couldn't find the binding for ScopedObject which is the expected behavior.
But if i do something like this:
val unscopedObject1 = kodein.direct.on("Scope").instance<UnscopedObject>()
val unscopedObject2 = kodein.direct.instance<UnscopedObject>()

It will be executed successfully.
The problem is, the returned instance unscopedObject2 is the same instance from unscopedObject1. Since unscopedObject1 has dependency from "Scope", isn't it kinda leaking the scope?
Hopefully this comment doesn't have too much typos that causing more confusion.

Ok, I get it. I don't think this is a glitch, because what you try to do is mix scoped and unscoped objects.
What happen when you do the following code ?
val unscopedObject1 = kodein.direct.on("Scope").instance<UnscopedObject>()

Kodein tries to resolve UnscopedObject in the scope, but it doesn't. So it tries to resolve it without scope and find a way out with
bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }

But, it also needs to resolve ScopedObject in order to invoke the UnscopedObject constructor. This object is bound in a scope, so kodein use the context "Scope" to retrieve the ScopedObject.
Also, if you try to retrieve an unscoped object with a scope, like:
...
bind<UnscopedObject2>() with singleton { UnscopedObject2() }
...
val unscopedObject2 = kodein.direct.on("Scope").instance<UnscopedObject2>()

This will work.
Be careful, because if you mix scoped and unscoped you will have issues.
Regarding the following  bindings:
bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject() }
bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }

if you try to retrieve the UnscopedObject for two differents scopes, like:
val unscopedObject1 = kodein.direct.on("Scope1").instance<UnscopedObject>()
println("$unscopedObject1 / ${unscopedObject1.scopedObject}")
val unscopedObject2 = kodein.direct.on("Scope2").instance<UnscopedObject>()
println("$unscopedObject2 / ${unscopedObject2.scopedObject}")

then you will end with:
org.kodein.di.sandbox.scope.UnscopedObject@782830e / org.kodein.di.sandbox.scope.ScopedObject@470e2030
org.kodein.di.sandbox.scope.UnscopedObject@782830e / org.kodein.di.sandbox.scope.ScopedObject@470e2030

so unscopedObject1==unscopedObject2 and unscopedObject1.scopedOject == unscopedObject2.scopedObject. Because you UnscopedObject binding is singleton.
If you want to mix scoped and unscoped objects you should consider using a provider
bind<UnscopedObject>() with provider { UnscopedObject(instance()) }

otherwise I recommend you to scope your unscoped object too.
    bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject() }
    bind<UnscopedObject>() with scoped(SessionScope).singleton { UnscopedObject(instance()) }

Yes that's what i've trying to describe. I've actually have similar provider pattern for such use case, but the fact that this binding is allowed and didn't crash is what worried me. Since mixed scope is a common pattern, for example in our project we use it to have some kind of hierarchy similar to Dagger subcomponent.
Also on code review context, when we review change similar to this:
bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }

class UnscopedObject(val dependency: ScopedObject)

There is no way we could know that UnscopedObject depends to scoped. And most of the time we provide the Kodein with a scope that's relevant when we use it (the user doesn't care where the dependency comes from) it will be harder to catch the issue during runtime/sanity test.
At the moment i still use the old version of Kodein (3.4.1) and it doesn't have this issue, but yeah we need to add our custom logic so it's able to access top-level object from scoped context.
Is it possible to retain current resolution mechanism (accessing top scope singleton from lesser scoped one) while disallowing this kind of binding (top level binding to scoped one)?
We have a wrapper on top of Kodein at the moment and we have a test that explicitly disallow such behavior, and it's the only blocker that prevent us from upgrading at the moment.

the fact that this binding is allowed and didn't crash is what worried me
From my knowledge, we do not check scope binding in that way

I'm confused, if you don't know that dependencies are scoped, how do you expect that Kodein retrieve a ScopedObject outside of a scope without telling it ? Or, how do you tell it in which scope are you at the retrieval time ?

Is it possible to retain current resolution mechanism (accessing top scope singleton from lesser scoped one) while disallowing this kind of binding (top level binding to scoped one)?

Are you asking for some changes in our codebase or some help to find a smooth resolution ?
Plus, I just copied your test code and run it on (6.3 && 6.4):
package org.kodein.di.sandbox.scope

import org.kodein.di.Kodein
import org.kodein.di.bindings.ScopeRegistry
import org.kodein.di.bindings.StandardScopeRegistry
import org.kodein.di.bindings.WeakContextScope
import org.kodein.di.direct
import org.kodein.di.generic.*
import org.kodein.di.sandbox.singleton.kodein
import kotlin.test.assertFails
import kotlin.test.assertTrue

class ScopedObject(val contextName: String)
class UnscopedObject(val dependency: ScopedObject)

object SessionScope: org.kodein.di.bindings.Scope<String> {
    val registryMap = mutableMapOf<String, ScopeRegistry>()
    override fun getRegistry(context: String): ScopeRegistry =
        registryMap.getOrPut(context) { StandardScopeRegistry() }

}
val kodein = Kodein {
    bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject(context) }
    bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }
}

fun main() {
    val ex1 = assertFails("Accessing unscoped object with scoped deps should fail") {
        kodein.direct.instance<UnscopedObject>()
    }
    println(ex1)

    val ex2 = assertFails("Accessing unscoped object from scope with scoped deps should fail") {
        val instance = kodein.direct.on("Scope").instance<UnscopedObject>()
        println("Successfully retreived $instance: ${instance.dependency.contextName}")
    }
    println(ex2)

    val ex3 = assertFails("Accessing unscoped object with scoped deps should fail") {
        val instance = kodein.direct.instance<UnscopedObject>()
        println("$instance: ${instance.dependency.contextName}")
    }
    println(ex3)
}

all 3 cases failed.

I'm confused, if you don't know that dependencies are scoped, how do you expect that Kodein retrieve a ScopedObject outside of a scope without telling it ?

What i mean is, usually when we retrieving a dependency for object A, we know what the scope for that object A but we don't really care about the 'scope' of the dependencies.
Let say from the example i provided, we add another binding like this:
data class ScopedObject(val contextName: String)
data class UnscopedObject(val dependency: ScopedObject)
data class AnotherObject(val unscopedObject: UnscopedObject)

val kodein = Kodein {
    bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject(context) }
    bind<UnscopedObject>() with singleton { UnscopedObject(instance()) }
    bind<AnotherObject>() with scoped(SessionScope).singleton { AnotherObject(instance()) }
}

val anotherObject = kodein.direct.on("SomeScope").instance<AnotherObject>()
println(anotherObject)

I think it's clearer now that we have misconfiguration on the bindings, and the scoping of the dependencies should be fixed. But instead of crashing, it executes successfully and produces following output:
AnotherObject(unscopedObject=UnscopedObject(dependency=ScopedObject(contextName=SomeScope)))

And subsequent accessing UnscopedObject without any scope will return the same object from "SomeScope".

Are you asking for some changes in our codebase or some help to find a smooth resolution ?

My main question is, whether this kind of behavior is expected on Kodein? I think it's one of the case of misconfigured binding that should crash earlier so there should be some changes in Kodein implementation to throw error for this behavior.

all 3 cases failed

Do you mean all ex1, ex2, and ex3 is printed successfully? Because when i run it the first assertion failing as expected and ex1 is printed to the console, while the anything after ex2 is not printed because it didn't throw anything.
Here is my output when running it:
org.kodein.di.Kodein$NotFoundException: No binding found for bind<ScopedObject>() with ? { ? }
Available bindings for this type:
        bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject }
Registered in this Kodein container:
        bind<ScopedObject>() with scoped(SessionScope).singleton { ScopedObject }
        bind<UnscopedObject>() with singleton { UnscopedObject }

Successfully retreived org.kodein.di.sandbox.scope.UnscopedObject@4c203ea1: Scope
Exception in thread "main" java.lang.AssertionError: Accessing unscoped object from scope with scoped deps should fail. Expected an exception to be thrown, but was completed successfully.
	at org.junit.Assert.fail(Assert.java:88)
	at kotlin.test.junit.JUnitAsserter.fail(JUnitSupport.kt:56)
	at kotlin.test.AssertionsKt__AssertionsKt.checkResultIsFailure(Assertions.kt:134)
	at kotlin.test.AssertionsKt.checkResultIsFailure(Unknown Source)
	at org.kodein.di.sandbox.scope.ScopingTestKt.main(ScopingTest.kt:36)
	at org.kodein.di.sandbox.scope.ScopingTestKt.main(ScopingTest.kt)

Also i use following artifact for the dependencies if that relevant:
implementation org.kodein.di:kodein-di-generic-jvm:6.3.3
implementation org.kodein.di:kodein-di-conf-jvm:6.3.3

Ok, I get it, its clearer with your new example. I agree that there is something wrong, but not sure what exactly for the moment.
Indeed, the UnscopedObject will still be the first instance created, it's a singleton. So this doesn't disturb me at all, and I think this is what I would expect from Kodein. As the object is not scoped, it will be available in every cases.
But, we still can consider adding some check to avoid such misconfiguration. However, we'll have to add it to the roadmap and discuss about it first. Unfortunately if we agree on the implementation, this couldn't be done before some time. I will create an issue for that (#252).
However, even the implementation of a misconfiguration is missing, and if you really want to upgrade, I suggest you to change your bindings, to avoid such a case. Why not scoping the UnscopedObject as you will always need it in a scope ? Or, if it's a test case, ignore it until we provide a solution.

Do you mean all ex1, ex2, and ex3 is printed successfully?
No, sorry, in fact I had some bad imports making the test successful...


[Task]: Update Stronghold Version

Task description
Once stronghold migration is enabled, we need to update this line to V3:
https://github.com/iotaledger/firefly/blob/cfce0fc133fd1717918de8d682b8896cc14a5b5b/packages/shared/lib/core/stronghold/constants/stronghold-version.constant.ts#L3
Requirements
TBD
Creation checklist

[ ] I have assigned this task to the correct people
[X] I have added the most appropriate labels
[X] I have linked the correct milestone and/or project

Requires new iota-sdk release.


Support permalinks from a git tag

When trying to create a permalink for https://github.dev/python/cpython/blob/v3.8.12/Objects/typeobject.c#L921 (note the v3.8.12 tag), I get the following message:

On github.com I can create the link without issue, so I would love to be able to do the same from github.dev .

Super weird--looks like this is what the GitHub APIs are returning to us...

OK, problem is we assumed the OID for a tag is also the associated commit SHA:

I've pushed a change to correctly set HEAD.commit for tags in RemoteHub.
Even with this change though, GHPRI cannot generate permalinks for tags (or commits, for that matter).
There are a few issues with the current state of things:

RemoteHub doesn't support Repository.log when a path is specified (and also GHPRI is passing uri.fsPath as the path to filter on, which is not valid for RemoteHub URIs), so this call will throw https://github.com/microsoft/vscode-pull-request-github/blob/2811810bbf9c26d8d982b56d001d09ad7e7fc4d0/src/issues/util.ts#L480
When Repository.log throws, we end up falling back to getSimpleUpstream, and the call to getSimpleUpstream always returns undefined for commits and tags (even on desktop with the vscode.git IGit implementation) since there is no repository.state.HEAD.upstream for commits and tags.
Even if I fix the Repository.log implementation and we get to getUpstream, GHPRI runs a search for getBranches with pattern: "remotes/origin/HEAD" which doesn't seem to be a valid branch name when passed to GitHub APIs https://github.com/microsoft/vscode-pull-request-github/blob/2811810bbf9c26d8d982b56d001d09ad7e7fc4d0/src/issues/util.ts#L409-L414
Also RemoteHub doesn't properly support getBranches for a specific commit, and it looks like this would be quite expensive to implement given the state of GitHub APIs: https://github.community/t/is-there-a-way-to-get-which-branch-a-commit-belongs-to-via-graphql/122561/5

Can GHPRI pick a remote in getSimpleUpstream when repository.state.HEAD.upstream is undefined (which is the case for tags and commits)? Also, can you share more context on how the remotes/origin/HEAD branch pattern works? I think ideally I'd fix RemoteHub's Repository.log and Repository.getBranches implementations so that GHPRI doesn't rely on the getSimpleUpstream fallback, but am not sure how to support that query pattern.

Can GHPRI pick a remote in getSimpleUpstream when repository.state.HEAD.upstream is undefined (which is the case for tags and commits)?

Yes, absolutely. I have pushed a change to do this. If the commit SHA is corrected then we should be good to go there (I tried running out of sources, but I still saw the wrong commit SHA).

For the pattern that we pass into Repository.getBranches (remotes/origin/HEAD above), that comes from the fact that the git extension uses for-each-ref in it's implementation of getBranches (https://git-scm.com/docs/git-for-each-ref). So for git, only branches that match refs/remotes/origin/HEAD will be returned from getBranches. As you pointed out, this is basically just a check to make sure the commit belongs to a branch on the remote. For Remote Repositories, I can probably skip a lot of the permalink figuring since by definition the commit exists on the current branch on the remote. This is basically what happens when with the getSimpleUptream fallback.

Just to make sure we are on the same page here, this is what I see when running GHPRI out of sources against the latest prerelease of RemoteHub--

The commitHash afaik is now correct, is this the value that you are looking at?
It seems like there was another change in GHPRI so the permalink generation still doesn't work--if commit is undefined (which is always the case with RemoteHub until we implement Repository.log we aren't going into getSimpleUpstream at all.

That commitHash looks correct. Something must have been stale somewhere as the one I saw while debugging was the old OID.
Thanks for checking this and catching my conflicting changes! I pushed the fix for the fix just now.

Running GHPRI out of sources against latest RemoteHub and can confirm that GHPRI permalink generation now works when opening the following GitHub urls in RemoteHub (previously, if you had any of these open, permalink generation did not work):

https://github.com/python/cpython/commit/304f5b63e904c3ab0b746ef7ad58c5c2ff0154a8
https://github.com/python/cpython/tree/v3.8.12/Objects/typeobject.c#L921
https://github.com/python/cpython/blob/v3.8.12/Objects/typeobject.c#L921
https://github.com/python/cpython/blob/aeb66c1abbf4ec214e2e80eb972546996d1a1571/Lib/test/test_finalization.py

Something must have been stale somewhere as the one I saw while debugging was the old OID.

This is because RemoteHub caches metadata on disk and doesn't invalidate that cache appropriately. I have pushed a fix in RemoteHub to ignore cached metadata and ask for the latest info from network when first initializing the repo. Users who have already seen the bad metadata once like @brettcannon should just be able to update RemoteHub and reload.


Create pass-authz release containing ACL updates

#28 significantly changed the ACLs in order to allow submissions and grants to be world-readable.  Cut a release that has these changes so that it can be pushed to Docker

Depends on #30

https://github.com/OA-PASS/pass-authz/releases/tag/0.2.0-SNAPSHOT


Can I use username.github.io/blog instead of username.github.io

Checklist

[x] I have read the newlest tutorials and know the correct effect of the functional design.
[x] There is no similar question on existing issues (including closed ones).
[x] I have tried to find the answer on Jekyll Forum and StackOverflow.
[x] My question is based on the latest code of the master branch.

Description

I already have a website at username.github.io and I want to use this template at username.github.io/blog. But in the getting started page the format is <GH_USERNAME>.github.io. I don't have domain so I can not use a subdomain for the blog.

When you enable github pages for your second repository (assuming that first is <GH_USERNAME>.github.io), that repository will be deployed on <GH_USERNAME>.github.io/repo_name. So in your case you just need to create a repo namedblog and enable github pages for it. Finally, config baseurl: '/blog' in your _config.yml.

When you enable github pages for your second repository (assuming that first is <GH_USERNAME>.github.io), that repository will be deployed on <GH_USERNAME>.github.io/repo_name. So in your case you just need to create a repo namedblog and enable github pages for it. Finally, configure baseurl: '/blog' in your _config.yml.

@NichtsHsu The sitemap does not work for baseurl: '/blog'

@SamirPaul1 Do you configure url: https://<GH_USERNAME>.github.io?

@SamirPaul1 Do you configure url: https://<GH_USERNAME>.github.io in _config.yml?

Thanks a lot, @NichtsHsu. Now it is working!


New guide for custom sessions and registration

This is the first draft for a new guide. I'll continue editing it and improving it.

Looks good, thanks! I've some suggestions for how to make it more concise. I'm currently traveling but I'll get back to this asap 😄

Great, I'm looking forward for your feedback!
Travel safe ;)

Sorry for the delay @abartier, this travel took pretty much all of my available time and first now I'm back at my desk. I've rebased your branch, and added some commits to make it more concise.
As you can see I prefer to keep the guides short and just handle one aspect, which in this case is custom controllers and routes. The accounts context and custom changeset is good too, but I think it would be better to have in a separate guide to not confuse the objective.
I've hopefully managed to keep your intention with the guide still 😄 what do you think?

Also, I've improved the code to ensure users are authenticated and not authenticated in the right routes.

This may be a good to add to the guide, to show how to use extensions with custom controllers: https://github.com/danschultzer/pow/issues/53#issuecomment-438459711

@danschultzer great improvements! I mentioned this was just a draft of the steps I took to achieve it. I think the refactored guide make more sense.
For the extensions part, don't you think we should make another guide? This can help to keep the guides concise as you did before?
I did not play with the extensions yet. When I'll, I can draft another guide as I did for the custom controllers. What do you think?
I'll start two new Phoenix projects in the next weeks, I'll test Pow in "production conditions". I'll be able to give a better feedback too.

Yeah, it's probably out of scope since it would require some more thoughts on the setup of the custom controllers. A separate guide on how to utilize extensions in a custom setup is more appropriate.
This is good as it is so I'll merge it in 🚀  Thanks for your help @abartier!

You're welcome.
I'll try to test extensions next week and play with it. Then I'll begin another draft for this new guide.


MM-17304 - Updating favourites button readout

Summary
MM-17304 - Updating favourites button readout
@lindy65 This should also remove the heading level 2 readout, and also fix the double readout.
Ticket Link
https://mattermost.atlassian.net/browse/MM-17304

Creating a new SpinWick test server using Mattermost Cloud.

Mattermost test server created! :tada:
Access here: https://mattermost-webapp-pr-3255.test.mattermost.cloud

Account Type
Username
Password

Admin
sysadmin
Sys@dmin123

User
user-1
User-1@123

Spinmint test server destroyed

Spinmint test server destroyed

Awesome, thanks for the quick review @lindy65

Creating a new SpinWick test server using Mattermost Cloud.

Mattermost test server created! :tada:
Access here: https://mattermost-webapp-pr-3255.test.mattermost.cloud

Account Type
Username
Password

Admin
sysadmin
Sys@dmin123

User
user-1
User-1@123

Thanks @asaadmahmood
Re-tested the "favorite" star  and "level heading 2" read-out and both look good to me.
Tested the group message read-out and the reader is reading it only once.
However, after the read-out, the reader says "link" after reading out GM names (it also reads out "link" after DM names).  Is this expected?

Spinmint test server destroyed

Spinmint test server destroyed

@lindy65 Yup, those are links, so it should read out the link for the other links in the sidebar too.

Thanks for confirming the "link" read-out Asaad :) Sounds good!


fix: Enable compilerOptions noImplicitReturns and noUnusedParameters to improve type safety

Hi, we are using your lib inside a typescript project having the following quite common compilerOptions enabled inside out tsconfig.json.
    "noImplicitReturns": true,
    "noUnusedParameters": true

This PR enabled this settings on your project as well because the code issues hiding in your code are letting our tsc fail as well. To enable it I fixed most of the underlying code issues. I added @ts-ignore to the PluginResult interface because I was too shy to remove the not used generic parameter O.
Thank you

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

5 of 5 (100.0%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 95.521%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
3441

Relevant Lines:
3549

💛  - Coveralls

Hi @jonluca, just kindly asking if you are creating a release for that.


[IM] Update read transaction resource minimas

Problem
Fixes #18610
Fixes #17418
Change overview

Implemented EnsureResourcesForRead and TrimFabricForRead
Unlike subscriptions, we only ensure minimal resources for each fabric and the clients are expected to retry since the span of read transactions are relatively short compared to subscriptions.
The PASE sessions will be counter on a virtual fabric and the resources will be guranteed when the device is not "fully" commissioned (i.e. have at least one empty slot for a new fabric)

Testing

Removed TestReadHandler_TwoParallelReads, adds TestReadHandler_ParallelReads with 8 cases (including 4 cases around PASE sessions).

There are 10 cases covered by the test.
We will serve the read requests at best efforts, and try not to evict the ongoing read requests (expect the client to retry later since the read transactions are short.)
Oversized read requests will be rejected when we don't have enough resources to serve it.
Case 1: Handling of oversized read requests

Case 1.1: The existing read requests (2 in the UT) used all resources for the path pool, and the incoming read request is oversized => paths exhausted. (https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR906)

Case 1.2: The path pool is not exhausted, but read handler pool is exhausted -> Busy (The same line, but it passed this check)
Case 1.3 is not for code coverage, but are some assumptions.

Case 1.3.1: oversized requests will be accepted if we have enough resources for them
Case 1.3.2: oversized fabric will be accepted if we have enough resources for them

But we will still evict the read requests when:
Case 2: One read request in one fabric is oversized, then one incoming read request from another fabric => accept by evicting one (when necessary).
(Repeated with different order to cover https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR818)
Note: the incoming read requests won't evict another read requests in the same fabric:
Case 3: One fabric is oversized, then one incoming read request from the same fabric => reject with Busy (when we don't have enough resources to serve it).
Reject if the fabric is oversized: https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR936
Case 4: One fabric is oversized (with no oversized read requests), and one incoming read request from another fabric => accept by evicting one (when necessary)
(Repeated with different order to cover https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR825)
Case 2 + Case 4: evicting priority:

Evict oversized requests
If all requests are oversized, or no requests are oversized, evict the youngest request.

When handling / evicting read transactions for CASE sessions, the logic depends on whether the fabric table is full:
Case 5: When the device's fabric table is not full, PASE sessions are counted as a valid fabric and can evict existing read transactions.

Case 5.1, Case 5.2: It will and will only evict oversized transactions from oversized fabrics.

Covers https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR843
Case 6: The device's fabric table is full, PASE sessions won't be counted as a "valid fabric" and it cannot evict existing read transactions.

It cannot evict transactions from normal fabrics. Just the other side of case 5

Covers https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR916
Case 7: We will accept read transactions on PASE session when the fabric table is full but we have enough resources for it.
Case 8: If the fabric table on the device is full, read transactions on PASE session will always be evicted.

Case 8.1 even if the existing fabrics is oversized, we will still evicting non-oversized "PASE fabric"

Covers https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR967 and https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR847
Case 9 -- PASE sessions are counted as a "normal fabric" if fabric table is not full, the read transactions from PASE sessions have (almost) the same priority when being evicted by incoming read transactions.
Covers https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR967

Case 9.1: If the fabric table on the device is not full, read transactions on PASE session will NOT be evicted when the resources used by all PASE sessions ARE NOT exceeding the resources guaranteed to a normal fabric.
Case 9.2: If the fabric table on the device is not full, the read handlers from normal fabrics MAY be evicted before all read transactions from PASE sessions are evicted.

also covers the case of guarantee more resources when possible (https://github.com/project-chip/connectedhomeip/pull/18884#discussion_r889474681)

Case 10: Just the other side of case 9: read transaction on PASE session will be evicted before evicting any other read transactions, even when the normal fabric is oversized.
Also covers https://github.com/project-chip/connectedhomeip/pull/18884/files?diff=split&w=0#diff-09d4e6f8f568b8ae1f60c465f4f2c89e3fb4e92d92ac2308fae80036b2430a1dR967

/rebase

Terminology
An oversized read request (transaction): A read request using more than the guaranteed (attribute or event) paths.
An oversized fabric: A fabric which either (1) have more read requests than the guaranteed number of read requests, or (2) the sum of (attribute or event) paths exceeds the guaranteed number of paths for the fabric.
PASE session: A session without an associated fabric index. They are counted as "fabric index 0". When we are iterating fabrics, all transactions on PASE session are counted to "fabric index 0", and fabric index 0 is counted.
CASE session: A session with an associated fabric index.
enough resources for handling a read request: We have enough free items in the path pool, and we have enough (in fact, 1) free read handlers.
Guaranteed resources:

Read request: 9 attribute paths, 9 event paths
Fabric: floor[(path pool size) / (fabric table size)] reads, floor[(path pool size) / (fabric table size)] * 9 {attribute|event} paths.
PASE sessions:

When fabric table is not full: the same as fabric
When fabric table is full: 0

Behavior
For an incoming read request, when we have enough resource for handling it, we always accept it regardless the actual resource usage.
Test Case: 1.3, Test Case 7, and assumed by all test cases.
The following test case all assumes we cannot handle it either we don't have enough free items in the path pool or we don't have enough free read handlers. Note: Base on the response code (and the branches in the code & conditions of the loops), we don't always discuss both cases.
For an oversized incoming requests:

If we don't have enough free items in the pool, it will receive "PathsExhausted" status code. (Test Case 1.1)
If we don't have enough free read handlers in the pool, it will receive "Busy" status code. (Test Case 1.2)
We don't check the actual fabric-level resource usage since the above two cases are exhausted.

For an incoming non-oversized request:

For non-oversized incoming read requests, we are not checking which resources are actually insufficient.

If it will make its fabric oversized (incl. its fabric is already oversized), it will receive "busy" status code. (Test Case 3)
If it comes from a PASE session, and the fabric table is full it will receive "ResourceExhausted" status code. (Test Case 6)

or we will evict transactions from other fabric to handle it (Test Case 5)

There must be one oversized fabric (or we should be able to handle it if no fabrics are oversized (incl. the new read request)), for a fabric we will only evict read transactions from it if it is oversized (last branch in TranFabricForRead).

If (and only if) the fabric table on the device is full, we will evict read requests from "fabric 0" before any eviction read requests on other fabrics (Test Case 8, Test Case 10). If the fabric table on the device is not full, we don't have a special order for evicting read requests from "fabric 0" and other fabrics. (Test Case 9)
If it has one or more oversized read requests:

The latest oversized read request will be evicted. (Test Case 2)

If it has no oversized read requests:

The lastest read request will be evicted. (Test Case 4)

Iterate over the fabrics and repeat until we have enough resources for handling this read request.


undefined is not a function (evaluating 'Object.getOwnPropertyNames(argument[i])

Environment
Environment:
OS: macOS 10.14.2
Node: 10.15.0
Yarn: Not Found
npm: 6.4.1
Watchman: 4.9.0
Xcode: Xcode 10.1 Build version 10B61
Android Studio: 3.2 AI-181.55<IP_ADDRESS>56338
Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: ^0.55.4 => 0.55.4
Description
After moving my folder to one another one, clean every cache you can imagine about it, I can't build or run in development
on Android anymore and receive this error:

It works fine on ios
The apk is crashing but I got an success message on android studio.
Any idea? this error is driving my team insane.
Cheers

occurs on 0.61.4


Tile server web interface for Update

!story G3.2
!component TileServer web interface

Web interface added for being able to update the layer definition of a tile server


Handle 401s better from dockerhub and avoid triggering rate limit

[11:35] < rhallisey> I can connect to dockerhub today
[11:35] < rhallisey> interesting
[11:36] < ernelson> I don't know what the deal is with that api, but it's very unreliable
[11:36] < rhallisey> we also should add some error checking around requests
[11:36] < rhallisey> yesterday I would get a 401 for each apb then 429s after docker got sick of the errors
[11:37] < rhallisey> 429 is too many requests and it would prevent me from trying again for a few minutes
[11:37] < ernelson> rhallisey: +1
[11:37] < ernelson> definitely need more validation
[11:37] < rhallisey> we should fail after 1 or 2 401's
[12:07] <@jmrodri> rhallisey: is this the broker that was making too many requests?
[12:07] < rhallisey> yes
[12:07] < rhallisey> broker would ask for image data from the dockerhub
[12:07] < ernelson> it's really easy to do, I'm rate limited all the time
[12:14] <@jmrodri> rhallisey: ok. definitely need to fix that then.
[12:14] <@jmrodri> ernelson: I'm sure

I haven't hit this in a long time. We can reopen if it pops back up.


Clear metadata when updating file type

This is a first attempt at approaching, fixes #2492. If the stream type of the source of the original claim is dimensional or playable, the appropriate field is cleared. Other metadata seem to be updating correctly. A simple integration test included.

@eukreign Ready for review


Add Symfony CLI support to FS.

FS no longer includes specific configurations.
Instead, create a personal repository like fs-php that you can clone to the root of FS.


Refactor ibis table import path

Description
fix #1675

Related Issues

Checklist

[ ] Is this code covered by new or existing unit tests or integration tests?
[ ] Did you run make unit-testing and make integration-testing successfully?
[ ] Do new classes, functions, methods and parameters all have docstrings?
[ ] Were existing docstrings updated, if necessary?
[ ] Was external documentation updated, if necessary?

Additional Notes or Comments

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (34830a7) 80.33% compared to head (bbbbe27) 80.29%.
Report is 1388 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1677      +/-   ##
==========================================
- Coverage   80.33%   80.29%   -0.05%
==========================================
  Files          95      119      +24
  Lines        6602     8414    +1812
==========================================
+ Hits         5304     6756    +1452
- Misses       1298     1658     +360

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Change example comment to not mention "Write" and add New- / Write-GCSObject example [userstudy]

Solved in https://github.com/GoogleCloudPlatform/google-cloud-powershell/pull/244


Opening a file with LightTable (Open With)

Opening a file in my file manager (Thunar) and using Open With on LightTable does not show the file, but instead just opens LightTable.

I just compiled the latest git-version and there is still no way to open a file with lighttable from a filemanager in linux. This is an essential function.
There is also no way to "drag and drop" files into lighttable.


Fix LCSC datasheets

LCSC recently switched their datasheet links on the main product page to point to a PDF view with an ordering panel to its side. So the datasheet that now gets downloaded by the tool is actually html with .pdf extension. Please update the crawler to actually download the embedded pdf from the site instead of just the HTML.
Edit: The filename of the pdf itself seems to stay consistent from the link in the product page to the actual file, so just the domain and path need to be replaced, e.g.
For product page https://www.lcsc.com/product-detail/Monitors-Reset-Circuits_LOWPOWER-LP5300B6F_C387703.html, with "datasheet" link https://datasheet.lcsc.com/lcsc/1912111437_LOWPOWER-LP5300B6F_C387703.pdf the actual pdf can be found at https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/1912111437_LOWPOWER-LP5300B6F_C387703.pdf

Thanks for reporting and also for presenting the fix right away! ^^

For product page https://www.lcsc.com/product-detail/Monitors-Reset-Circuits_LOWPOWER-LP5300B6F_C387703.html, with "datasheet" link https://datasheet.lcsc.com/lcsc/1912111437_LOWPOWER-LP5300B6F_C387703.pdf

Hm I do actually seem to be getting a download redirect from that link too, but I guess the download function doesn't properly pick that up.
I'm replacing "//datasheet.lcsc.com/" with "//wmsc.lcsc.com/wmsc/upload/file/pdf/v2/" in LCSC datasheet urls now, could you quickly confirm that this works as intended and fixes the issue?

Tried it with the example I gave above with current git master and it works now, thanks for the quick fix!

Perfect, thanks for confirming!


feat: Only accept barcodes detected on half-top of the camera image

Will fix #1930
Demo :
https://user-images.githubusercontent.com/246838/172691656-6a9c6bbc-5daf-4433-92d2-9889d95a9501.mp4

Same comment as in the other PR, are we comfortable doing this already

I think we can be now, as the results are far better than a few days ago


define a list of users for this app to present and get feedback during dev cycles

Think of users who can beta test this app, either real musicians or people who can pose as venues (for example the venue can be 'house gig at the lake')


[Snyk] Upgrade org.eclipse.microprofile.config:microprofile-config-api from 3.0.2 to 3.0.3

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade org.eclipse.microprofile.config:microprofile-config-api from 3.0.2 to 3.0.3.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 5 months ago, on 2023-04-06.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Sorry this was not supposed to be submitted.


ported particle sub-emission to 2D

Was much simpler than expected, and seems to be working mostly perfectly.  The bug described in #56886 is also present in 2D, but I'm not currently familiar enough with glsl to fix it right now.
Edit: Forgot to add, I wasn't sure if the z axis of the Transform3D required for particle emission had any effect in 2D, so I made the registered function take in a Transform2D and a Vector2. I can change that as soon as possible if required.

fixed style.

Updated Documentation.

I may messed something up with the github interface, but I think I squashed the generated commits correctly.

Thanks!

Thanks! And congrats for your first merged Godot contribution :tada:

Hi, does this PR fixes https://github.com/godotengine/godot/issues/50453 ?

Hi, does this PR fixes #50453 ?

It doesn't seem to, there's no change in behavior.


Use a CPP Cassandra driver

Note to self:

Add a migration unit test setup similar to what @mrvisser  did for the CQL2 -> CQL3 migration?
A script that will seed the test keyspace with a production dump of the schema, then do the migration, then run the unit tests overtop of it


Adding MIT License for application.

Simple license file been added with MIT license.

Coverage remained the same when pulling 21c613b53936b091ef749cfbc0f00de4223e0428 on travisjwarren:master into 155e720f1334b9c97e5894c438329a1579d59cda on teamtemp:master.

Should we add a license comment to each file too? Don't want to go overboard and add the whole license to each file - something like
http://programmers.stackexchange.com/a/85360

I'm leaning towards no.  Think it is enough to cover licencing for the application itself.


Update Mapbox cassettes to support city-only geocoding queries

Fixes #173
Note that mapbox has removed any notion of country_code from their responses :(

:+1:

:+1:

Sorry for the late response.