Regent: nondeterministic crashes in multi-node CI jobs

Similar to #1478 but we need to re-triage this to figure out what's failing. Part of the larger #1305 for nondeterministic CI failures.
Here are some failures I've observed:

Config: gcc9_cxx11_release_gasnet1_ucx_regent
Test: region_reduce_array.rg
Job: https://gitlab.com/StanfordLegion/legion/-/jobs/4477571498
Failure mode: Caught signal 11 (Segmentation fault: address not mapped to object at address 0x56268710ef10)
(Note this is in the regent-separate-compilation branch prior to merging to master.)
Config: gcc9_cxx11_release_gasnetex_ucx_regent
Test: spy5.rg
Job: https://gitlab.com/StanfordLegion/legion/-/jobs/4493007174
Failure mode: Generic MPI failure message. No application specific error reported.
Config: gcc9_cxx11_release_gasnetex_ucx_regent
Test: access_fspace_constraints_region.rg
Job: https://gitlab.com/StanfordLegion/legion/-/jobs/4509089650
Failure mode: Caught signal 11 (Segmentation fault: address not mapped to object at address 0x5602124ae710)
Config: gcc9_cxx11_debug_gasnetex_mpi_regent
Test: separate_compilation.rg
Job: https://gitlab.com/StanfordLegion/legion/-/jobs/4564740026
Failure mode: Unable to find variant 5 of task other_regent_task
Branch: control_replication

I'll update this list as I see more failures. I want to see the pattern of the failures before I attempt to draw conclusions.

