Add max weight matching function

This commit adds a new python function max_weight_matching() for
computing the maximum-weighted matching of a PyGraph object. The
implementation of this function is based on “Efficient Algorithms for
Finding Maximum Matching in Graphs”, Zvi Galil, ACM Computing Surveys,
1986. [1] It is basically a porting of the networkx implementation of
the algorithm [2] with some additional inspiration from the prototype for
the networkx version (it's basically the same code but some aspects were
a bit clearer to figure out from the prototype rather than networkx's
copy of it). [3][4]
Fixes #216
[1] https://dl.acm.org/doi/10.1145/6462.6502
[2] https://github.com/networkx/networkx/blob/3351206a3ce5b3a39bb2fc451e93ef545b96c95b/networkx/algorithms/matching.py
[3] http://jorisvr.nl/article/maximum-matching
[4] http://jorisvr.nl/files/graphmatching/20130407/mwmatching.py
TODO:

[ ] Fix test failures
[ ] Change output from function to be set of tuples for each matching pair instead of dict?

Pull Request Test Coverage Report for Build 494496231

584 of 590 (98.98%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.6%) to 95.484%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/max_weight_matching.rs
579
585
98.97%

Totals

Change from base Build 486512206:
0.6%

Covered Lines:
3679

Relevant Lines:
3853

💛  - Coveralls

Pull Request Test Coverage Report for Build 494496231

584 of 590 (98.98%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.6%) to 95.484%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/max_weight_matching.rs
579
585
98.97%

Totals

Change from base Build 486512206:
0.6%

Covered Lines:
3679

Relevant Lines:
3853

💛  - Coveralls

This is ready to review now. The only open question is on the return format. Right now it is returning a dict but networkx returns a  set of the  matching nodes. It's not hard to adjust it, but I'm not sure what people think is a better choice.

This is ready to review now. The only open question is on the return format. Right now it is returning a dict but networkx returns a  set of the  matching nodes. It's not hard to adjust it, but I'm not sure what people think is a better choice.

It might be good to add a unit test to compare results of networkx and retworkx with random graphs.

It might be good to add a unit test to compare results of networkx and retworkx with random graphs.

It might be good to add a unit test to compare results of networkx and retworkx with random graphs.

Sure, I added a couple of tests to do that in: https://github.com/Qiskit/retworkx/pull/229/commits/308c82a831ed73d963925af22545e199db00b895

It might be good to add a unit test to compare results of networkx and retworkx with random graphs.

Sure, I added a couple of tests to do that in: https://github.com/Qiskit/retworkx/pull/229/commits/308c82a831ed73d963925af22545e199db00b895

Thank you for this great job. I've just started to read but not yet completed. I have one question so far. Is there any reason to use endpoints data structure instead of vertex pairs? (Is it just for performance?)

It was actually to keep the data structures a bit simpler, i haven't done any performance on it. When I first went to port the function from networkx I found keeping track of the more complex (and dynamic) data structures that networkx is using hard to do (mostly because there are a lot of different things to keep track of) in a way that is statically defined. This was actually the piece that I borrowed from the prototype version (which looks like itself was ported from old C code) that I mentioned in the commit message vs the networkx version, is using lists/Vecs. My thinking was we could start with this flatter but more verbose approach and then make iterative improvements to simplify things with more complex types over time.

Thank you for this great job. I've just started to read but not yet completed. I have one question so far. Is there any reason to use endpoints data structure instead of vertex pairs? (Is it just for performance?)

It was actually to keep the data structures a bit simpler, i haven't done any performance on it. When I first went to port the function from networkx I found keeping track of the more complex (and dynamic) data structures that networkx is using hard to do (mostly because there are a lot of different things to keep track of) in a way that is statically defined. This was actually the piece that I borrowed from the prototype version (which looks like itself was ported from old C code) that I mentioned in the commit message vs the networkx version, is using lists/Vecs. My thinking was we could start with this flatter but more verbose approach and then make iterative improvements to simplify things with more complex types over time.

I think there is a subtle bug in here. I've been playing with adding more tests comparing retworkx's output with networkx's per @t-imamichi's suggestion and I'm seeing failures with some cases of different seeds. For example, I modified test_gnp_random_against_networkx to sweep the seed from 42 to 1066 with:
     def test_gnp_random_against_networkx(self):
-        rx_graph = retworkx.undirected_gnp_random_graph(10, .75, seed=42)
-        nx_graph = networkx.Graph(list(rx_graph.edge_list()))
-        nx_matches = networkx.max_weight_matching(nx_graph)
-        rx_match_dict = retworkx.max_weight_matching(rx_graph)
-        # Convert retworkx dict output to networkx set of tuples
-        rx_matches = {
-            (u, v) for (u, v) in set(map(frozenset, rx_match_dict.items()))}
-        self.assertEqual(nx_matches, rx_matches)
+        for i in range(1024):
+            rx_graph = retworkx.undirected_gnp_random_graph(10, .75,
+                                                            seed=42 + i)
+            nx_graph = networkx.Graph(list(rx_graph.edge_list()))
+            nx_matches = networkx.max_weight_matching(nx_graph)
+            rx_match_dict = retworkx.max_weight_matching(rx_graph)
+            # Convert retworkx dict output to networkx set of tuples
+            for (u, v) in set(map(frozenset, rx_match_dict.items())):
+                if (u, v) not in nx_matches:
+                    if (v, u) not in nx_matches:
+                        self.fail("seed %s failed. Element %s and it's "
+                                  " reverse %s not found "
+                                  "in networkx output.\nretworkx output: %s"
+                                  "\nnetworkx output: %s" % (
+                                      42 + i, (u, v), (v, u), rx_match_dict,
+                                      nx_matches))

and it fails first on seed 604. I also tried using the gnm random graph method instead of the gnp one and hit similar failures.
I'm also seeing issues in my attempt to use this in ignis (see: Qiskit/qiskit-ignis#552) which are likely related to the implementation here.
I'm going to push these test cases up so we block this on fixing whatever is causing things to fail.

I think there is a subtle bug in here. I've been playing with adding more tests comparing retworkx's output with networkx's per @t-imamichi's suggestion and I'm seeing failures with some cases of different seeds. For example, I modified test_gnp_random_against_networkx to sweep the seed from 42 to 1066 with:
     def test_gnp_random_against_networkx(self):
-        rx_graph = retworkx.undirected_gnp_random_graph(10, .75, seed=42)
-        nx_graph = networkx.Graph(list(rx_graph.edge_list()))
-        nx_matches = networkx.max_weight_matching(nx_graph)
-        rx_match_dict = retworkx.max_weight_matching(rx_graph)
-        # Convert retworkx dict output to networkx set of tuples
-        rx_matches = {
-            (u, v) for (u, v) in set(map(frozenset, rx_match_dict.items()))}
-        self.assertEqual(nx_matches, rx_matches)
+        for i in range(1024):
+            rx_graph = retworkx.undirected_gnp_random_graph(10, .75,
+                                                            seed=42 + i)
+            nx_graph = networkx.Graph(list(rx_graph.edge_list()))
+            nx_matches = networkx.max_weight_matching(nx_graph)
+            rx_match_dict = retworkx.max_weight_matching(rx_graph)
+            # Convert retworkx dict output to networkx set of tuples
+            for (u, v) in set(map(frozenset, rx_match_dict.items())):
+                if (u, v) not in nx_matches:
+                    if (v, u) not in nx_matches:
+                        self.fail("seed %s failed. Element %s and it's "
+                                  " reverse %s not found "
+                                  "in networkx output.\nretworkx output: %s"
+                                  "\nnetworkx output: %s" % (
+                                      42 + i, (u, v), (v, u), rx_match_dict,
+                                      nx_matches))

and it fails first on seed 604. I also tried using the gnm random graph method instead of the gnp one and hit similar failures.
I'm also seeing issues in my attempt to use this in ignis (see: Qiskit/qiskit-ignis#552) which are likely related to the implementation here.
I'm going to push these test cases up so we block this on fixing whatever is causing things to fail.

I've looked through all lines comparing with [4] http://jorisvr.nl/files/graphmatching/20130407/mwmatching.py
Excuse me, I couldn't find the lines that causes the test failure.

Yeah, I tested mwatching.py for one of the failure cases and it has identical output to this PR. So I think I ported the bug from there, I'll have to compare it to networkx to see where things are diverging.

Regarding output, I personally think set of tuples for each matching pair would be preferable.

Ok, I'll convert it to a set of tuples then. I have a local patch that does this. The only issue I had when doing this was the reverse ordering (u, v) vs (v, u) compared to networkx.

I've looked through all lines comparing with [4] http://jorisvr.nl/files/graphmatching/20130407/mwmatching.py
Excuse me, I couldn't find the lines that causes the test failure.

Yeah, I tested mwatching.py for one of the failure cases and it has identical output to this PR. So I think I ported the bug from there, I'll have to compare it to networkx to see where things are diverging.

Regarding output, I personally think set of tuples for each matching pair would be preferable.

Ok, I'll convert it to a set of tuples then. I have a local patch that does this. The only issue I had when doing this was the reverse ordering (u, v) vs (v, u) compared to networkx.

I've checked the seed 604 test case, and confirmed that retworkx just select a different maximum matching from that by networkx (there are several maximum matchings in the graph instance). So this may not be a bug. Maybe it comes from the subtle difference between [4] and networkx.
retworkx output: {3: 9, 7: 2, 0: 4, 6: 8, 9: 3, 1: 5, 2: 7, 4: 0, 5: 1, 8: 6}
= {(0, 4), (2, 7), (5, 1), (6, 8), (9, 3)}
networkx output: {(0, 4), (2, 7), (9, 5), (8, 6), (1, 3)}
edge list: [(1, 0), (3, 1), (3, 2), (4, 0), (4, 1), (4, 3), (5, 0), (5, 1), (5, 2), (6, 1), (7, 0), (7, 1), (7, 2), (7, 4), (7, 5), (8, 1), (8, 3), (8, 4), (8, 6), (8, 7), (9, 0), (9, 1), (9, 2), (9, 3), (9, 4), (9, 5), (9, 6), (9, 7)]

I've checked the seed 604 test case, and confirmed that retworkx just select a different maximum matching from that by networkx (there are several maximum matchings in the graph instance). So this may not be a bug. Maybe it comes from the subtle difference between [4] and networkx.
retworkx output: {3: 9, 7: 2, 0: 4, 6: 8, 9: 3, 1: 5, 2: 7, 4: 0, 5: 1, 8: 6}
= {(0, 4), (2, 7), (5, 1), (6, 8), (9, 3)}
networkx output: {(0, 4), (2, 7), (9, 5), (8, 6), (1, 3)}
edge list: [(1, 0), (3, 1), (3, 2), (4, 0), (4, 1), (4, 3), (5, 0), (5, 1), (5, 2), (6, 1), (7, 0), (7, 1), (7, 2), (7, 4), (7, 5), (8, 1), (8, 3), (8, 4), (8, 6), (8, 7), (9, 0), (9, 1), (9, 2), (9, 3), (9, 4), (9, 5), (9, 6), (9, 7)]

I've checked the seed 604 test case, and confirmed that retworkx just select a different maximum matching from one by networkx (there are several maximum matchings in this unweighted graph instance). So this may not be a bug. Maybe it comes from the subtle difference between [4] and networkx.
retworkx output: {3: 9, 7: 2, 0: 4, 6: 8, 9: 3, 1: 5, 2: 7, 4: 0, 5: 1, 8: 6}
= {(0, 4), (2, 7), (5, 1), (6, 8), (9, 3)}
networkx output: {(0, 4), (2, 7), (9, 5), (8, 6), (1, 3)}
edge list: [(1, 0), (3, 1), (3, 2), (4, 0), (4, 1), (4, 3), (5, 0), (5, 1), (5, 2), (6, 1), (7, 0), (7, 1), (7, 2), (7, 4), (7, 5), (8, 1), (8, 3), (8, 4), (8, 6), (8, 7), (9, 0), (9, 1), (9, 2), (9, 3), (9, 4), (9, 5), (9, 6), (9, 7)]

Oh, that's interesting I hadn't considered that. I didn't really look closely at it yet and just assumed that retworkx was generating an incorrect matching. I wonder how we should proceed here then?

I've checked the seed 604 test case, and confirmed that retworkx just select a different maximum matching from one by networkx (there are several maximum matchings in this unweighted graph instance). So this may not be a bug. Maybe it comes from the subtle difference between [4] and networkx.
retworkx output: {3: 9, 7: 2, 0: 4, 6: 8, 9: 3, 1: 5, 2: 7, 4: 0, 5: 1, 8: 6}
= {(0, 4), (2, 7), (5, 1), (6, 8), (9, 3)}
networkx output: {(0, 4), (2, 7), (9, 5), (8, 6), (1, 3)}
edge list: [(1, 0), (3, 1), (3, 2), (4, 0), (4, 1), (4, 3), (5, 0), (5, 1), (5, 2), (6, 1), (7, 0), (7, 1), (7, 2), (7, 4), (7, 5), (8, 1), (8, 3), (8, 4), (8, 6), (8, 7), (9, 0), (9, 1), (9, 2), (9, 3), (9, 4), (9, 5), (9, 6), (9, 7)]

Oh, that's interesting I hadn't considered that. I didn't really look closely at it yet and just assumed that retworkx was generating an incorrect matching. I wonder how we should proceed here then?

How about checking the equality of the optimal values and the validity of the matched edges (those would be sufficient to check the correctness of the solution) in the cases when the matchings from retworkx and networkx are not equal in the test? Also it would be nice to add a similar randomized test with random edge weights in order to cover cases for weighted graphs.

Ok, sorry for the delay I've added a fallback check for the cases where networkx and retworkx return differing matchings to verify the retworkx matching is still correct (I hope I implemented it correctly). I also added a test that assigns a random integer weight to each edge.

As an aside, these tests are the slowest in the suite (taking 3-4 seconds) so I was curious where the bottleneck was and ran a profile of the test class. The slowdown is from running networkx's max_weight_matching(), but it actually gives us a good performance comparison against the retworkx version of the function being added here:

library
cumulative time (sec)
number of calls
time per call (sec)

retworkx
0.1376
5150
2.672e-05

networkx
7.146
5123
0.001395

These numbers are over the entire test class including the test methods which do not call networkx (also they have cProfile overhead which will be a bit worse for networkx because it has a deeper python call stack).


Test runner has no set_property

The used GdUnit4 version:
4.1.1 (and master)
The used Godot version:
v4.0.3.stable.official [5222a99f5]
OS including version:
MacOS Ventura 13.4 (22F66)
OpenGL API 4.1 Metal - 83.1 - Compatibility - Using Device: Apple - Apple M1
Describe the bug
I need to set a property of my scene but there is no method set_property on runner
One can use runner._current_scene.x = 9 but that is not as intended.
Steps to Reproduce
extends Node

@export var x:int = 10

and test
func test_y() -> void:
	var runner :GdUnitSceneRunner = scene_runner("res://x.tscn")

	var x :int = runner.get_property("x")
	assert_int(x).is_equal(10)

	runner._current_scene.x = 9
	x = runner.get_property("x")
	assert_int(x).is_equal(9)

	runner._current_scene['x'] = 8
	x = runner.get_property("x")
	assert_int(x).is_equal(8)

	runner.set_property("x", 7) # <==== wished for method
	x = runner.get_property("x")
	assert_int(x).is_equal(7)

Minimal reproduction project:
issue_198.zip

See PR #199