I'm only considering crashes at or after de387fb2722b0a112f6edcdcaee7dbd834e8526d (merged to master in 8b51cb74139b87b138abdb1ac481e85d617ddc58) because that's when I modified separate_compilation.rg to avoid  the use of JIT mode. If we see new failures in separate_compilation.rg, those are relevant, or if we see failures in other tests (not otherwise described in #1305), we should track those here.

Here's a great that recently failed on master. No error message.
https://gitlab.com/StanfordLegion/legion/-/jobs/4493007174

Someone inside NVIDIA reported an identical failure mode to this on a Legate run using UCX. There's obviously no Regent code in that run, so I think we can rule out Regent/Terra as sources of the problem here.

@elliottslaughter can we add UCX_HANDLE_ERRORS=none to the environment of these jobs to see if we can get a different backtrace of where things are going wrong?

Added in https://gitlab.com/StanfordLegion/legion/-/commit/8f8821278d243f5d86d8c0785c7974f5fd2ba612. I'll keep watching the tests.

Here's a new failure. Somewhere inside a Regent task according to the backtrace: https://gitlab.com/StanfordLegion/legion/-/jobs/4526318414

That is just a known legion failure in the master branch that is already fixed in the control replication branch and is too expensive to backport. You can ignore it.

So here's a crash of separate compilation which suggests that the problem is that not all the variants are registered across all the nodes before launching a control replicated task that needs them:
https://gitlab.com/StanfordLegion/legion/-/jobs/4564740026

This error makes no sense to me. We're compiling a set of shared libraries, linking them into an executable, and calling exec on it. The sequence of registration calls is deterministic. Unless the compiler is doing something really bad, I don't see how we could be losing a registration. The JIT is entirely gone here, so we're just doing regular ELF binary execution with shared libraries. We do not rely on shared library constructors and explicitly call the registration functions ourselves:
https://github.com/StanfordLegion/legion/blob/5b6f90d900f184d4a060fc4f83e94516328e83e4/language/examples/separate_compilation.rg#L58-L68
Note: if the last loader weren't the one that started the runtime, the program would not compile because we pass argv, argc to the last loader only.
I have no operational hypothesis for how this bug manifests, so without a reliable reproducer I can't debug it.

So there are two obvious possibilities here:

The task variants were registered in different orders on different nodes (which seems unlikely since you're doing things with lists)
The names of the variants weren't selected in a consistent way (how does regent pick the variant names for its tasks or does it let Legion pick them?)

Also, all these registrations are being done before you start the runtime? It's hard for me to follow where the runtime actually gets started.

Right. As you can see, the libraries are called in a deterministic order.
There are a couple ways for this to fail, but I find it hard to imagine either of these happening:

If the name of the task isn't deterministic, Regent would not be able to link it properly. However, all these tasks have unique and deterministic names.
Each task name becomes a global variable (e.g., my_task_name => my_task_name_task_id). The global is used to store the task ID. If somehow linking that global messed up, then we'd get a 0 or garbage at the point of calling the task. However, because this is failing nondeterministically, I have a hard time imagining this being the case.

All registrations are done statically, in advance of starting the runtime. The runtime is literally the last call.
Again, without a reliable reproducer we're really shooting in the dark here.

So we got a failure with the new logging here:
https://gitlab.com/StanfordLegion/legion/-/jobs/4946867412
There's definitely something wrong here. What it looks like happened is that on node 0 Regent picked its own task ID (4) for the my_regent_task and then started asking Legion to generate task IDs for the remaining tasks (1048576 for other_regent_task and 1048577 for main). However, on node 1 Regent asked Legion to generate all the task IDs which assigned 1048576 to my_regent_task, 1048577 to other_regent_task, and 1048578 for main. This discrepancy in the task IDs across the nodes is almost certainly the cause of the crash. What I can't explain at the moment is why Regent chose to assign a task ID on one node but not the other. Any ideas @elliottslaughter?

Nothing in the separate_compilation test sets a task ID:
$ rg 'set_task_id' examples/separate_compilation*

Regent, when in separate compilation mode, should make a global variable per task and initialize it to -1.
https://gitlab.com/StanfordLegion/legion/-/blob/master/language/src/regent/std_base.t?ref_type=heads#L1719-1725
(The value of c.AUTO_GENERATE_ID is -1.)
You know for sure we're not accidentally disabling separate compilation, because if we were doing that, then task IDs would start at 10000:
https://gitlab.com/StanfordLegion/legion/-/blob/master/language/src/regent/std_base.t?ref_type=heads#L1297
So, therefore, the only thing I can see that would be happening is that the global that holds the task ID is getting garbage and the garbage happens to be 4. Otherwise I have no explanation for why this would occur.
I suppose there could be a linkage issue with Terra. We've suspected something like that in the past. It's going to be devilishly hard to track it down though if this is how often it reproduces.
I'm open to suggestions and alternative hypotheses, of course.

So I'm pretty confident that Legion definitely saw 4 get passed in as the task ID to the preregister task call. If the value got corrupted after Legion generated a task ID inside the runtime, then the other two task IDs would still have aligned between the nodes. However, since those don't align, then Legion started generating IDs only for the next task on node 0 and I feel very confident that 4 was the value passed into Legion for preregistering the first task variant.
We can safely rule out the case of the libraries being registered in different orders. The tasks are printed out from Legion in the same order that the API calls were done to preregister the task variants, so we can conclude that that happened in the same order on both nodes.

So, therefore, the only thing I can see that would be happening is that the global that holds the task ID is getting garbage and the garbage happens to be 4. Otherwise I have no explanation for why this would occur.

I think I agree with that. It feels like there is a race between reading the global variable c.legion_task_id and the initialization with the value -1. Almost like one part of the separate compilation is making this global variable while the other one has already started running and tried to read the global variable before it was finished being initialized by the one creating it. It does eventually get initialized and the later two task registrations read the right value. Does c.legion_task_id live in the Lua interpreter state or is it created on the C side so that it can be visible to all the generated code? I'm guessing the latter and I wonder if somehow we're making it available before it is finished being initialized.

I think there's some misunderstanding here. In the new separate_compilation.rg test (ever since I modified it a few months ago), we do not use JIT-mode Terra at all. We produce some .so files, we link them into an executable, and we run it. Therefore, at runtime there is no Lua or Terra in process at all.
What could be happening is that Terra compilation itself is nondeterministic. I have no evidence right now that this is happening, but an example of how this would go would be if, somehow, Terra generated buggy code in one of the two processes. E.g., if somehow one of the globals ended up with the value 4, then the code produced by Regent would just register the task with that task ID instead of generating a new ID. I believe the reason for this is that Regent's code is designed to idempotent: if a task gets registered multiple times, on the subsequent registrations it should reuse the task ID from the first registration. Obviously, that works if and only if the global preserves its correct initializer value of -1.
I suppose what I could do would be allow Regent task registration to be nonidempotent. That is, on every call to register a Regent task, we would always perform registration (either with the task's compile-time constant task ID, or with -1 if we're in separate compilation). Therefore, registering a task multiple times would result in multiple IDs being allocated, and the global task ID variable to be overwritten multiple times. However, those would all be valid copies of the task and execution ought to still be valid. Because the generated code is (or should be) deterministic, that would avoid the issue above even if Terra has a low-probability nondeterministic miscompilation.
If that sounds ok, I can go ahead and implement it.

In principle I should be able to add code to inspect the generated shared library prior to running (or maybe after the program fails).
Alternatively, I wonder if we should set up a system to capture artifacts from failed jobs. That would hit two birds with one stone because it would help us track down low-probability failures in the profiler too.

How much effort do we think it is to establish that system? If it's not too much it feels like the right answer as it will continue to pay dividends going forward.

I saw another one of these failures today, so it at least seems to be repeatable:
https://gitlab.com/StanfordLegion/legion/-/jobs/5197860435


refactor!: remove goerli and mumbai

What I did
https://blog.ethereum.org/2023/11/30/goerli-lts-update
https://www.alchemy.com/blog/goerli-faucet-deprecation
Goerli support on all networks is ending soon:

February 16th - Base Goerli
March 7th - Optimism Goerli
March 18th - Arbitrum Goerli
April 1st - Ethereum Goerli
April 6th - Polygon zkEVM Goerli
April 11th - Starknet Goerli
April 13th - Polygon Mumbai

https://www.alchemy.com/blog/polygon-mumbai-testnet-deprecation

Removed Goerli
Updated documentation
Refactored tests

fixes: #
How I did it

How to verify it

Checklist

[X] All changes are completed
[X] New test cases have been added
[X] Documentation has been updated

Why is only mac breaking?


Fixes a default config bug of gc scheduler

I ran the containerd service with the default config, the service failed when loading config file with error log:
containerd[10993]: containerd: time: missing unit in duration 100000000

That's because toml.Decode can not decode 100000000 to time.Duration variable.
We should encode time.Duration variable to string with unit (e.g.: 100000000  -> "100ms") when print the the default config with containerd config default.
This pr fixes the bug.
Signed-off-by: Yanqiang Miao<EMAIL_ADDRESS>

LGTM
@dmcgowan PTAL

LGTM


Workspace Factory #17: Get block types currently used

Added function in generator that returns an array of all the block types being used without any duplicates. For use in integrating with Blockly Factory to allow the exporter to know which blocks are being used in the toolbox and pre-loaded blocks. This will allow the exporter to be able to automatically add all blocks currently being used in workspace factory to the selector workspace.

This change is

+@picklesrus +@vicng +@quachtina96

Review status: 0 of 1 files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 4 unresolved discussions.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 119 [r1] (raw file):

FactoryGenerator.prototype.getAllUsedBlocks = function() {
  var blockTypeList = [];
  if (!this.model.hasElements()) {

These calls would read nicer as ".isFlyout()", instead of deducing that it's a flyout.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 122 [r1] (raw file):

    // If has a single flyout, add block types for the single flyout.
    this.pushBlockTypesToList_(this.model.getSelectedXml(), blockTypeList);

Nit: Remove extra line.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 127 [r1] (raw file):

    var toolboxList = this.model.getToolboxList();

    for (var i = 0, category; category = this.toolboxList[i]; i++) {

Remove "this."?

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 153 [r1] (raw file):

  this.hiddenWorkspace.clear();
  Blockly.Xml.domToWorkspace(xml, this.hiddenWorkspace);
  var blocks = this.hiddenWorkspace.getAllBlocks();

Is there a way to get the block type without using the generator's hidden workspace? These two methods seem more appropriate in the Model class, since nothing is being generated here.

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 5 unresolved discussions.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 117 [r1] (raw file):

 * @return {!Array<!string>} Array of block types currently being used.
 */
FactoryGenerator.prototype.getAllUsedBlocks = function() {

'getAllUsedBlockTypes' is more accurate of a name

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 153 [r1] (raw file):
Previously, vicng wrote…
> Is there a way to get the block type without using the generator's hidden workspace? These two methods seem more appropriate in the Model class, since nothing is being generated here.

@evd2014  If you are looking to extract the blocktype from the xml,  I have a function AppController.prototype.getBlockTypeFromXml_, which extracts block type from xml text, the kind that is saved in block library storage. I dont think my function does exactly what you want here, but it is not hard to adjust.  Notes here: https://docs.google.com/document/d/1r4ZEBzDFAjCItUHpwfr47-LmFOiIsyPU5CkdA1iSXr8/edit

Comments from Reviewable

Review status: 0 of 1 files reviewed at latest revision, 5 unresolved discussions.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 117 [r1] (raw file):
Previously, quachtina96 (Tina Quach) wrote…
> 'getAllUsedBlockTypes' is more accurate of a name

Done.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 119 [r1] (raw file):
Previously, vicng wrote…
> These calls would read nicer as ".isFlyout()", instead of deducing that it's a flyout.

When moved to model, could directly access the flyout ivar.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 122 [r1] (raw file):
Previously, vicng wrote…
> Nit: Remove extra line.

Done.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 127 [r1] (raw file):
Previously, vicng wrote…
> Remove "this."?

Changed to just use this.toolboxList directly now that I'm in the model.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 153 [r1] (raw file):
Previously, quachtina96 (Tina Quach) wrote…
> @evd2014  If you are looking to extract the blocktype from the xml,  I have a function AppController.prototype.getBlockTypeFromXml_, which extracts block type from xml text, the kind that is saved in block library storage. I dont think my function does exactly what you want here, but it is not hard to adjust.  Notes here: https://docs.google.com/document/d/1r4ZEBzDFAjCItUHpwfr47-LmFOiIsyPU5CkdA1iSXr8/edit

Thanks! Looked through this and came up with something similar to parse the XML for the block type. Refactored to extract block type from the XML and put these functions in the model.

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 402 [r2] (raw file):

  for (var i = 0; i < blocks.length; i++) {
    var type = blocks[i].getAttribute('type');
    if (list.indexOf(type) == -1) {

Would it be more efficient to use a set to store the types of blocks and then convert that to an array at the end?

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 363 [r2] (raw file):

FactoryModel.prototype.getAllUsedBlockTypes = function() {
  var blockTypeList = [];
  console.log(this.getSelectedXml());

Remove this log and just add an empty line.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 366 [r2] (raw file):

  if (this.flyout) {
    // If has a single flyout, add block types for the single flyout.

You can remove this extra line

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 395 [r2] (raw file):

 * @param {!Array<!string>} list The array of block types to add to.
 */
FactoryModel.prototype.pushBlockTypesToList_ = function (xml, list) {

Unless this will be used elsewhere, can this be defined as an inline function inside getAllUsedBlockTypes?

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 363 [r2] (raw file):
Previously, vicng wrote…
> Remove this log and just add an empty line.

Done.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 366 [r2] (raw file):
Previously, vicng wrote…
> You can remove this extra line

Done.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 395 [r2] (raw file):
Previously, vicng wrote…
> Unless this will be used elsewhere, can this be defined as an inline function inside getAllUsedBlockTypes?

Actually was just planning some stuff with Tina and this function will be used elsewhere. Removed the @private tag.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 402 [r2] (raw file):
Previously, quachtina96 (Tina Quach) wrote…
> Would it be more efficient to use a set to store the types of blocks and then convert that to an array at the end?

We talked about this offline, and IE support for Sets is pretty minimal.

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 120 [r3] (raw file):

 * @param {!Element} dom The DOM element to append the generated XML to.
 */
FactoryGenerator.prototype.loadToHiddenWorkspaceAndSave_ = function(xml, dom) {

There should only be one method that controls loading data into the hidden workspace.
This method should just be loadToHiddenWorkspace_ and it shouldn't call appendHiddenWorkspaceToDom_. Once that's fixed, then you can call it in generateWorkspaceXml.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 395 [r2] (raw file):
Previously, evd2014 (Emma Dauterman) wrote…
> Actually was just planning some stuff with Tina and this function will be used elsewhere. Removed the @private tag.

This doesn't belong as a Model method. It isn't using anything Model specific.

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

demos/blocklyfactory/workspacefactory/wfactory_generator.js, line 120 [r3] (raw file):
Previously, vicng wrote…
> There should only be one method that controls loading data into the hidden workspace.
>
> This method should just be `loadToHiddenWorkspace_` and it shouldn't call `appendHiddenWorkspaceToDom_`. Once that's fixed, then you can call it in `generateWorkspaceXml`.

That makes sense. Done.

demos/blocklyfactory/workspacefactory/wfactory_model.js, line 395 [r2] (raw file):
Previously, vicng wrote…
> This doesn't belong as a Model method. It isn't using anything Model specific.

Completely agreed. The reason I left it in the model even though I didn't think it was the best place for it was because getAllUsedBlockTypes needed access to it, and the model doesn't have access to any methods outside the model. I added a TODO to move it to FactoryUtils once this CL gets merged into the develop branch. For now, I made it an inline function inside getAllUsedBlockTypes like you initially recommended.

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

Comments from Reviewable


Why is the Instance picker not working?

Somehow the Picker works great within a Menu. However only with enums, not with our loop over struct Instance.
The picker selection: is an @AppStorage variable:
@AppStorage("movieInstance") private var selectedInstanceId: UUID?

How can this be remedied?
https://github.com/tillkruss/ruddarr/blob/40480c86c661a3823c1c26db76f495bb8dc79500/Ruddarr/Views/MoviesView.swift#L111-L127

Requires Optional.some(instance.id)


SAM Collapsed Navigation Bar Hover should be sticky

When the navigation bar is collapsed. The user can hover over the Settings Icon to get a menu. This menu should be sticky. Should only close when the user clicks outside of it. To see an example, click on the hexagonal Plus button, the menu that comes out is sticky and remains open.

@hlivian  would like to make this change post GA. we tested it multiple ways before and I like the current approach.


[BUG]: Error: Unable to render  because window.paypal.Buttons is undefined.

Is there an existing issue for this?

[X] I have searched the existing issues.

🐞 Describe the Bug
Getting this error "Error: Unable to render  because window.paypal.Buttons is undefined." while using the package with Next.js
I have used the script tag for a workaround with the before interactivity strategy, then it's not throwing the error, but the buttons are still not appearing.
😕 Current Behavior

🤔 Expected Behavior
No error
🔬 Minimal Reproduction
Just use it with Next.js app

🌍 Environment
| Software         | Version(s) |
| ---------------- | ---------- |
| react-paypal-js  |     7.8.3       |
| Browser          | 113.0.5672.92
| Operating System |     macos

Relevant log output
Unhandled Runtime Error
Error: Unable to render <PayPalButtons /> because window.paypal.Buttons is undefined.

Call Stack
eval
node_modules/.pnpm/@paypal+react-paypal-js<EMAIL_ADDRESS>(417:0)
basicStateReducer
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(16540:0)
updateReducer
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(16664:0)
updateState
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(17004:0)
Object.useState
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(17915:0)
useState
<EMAIL_ADDRESS>(1622:0)
PayPalButtons
node_modules/.pnpm/@paypal+react-paypal-js<EMAIL_ADDRESS>(396:19)
renderWithHooks
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(16305:0)

Code of Conduct

[X] I agree to follow this project's Code of Conduct

➕ Anything else?
No response

I made it work somehow!

For anyone coming here: had the same issue and fixed it by changing the id paypal of another element on the page. In my case I had a radio button with that id and renamed it to paypal-radio. 🙃


Meizu MX6 cannot screen on scrcpy2.0.

scrcpy 2.0 https://github.com/Genymobile/scrcpy
C:\Program Files (x86)\Androidscreen\Resources\scrcpy-serv...file pushed, 0 skipped. 106.7 MB/s (52867 bytes in 0.000s)
[server] INFO: Device: Meizu MX6 (Android 7.1.1)
[server] ERROR: Exception on thread Thread[main,5,main]
java.lang.NullPointerException: Attempt to invoke virtual method 'android.content.pm.ApplicationInfo android.content.Context.getApplicationInfo()' on a null object reference
at android.content.ContextWrapper.getApplicationInfo(ContextWrapper.java:151)
at android.content.ContextWrapper.getApplicationInfo(ContextWrapper.java:151)
at com.android.server.NetworkManagementSocketTagger.getApplicationInfo(NetworkManagementSocketTagger.java:262)
at com.android.server.NetworkManagementSocketTagger.getProcessInfo(NetworkManagementSocketTagger.java:292)
at com.android.server.NetworkManagementSocketTagger.tag(NetworkManagementSocketTagger.java:139)
at libcore.io.BlockGuardOs.tagSocket(BlockGuardOs.java:47)
at libcore.io.BlockGuardOs.socket(BlockGuardOs.java:288)
at android.system.Os.socket(Os.java:491)
at android.net.LocalSocketImpl.create(LocalSocketImpl.java:256)
at android.net.LocalSocket.implCreateIfNeeded(LocalSocket.java:107)
at android.net.LocalSocket.connect(LocalSocket.java:130)
at com.genymobile.scrcpy.DesktopConnection.connect(DesktopConnection.java:50)
at com.genymobile.scrcpy.DesktopConnection.open(DesktopConnection.java:85)
at com.genymobile.scrcpy.Server.scrcpy(Server.java:97)
at com.genymobile.scrcpy.Server.main(Server.java:381)
at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:308)
ERROR: Server connection failed

What is the value of Build.BRAND?
https://github.com/Genymobile/scrcpy/blob/45717733a10b8e73ae70b25722b2ddf5922c1c07/server/src/main/java/com/genymobile/scrcpy/Server.java#L84

It works fine on scrcpy1.24.

这个版本有效吗：#3801（评论）？

Ok, I'll test it now.

这个版本有效吗：#3801（评论）？

It works fine. Would you consider releasing a fix?

It works fine.

That's very strange, this version is not supposed to fix a problem with Meizu devices :confused:

Would you consider releasing a fix?

It will be in the next minor release, I don't know when (there is no rush).

And does this version work: #3801 (comment) ?

Ok, scrcpy-server is big. Is that normal?

127Kb is not big.

Oh, it's because it has been build from my debug builddir (so with gradle assembleDebug) while the release is built in release mode (gradle assembleRelease).

哦，这是因为它是从我的调试构建器构建的（所以使用 ），而版本是在发布模式下构建的（）。gradle assembleDebug``gradle assembleRelease

I see. Thank you.


NullReferenceException: Object reference not set to an instance of an object when building animator

I imported the unitypackage and then dragged the WorldObject prefab to the root of my scene. I then dragged it to the root of my avatar. I added the script to my avatar and pressed Build Animator. It didn't work and spat out this error. Im on the latest sdk and unity 2019.4.31f1.

I then tried it in a new project with only the sdk and the fbx of an avatar in it. It had new an entirely empty fx layer and fresh menu/parameters. I followed the same instructions and performed the same steps. And it spat out the exact same error when I pressed build animator.
Both tests only seem to have gotten as far as adding the parameters. No layers got actually created.

Here's the raw text of the error if you need it

NullReferenceException: Object reference not set to an instance of an object
WorldObjectSetupEditor+<>c__DisplayClass8_0.b__0 (UnityEngine.Object asset) (at Assets/vrc-worldobject/Editor/WorldObjectSetupEditor.cs:218)
System.Array.Find[T] (T[] array, System.Predicate`1[T] match) (at :0)
WorldObjectSetupEditor.GetOrCreateClip (UnityEditor.Animations.AnimatorController controller, UnityEngine.Object[] existingAssets, System.String name) (at Assets/vrc-worldobject/Editor/WorldObjectSetupEditor.cs:218)
WorldObjectSetupEditor.GenerateStateMachine (UnityEditor.Animations.AnimatorController controller, System.Boolean isFine, System.Single range) (at Assets/vrc-worldobject/Editor/WorldObjectSetupEditor.cs:135)
WorldObjectSetupEditor.GenerateWorldObject (System.Single range) (at Assets/vrc-worldobject/Editor/WorldObjectSetupEditor.cs:55)
WorldObjectSetupEditor.OnInspectorGUI () (at Assets/vrc-worldobject/Editor/WorldObjectSetupEditor.cs:29)
UnityEditor.UIElements.InspectorElement+<>c__DisplayClass58_0.b__0 () (at :0)
UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)

Hey @FizzyTaco, thanks for the very thorough report. I'm having trouble reproducing the issue locally, but I do have an idea based on the info you provided. Could you try out this new version of vrc-worldobject/Editor/WorldObjectSetupEditor.cs and see if it fixes the issue? https://raw.githubusercontent.com/seanedwards/vrc-worldobject/main/Editor/WorldObjectSetupEditor.cs


Fixes link in README

The link on the homepage is dead.

Coverage remained the same at 98.885% when pulling 6cb974b64a05d0aa4abebb39f391e2d2c915ad68 on znetstar:master into 6afc2de451e947ac7f4738922205c6ff7e1f3436 on thunks:master.

Coverage remained the same at 98.885% when pulling 6cb974b64a05d0aa4abebb39f391e2d2c915ad68 on znetstar:master into 6afc2de451e947ac7f4738922205c6ff7e1f3436 on thunks:master.


Add correct meta tag when feed to boilerplate

For example
<link rel="alternate" type="application/rss+xml" title="Website name ?" href="https://example.com/feed.xml" />

Going to be fixed with #925

No more boilerplate with v1.


updated release workflows

Why not adding this to https://github.com/giantswarm/github/ ?

Why not adding this to giantswarm/github ?

I'm trying to https://github.com/giantswarm/github/pull/64


Proposal: Metadata retrieval support for SQL connectors

Summary
Introduce a metadata client, APIs and corresponding record types to retrieve and represent metadata relating to tables,
columns and constraints of relational databases.
History
In 1.4.x versions and below of SQL packages, there was no specific support to retrieve metadata. Instead, the SQL
query() method  could have been used to query the tables specific to the RDBMS containing metadata, and then retrieve
and parse the required information.
This requires the user to have in-depth knowledge of the RDBMS being used in order to understand the schema which
is used to store the metadata.
Goals

Support to retrieve and map metadata relating to tables, columns and constraints in a relational database.
Provide an extensible design which can be implemented by the SQL connectors (MySQL, MSSQL, PostgreSQL, OracleDB, and any other future connectors).

Non-goals

This would only provide support to retrieve metadata from one database per client. If there is a requirement to retrieve metadata regarding multiple databases, then multiple databases would have to be created.

Motivation
With this support, the user would not need to write specific queries, nor have in-depth knowledge of the RDBMS being used.
Instead, they may make simple API calls to retrieve the necessary information.
Description
Schema client
A new client would be introduced which is used to query the database to retrieve the relevant metadata. On initialization,
the user would have to provide credentials to access the relevant metadata tables (e.g. INFORMATION_SCHEMA tables in
MySQL and SQL server). If the provided credentials do not provide the necessary privileges to access the metadata tables,
an AuthorizationError would be returned.
# Represents an error that occurs when the user does not have the required authorization to execute an action.
public type AuthorizationError distinct ApplicationError;

It is also required to provide the name of the database regarding which the metadata should be retrieved.
Example client initialization (for MySQL)
# Represents a Mock database schema client.
isolated client class MockSchemaClient {
    *SchemaClient;

    public function init(string host, int port, string user, string password, string database) returns Error? {
        // Use the connector's underlying `client` to establish the connection.
    }
}

NOTE:  The parameter database in the example above refers to the database for which the metadata retrieved is
about. It does not indicate that the client connects to that database.

This client can be extended by each SQL connector to customize the implementation as necessary.
Types
New record-types would be introduced to represent the metadata which may be retrieved.

TableDefinition
ColumnDefinition
CheckConstraintDefinition
ReferentialConstraintDefinition
RoutineDefinition
ParameterDefinition

These record types contain only fields which are common to relational databases. However, they may be inherited and then
extended by each SQL connector to provide support for additional database-specific fields.
Table Definition
# Represents a table in the database.
#
# + name - The name of the table
# + 'type - Whether the table is a base table or a view
# + columns - The columns included in the table
public type TableDefinition record {
    string name;
    TableType 'type;
    ColumnDefinition[] columns?;
};

The columns field is optional as there are use cases where the user would not want to retrieve information regarding
the columns of a table.
The TableType type is an enum, which can take one of two values:

BASE_TABLE
VIEW

Column Definition
# Represents a column in a table.
#
# + name - The name of the column
# + 'type - The SQL data-type associated with the column
# + defaultValue - The default value of the column
# + nullable - Whether the column is nullable
# + referentialConstraints - Referential constraints (foreign key relationships) associated with the column
# + checkConstraints - Check constraints associated with the column
public type ColumnDefinition record {
    string name;
    string 'type;
    anydata? defaultValue;
    boolean nullable;
    ReferentialConstraint[] referentialConstraints?;
    CheckConstraint[] checkConstraints?;
};

The referentialConstraints and checkConstraints fields are optional as there may be use cases where the user does not
want to retrieve this information.
Referential Constraint
# Represents a referential constraint (foriegn key constraint).
#
# + name - The name of the constraint
# + tableName - The name of the table which contains the referenced column
# + columnName - The name of the referenced column
# + updateRule - The action taken when an update statement violates the constraint
# + deleteRule - The action taken when a delete statement violates the constraint
public type ReferentialConstraint record {
    string name;
    string tableName;
    string columnName;
    ReferentialRule updateRule;
    ReferentialRule deleteRule;
};

The ReferentialRule type is an enum with four possible values:

NO_ACTION
CASCADE
SET_NULL
SET_DEFAULT

Check Constraint
# Represents a check constraint.
#
# + name - The name of the constraint
# + clause - The actual text of the SQL definition statement
public type CheckConstraint record {
    string name;
    string clause;
};

Routine Definition
# Represents a routine.
#
# + name - The name of the routine
# + 'type - The type of the routine (procedure or function)
# + returnType - If the routine returns a value, the return data-type. Else ()
# + parameters - The parameters associated with the routine
# + created - The timestamp at which the routine was created
# + lastAltered- The timestamp at which the routine was last altered
public type RoutineDefinition record {
    string name;
    RoutineType 'type;
    string? returnType;
    ParameterDefinition[] parameters;
    time:Civil created;
    time:Civil lastAltered;
};

The RoutineType type is an enum which can take one of two values

PROCEDURE
FUNCTION

Parameter Definition
# Represents a routine parameter.
#
# + mode - The mode of the parameter (IN, OUT, INOUT)
# + name - The name of the parameter
# + type - The data-type of the parameter
public type ParameterDefinition record {
    ParameterMode mode;
    string name;
    string type;
};

The ParameterMode type is an enum which can take one of three values

IN
OUT
INOUT

Methods
The SchemaClient will contain six methods which may be used to retrieve metadata.

listTables()
getTableInfo()
listRoutines()
getRoutineInfo()

All of these methods will be implemented by each SQL connector.
Retrieve all tables
remote isolated function listTables() returns string[]|Error;

This would fetch the names of all the tables in the database.
Retrieve a single table
remote isolated function getTableInfo(string tableName, ColumnRetrievalOptions include = COLUMNS_ONLY) returns TableDefinition|Error;

public enum ColumnRetrievalOptions {
    NO_COLUMNS,
    COLUMNS_ONLY,
    COLUMNS_WITH_CONSTRAINTS
}

This would fetch all relevant information from a given table from the database. Based on the option provided for the include parameter, relevant column information would also be retrieved.
Retrieve all routines
remote isolated function listRoutines() returns string[]|Error;

This would fetch the names of all the routines created in the database.
Retrieve a single routine
remote isolated function getRoutineInfo(string name) returns RoutineDefinition|Error;

This would fetch all relevant information regarding the provided routine (including the parameter data).
References
[1] https://docs.microsoft.com/en-us/sql/relational-databases/system-information-schema-views/system-information-schema-views-transact-sql?view=sql-server-ver16
[2] https://www.postgresql.org/docs/current/information-schema.html
[3] https://dev.mysql.com/doc/mysql-infoschema-excerpt/8.0/en/information-schema-table-reference.html
[4] https://docs.oracle.com/cd/E19078-01/mysql/mysql-refman-5.0/information-schema.html

Few Suggestions:

Instead of MetadataClient, shall we name the client as SchemaClient. As this client provides DB schema information.
Shall we have the following APIs,

List Tables in the Database
remote isolated function listTables() returns string[]|Error;

Get Table Info
remote isolated function getTableInfo(string name, XYZ include = COLUMNS) returns TableDefinition|Error;

type enum XYZ(proper name) {
  COLUMNS;
  COLUMNS_WITH_CONSTRAINS;
}

We don't APIs to fetch column details. we can fetch them with Table definition.
List Routines in the Database
remote isolated function listRoutines() returns string[]|Error;

Get Routine Info
remote isolated function getRoutineInfo(string name) returns RoutineDefinition|Error;

@kaneeldias WDYT?

For the client init function parameter, shall we keep the order the same as other SQL clients and make database a required param

For the client init function parameter, shall we keep the order the same as other SQL clients and make database a required param

This would be idea, but in that case the compilation fails with required parameter after the defaultable parameter since the username, password etc. would be defaultable. Any better solutions for this?

@daneshk the proposal has been updated with the feedbackl

For the client init function parameter, shall we keep the order the same as other SQL clients and make database a required param

This would be ideal, but in that case the compilation fails with required parameter after the defaultable parameter since the username, password etc. would be defaultable. Any better solutions for this?
public function init(string url, string? user = (), string? password = (), string? datasourceName = (),
    string database) returns Error?

Shall we make user and password required?. Here we need an admin user right, there should have a user and password in this case.

For the client init function parameter, shall we keep the order the same as other SQL clients and make database a required param

This would be ideal, but in that case the compilation fails with required parameter after the defaultable parameter since the username, password etc. would be defaultable. Any better solutions for this?
public function init(string url, string? user = (), string? password = (), string? datasourceName = (),
    string database) returns Error?

Shall we make user and password required?. Here we need an admin user right, there should have a user and password in this case.

Updated the proposal with the suggestion

@sameerajayasoma Can you check this proposal for database schema retrieval support for SQL connectors? This support will be helpful for our persist layer to compare the generated schema with the underline database schema and create migration scripts.

@kaneeldias A small suggestions, shall we rename the authorisation error as below?
# Represents an error that occurs when the user does not have the required privileges to execute an action.
public type InsufficientPrivilegesError distinct ApplicationError;

I feel this would be more descriptive.

@kaneeldias A small suggestions, shall we rename the authorisation error as below?
# Represents an error that occurs when the user does not have the required privileges to execute an action.
public type InsufficientPrivilegesError distinct ApplicationError;

I feel this would be more descriptive.

+1 amended the proposal

Let's do the implementation for the SQL module initially in update 02. Then let's planned to support this in other connectors in future updates

Removed InsufficientPrivilegesError error type as is it not possible for a user to not have read access to the INFORMATION_SCHEMA tables [1].
[1] https://stackoverflow.com/questions/68758308/deny-access-to-information-schema-in-mariadb


[stable/kafka-manager] Bump Image Tag

What this PR does / why we need it:
Uses the newer version of Kafka Manager
Special notes for your reviewer:
Also adds me as a maintainer/owner to help with maintenance of the chart
@giacomoguiulfo
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @giacomoguiulfo

/ok-to-test

/lgtm


Make LPE default estimator.

This switches the default estimation group to attitude estimator q + lpe instead of attitude estimator q + inav.
There is also a small gain tuning for iris to avoid overshoot in position control mode for small step responses.
Logs and flight tests will be attached.

This is mission mode, alt mode, position mode, and manual without flow outdoors with alt mode 0.
http://logs.uaventure.com/view/JJZy8wj76uAEuk59xB9Fr3

Mission mode with alt mode 1 when no lidar/ flow attached, testing that it defaults back to alt mode 0.
http://logs.uaventure.com/view/E9bhG3f8qMSVbEtH6dBoPB

First ever mission with px4flow for position!
http://logs.uaventure.com/view/xQ5N9uvGBEKec4FLGsZa86
Note, had to lower MPC_XY_P to 0.2 to avoid large tilt angles and set max takeof alt to 1, and set all altitudes for waypoints to 2 m.

@tumbili Can you please add this to your testing?
@kd0aij Do you have an opportunity to flight-test this including a mission?

@jgoppert Definitely something we should make the default for 1.4!

@LorenzMeier Sounds good. I will get in some more testing as well.

@jgoppert Regarding flight testing of the attitude estimate: has anyone run multiple estimators in parallel and logged the results at high rates for comparison? I've done that in the past to validate the MPU6000 when it was first added to the UDB series. I'd really like to quantify the accuracy issues e.g. with and without GPS for acceleration compensation.
I've been hoping to see tests done with mocap data for ground-truth, but those are either private or non-existent.

@kd0aij The attitude estimator here is just attitude estimator q. It would be good to see some mocap results.

Yes, I was thinking of running two copies of the Q estimator, one with GPS feedback disabled (it looks like parameter ATT_ACC_COMP controls that), then flying a pattern designed to demonstrate the need for acceleration compensation.

@LorenzMeier, @tumbili  Let's merge this. INAV is just causing us more headaches than it is worth at this point. I spent a day debugging an issue that didn't exist on LPE and was really an INAV bug because of end user confusion.

This diff is just 1 character so should be easy :-).

@jgoppert nice diff ;)
@LorenzMeier Let's get this in ASAP. I've been referring all the people who've been trying optical flow to LPE, and we've achieved that level of "it just works!".

For reference,  this is the result a student (with no prior PX4 experience) got, just after taping a PX4Flow to his Iris and setting this param.
https://www.youtube.com/watch?v=TtTVMpdwHJI

fluorescent lights?
On Mon, Jun 6, 2016 at 8:16 PM Kabir Mohammed<EMAIL_ADDRESS>wrote:

For reference, this is the result a student (with no prior PX4 experience)
got, just after taping a PX4Flow to his Iris and setting this param.
https://www.youtube.com/watch?v=TtTVMpdwHJI
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PX4/Firmware/pull/4483#issuecomment-224146308, or mute
the thread
https://github.com/notifications/unsubscribe/ACMZPQieGt_v2EhbxLA6IZzh4rjwVJNyks5qJNR7gaJpZM4IZwY2
.

Type of lighting isn't critical, have flown with 180 lumen led work light outside  at night. Also daylight outdoors or led/incandescent indoors works.

I thought there was a stong strobe effect with fluorescents.
Is there any need to tune parameters for LPE for different size quads?
On Mon, Jun 6, 2016 at 8:44 PM Mark Whitehorn<EMAIL_ADDRESS>wrote:

fluorescent lights?
On Mon, Jun 6, 2016 at 8:16 PM Kabir Mohammed<EMAIL_ADDRESS>wrote:

For reference, this is the result a student (with no prior PX4
experience) got, just after taping a PX4Flow to his Iris and setting this
param.
https://www.youtube.com/watch?v=TtTVMpdwHJI
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/PX4/Firmware/pull/4483#issuecomment-224146308, or mute
the thread
https://github.com/notifications/unsubscribe/ACMZPQieGt_v2EhbxLA6IZzh4rjwVJNyks5qJNR7gaJpZM4IZwY2
.

Haven't flown under fluorescent myself. No changes necessary for different size quads.

@kd0aij @pkocmoud @LorenzMeier  I plan to do some flying tomorrow morning with lidar on my iris so we can quantify the qualitative improvements we have been making with the altitude parameters without lidar. I will add a parameter so that the lidar doesn't go into the correction but is still recorded, similar to LPE_GPS_ON, probably LPE_LDR_ON so we can use it as a baseline.
I would like to see this merged with master this weekend if possible, so if you guys have time for a final flight for a thumbs up, would be appreciated.

Just tested with optical flow outdoors, works even better with latest updates to LPE, I flew at 2m and 3m above the ground with few issues. I did make the following gain changes to make the optical flow more manageable:
Comparison vs. GPS

Params
MPC_ALT_HOME =  1 (Terrain following)
MPC_XY_VEL_MAX = 2
MPC_XY_P = 0.5
Video:
https://www.youtube.com/watch?v=Ttfq0-2K434
Log:
http://logs.uaventure.com/view/KwTFDaheRueMNmFRJQ3huH

@jgoppert  I think MPC_ALT_HOME should be MPC_ALT_MODE.

Yes, sorry for the typo.

@ecmnet @ilia-sheremet @kd0aij Tests with LPE and the latest beta branch would be much appreciated. Please also fly INAV with the same mission.

@LorenzMeier Last time I had this issue and nobody closed it yet. Will fly next week to try the latest firmware on different estimators.

@LorenzMeier I'm working on getting SITL to the point I can verify LPE is behaving correctly over various terrains and with optical flow. That should allow me to close open issues such as from @ilia-sheremet and @ecmnet  and get to the point they can flight test confidently. I will try to get it wrapped up in the next few days.


DOC: The LLM type given in the Caching section is incorrect. It should be changed from ChatOpenAI to ChatGPT

Issue with current documentation:
During the use of ChatOpenAI, it was found that even if langchain.llm_cache=True is set, the answer is different each time for the same question, such as "What is LangChain".
Upon tracing the source code, it was discovered that ChatOpenAI inherited BaseChatModel, which does not support the caching logic.
If the type of LLM switched from ChatOpenAI to ChatGPT, caching will be effective. Therefore, using ChatOpenAI in the LangChain Document example is incorrect, and should be replaced with ChatGPT. The corresponding address is: https://python.langchain.com/docs/modules/model_io/models/chat/how_to/chat_model_caching.
Idea or request for content:
It is suggested to modify the example and replace ChatOpenAI with ChatGPT.
llm = ChatGPT()

The base chat model does seem to support cache. Am i missing something here?:
https://github.com/hwchase17/langchain/blob/81eebc40702ff676c2f62c42ab4c6732ff794164/langchain/chat_models/base.py
class BaseChatModel(BaseLanguageModel, ABC):
    cache: Optional[bool] = None ##Caching supported in base model
    verbose: bool = Field(default_factory=_get_verbosity)
    """Whether to print out response text."""
    callbacks: Callbacks = Field(default=None, exclude=True)
    callback_manager: Optional[BaseCallbackManager] = Field(default=None, exclude=True)
    tags: Optional[List[str]] = Field(default=None, exclude=True)
    """Tags to add to the run trace."""

Thank you very much for your reply. The new version of BaseChatModel in LangChain already supports caching, and using the new version has resolved my question. Thank you for your response.


Upload the new updated conftest.py

Includes the new
from reportportal_client import RPLogger, RPLogHandler

Released in v1.16.1


Android 9 Fix

Background mode is not working for android 9. As it would not launch the Foreground service.
Based on android documentation FOREGROUND_SERVICE permission is required:

Note: Apps that target Android 9 (API level 28) or higher and use foreground services must request the FOREGROUND_SERVICE permission. This is a normal permission, so the system automatically grants it to the requesting app.
If an app that targets API level 28 or higher attempts to create a foreground service without requesting FOREGROUND_SERVICE, the system throws a SecurityException.
source

Also the service was not added correctly to the AndroidManifest.xml

Please Merge it!!

A merge would be appreciated!
@okhiroyuki Until this is merged you can add the following snippet to the Android platform section in your config.xml:
<config-file parent="/*" target="AndroidManifest.xml">
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
</config-file>

Full structure like this:
<widget id="com.example.app" version="1.0.0">
    [...]
    <platform name="android">
        <config-file parent="/*" target="AndroidManifest.xml">
            <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
        </config-file>
        [...]
    </platform>
    [...]
</widget>

@RafaelKr Thank you. It's a nice snippet!!

If i implement this Code it is working fine.
https://github.com/katzer/cordova-plugin-background-mode/issues/436#issuecomment-479880108

quick note: as per this comment by @Lazza, I had to include an entry in my config.xml for two permissions before I got this to work on my Xiaomi Mi Mix 2 with LineageOS 16.0 (Android 9.0.0):

android.permission.FOREGROUND_SERVICE
android.permission.WAKE_LOCK

can anyone else confirm this behaviour?

To add more information.  I also had to add the WAKE_LOCK permission.  I was also getting a "unbound prefix" error when I was trying to do the above work around.
To fix that I followed these instructions:
https://github.com/dpa99c/cordova-custom-config/issues/24

The xmlns:android="http://schemas.android.com/apk/res/android" attribute should be added to the root  tag inside the config.xml if you want to use .

+1 to merging this


Navigation by anchor seems to be off

This is probably a vitescript issues but when I navigate to an anchor
eg https://cap.cloud.sap/docs/get-started/in-a-nutshell#vue
the page doesn't seem to land at that anchor properly.
Sometimes it seems to be at the bottom of the page and sometimes just under the header at the top.
If I discover more about the behaviour I will add to this but as I said not sure if it is a vitepress issue or this repo?
(Ahha - if I dismiss the survey notice at the top it seems to be better.)

We are aware of this issue.  The behavior is caused by

The header offset which Vitepress doesn't take into account properly. I still need to report this.
Our Node/Java toggle which manipulates the DOM through JS.  This interfered with Vitepress' calculation of the scroll position.  We have changed this to CSS.  The fix is going to be available with the upcoming release next week.

Hi Nigel,
The fix is now publicly available.
Thanks,
René


Text input refocussing

The Toggl Desktop has the annoying habit of moving the focus of the text input at will.
Reproduce:
Start a task.
Stop the task.
Edit the task end-time.
Click on the black "titlebar" and start typing the new task name.
Actual result:
After typing a few characters of the new task name, Desktop moves the focus to the task name of the previous task and any characters typed appear at the end of the previous task's name.
Expected result:
I can continue typing the new task name, then press enter to have it start.

Could you please specify the platform you are using.

This is on Windows 10.
From what I see, it seems the of the "side panel" (where you can edit times) takes some time to process the change (communicating with the server, I assume), then moves the input focus afterwards.

I can reproduce this problem, it is in fact specific to Windows.
To reproduce

Edit an existing time entry (description is fine) and leave the edit screen open
Start typing into the "What are you doing" field
The text should jump from "What are you doing" to the description of the TE you just edited

This only happens when the edit screen is left open. If you close it (after editing the TE) there is no problem.
On macOS the app automatically closes the edit screen as soon as you click into the "What are you doing" field.
I tested this with .349

duplicate of #1995


Build results can be copied to theorycraft tab

Resolve #629 - Build results can be copied to theorycraft tab.

White screen when:

Optimize
Copy a build to TC tab
Go back to Optimize tab
Go back to TC tab
White screen

White screen when:

Should be fixed

Various hook dependency warnings


ARROW-12771: [C++][Compute] Fix MaybeReserve parameter in the Consume function of GroupedCountImpl

The parameter of MaybeReserve in GroupedCountImpl's Consume function is incorrect.
counts_.length() means the buffer's byte size, it should be replaced with num_groups_.  Otherwise, subsequent chunked arrays with more groups are skipped as counts_.length() is actually num_groups_*sizeof(int64_t)

CI failures look unrelated. I've restarted the failed jobs, will merge when everything's green


Support request - [Map page] Excess scrool bars on tooltips when scaling close to the element

Summary: [Map page] Excess scrool bars on tooltips when scaling close to the element
Issue type: Bug
Severity: Trivial
Assignee: @kmakarenko
Reporter: A.Khilko
Environment: Google Chrome Версія 61.0.3163.100 (Розробка) (32-розрядна версія)
Description:
Steps to reproduce:

Open page http://portal.demo.ehealth.world/
Go to Map link in header
Scale to the one of MSP on the map
Hover on the point so that a tooltip appears
Observe a tooltip
Actual result:
Vertical and Horizontal scroolbar appear
Expected result:
No scroolbar is shown
Attachment:

Verified


When using @alias imports, CRA v3.0.1 will fail in TypeScript production builds in CI

Craco is awesome to support @alias paths.  But with CRA v3.0.1 an annoying warning is generated when running a production build that will cause CI to throw an error when using TypeScript.
aliased imports are not supported
This is because of line 132 in:  react-scripts/scripts/utils/verifyTypeScriptSetup.js
paths: { value: undefined, reason: 'aliased imports are not supported' },
Resolving this seems out of the scope of Craco as it happens before the webpack build.
Leaving a solution here in case somebody needs it.
Install patch-package and comment out the line!
Hope this helps.
This will not be necessary when eventually CRA supports @aliases as they say that they intend to.

@euanmillar Do you have a source for the CRA team stating they intend to support @Aliases?


[KBFS-1489] Fix tricky edge cases in journalMDOps.PutUnmerged

Enumerate in detail the cases the mdJournal.put expects
to handle, and have journalMDOps.PutUnmerged simply forward
to mdJournal.put.
Add test coverage for all cases in mdJournal.put. Add more
test coverage for journalMDOps.PutUnmerged.

Looks good to me, just some comment suggestions.  Thanks!

CI failure is known kbfs-server login timeout.


merge from arlac77/template-arlac77-github,arlac77/template-esm-only,arlac77/template-node-app

.github/workflows/update_readme_api.yml

chore: add 14.10.0 (jobs.update_readme_api.steps.with.node-version)

Coverage increased (+0.1%) to 87.422% when pulling f9a73979751e415b5e70b2ee77de255e9f7b34ee on npm-template-sync/arlac77/template-arlac77-github,arlac77/template-esm-only,arlac77/template-node-app into c22976432d365ef7ac82f07522a593ea8507d8f9 on master.

:tada: This PR is included in version 9.15.9 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Figure out how to remove dependency on Gorilla framework

Gorilla framework is now in deprecated mode and we need to have a plan how to remove dependency on it

Red Hat members is going to work on Gorilla framework, so no deprecation on our side is needed.


Fix(eos_designs): Tags not inherited from profile

Change Summary
Tags not inherited from svi_profiles in network_services
Component(s) name
arista.avd.eos_designs
Proposed changes
TBD
How to test
Updated molecule test

This is a new feature and will take time to implement


Update of contribution guidelines

Description
Currently we have several locations that describe how contributions shall be performed:

Contribution guidelines are in CONTRIBUTING.md.
PR checklist in PULL_REQUEST_TEMPLATE.md
Guidelines in the documentation like the Rust coding guidelines and the Documentation guidelines.

Goal
I think that usually the CONTRIBUTING.md file is considered as the starting point for contributors and thus shall reference all other guidelines.
Final result
Summary
CONTRIBUTING.md file is considered as the starting point for contributors and references all other guidelines. To ensure that the contributing guideline is also followed, it shall be referenced in the PR checklist in PULL_REQUEST_TEMPLATE.md
Tasks

[ ] Update  CONTRIBUTING.md s.t. it requests:
** compliance to the following guidelines:
*** code of conduct
*** Rust coding guidelines
*** unit verification strategy
** making sure that the following documents are also up-to-date:
*** software design incl. linkage in code and tests
*** Ankaios user documentation (if adding new features)
[ ] Update PULL_REQUEST_TEMPLATE.md to request compliance to the CONTRIBUTING.md

I've updated the first task with more information and added a new task to reference the CONTRIBUTING.md in the definition of done for the pull requests (PULL_REQUEST_TEMPLATE.md checklist).

Fixed with #66


FR: Installation Validation Tool

Describe the feature request
Istio should provide a tool that can verify that a cluster has a "complete" install for a given release. This tool could be istioctl, a la istioctl verify-install --version 1.0.2 or similar.
As discussed at the last Policies and Telemetry WG, there are many examples in the wild of partial installs of Istio leading to user confusion and operator pain. The partial installs can be caused by any number of issues, from Istio version upgrade to errors during kubectl apply -f executions to issues with helm itself.
Obviously, validation of install gets a bit tricky, as users/operators are free to customize config artifacts, etc., but I feel like for default / first-time users, as well as support use cases, there is a baseline validation that should be possible.
One possibility would be to generate metrics on Istio-related resources and then run queries to retrieve those values and compare against a baseline generated with each Istio release.
Describe alternatives you've considered
Absent providing an explicit tool, perhaps Galley could expose a metric/endpoint that indicates the version of Istio that it believes is installed. So, maybe istio-galley:9093/versions/istio could return a string like istio-1.0.2-default or istio-1.0.2-dirty (where when -dirty appears, additional lines detail the diff from a "default" install) or unknown (to indicate the install base does not match baseline for any known Istio version).
Additional context
/cc @geeknoid @ozevren @ayj @theganyo

Galley doesn't have access to topology information. We might add in the future, strictly for config distribution purposes, but I don't think it is otherwise a reasonable place to make this deduction at this point.
An "Istio Controller" that performs actual Istio deployments might be a better place for this. In fact, the configuration of such a controller can be the place for deducing such things.
What was the most common cases? Given the information above, it looks like this is an "errors during installation being ignored by the user" problem more than anything else. (This is akin to program installation. If it fails, there should not be a reasonable expectation of correctness). Was there more to the issue?

There was a long thread recently on the #general channel that was related (names, etc., removed here):
Hi All, a bit of a newbie question but I am running through the bookinfo example and I get the following error when trying to create the gateway and virtualservice, anyone else encountered this? unable to recognize "samples/bookinfo/networking/bookinfo-gateway.yaml": no matches for kind "Gateway" in version "networking.istio.io/v1alpha3"

`kubectl get crds | wc -l` plz (edited)
if it is not a large number, like 45+, the crds are not installed

thanks, much appreciated, the number is 46

that sounds close
run `kubectl get crds | grep Gateway`

done, should it now work as i still see 46

that should output a 1 liner

$ kubectl get crd | grep gateway
gateways.networking.istio.io           1d

gateways.config.istio.io                                  30d

Notice the diff in namespaces for gateways config. That problem was resolved via:
kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml

I'm not sure that we can pin such issues exclusively on "users ignoring error messages". A simple helm install generates a large amount of information that flies by on the screen. That information is mostly meaningless to an average human.
And, even if that were the root cause, it would be nice to have a simple tool that is doing the kind of installation validation that was manually attempted here. Instead of saying "you should see something like 45 CRDs", we should be able to have a simple "run this tool. does it report errors?" support.

Not denying the validity of the problem, but being able to easily figure out a failure at the point of failure (i.e. install/upgrade) seems to be a much more valuable thing to have than being able to tell after it happened.
I am not aware of any, but I am wondering if there is some tooling we can already use to cheaply detect this for diagnostic purposes: Something that can read the current config state and diff against a representative Yaml perhaps? I don't think this is an Istio specific problem in this regard.

... Something that can read the current config state and diff against a representative Yaml perhaps? I don't think this is an Istio specific problem in this regard.

Diagnosing and fixing the problem would also be useful. e.g. a reconciliation loop that ensures the actual Istio install matches the desired state.

For the long term, an "Istio controller" is probably the right solution to this problem. As a bona fide Kubernetes controller, it would do reconciliation and avoid "half-install" problems.
For the short term though a cheap, diff-based solution might give us a very good mileage.

I tend to find the most common failure case in bug reports is probably a documentation issue in that evaluators often skip step #1 (apply CRDs) and jump right to step #2 (apply Istio yaml).
It probably doesn't help that sometimes people don't read the documentation at all :)
The challenge of a generic deployment validation tool is determining "what makes a deployment valid" - this is typically uniquely individual to each component, and requires component level understanding coupled with a holistic view of the components interactions with one another and their configuration.  This same challenge is what makes installation so challenging to even get right, as well as upgrade and reconfig.  Validation seems achievable; would like to see us having upgrade and reconfig working well in addition.
Cheers
-steve

I think this will be particularly useful as I know there are times I thought my istio env is good enough but it is not.   This can especially happen after i run helm upgrade a few times to switch among different configurations.
Is it possible to do this on the client side like istioctl?  Having Galley handle the server side is fine if it exists but there are scenarios where Galley isn't even installed, see https://istio.io/docs/setup/kubernetes/minimal-install/

Here is a straw-man design for a tool:

Capture/retain the setup Yaml file (i.e. Helm/tiller based deployments will not be supported).
Tool parses the Yaml file and extract resources generically.
For each resource type, apply validation functions:

Generically, for each resource, check that the resource exists or not.
If the Kind of the resource is recognized, then run an appropriate Kind specific code for validation. As an example, if Kind == Deployment, ensure that the deployment has completed successfully.
In addition to 1-1 validation, allow set validation rules (e.g. for Kind == Deployment, you cannot have additional deployments in the same namespace). These can be pretty generic.

Add point-wise specific checks as needed through custom code, as we identify gaps.

Does this sound like a reasonable approach to a tool?

@ozevren that sounds reasonable to me. and likely to provide some useful debug bits (diffs between versions), etc. a first pass that just did simple counts might also be enough to start.

@ozevren while validating yaml is helpful, I think it is more valuable to validate against a running env like k8s to see if istio is installed properly, for a given feature or profile.  In my case, I always start with recommended istio yaml or helm chart (which is golden and tested by our tests framework) but still ends up with non functional istio env.

This is about validating against installed Istio.
The tool would diff the yaml on-hand against the state from API Server.
On Thu, Sep 20, 2018 at 6:34 PM Lin Sun<EMAIL_ADDRESS>wrote:

@ozevren https://github.com/ozevren while validating yaml is helpful, I
think it is more valuable to validate against a running env like k8s to see
if istio is installed properly, for a given feature or profile. In my case,
I always start with recommended istio yaml or helm chart (which is golden
and tested by our tests framework) but still ends up with non functional
istio env.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/8663#issuecomment-423385637, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQR8IzqyCOqNSTlD8Q2fyXQupEIr25a9ks5udEIRgaJpZM4Wluku
.

Ok cool, I missed that.   would you propose to do this within istioctl against a running k8s?

istioctl has been the default place to put things in, so it probably makes sense to put the command-line portion there.
The core logic should be a library though. It would be useful for tests as well.

cc @irisdingbj who expressed interest in working on this.

Will add command like "istioctl install-validate -f istio-demo.yaml" to validate the status from api server against the install file user used.

@linsun @ozevren @ayj @douglas-reid Does above command work? If so I will begin to implement it.

It sounds reasonable to me. I might just call the command validate (and maybe have a subcommand of install) for simplicity, but otherwise that seems reasonable to me.

+1 thank you @irisdingbj !  for -f, it would be great if it can take a url or local file.
istioctl validate -f xx.yaml works for me.

one thing is our profiles today assume CRDs are installed too, and CRDs could change among releases, so it would be useful to have a -v flat to pass in versions of istio.

istioctl validate already exists for validating user authored configuration. Maybe istioctl validate-install or istioctl check-install? Also, we may want to put this under istioctl experimental while we experiment with the requirements/implementation.

Agreed with @ayj. Please put the command-line under experimental, and let's not use validate.
How about verify-install?

ok if validate already exist (I don't see it in my 1.0.2 istioctl), i'd agree not use it.
Now, do we expect this cmd to just validate install?  Would it be convenient for the user to also print out control plane status??  It is like give me my istio status which install is a key piece of.

how about istioctl mesh-info?

Can we keep it scoped for the time being? We can add new features, or make
it part of a bigger feature as we make progress.
On Thu, Oct 18, 2018 at 10:35 AM Lin Sun<EMAIL_ADDRESS>wrote:

how about istioctl mesh-info?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/8663#issuecomment-431096733, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQR8IwXaG4kwW3z-0XTXXaWa6p7QMxcWks5umLvfgaJpZM4Wluku
.

one thing is our profiles today assume CRDs are installed too, and CRDs could change among releases, so it would be useful to have a -v flat to pass in versions of istio.

Yeah, this might be easier/better UX: istioctl experimental verify-install -v 1.0.2-demo (in case you don't have the exact generated file in front of you... not sure exactly what that case would be, but...).

I don't think we should try to do this. The tool is meant to be tactical
(i.e. given a yaml file, see if it is installed correctly). This is a
simple problem with a straightforward implementation, and is a simple
diagnostic utility.
Given that with Helm, we can specify numerous options to generate a huge
variety of Yaml files, I don't think we can exhaustively and meaningfully
say what "version xxx Istio" looks like.
IMHO, the actual problem should be fixed by a Istio application/add-on
controller that can continuously reconcile the state of Istio. That should
obviate the need for such a tool.
On Thu, Oct 18, 2018 at 6:25 PM Iris<EMAIL_ADDRESS>wrote:

Thanks all for the comments. I think we all agree with "istioctl
experimental verify-install -f istio-demo.yaml". One issue now is the "-v"
option, for example if we use -v option, how can we get the related
crd.yaml and istio-demo.yaml? Should we add logic to get them online
similarly with "curl -L https://git.io/getLatestIstio | sh -" ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/8663#issuecomment-431215056, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQR8I5BkmzmTAQCyUBXYcRvdZU5z7m-Dks5umSnsgaJpZM4Wluku
.

I agree, our install is highly customization so it makes sense for user to feed us the yaml.

@ozevren @linsun  @ayj  @douglas-reid  The initial implementation is ready at https://github.com/istio/istio/pull/9468, Please let me know your comments. Many Thanks~

This has already been delivered in https://github.com/istio/istio/pull/9628


fix(deps): update terraform-module

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/kms-all-inclusive/ibm (source)
module
patch
4.15.11 -> 4.15.12

terraform-ibm-modules/secrets-manager/ibm (source)
module
patch
1.18.1 -> 1.18.2

Release Notes

terraform-ibm-modules/terraform-ibm-kms-all-inclusive (terraform-ibm-modules/kms-all-inclusive/ibm)
v4.15.12
Compare Source
Bug Fixes

deps: update terraform ibm to latest for the deployable architecture solution (#546) (23941aa)

terraform-ibm-modules/terraform-ibm-secrets-manager (terraform-ibm-modules/secrets-manager/ibm)
v1.18.2
Compare Source
Bug Fixes

deps: update terraform-module (#197) (945a308)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

:tada: This PR is included in version 1.19.12 :tada:
The release is available on:

GitHub release
v1.19.12

Your semantic-release bot :package::rocket:


Thank you

Riot was the very first project I ever contributed to on github.  You & alex were really friendly and helpful even though I was a total noob and didn't know what I was doing at all.
Just wanted to say thanks a ton for your patience and kindness back in the day.  I've mostly stopped using ruby now, but I saw a news item for this repo pop up in my feed & just wanted to let you know you guys are great.

Love to close 5 year old issues :)


Publish roadmap and canvas

We have worked on those and both are almost finished. We need to make a push and conclude these and publish this on the web since I believe these will be very useful. Right now this work is not visible.

@bast please attach the roadmap and canvas document here.

Roadmap (probably quite outdated by now) and open canvas documents are now attached.
CodeRefinery Open Canvas.pptx
CodeRefinery Roadmap.docx

We are now 4 years later and did not manage to pick this up. Closing.


Ignored files can't be found in folder tree.

Add an option to keep it.

@rockmandash
Thank you for your suggestion!
It seems similar to #181, but the requirement is indeed different.
I understand there's a need to show ignored files in the file structure. However, simply showing all of them would raise issues like how to handle node_modules, and ignoring only a part of them doesn't seem like a clean solution either.
I think the approach in #181 might be a better way to go, but I'm not entirely convinced yet. I'd like to think about it a little more.


Port shape estimation to .auto

Description
.auto porting for shape estimation
Review Procedure

Remarks

Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.

[x] Read pull request guidelines
[x] Code follows coding guidelines
[x] Assign PR to reviewer

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code follows coding guidelines
[ ] (Optional) Unit tests have been written for new behavior
[ ] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets
[ ] Write release notes

CI Checks

Build and test for PR / build-and-test-pr: Required to pass before the merge.
Build and test for PR / clang-tidy-pr: NOT required to pass before the merge. It is up to the reviewer(s). Found false positives? See the guidelines.
Check spelling: NOT required to pass before the merge. It is up to the reviewer(s). See here if you want to add some words to the spell check dictionary.

大変申し訳無いのですがspellcheckでConvexhullで引っかかるのでConvexHullに変えてもらってもいいでしょうか？ :pray:

@yukkysaito I fixed typo(Convexhull -> ConvexHull) at https://github.com/tier4/AutowareArchitectureProposal.iv/pull/551/commits/e251e92e52b6a7e82474f88aa79cc7ec378e94e9.

@yukkysaito Can I proceed to merge?

Hi everyone, I am planning port tier4's shape_estimation to Autoware.Auto. Releted Issue here : https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/1399
I think you are already changed its message type to new Autoware.Auto message type. Does anyone working this porting?
Thanks.
@wep21 @yukkysaito

@kaancolak
Thank you for comment.
This shape estimation was made to support the new type of Autoware.auto.
but autoware_auto_msgs have not been merged, and I ported under the assumption that these changes have been merged.
https://gitlab.com/autowarefoundation/autoware.auto/autoware_auto_msgs/-/merge_requests
We plan to deploy this repository to the AWF Autoware.Auto.Universe by the end of December.
If you have any questions, please contact me or @mitsudome-r


There might be a bug which leads to ClusterAutoScaler fails to handle the ResourceExhausted situation

What happened:
We are creating multiple worker groups for every kind of workload so that we can fallback to other worker groups when the major one is unhealthy, resource exhausted for example.
It is hard for me to reproduce it in the real world.
But if I read the source codes correctly there might be a defect for the situation.
The provider's CreateMachine function returns error code codes.Internal for all kind of errors.
But cluster auto scaler needs error code codes.ResourceExhausted here, so that it can backoff the group when handleInstanceCreationErrorsForNodeGroup
Here is how aws provider handle with it.
What you expected to happen:
When resource exhausted, it should return correct error code to cluster auto scaler.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know:
Environment:

Similar to https://github.com/gardener/machine-controller-manager-provider-alicloud/pull/57

Hi @dongyingbo, with https://github.com/gardener/machine-controller-manager-provider-azure/pull/105, we move to use the latest azure API. With this change we also introduce the ResourceExhausted error code.

In the first increment we only map ZoneAllocationFailed. See here (This link is from the PR @rishabh-11  pointed to above, which is current under review). As and when we learn of other error codes we will keep adding to this list.

/close
#105 is already merged and released.


Implement I0 emotes

This will take several steps to accomplish.

[x] Implement slash commands for all emotes
[ ] Implement emote text using the emote channel (relies on #175)
[ ] Implement animations to accompany emotes

I have completed task 1 in my local repository. I'm holding off on a PR as it also contains my readme and DLL transfer edits, which are not yet perfected.

Task 1 has been officially completed in master, though it looks like you already took care of that!

@nemerle, should I close this issue for now, and reopen a new (broader) one for animations? Or leave it open and reference this issue from a new one for animations?

I'm going to close this for now, as animations and FX are a ways away.
Great job on this @erpmario!


Non-trailing optional parameters

I was going through the parameter-freedom proposal and wanted to comment on something but I didn't know how, so I'm leaving my comment as a github issue:
The reason all languages require optional parameters to appear in the end is because of ambiguities in cases like this:
void foo([int x = 0, int y = 0], int z) {
  // ...
}

foo(10, 20);

Obviously, the 20 goes to z in the above example. But what about the 10? If the 10 goes to x, then it feels weird that I'm passing two adjacent arguments 10 and 20, but they are going to the 1st and 3rd parameter.
Just my 2 cents :) And great work by the way, I love this project!
Also, there's been some relevant discussions here: https://github.com/dart-lang/language/issues/58 about rest parameters.

I was going through the parameter-freedom proposal and wanted to comment on something but I didn't know how, so I'm leaving my comment as a github issue

Yup, that's fine. :)
You can also file issues on the language repo as this work migrates over there. (I started in this repo before the language repo had been set up, but now that that's up and running, I'm gradually moving this over there.)

The reason all languages require optional parameters to appear in the end is because of ambiguities in cases like this

Ruby actually doesn't require optional parameters to be trailing.

But what about the 10? If the 10 goes to x, then it feels weird that I'm passing two adjacent arguments 10 and 20, but they are going to the 1st and 3rd parameter.

The parameter freedom proposal lays out what happens here. It does the same thing that Ruby does, which is that 10 goes to x. It is a little weird that it "skips" over a parameter, but the signature of that function is kind of weird too. If you design weird APIs, it's gonna feel weird to use them. :)

Ruby actually doesn't require optional parameters to be trailing.

I didn't know Ruby allowed that so I just looked at it. It's confusing at best and requires extra-concentration and mental gymnastics to figure out which value is going to which parameter 🤔 I've yet to see a strong, practical use case for this pattern.

The parameter freedom proposal lays out what happens here.

I know 😊 I'm just using it as an example to explain the ambiguity and confusion.
To be honest, I'm not a big fan of APIs that behave differently based on the number of arguments. Or, god forbid, the jQuery-like APIs that have a gazillion combinations of args.

To be honest, I'm not a big fan of APIs that behave differently based on the number of arguments.

In general, any language feature can be overused to the point of regret and I don't think overloading is any different in that respect. But it is really handy to be able to omit certain parameters in some cases. Dart's current rules for handling that cover a lot of the useful cases but not quite all of them.


Custom collections styling

Here are two options for displaying custom collection membership for packages in the SSWG collections:

I’m using the badge property of the metadata to create the lozenge and then the name after that. Multiple collections are in a listPhrase. For the screenshot, I have manually adjusted the collection name to not include the letters “SSWG”. We’d need to adjust the PackageList JSON to make that permanent.
I thought I’d prefer the separate badge when I set out to design it, but it doesn’t look like a link and it didn’t fit well where I first wanted it to go, under the package title.
I think the list item is the way to go.
Here's an alternative on the lozenge:

Let me know which one the workgroup prefers.

For the screenshot, I have manually adjusted the collection name to not include the letters “SSWG”. We’d need to adjust the PackageList JSON to make that permanent.

This looks great!
The only issue I see is that if we drop the "SSWG" from the name, we end up with "Graduated package collection" on the collection page:

We can fix that by simply prefixing it with the badge there. Or should we replicate the lozenge?

FYI, I'll rebase this branch because the blog post one is based on this branch.

Was there any feedback from the SSWG on this design? The metadata one would be my preference, did they agree?

They were happy with either, we mainly talked about the process to get the json files hosted tbh (this was on Nov 20).

I'll wrap this up today then.

This is ready for a final review and can go live whenever.


Add extraction function support for Dimension Selector

Some minor comments but overall LGTM

if there are no more comments, can i squash the commits?

:+1:

can we merge this?

:+1: (after travis)


Documentation: Creating a SOAP Client

The documentation about create a SOAP proxy client needs some improvment (IMHO):
quarkus.cxf.endpoint."/fruit".client-endpoint-url=http://localhost:8080/
quarkus.cxf.endpoint."/fruit".service-interface=org.acme.cxf.FruitWebService

(A) The example assumes an (external) endpoint published at address http://localhost:8080/fruit featuring SEI org.acme.cxf.FruitWebService. It is not obvious that "/fruit" and the value's property are joined to become the final address.
(B) The configuration of such a client proxy is currently (0.6.0-SNAPSHOT) possible for a truly external service, only for a service without an implementation. Here's an example:
@WebService
public GreetingImpl implements GreetingService {}      // Here we have IMPL and SEI
@WebService
public interface FruitWebService {}                                 // SEI only, no IMPL in classpath

Given this setup, then
@Inject GreetingService greetingClient;                        // This works regardless of any config in application.properties

@Inject FruitWebService fruitClient;                               // This bean is produced by quarkus-cxf if a configuration
                                                                                // like above is present, otherwise not.

Viewed from another angle being application.properties:
quarkus.cxf.endpoint."/greet".client-endpoint-url=http://localhost:${quarkus.http.port}/
quarkus.cxf.endpoint."/great".service-interface=org.acme.cxf.GreetingService
quarkus.cxf.endpoint."/great".features=org.apache.cxf.feature.LoggingFeature

This setup is or appears to be silently ignored.
For reasons of consistency it would be really smooth if there is no difference - configuration of an internal or  external service should follow the same pattern.

(A) The example assumes an (external) endpoint published at address http://localhost:8080/fruit featuring SEI org.acme.cxf.FruitWebService. It is not obvious that "/fruit" and the value's property are joined to become the final address.

+💯! This is really confusing currently because it doesn't make sense having to set a relative path for a client.
I'd find it way more intuitive to just freely choose some descriptive name instead of a relative path. The value of the property would then be the full URL.

Btw: What if that external webservice doesn't use a context path at all and is instead reachable directly via http://localhost:8080/? Is the infix then just "/", e.g. quarkus.cxf.endpoint."/".client-endpoint-url=...?

I guess that would be the logical consequence.
In addition: what if there are two services published at "/" or, more generally, published with the same path, i.e.
https://allfruits.com/fruits
https://worldfruits.com/fruits

@famod I know . For config, I start with server and hen I work on client, I want to reuse same config to simplify work and I never came back to it. And I was afraid to change format of config later for backward compatibility. Anyway @wh81752 take the point and a big patch will arrive for that.

@dufoli I get it, start simple and reuse stuff, make it more complicated later. 😁

easiest way to create a soap client is just treat it as XML over HTTP and simply use resteasy jaxb to marshall the response xml. Easy if you hav a simple request xml body.
However, looking for a templating engine that will make marshaling the request easier when the request body xml is more ocmplicated.

Hi @tbkahuna48 The purpose of this extension is to leverage CXF to support the myriad of WS-* specifications and standards.
Having said that, if the use case is very simple - one can leverage just the Quarkus REST client to invoke an HTTP SOAP endpoint, without even having a need to marshal the response using RESTEasy JAXB.

However, looking for a templating engine that will make marshaling the request easier when the request body xml is more complicated.

I'm not sure what you mean by the above?  You can auto-generate your Java model classes from any schema, and then use those for JAXB marshaling.  I don't quite see how a templating engine fits in with JAXB.

Sorry mixed dialog there. The template freemarker - just makes it easy to create the xml content for the  request body without needing a pojo for marshaling. The quarkus jaxb stuff makes it easy to use buildEntity(Some.class) on the returned response to marshal the response content.  However, soap messages , particularly when tags have attributes, so just wishing there was some utility to marshal something that less ugly.


Failed to fetch organization locally

I've set up Nexus locally with docker. However, when running nexus web auth, the web page displayed an error message as follow:

Also, no organization shows up although I create one by using CLI.
Are there other settings that should set before I use web auth?  I tried to create a Realm but not helpful to it.

Hi @yiiifan, I believe the correct command is nexus auth web. However, you won't be able to login unless you create a realm first.
Regarding organizations not showing up in web, do they show up when you run nexus orgs list?

I could see organizations I created if I run nexus orgs list. I've created realms by okta but I still can't see any login button and get error for failing to fetch organization on web . Here is the payload for creating a new realm:
{
    "name": "Nexus Test",
    "openIdConfig": "https://{okta-account}.okta.com/.well-known/openid-configuration"
}

and its response is :
{
            "@id": "http://localhost/v1/realms/realm1",
            "@type": "Realm",
            "name": "Nexus Test",
            "openIdConfig": "https://{okta-account}.okta.com/.well-known/openid-configuration",
            "_label": "realm1",
            "_grantTypes": [
                "authorizationCode",
                "implicit",
                "refreshToken",
                "password"
            ],
            "_issuer": "https://{okta-account}.okta.com",
            "_authorizationEndpoint": "https://{okta-account}.okta.com/oauth2/v1/authorize",
            "_tokenEndpoint": "https://{okta-account}.okta.com/oauth2/v1/token",
            "_userInfoEndpoint": "https://{okta-account}.okta.com/oauth2/v1/userinfo",
            "_revocationEndpoint": "https://{okta-account}.okta.com/oauth2/v1/revoke",
            "_endSessionEndpoint": "https://{okta-account}.okta.com/oauth2/v1/logout",
            "_rev": 1,
            "_deprecated": false,
            "_createdAt": "2020-05-15T18:58:20.018Z",
            "_createdBy": "http://localhost/v1/anonymous",
            "_updatedAt": "2020-05-15T18:58:20.018Z",
            "_updatedBy": "http://localhost/v1/anonymous"
        },

Is this a right way to create a realm? Let me know if I misses some part...
Thanks very much

Updates about this issue:
I found everything works fine on my local.
But on the server, version URL is still being called by http://localhost/version
instead of http://{server-URL}/version, so nothing could show up

@yiiifan The realm creation looks correct.
If you deployed the app on a server you need to update the public URL by setting the environment variable https://github.com/BlueBrain/nexus-kg/blob/master/src/main/resources/app.conf#L31

What should I do if I set up it by docker? I tried to change PUBLIC_URI of kg environment in yaml file but it not works...

deploying with docker swarm on a remote server causes, problems. it works fine if its the page is requested from the same host, but if its requested from a remote host, it forwards request to localhost always. problem with docker bluebrain nexus image

@mdamanuddin have you updated the docker template to replace all localhost references to the ip (or hostname) of the "remote server"?

changing localhost reference to the IP fixed the issue.

@yiiifan have you tried to make the same change? does it work for you?

@yiiifan have you tried making the same changes as @mdamanuddin ?

Closing due to inactivity.


Bug in materialize website ( support us page and css Typography page )

The menu icon is collide with title of the page in responsive design ( model : Moto g4 plus )
Reduce the size of title will help you to remove that bug

#

I would like /claim this issue

@johnschult @italomaia @douggr Will you please guide me where is this 'support-us.html' file located in the repo, help me to fix this bug??


network drives?

hi,
nice lib but what about network drives? Any pointer how to add this?
thank you

Interesting feature. What OS are you running?
If you're running an UNIX based OS, are the network drives being registered as /dev/ devices?

I will need only for mac & windows then. I am trying to build custom file picker with it. Any glue where to go for windows? I think there are windows CLI commands to get a list of the mapped drives.

yeah, parsing 'net use' will do for me, and for linux 'df -h' seems ok too, (i dont need the stats). now I just need to figure it for mac and done ;-)

ah, df -h works on mac too. For me its done, i will implement this in my fork but I doubt I will make a PR since i will remove coffee script as well.


Change RuntimeShape to support max size of 6 dimensions.

Our upstream sync with TF is broken due to b/275337654 which introduces 6D usage in the Add operator.
RuntimeShape.h is managed separately for TFLM vs TFLite.
Since we do not have dynamic memory allocation, we have to explicitly set the max number of dimensions, as previously it was 5.

Changing the max size to 6 to support the changes to Add.
BUG=276954955

Will it be possible to change kmaxsmall size to 6 in a separate PR and then have the sync pr get merged as is?

Yes. Will remove those files from this PR.


atomically write checkpoints, tx history and delegation certs when discovered

Issue Number

#899
Overview

[ ] I have adjusted the restoration loop to atomically write checkpoints, tx history and delegation certs when discovered

Comments

bors r+


chore: Bump karpenter-core

Fixes #
Description
Bumps karpenter-core, staging out the changes for the Machine migration
How was this change tested?

make presubmit
Manual Consolidation Testing
Manual Inflight Check Testing
FOCUS=Integration make e2etests succeeded
Validating metrics through manual testing with Prometheus

Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

Release Note

None

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

All tests pass
:white_check_mark: utilization-pr-3596-lgkbc tests passed
:white_check_mark: interruption-pr-3596-4q25q tests passed
:white_check_mark: drift-pr-3596-hr6qs tests passed
:white_check_mark: ipv6-pr-3596-wdf6s tests passed
:white_check_mark: chaos-pr-3596-qfxzj tests passed
:white_check_mark: consolidation-pr-3596-qw8lv tests passed
:white_check_mark: upgrade-pr-3596-8q5n2 tests passed
:white_check_mark: integration-pr-3596-zgbkj tests passed


Add support for Mac Roman character encoding

Add support for Mac Roman character encoding.
Incoming strings from the client will be assumed to be Mac Roman encoding instead of ASCII and converted to UTF-8.
Outgoing strings will be converted from UTF-8 to Mac Roman.
Mac Client:

Server file system:
❯ ls
HéLLø                   My Cool Stuff ƒ

Fixes #37


Fix jenkins badge to display master branch status

Signed-off-by: Andy Goldstein<EMAIL_ADDRESS>

Looks like this job has only run once? what needs to change to get it to build on PR merge?

I had it misconfigured. It should be good to go now. We'll see on the next merge.

Ah, ok. Let's try it out with this one then. LGTM.

It's working!


Add logging crate

Add bevy's logging for debug builds, so that using --release the user sees nothing, but if they have issues (like I was) we can tell them to run it without the release flag and all will be revealed.

Note: closes https://github.com/DGriffin91/bevy_mod_environment_map_tools/issues/1


Various bug fixes

Coverage remained the same at 49.31% when pulling 15ed06192960a028e1a3b14470559c2571202787 on m3brown:master into 05b70e81586e860adb462f4bf0c0d55861cc2ebf on excellalabs:master.


[bug] aks-secure-baseline add-on doesn't work when using an user-assigned identity (user-msi)

Issue
aks-secure-baseline add-on doesn't work when using an user-assigned identity (user-msi)
To Reproduce
Steps to reproduce the behavior:

Create an AKS Cluster using UserAssigned identity
Apply the aks-secure-baseline (v1 or v2) add-on on the configuration
See error in the below screenshot

Expected behavior
The principal id value cannot be null when you do a role assignment. This value needs to be fetched from managed identity  and used while doing the role assignment using the user msi.
Screenshots

PR submitted - https://github.com/Azure/caf-terraform-landingzones/pull/238

Hello, I am having another issue after the PR merged (screenshot below). Had no error earlier while running this aks_secure_baseline_v2.

Should all be fixed in 2108.0, let us know!


Gh-2954: Remove mentions of v2-alpha

Related Issue

Resolve #2954

This needs to happen after merging v2-alpha into develop


v3.0.0

Various small fixes that shouldn't change the behaviour. Plus one behaviour change - make sure /wp-admin/admin-ajax.php requests are blocked too.

Oops.
If you're editing a post, the page sends heartbeats back to WP to check you're still logged in (POST /wp-admin/admin-ajax.php action=heartbeat).
Normally WP shows you a login overlay when you become logged out. But with this change that doesn't happen.
Okay, we need to block all unauthenticated admin-ajax requests except heartbeats.


Connections associated with partially iterated tables aren't close when client is stopped, for H2 database

Description:
var selectRet = testDB->select("SELECT int_type from DataTableRep order by int_type desc", ResultPrimitiveInt);

testDB.stop();

This is because HikariCP does abort active connections[1] but, H2 database does not support abort operation[2]. Therefore this cannot be fixed at the Ballerina level.
[1] https://github.com/brettwooldridge/HikariCP/blob/HikariCP-3.2.0/src/main/java/com/zaxxer/hikari/pool/HikariPool.java#L515
[2] https://github.com/h2database/h2database/blob/version-1.4.197/h2/src/main/org/h2/jdbc/JdbcConnection.java#L2020


Use cheaper runner for CI

16-cores costs $0.064/minute. 8-cores costs $0.032/minute. The default 2-cores costs $0.008/minute.

Looks like tests are executing in the same amount of time with the smaller runner. Thanks, @erbridge!