This is now superseded by #202 thus closes #201
See also #200


Easy file-tests macros

Some ideas for easier writing tests. Currently people do stuff like
- test -f $PREFIX/include/mamba/test.hpp  # [unix]
- if not %LIBRARY_PREFIX%\include\mamba\test.hpp exit 1 # [win]

which is super error prone and hard to get right.
Ideas for "files" macros:

site-packages("mamba") -> checks that pythonX.X/site-packages/ exists and has contents (at least one init.py)
pymodule("mamba") -> checks that pythonX.X/site-packages/ exists and has contents (at least one init.py)
lib("libmamba", soversion="...") -> check that at least libmamba.so / libamamba.dylib is found in lib/, additionally check for so-versions that link to that, or for windows, check that bin/libmamba.dll and lib/libmamba.lib are there
include("mamba") -> check that include folder include/mamba/ exists
include("mamba/test.hpp") -> check that file include/mamba/test.hpp` exists in package
`bin("mamba")

I am unsure about the following ones:

cmake_find("mamba") -> make sure that find_package("mamba") would work
pkgconfig("mamba") -> make sure that pkgconfig mamba works

There are probably some good ideas to support other languages and their install prefixes. I don't know where R installs to?!
We can also use qualifiers to disallow any files outside those matched by the macros, except maybe files in /share or some other data-centric directory. That would give pretty strict control over the package content.

We probably want to express this as something like
- exists:
    site-packages:
      - mamba
    pymodule:
      - mamba
    file:
       - $LIBRARY_PREFIX/some/file
    glob:
      - "**/another/file"

I agree that @mariusvniekerk suggestion seems to be more straightforward

I like the idea of the cmake_find and pkgconfig
I'm not sure an existence macro for site-packages/pymodule is a common enough use case. Most packages should have imports specified already from which you can guess which files should exist.

I believe would be better to rename site-packages to python_modules, maybe?

@chrisburr how do they specify the imports?

@chrisburr the idea would be to also check for files that should not be in the package (basically the inverse) and either strongly warn or error out if something is in there that shouldn't be. But we could totally implicitly use the imports tests to check that.
@CJ-Wright thats another test field where one can check that a python lib gets imported fine.

@wolfv There is always the option of using:
- exists:
    file:
       - $SP_DIR/mamba/__init__.py

for the one or two exceptions where importing isn't possible because it needs to have a propitiatory shared library available or something.

I think we'd need more than just checking that a single file is imported, we'd need to check that all expected files are imported properly. In the past conda-forge's recipes haven't handled this well, leading to a bunch of issues on that front (and why I went and used the files themselves rather than the import tests to determine what modules are available)

@CJ-Wright I'm not sure quite what you're referencing? In the example:
test:
  imports:
    - mamba

then roughly maps to the command python -c 'import mamba'. Is it that you want to explicitly check all submodules as well? i.e.
test:
  imports:
    - mamba
    - mamba._version
    - mamba.mamba
    - mamba.mamba_env
    - mamba.repoquery
    - mamba.utils

I believe we should not test all submodules, or at least if the maintainer wants to they can do it using a separated command
because a lot of packages they accidentally package the test as well, and on top of there are some projects which have optional dependencies, so it may result in some errors in one of the imports due to the missing of one optional dependency

Sorry, maybe I have the wrong context. I thought this was being brought up to help address the file clobbering problem, by testing that only the expected files were available and no other files got in. If this is not the goal then not testing submodules is fine, but if we are going to address the clobber issue we need to test all the files.

Well, IMO if you define a pymodule or import then you "own" that "prefix". It would also say that you are not allowed to have any other pymodules (e.g. you are not allowed to accidentally add requests). This way we could help developers prevent accidental clobbers (not deliberate ones, though).
So if you add pymodule("mamba") your package is allowed to put any files it wants under site-packages/mamba/**/* but not elsewhere.
Does that make more sense now, @CJ-Wright ? The current way of testing for positive or negative file existence in conda-build is really cumbersome and error prone.

I think that makes sense, although you will need to have the ability for carve outs, for instance for matplotlib

One other lint we could do when we have a more semantic way of testing for a shared library is to automatically strongly warn if there is no run-exports.

cmake_find("mamba") -> make sure that find_package("mamba") would work

On CMake, it would be convenient to be able to both check the existence of a CMake package, and of the CMake imported targets, something like:

cmake_find("Eigen3", "Eigen3::Eigen")

This is particular convenient for packages that automatically disable some targets if the dependency is not correctly found.


Segmentation - Incorrect IoU being printed on master process

https://github.com/pytorch/vision/blob/96950a5cff2cf3ebee1b91cd3fbafe086d54c9c5/references/segmentation/utils.py#L91
The expected behavior of this line is to all-reduce self.mat in-place. However, the reduce_across_all_processes method creates a copy of the tensor (https://github.com/pytorch/vision/blob/96950a5cff2cf3ebee1b91cd3fbafe086d54c9c5/references/segmentation/utils.py#L297) and runs the allreduce on that copy. Thus self.mat is not updated and the master process prints incorrect IoUs.
I guess this is a potential fix -
self.mat = reduce_across_processes(self.mat).to(torch.int64)
PR - https://github.com/pytorch/vision/pull/7916 attempts to fix this.

Fixed in https://github.com/pytorch/vision/pull/7916, thanks for the report and for the fix @siddharth9820


Allow http namespacing in the url

Your issue may already be reported!
Please search on the issue tracker before creating one.
Expected Behavior

I would like the ability to set the root url path for the service so that it doesn't pollute the / path on the load balancer. something like https://domain.com/gotenberg/convert/html would be helpful since I do service discovery via url paths.
Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Logs (LOG_LEVEL="DEBUG")

Context

Your Environment

Version used:
Operating System and version:
Link to your project:

Hello @ecasilla
It should be quite easy to implement!
What kind of load balancer are you using?
Does the service discovery via URL path a common practice?

So for aws alb when using ECS you can say anything for api/v1/service_name_a goes to this cluster and for api/v1/service_name_b goes to this cluster


re-enable IE11 testing when issues are resolved

Testing in IE11 currently fails, most likely related to this issue:
https://github.com/Polymer/polymer-cli/issues/779
The actual "" errors seem to just be a warning and a red herring, but underling Object doesn't support this action issues persist when visiting test/index.html.

Closing since IE11 is 💀

Closing since IE11 is 💀


Added possible fix for pkg install on El Capitan.

El Capitan is the first version of OS X to not have root, and locations that are not writable, one of which is /usr/bin. The previous version of the foreman installation package relied upon the fact that this was
writeable, and thus it failed on the new version of the OS.
This PR should, in theory, fix this issue, but I found no way to build the pkg myself.

If this works, it might need some more documentation though, since /usr/local/bin isn't usually in $PATH

what will happen now please? I would like to see foreman working on captain

@ddollar should I close this?

Thanks!

Fixed by #585

@ddollar no problem! thanks for taking the time to merge this :)


bug: Minor Issue

Describe the bug
It appears that cp doesn't exist in fs/promises anymore.
To Reproduce

Install the CLI first obviously.
Run sapphire init or any command really.

Expected behavior
Node should shout at your console with the stack trace that cp doesn't exist in fs/promises anymore.
Screenshots

Additional context

used node v16.6.1
used npm v8.1.3

OOPS I showed the wrong command in the shot. Here's the real one:

CLI requires node 16.7 and higher. Update your node.

CLI requires node 16.7 and higher. Update your node.

Thanks. Closing this with disappointment because I can't seem to install this on my pc now.


Faster builds / fix MUI & turf imports

update typescript and react-scripts
start fixing material imports to avoid unnecessary type checking at compile time

Overview
This PR includes the following proposed change(s):

{List all the changes, if possible add the linked issue/ticket #}

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Refactoring / Documentation
[ ] Version change

if your change is a breaking change, please add breaking change label to this PR
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Screenshots
Please add any relevant UI screenshots if applicable.
Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[ ] New and existing unit tests pass locally with my changes

/rebase


Fix redirecting in mobile browsers

kind of bug around auth

https://github.com/nextauthjs/next-auth/issues/6435


Release on conda-forge

It would be great to be able to use this inside a reproducible conda environment. It can be pip installed in the conda environment but that's not ideal.
I can help with this too. cc @cab938

@aktech Thank you for bringing this up! If you have time to work on this it would be great!

We haven't done a conda forge release yet @aktech, so if you have tips on
how to put this together (or a PR!) they would be welcomed!
On Tue, Dec 5, 2023 at 3:20 PM mengyanw @.***> wrote:

CAUTION: External to USask. Verify sender and use caution with links and
attachments. Forward suspicious emails to @.***
@aktech https://github.com/aktech Thank you for bringing this up! If
you have time to work on this it would be great!
—
Reply to this email directly, view it on GitHub
https://github.com/educational-technology-collective/jupyterlab-pioneer/issues/30#issuecomment-1841488550,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKK66J3PELYF3B33OOYUGLYH5ZAJAVCNFSM6AAAAABAHCOMAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGQ4DQNJVGA
.
You are receiving this because you were mentioned.Message ID:
<educational-technology-collective/jupyterlab-pioneer/issues/30/1841488550
@github.com>

--
Christopher Brooks
Associate Professor, School of Information
E-Mail: @.***
Web: http://christopherbrooks.ca
Lab: http://edtech.labs.si.umich.edu
School of Information
University of Michigan
4439 North Quad
105 S. State St.
Ann Arbor, MI 48109-1285

I have created a PR for conda-forge release here: https://github.com/conda-forge/staged-recipes/pull/24685
If you guys wish to and are happy to be added as recipe maintainers, I can add your handles their, you'd have to comment on the PR after that.

Thank you! @aktech We are willing to be added.

Awesome, added: https://github.com/conda-forge/staged-recipes/pull/24685#issuecomment-1843241900

@cab938 you'd also need to comment on the above mentioned pull request, to approve consent to be added.


Subtitle on auth dialogs should be different depending on use case

Task/Issue URL: https://app.asana.com/0/1203115518054842/1204258140066144/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #2926

PR #3005   👈
PR #3004
PR #2959
PR #2936
PR #2934
PR #2933
PR #2932
PR #2956
PR #2929
PR #2928
PR #2927
PR #2995
PR #2947
PR #2946
PR #2945
PR #2944
PR #2981

This comment was auto-generated by Graphite.


fix: cannot download redirect url

handle redirect on DownloadConnection layer

Codecov Report

Merging #180 into master will increase coverage by 0.11%.
The diff coverage is 89.47%.

@@            Coverage Diff             @@
##           master     #180      +/-   ##
==========================================
+ Coverage   83.17%   83.28%   +0.11%
==========================================
  Files          64       64
  Lines        3786     3817      +31
  Branches      615      615
==========================================
+ Hits         3149     3179      +30
- Misses        369      370       +1
  Partials      268      268

Impacted Files
Coverage Δ

...lishuo/okdownload/core/download/DownloadChain.java
92% <100%> (ø)
:arrow_up:

...ulishuo/okdownload/core/download/DownloadCall.java
79.78% <100%> (+0.11%)
:arrow_up:

.../main/java/com/liulishuo/okdownload/core/Util.java
83.6% <100%> (+0.18%)
:arrow_up:

...in/java/com/liulishuo/okdownload/DownloadTask.java
85.6% <100%> (+0.17%)
:arrow_up:

...oad/core/connection/DownloadOkHttp3Connection.java
78.26% <33.33%> (-3.14%)
:arrow_down:

...ulishuo/okdownload/core/download/ConnectTrial.java
83.17% <80%> (-0.32%)
:arrow_down:

...in/java/com/liulishuo/okdownload/RedirectUtil.java
83.33% <83.33%> (ø)

...ownload/core/connection/DownloadUrlConnection.java
90.24% <94.44%> (+5.93%)
:arrow_up:

Continue to review full report at Codecov.

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


[WIP] Add first pass at setting global server settings

We don't have current functionality for setting a server setting once for all servers.
It's probably all going to be wrong, but we have to start somewhere.
I'll link the issue when I'm more sure that this is the right approach  which honestly might not be ever — as Joe said, the downside of this is that it  requires that we push out this server setting change for each new server added to an environment.

@miq-bot assign @jrafanie

The thing about this approach is it's a net +3 lines in the existing script and we get to delete the old script.  I don't see any feature we lose.  The only downside is we aren't setting it at a zone/region level, so you need to do it for any new servers but that was the case for the old script.
We should link to #19747 and have @evertmulder review this to ensure it handles the existing use cases.  Also, is the issue you were trying to fix in #19441 also a problem with this PR's approach?

@evertmulder any chance you might be able to address https://github.com/ManageIQ/manageiq/pull/19848#issuecomment-588391511 please?

Why does this set it server by server as opposed to setting it at the region level once?

Because I liked option two better: https://github.com/ManageIQ/manageiq/issues/19747#issue-553789463

I don't like option 2 specifically because it doesn't account for new servers.  The only con there that seems to make sense is that you have to deal with servers that have the value already overwritten, but that is handled already via the magic settings keywords (I think it's <enforce>, but I'd have to check)

I don't like option 2 specifically because it doesn't account for new servers.

It's replacing tools/server_settings_replicator/server_settings_replicator.rb , which also didn't account for new servers, and the code added was so trivial, I was fine with doing this for now especially due to the following...

The only con there that seems to make sense is that you have to deal with servers that have the value already overwritten, but that is handled already via the magic settings keywords ~(I think it's <enforce>, but I'd have to check)~

Are you able to edit/view settings for region/zone in the UI/api?  For example, if you blasted a value for a region/zone and wanted to confirm it in the UI/api, I'm not sure if that's easy to do.   I know it works in the backend but if it's not in the UI/api, it might make sense to do a more equivalent replacement script while we determine what's missing in the region/zone settings work.

Are you able to edit/view settings for region/zone in the UI/api?

Yes.  You can view and edit the settings at any level.  API can also do it at any level.

Are you able to edit/view settings for region/zone in the UI/api?

Yes. You can view and edit the settings at any level. API can also do it at any level.

TMYK.  Cool.  I'll have to review it with @d-m-u @yrudman as I think he implemented some of it.  I'm not sure how to view settings at the region/zone level.
Before this PR, we had 2 scripts saving server based settings:
tools/server_settings_replicator/server_settings_replicator.rb
tools/configure_server_settings.rb

After this PR, we have most if not all of the former's features by adding 3 lines to the latter.  I question if we should first deprecate the former script but nevertheless, it's a surgical replacement.
We can implement blasting region/zone settings later on to solve the problem of having to update settings to new servers but my hope was first to remove the nearly duplicate script first.  Also, region/zone settings isn't a direct replacement of the former script so I thought this would be easier to take in steps.

Add first pass at setting global server settings

Maybe let's rename this PR to "Consolidate existing server setting CLI tools".  This PR's intention was to de-duplicate our existing scripts down to one tool to set server settings.  It doesn't prevent us from adding zone/region setting support.

@miq-bot add_label jansa/yes

Jansa backport details:
$ git log -1
commit 4c90e011031726f0bd979713fa514b51599a4682
Author: Joe Rafaniello<EMAIL_ADDRESS>Date:   Fri Mar 27 09:56:59 2020 -0400

    Merge pull request #19848 from d-m-u/adding_option_to_copy_server_settings_pass_one

    Consolidate existing server setting CLI tools

    (cherry picked from commit 7f454fc8b0fa8949df7b5de7b370b29cbc097a26)


Add support for exercises/TRACK_HINTS.md in trackler

Helping out with exercism/exercism.io#3240

Add support for exercises/TRACK_HINTS.md in trackler (without deleting support for SETUP.md)

SETUP.md is a terrible name, since it sounds like it should be a one-time thing about how to set the track up. If you're doing all the exercises in a track, this will get annoying.
Instead of SETUP.md, we're going to use exercises/TRACK_HINTS.md.

This changes the track_hint() method that is used to build the READ ME to first check if the TRACKS_HINT.md file exists and if so use that in the READ ME.
I took this approach so that it could support both the SETUP and the TRACK_HINTS file until SETUP is deprecated.

Thanks @nickborromeo, I'll review this when I get a chance.

Two more tests that I think are needed are:

An explicit test for hints from SETUP.md. The fruit track has this. (It's not technically your problem, but would be useful to add in while we're working in the area.)
The content of a SETUP.md present on the sports track is not included. (This would make test_readme_uses_track_hint_instead_of_setup make sense as a test name)


Feature Request: APPEND -> INSERT

A nice feature would be, to refactor the APPEND statements into the INSERT version, to be independant from table types.
" Old version
APPEND ls_structure TO lt_table.
APPEND VALUE #( field = '' ) TO lt_table.

" New version
INSERT ls_structure INTO TABLE lt_table.
INSERT VALUE #( field = '' ) INTO TABLE lt_table.

Should also be formatted with VALUE rules.

Could be an optional thing, appending entries to the end work fine with standard tables and empty keys. The use of the simple appends are very rare. This will help most people migrating their code to better versions and think about correct keys for tables.

Hi Xexer and Fabian,
nice idea! I agree that this should rather be an opt-in rule (i.e. deactivated by default); but if the style guide says "Prefer INSERT INTO TABLE to APPEND TO", this is at least a good reason to offer such a rule!
Kind regards,
Jörg-Michael

There are however two pitfalls, when converting APPEND to INSERT:

By sorted tables with non-unique key appended lines are in the appending order, while inserted lines are in the reverse order.

TYPES: BEGIN OF line,
  number TYPE i,
  description TYPE string,
END OF line.

DATA sorted_table TYPE SORTED TABLE OF line WITH NON-UNIQUE KEY number.

APPEND VALUE #( number = 1  description = `Will be third` ) TO sorted_table.
APPEND VALUE #( number = 1  description = `Will be fourth` ) TO sorted_table.

INSERT VALUE #( number = 1  description = `Will be second` ) INTO TABLE sorted_table.
INSERT VALUE #( number = 1  description = `Will be first` ) INTO TABLE sorted_table.

By character lines APPEND writes from left to right ignoring the structure. By INSERT (and in both cases when using VALUE) inappropriate structure leads to an syntax error.

TYPES: BEGIN OF line_a,
  component_1 TYPE c LENGTH 2,
  component_2 TYPE c LENGTH 4,
END OF line_a,
BEGIN OF line_b,
  component_1 TYPE c LENGTH 4,
  component_2 TYPE c LENGTH 2,
END OF line_b.

DATA: structure_a TYPE line_a,
      table_b     TYPE STANDARD TABLE OF line_b.

structure_a-component_1 = '11'.
structure_a-component_2 = '2222'.

APPEND structure_a TO table_b.

I've seen too much code working with unsorted table types and expecting the table entries to be appended. Such a rule wouldn't be useful to me as it would be too risky. I hope you'll get some use out of it though 🙂

I've seen too much code working with unsorted table types and expecting the table entries to be appended. Such a rule wouldn't be useful to me as it would be too risky. I hope you'll get some use out of it though 🙂

But for standard (=unsorted?) tables there is no difference, both instructions do the same, don't they?

But for standard (=unsorted?) tables there is no difference, both instructions do the same, don't they?

You're right. Here's a quote from the documentation:

For standard tables, each new row is appended as the last row in the internal table regardless of the primary table key.

I don't know why I thought it did something else? 😅 I guess I could actually get some use out of the suggested rule.

Hi Xexer and Fabian,
nice idea! I agree that this should rather be an opt-in rule (i.e. deactivated by default); but if the style guide says "Prefer INSERT INTO TABLE to APPEND TO", this is at least a good reason to offer such a rule!
Kind regards, Jörg-Michael

As an opt-in rule, I see no reason not to do this - notwithstanding m-badura's examples.

I've been thinking; since the Clean Code style guide says:
Use APPEND TO only if you use a STANDARD table in an array-like fashion, if you want to stress that the added entry shall be the last row.
m-badura's examples refer to SORTED tables, they're not really relevant.


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/84866

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/85891

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/89467

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/105326


Feature/account onboarding

account onboarding
:gear: Release Notes
Onboarding:

Consent
Invitation
Onboarding
SequentialOnborading

Account:

Login
Register
Credential Manager

:books: Documentation
tbd
:pencil: Code of Conduct & Contributing Guidelines
By submitting creating this pull request, you agree to follow our Code of Conduct and Contributing Guidelines:

[x] I agree to follow the Code of Conduct and Contributing Guidelines.

Reviewing 🙌
Feel free to commit any time though
FYI, I will mark all @PSchmiedmayer comment's as unresolved even though you have a applied the suggestions, just for me to have a better overview of the discussions :)


fixing the issue that caused "has_top_container" always to be false

The problem in the original was that it expected "json" to be part of the hash.  I fixed that by removing the dig method, and changing the assignment to "self.record.json['instances']".  That's all that's needed to fix the bug.
I also changed the test to "unless top_container_uri.nil?", but it should be fine to keep that as "if top_container_uri.present?" if that's preferred.

Just a note that upon more testing, I realized that this "fix" was't enough.  I'm not sure if there are configuration options yet available for this or not, but I also needed to be able to test requesting of accessions and top containers, all the while having "requests permitted for containers only" set to true.  So, although this is not the way to do it, here's how I redefined that "show_action?" method to get on with testing:
    def show_action?
        begin
            puts "Aeon Fulfillment Plugin -- Checking for plugin settings for the repository"

            if !self.repo_settings
                puts "Aeon Fulfillment Plugin -- Could not find plugin settings for the repository: \"#{self.repo_code}\"."
            else
                puts "Aeon Fulfillment Plugin -- Checking for top containers"
                has_top_container = false

                other_ways_to_request = ['accession', 'top_container'].include?(self.record.json['jsonmodel_type'])
                instances = self.record.json['instances']

                if instances
                  instances.each do |instance|
                        sub_container = instance.dig('sub_container')
                        next if !sub_container
                        top_container_uri = sub_container.dig('top_container', 'ref')
                        if top_container_uri.present? || other_ways_to_request == true
                            has_top_container = true
                        end
                    end
                end

                only_top_containers = self.repo_settings[:requests_permitted_for_containers_only] || false

                puts "Aeon Fulfillment Plugin -- Containers found?    #{has_top_container}"
                puts "Aeon Fulfillment Plugin -- only_top_containers? #{only_top_containers}"

                return (other_ways_to_request || has_top_container || !only_top_containers)
            end

        rescue Exception => e
            puts "Aeon Fulfillment Plugin -- Failed to create Aeon Request action."
            puts e.message
            puts e.backtrace.inspect

        end

        false
    end

I'll keep testing with that for now, but obviously this should be handled differently in the plugin :)
Also, I'm not sure about the usability of having the Request button disabled on archival_object pages that do not have top containers, since we'll be turning requests off for those archival_object pages.  For the time being, I also added a title attribute to that button when it's disable so that there's some hover text to encourage the user to dig a little deeper into the collection.  Something like that could be the way to go, or I could also imagine that our Aeon User Group at Yale might just want that button to disappear on those pages.

Closing this, since it has been updated in Atlas's plugin.


[Translatable] How to override default locale?

The default locale is hardcoded as 'en' in TranslatablePropertiesTrait, however sometimes the default is something else, e.g. en-GB, or nl, etc.
What is the best way to override this (for example, from services.yaml or some other config, not code), so that in whatever way translatable entities are created/fetched, they will have that default locale?
Changing the defaultLocale after instantiation does not work, as earlier the default is used to set the currentLocale.

The defaultLocale is configured by the TranslatableSubscriber, here:
https://github.com/KnpLabs/DoctrineBehaviors/blob/master/src/EventSubscriber/TranslatableSubscriber.php#L177-L180
And if you take a look at [LocaleProvider#provideFallbackLocal()](https://github.com/KnpLabs/DoctrineBehaviors/blob/master/src/Provider/LocaleProvider.php#L61-L77), it will use locale from:

current request, if it exists
from parameter locale, if it exists
from parameter kernel.default_locale, if it exists

Right thanks!
Also not sure if this is very relevant, but I only now discovered that the translate fallback is about falling back from en_GB to en for example, not falling back to the default locale.  🤷♂ I guess that makes sense, it's just my mental model was different.

Hi, I'm going through old opended issues and PRs to cleanup too-long-opened items and close them. Thank you for your contribution and time.
We needs a feature with test and passing CI to be able to merge it without letting a bug in.
If this is still relevant for you, please add code with test and make CI pass first. Then we'll able to merge your feature without further waiting :+1:
Thank for understanding.


Short URL for Share function

Should be able to generate bitly short URLs?

The max URL length bitly accepts is only 2048 characters.
We will skip adding this function for now.


[VSCode] Add icon to indicate Razor extension is active and running.

We should add a Razor icon that indicates we're active and also enables users to view the generated C# and generated HTML at the bottom of the IDE to assist in debugging issues once we ship an alpha.

@NTaylorMullen I tagged this as VSCode although the original issue didn't specify. If this is wrong, please feel free to change

Closing this out. Commands exist for showing generated code, and we're not an optional runtime component any more.


Swap Hands reload doesn't work

Current/Expected Behavior
So basically, reload perfectly works when you use Drop item for reload, but do not work when you use Swap hands as a reload button, it just starts reloading and stops at the last millisecond and cancels the reloading. I guess that fixing #462 is the reason
Steps To Reproduce
Use Swap_hands as reload button
Log File
No errors
Anything else?
Sorry for my mistakes in grammar if there is some, not fluent in english

Did some research on that, it is actually because of some Folia patches in 3.5.0
Here's the changelog between 3.4.14 and 3.5.0
(https://github.com/WeaponMechanics/MechanicsMain/compare/v3.4.14...v3.5.0)
SWAP_HANDS trigger is working fine in 3.4.14, just tested that

awesome, thanks!

v3.5.4, it still can't work at 1.21.1

v3.5.4, it still can't work, just starts reloading and stops at the last millisecond and cancels the reloading

gonna test this real quick


Exception caught by gesture

I have a button , I want when I tapped call a function in another class , to calculate some values and return a value and saved in .. but it keeps give me error ..
here is the function
double snacks_calories_calculate(double f_calories , double quantity)
  {
    double result = f_calories * quantity ;
    return result ;
  }

  double calculate_meal(meal_type meal, double f_calories , double quantity)
  {  double meal_result =0 ;
    switch(meal)
    {
      case meal_type.Breakfast : meal_result = breakfast_calories_calculate(f_calories, quantity);
      break ;
      case meal_type.Launch:
       meal_result =   launch_caloreis_calculate(f_calories, quantity);
        break;
      case meal_type.Dinner:
       meal_result =  dinner_calories_calculate(f_calories, quantity);
        break;
      case meal_type.Snacks:
        meal_result = snacks_calories_calculate(f_calories, quantity);
        break;
    }
    return meal_result ;
  }

and here is my code for tapping a button
class createButtons extends StatelessWidget {
  @override
  Widget build(BuildContext context) {

    return  Container(
     //margin: EdgeInsets.all(0),
      child: IconButton(
        icon: Icon(iconData,color: Colors.teal[700],),
        onPressed: (){
         increment();
        },
      ),
    );
  }

void increment(){
    setState(() {
      quantity = quantity +1;

     total=  meals_calculator.calculate_meal(selected_meal,
         f_element.food_calorie_per_gram['food_calorie'] , quantity);
    });
 }

I tried to call the function with static numbers , like this call
void increment(){
    setState(() {
      quantity = quantity +1;
     //total = f_element.food_calorie_per_gram['food_calorie']*quantity ;
     total=  meals_calculator.calculate_meal(selected_meal,
          3, 3);
    });

and it works , but i don't know why don't work with first one , it keeps telling me and show me this message
Handler: "onTap"
Recognizer: TapGestureRecognizer#c5955
  debugOwner: GestureDetector
  state: ready
  won arena
  finalPosition: Offset(321.1, 197.3)
  finalLocalPosition: Offset(33.8, 10.6)
  sent tap down

════════════════════════════════════════════════════════════════════════════════════════════════════

════════ (2) Exception caught by gesture ═══════════════════════════════════════════════════════════
type 'int' is not a subtype of type 'double'

I also tried to parse the value , like this
  total=  meals_calculator.calculate_meal(selected_meal,
          double.parse( f_element.food_calorie_per_gram['food_calorie']), quantity);

Can anyone help me please ?

Hi @sunaarun
This platform is not met for assistance on personal code.
Please see https://flutter.dev/community for resources for asking questions like this,
you may also get some help if you post it on Stack Overflow.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it
Thank you

Hey @iapicca  .. Thank you for your reply ..
I found the problem .. yes it wasn't about flutter .. I t was about the function that I called when i tapped ..   I found where the issue ..
Thank you
double calculate_meal(meal_type meal, double f_calories , double quantity)   {  double meal_result =0 ;     switch(meal)     {       case meal_type.Breakfast : meal_result = breakfast_calories_calculate(f_calories, quantity);       break ;       case meal_type.Launch:        meal_result =   launch_caloreis_calculate(f_calories, quantity);         break;       case meal_type.Dinner:        meal_result =  dinner_calories_calculate(f_calories, quantity);         break;       case meal_type.Snacks:         meal_result = snacks_calories_calculate(f_calories, quantity);         break;     }     return meal_result ;   }

I'm glad that you solved the issue @sunaarun

Hey @iapicca .. Thank you for your reply ..
I found the problem .. yes it wasn't about flutter .. I t was about the function that I called when i tapped .. I found where the issue ..
Thank you
double calculate_meal(meal_type meal, double f_calories , double quantity) { double meal_result =0 ; switch(meal) { case meal_type.Breakfast : meal_result = breakfast_calories_calculate(f_calories, quantity); break ; case meal_type.Launch: meal_result = launch_caloreis_calculate(f_calories, quantity); break; case meal_type.Dinner: meal_result = dinner_calories_calculate(f_calories, quantity); break; case meal_type.Snacks: meal_result = snacks_calories_calculate(f_calories, quantity); break; } return meal_result ; }

hey man ! could you help me how to solve it ? I got the same issue.


Text widget does not work

How can this bug be reproduced?
Add a TEXT widget to the footer widgets area... or sidebar widgets area
What did you expect to happen?
For me to be able to use a text widget with standard text...
What happened instead?
When you click save, the content entered disappears and no information is saved.
Please List the Following:

OS & version:
Node version (node -v) [Node v6+ is required] :
FoundationPress version (see line 3 in package.json):
2.10.5
Foundation version (found in node_modules/foundation-sites/package.json) :
<EMAIL_ADDRESS>

I've had the same problem with the text widget.
I added another widget & then both appeared.
Delete the text widget & the other widget remains, but again, I cannot re-add the text widget,


Replace data files and parameters with values from PAGE-ICE

I only replaced files and parameters that exactly corresponded to the current code in PAGE09, and I drew these from the NDC scenario from PAGE-ICE.  (The choice of scenario won't matter once we model scenarios within mimi-page-2020, but it's useful now for unit testing.)

I haven't looked at all changes yet, but one thing I noticed when I glanced over it is how 'e_0globalCH4emissions' in CH4cycle.jl was changed to 1803.0 (I think accidentally the ppbv value was taken here too) rather than the ~371 Mtonne (in PAGE-ICE: [Base data:G35] ) that I think it should be.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@cbb4053). Click here to learn what that means.
The diff coverage is 0%.

@@           Coverage Diff           @@
##             master    #16   +/-   ##
=======================================
  Coverage          ?   7.4%
=======================================
  Files             ?     31
  Lines             ?    621
  Branches          ?      0
=======================================
  Hits              ?     46
  Misses            ?    575
  Partials          ?      0

Impacted Files
Coverage Δ

src/components/CH4cycle.jl
0% <ø> (ø)

src/components/Discontinuity.jl
43.47% <ø> (ø)

src/components/GDP.jl
12.5% <ø> (ø)

src/components/N2Ocycle.jl
0% <ø> (ø)

src/components/CH4forcing.jl
0% <ø> (ø)

src/components/CO2cycle.jl
0% <ø> (ø)

src/components/SeaLevelRise.jl
0% <ø> (ø)

src/components/MarketDamages.jl
0% <ø> (ø)

src/components/SLRDamages.jl
0% <ø> (ø)

src/components/LGcycle.jl
0% <ø> (ø)

... and 6 more

Continue to review full report at Codecov.

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

@jkikstra Thanks for the catch!  I've fixed that.  It probably isn't the only typo I've made in this process, but I'm trusting that the automated testing will complain about anything I've missed.  By the way, currently I've disabled most of that automated testing, on the principle that we don't expect everything to match PAGE-ICE yet anyway.

Hi @jrising , this is @jrising , and everything looks good.


HW 10.10.2016 Tests

https://github.com/derzolew/hw-tests/commit/cfcac21b7d7e6a2f691bc254ecbbb5fbccba1e6e

good


[Bug Report] Steering of the ego-vehicle fluctuates

Describe the bug
As the video below shows, steering of the ego-vehicle sometimes fluctuate while driving and it makes the vehicle eventually stop and drive again after few seconds.
To Reproduce
Steps to reproduce the behavior:

Run Apollo 7.0 and Carla-Apollo bridge following the instruction here
Set mission(starting point and destination point) for Apollo (Actually, I set each mission randomly).
After repeating the step 2, I could find the video above (I could reproduce the situation within 3 trials).

Expected behavior
The ego-vehicle successfully drives to the given destination point.
Screenshots
I got the video below:
https://github.com/ApolloAuto/apollo/assets/50267797/d1a2ad5c-3231-4613-bd13-85d13f563d4d
Also, here's the record file: link
The record file contains full record of the driving, so please check only first 25 seconds of it.
Desktop (please complete the following information):

OS: Ubuntu
Browser: Chrome and Firefox
Version 20.04.6 LTS (for ubuntu)

Additional context
In my experience, the situation does not depend on the mission(starting point and destination point), but it seems like occur while accelerating.
Also, this fluctuation occurs many times during a one driving scenario.

By the way, would you accept bug reports on the old versions of Apollo(e.g. 6.0, 7.0, ...)?
I've tried to run the most recent version(8.0) of Apollo on Carla, but it seems that they are not compatible (mainly because there's no the Carla-Apollo bridge for Apollo 8.0).
I've also tried to run Apollo 8.0 on LGSVL, but it did not work.
So I had no choice but to run the old ones. Do the bug reports on the old versions hold?

Are you using the default LQR control? I am also running the Apollo 7.0 + Carla simulation, and met with many similar control problems, including the fluctuates, vehicle stops when turning (will move again only after restart control module), vehicle drives out of lane when turning... I tried to switch to the MPC control, but the performance only gets worse.
I am trying to find the reason. One guess is that the mapping between the control command output and the actual brake/throttle message
(provided in control_conf.pb.txt) does not match the vehicle dynamic model.

Hi @PhilWallace,
Actually, I have little knowledge on Apollo, so I don't know about the control modules like LQR or MPC.. I'm just using a default one, so it would be LQR I guess.
Thank you for the insight! I also have doubt on control commands passing between Carla and Apollo. I think I should make more investigation. I'll let you know if I could get any finding.

Hello, I indeed found a mismatch problem for the vehicle model. After fixing it, the vehicle control gets much better. Please refer to https://github.com/guardstrikelab/carla_apollo_bridge/issues/110.
But it still does not fix everything. Even though the control gets better, it seems that the planning module is very likely to give a bad planning when vehicle is making turn. So it is still likely that the vehicle will collide to the roadside. However, at least it could follow the straight lane better. Maybe you can have a try.

@PhilWallace 请问你是怎么在apollo-carla-bridge生成交通流的

@PhilWallace 请问你是怎么在apollo-carla-bridge生成交通流的

I have not tried to generate traffic yet. The video with generated traffic is by @Kim-mins . Maybe he could share about how to generate traffic in Carla.
I guess it could be generated by the Python API provided in Carla docker.

Hi @fpeanut, sorry for late.
I just used the script here.
The script is for generating vehicles and pedestrians.

Hi @fpeanut, sorry for late. I just used the script here. The script is for generating vehicles and pedestrians.

Thanks for your sharing. Actually I'm also trying to generate traffic by using generate_traffic.py, but the generated vehicles does not follow traffic rules and will crash to the roadside. Did you meet similar problems? Many thanks!

@PhilWallace I'm experiencing the same issue too.. those cars also fluctuate and eventually rush to the wall. I guess they are also related to the fluctuation of Apollo car, but I don't know why.


Fix render context bug

Description
Adds a safe guard for samples which do not use the render context
Fixes #725
General Checklist:
Please ensure the following points are checked:

[x] My code follows the coding style
[x] I have reviewed file licenses
[x] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
[x] I have commented any added functions (in line with Doxygen)
[x] I have commented any code that could be hard to understand
[x] My changes do not add any new compiler warnings
[x] My changes do not add any new validation layer errors or warnings
[x] I have used existing framework/helper functions where possible
[x] My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions
[x] My changes do not add any regressions
[x] I have tested every sample to ensure everything runs correctly
[x] This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

[x] I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
[ ] My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

Sample Checklist
If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

[ ] I have tested the sample on at least one compliant Vulkan implementation
[ ] If the sample is vendor-specific, I have tagged it appropriately
[ ] I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
[ ] Any dependent assets have been merged and published in downstream modules
[ ] For new samples, I have added a paragraph with a summary to the appropriate chapter in the samples readme
[ ] For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering

Latest changes fixed copyright but also reset the approvals

Merging on two as this fixes a critical bug in the swapchain recreation sample


Add stats, improve manage page and Subspace Account format

Add stats page and Subspace Account format

Add stats page (similar to manage page without the form input and not specific to an owner account)
Improve the manage page to use on-chain data
Use the Subspace account format
Add a navigation button to reach each page

Note

I don't see any nominators currently, making it hard to add the logic to count the nominators per operator or total nominators
Similarly, I only see 1 operator on domainId 0 currently, making it hard to add the logic that filter the manage page by operator owner

Screenshot

Looks good code-wise, but the fetched stats for the domain are incorrect. The number of operators is the same, bit their IDs as well as their stake is different 🤔. I can provide you with the data for testing if needed.
As for nominators - there're none, so can't really test it atm.
Additionally, we likely need to check if the operator has been deregistered as well, before listing it on the page. E.g. operators with ID 5 and ID 6 were de-registered.

I just fix the page manage to only show the stake link to the connected wallet
For the total stake been different, currently I use currentTotalStake from operators... I see there is also totalShares but not sure if this is actually the value we want to show?
I also added the right operator id (wallet address) and % next to nominator tax


CI: Test all supported Python versions

Expanding the supported Python versions is required for https://github.com/commaai/body-jim/issues/9

Just a weird issue with Cython 3.12...

@fredyshox is it ok to bump PyAV?


[otp_ctrl] DAI and KDI interface both uses scrambling issue

Hi Michael,
I wanted to ask can DAI and KDI issue request in the same time? If that is okay, I think there is an issue.
Seq:

Issue otbn_otp_key_i
While calculating the key in DAI interface, issue cal_digest (in this sequence, is for hw_cfg partition)
Then I can see a mismatch in second 64 bits otbn output key

Issue:
In the sequence above, the scrambling module did the following thing:
Step 1. Calculate first 64 bits otbn key with key input: 1) key_seed_from_OTP 2).EDN 3).Final_constant
Step 2. Calculate second 64 bits otbn key with key input 1). key_seed_from_OTP
Step 3. Then DAI interface digest calculate request came, and scrambling module jumped to calculate digest
Step 4. When digest finished, it went back to do second key with input EDN, however, the input 64 bits data is not correct.
--> The input 64 bits are supposed to be the result from step 2, but it uses the output from step 3
I could not capture a good waveform to really show the issue (but still paste one here in case...). To see the entire waves, you can open a verdi session here:
/edascratch/chencindy-opentitan/scratch/otp_sequence_key_req/otp_ctrl-sim-vcs/0.otp_ctrl_rand_key_rsp/out
verdi -ssf waves.fsdb

Thanks,
Cindy

Hey @cindychip,
I think I understand what you're saying.
Yeah this is possible and expected to happen.
Let me take a look...

Hey @cindychip,
I think I understand what you're saying.
Yeah this is possible and expected to happen.
Let me take a look...

Looks like I forgot to hold the mutex on the scrambling datapath when requesting EDN data in the KDI. Fix is coming...

Looks like I forgot to hold the mutex on the scrambling datapath when requesting EDN data in the KDI. Fix is coming...


delete trailing period which breaks issue URL

The error which asks users to comment on #60 has a period immediately after the url, which results in the url being parsed as https://github.com/JuliaOpt/Gurobi.jl/issues/60. when displayed in, for example, IJulia. This makes it look like the issue has been removed, and might be preventing users from reporting occurrence of the bug.

Seems reasonable


fix: Increase the default timeout to 30 seconds

There were reports that 5 seconds may be a bit too short
for a default timeout.  Increase to 30 seconds.  Anything
beyond that should be considered an error, and the retry
logic should be allowed to kick in.
Semver: patch
Ref: LOG-7278
Fixes: https://github.com/logdna/logger-node/issues/15

I still believe this timeout is a bit too long for a default. Its hiding a problem. 10-15s default with exponential back-off to 30s is a bit more reasonable


Update part numbering function to match 199 spec, or change 199 spec to match numbering function

@morops can you provide more detail on the 199 spec?

See part naming convention under Design/Standards on drive. Likely to just use the 254 system, since the 199 system was assuming manual entry originally and so we decided to not do things like group parts by parent assembly.

updating 199 convention to match 254


Return JSON object from t.field resolver

Since prisma2 does not yet support JSON/B columns, I'm storing my JSON data in Posgres as a string.
This is fine, but Id like to return JSON to my consumers.
How can I change the return type of a string field to an object in my graphql schema?
The example below returns this error: "message": "String cannot represent value: {}",
I think I need to tell GraphQL that the field metadata actually returns an object now.
t.field("metadata", {
  type: "String",
  resolve(root, args, ctx) {
  const str = root["metadata"];
    if (!str) {
      return {};
    }
    return JSON.parse(str);
  }
});

Im relatively new to GraphQL and prisma, so any help is appreciated! Thanks

import { GraphQLJSONObject } from 'graphql-type-json'
import { scalarType } from 'nexus'

export const JSONScalar = scalarType({
  name: 'JSON',
  serialize: GraphQLJSONObject.serialize,
  parseValue: GraphQLJSONObject.parseValue,
  parseLiteral: GraphQLJSONObject.parseLiteral,
})


[BUGFIX] wrong action names in if-statement

This fixes wrong action names in if-statement.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/#/issues/SW-15073.
Please use this issue to track the state of your pull request.

Hi @mjosef89 and thanks for your PR.
We've got your intend and improved it by moving the setNoRender() method call into the actions. This approach is more straight forward.
Merged with 4c1081f1b9b68e856dba551be95650968a50d397.


L15 Setup script

New script that will be used in spinning up nodes of cluster and participants replacing: https://raw.githubusercontent.com/lukso-network/lukso-orchestrator/feature/l15-run-script/scripts/lukso.sh.
Docs (WIP): https://docs.lukso.tech/networks/setup

Running on macos like:
sudo rm -rf /opt/lukso ~/.lukso
sudo curl https://raw.githubusercontent.com/lukso-network/lukso-orchestrator/feature/l15-setup-script/scripts/install-unix.sh | bash
lukso start


upgrade x/sys version

upgrade x/sys version
from v0.0.0-20190730174312-6a60838ec25 to v0.0.0-20190813064441-fde4db37ae7a
build with go 1.13
failed log
go<EMAIL_ADDRESS>invalid pseudo-version: revision is shorter than canonical (6a60838ec259)

@googlebot I fixed it.

@googlebot I fixed it.


Do not allow Connections without certificate

Allowing connections without a certificate beats the purpose of SSL.

The TLS mode is preferTLS though, so even if allowConnectionsWithoutCertificates is false, clients can still connect without TLS.
Removing allowConnectionsWithoutCertificates would make more sense to me if TLS mode is requireTLS.
Maybe a better approach would be to move the TLS mode and allowConnectionsWithoutCertificates parameters to the start command to make it easier to configure the level of TLS security without creating a new config file?

When you set TLS on the server, you want TLS to be enforced. Therefore, I think the second approach is the preferred method, in my opinion.


Language services debug assertion when switching compiler options

Suppose you are writing a client of the LanguageService that provides a LanguageServiceHost that implements getCompilationSettings to return CompilerOptions that target ScriptTarget.ES5.
If you compile once, then change getCompilationSettings to instead target ScriptTarget.ES6 -- that is, if you dynamically switch the targeted language -- you'll eventually fall into the below code path and hit the debug assertion seen in the snippet.
However, it appears the below code after the debug assertion is attempting to correctly handle the case where the settings have changed.  So I think that the debug assertion is unnecessary and should be removed.
This issue can also be worked around by recreating the whole stack of LanguageServiceHost from scratch when the compilation target changes, but that seems like it might be slow.  It's potentially the case that clients should expect to recreate this object in that scenario, but then it's not clear why the below code handles the missing entry.
Feel free to tell me I'm using the API wrong, or whether a reproduction test case would be useful (I pulled this out of a much larger program so reducing it will be a bit painful).
        function acquireOrUpdateDocument(fileName, compilationSettings, scriptSnapshot, version, acquiring) {
            var bucket = getBucketForCompilationSettings(compilationSettings, /*createIfMissing*/ true);
            var path = ts.toPath(fileName, currentDirectory, getCanonicalFileName);
            var entry = bucket.get(path);
            if (!entry) {
                ts.Debug.assert(acquiring, "How could we be trying to update a document that the registry doesn't have?");
                // Have never seen this file with these settings.  Create a new source file for it.
                var sourceFile = createLanguageServiceSourceFile(fileName, scriptSnapshot, compilationSettings.target, version, /*setNodeParents*/ false);
                entry = {
                    sourceFile: sourceFile,
                    languageServiceRefCount: 0,
                    owners: []
                };
                bucket.set(path, entry);
            }

The system assumes that files and compilation settings are not mutable. there are places that are built on this assumption. creating a new LS object is the correct way to go. the system is wired to make this a cheap operation, by caching SourceFile objects, and reusing them.