$::jenkins::port does not properly manage listening port

Unless I'm mistaken $::jenkins::port does not properly manage the listening port on EL 7:
Consider the following snippet:
class { '::jenkins':
  port => '80',
}

When applying this adjustment the config file remains unchanged.
# grep -ri jenkins_port /etc/sysconfig/jenkins
JENKINS_PORT="8080"

Which obviously results in the module not being able to manage a number of settings:
Notice: /Stage[main]/Jenkins::Service/Service[jenkins]/enable: enable changed 'false' to 'true'
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: java.io.IOException: There's no Jenkins running at http://<IP_ADDRESS>:8080/
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 	at hudson.cli.CLI.getCliTcpPort(CLI.java:288)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 	at hudson.cli.CLI.<init>(CLI.java:128)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 	at hudson.cli.CLIConnectionFactory.connect(CLIConnectionFactory.java:72)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 	at hudson.cli.CLI._main(CLI.java:479)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 	at hudson.cli.CLI.main(CLI.java:390)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 	Suppressed: java.io.FileNotFoundException: http://<IP_ADDRESS>:8080/cli
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 		at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1626)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 		at hudson.cli.FullDuplexHttpStream.<init>(FullDuplexHttpStream.java:78)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 		at hudson.cli.CLI.connectViaHttp(CLI.java:158)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 		at hudson.cli.CLI.<init>(CLI.java:132)
Notice: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: 		... 3 more
Error: /usr/bin/java -jar /usr/lib/jenkins/jenkins-cli.jar -s http://<IP_ADDRESS>:8080 groovy /usr/lib/jenkins/puppet_helper.groovy set_num_executors 3 returned 255 instead of one of [0]
Error: /Stage[main]/Jenkins/Jenkins::Cli::Exec[set_num_executors]/Exec[set_num_executors]/returns: change from notrun to 0 failed: /usr/bin/java -jar /usr/lib/jenkins/jenkins-cli.jar -s http://<IP_ADDRESS>:8080 groovy /usr/lib/jenkins/puppet_helper.groovy set_num_executors 3 returned 255 instead of one of [0]
Notice: /Stage[main]/Jenkins/Anchor[jenkins::end]: Dependency Exec[set_num_executors] has failures: true
Warning: /Stage[main]/Jenkins/Anchor[jenkins::end]: Skipping because of failed dependencies
Notice: /Stage[main]/Jenkins::Cli::Reload/Exec[reload-jenkins]: Dependency Exec[set_num_executors] has failures: true
Warning: /Stage[main]/Jenkins::Cli::Reload/Exec[reload-jenkins]: Skipping because of failed dependencies
Notice: Applied catalog in 103.02 seconds

@arioch The port parameter appears to not presently do anything.  A refactor of both the port handling and the docs is needed but the former is tricky to do without breaking backwards compatibility.
TL;DR -- try this instead:
class{ 'jenkins':
  config_hash => { 'HTTP_PORT' => { 'value' => '9090' }},
}

Ps. - I doubt you'll be able to bind jenkins directly to a privileged port with the current init script.  I suggest using iptables or a proxy server -- I use nginx in front jenkins.

@arioch I'm going to close this ticket since it is a duplicate of #214 but please let us know if the example I provided doesn't solve the problem.

@jhoblitt Your workaround doesn't work. It still persists HTTP_PORT=8080 in /etc/default/jenkins.


[Bug] Display only Parent items and Display Child items are not functional

Description
Release/Production - MultiTreeSelect - It is observed that display only parent items and display only child items options are not not functional
Expected Result:
Choosing display only Parent items should display the parent item in the widget and display only child item should display only child item in the widget. Currently for all the three options - All values are displayed
Steps to reproduce the behaviour:

Launch Appsmith app in release/Production environment
Drag and drop MultiTreeSelect Widget
Choose Display only parent item in mode field and observe
Choose Display only child item in mode field and observe

videolink:
https://loom.com/share/339c18aa84564225abefe7af4a0d5933
Important Details

Version: [11.3]
OS: [MacOS]
Browser [chrome, safari]
Environment [production, release]

@somangshu @vivekverma2312 - Discussed with Vivek and it is seems to be working fine.


Audit images

Description
Please provide a detailed description of what was done in this PR.
Precise the issue that you are resolving.
Changes include

[ ] Bugfix (non-breaking change that solves an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)

Breaking changes
Please complete this section if any breaking changes have been made, otherwise delete it.
Checklist

[ ] I have assigned this PR to myself
[ ] I have added at least 1 reviewer
[ ] I have added the needed labels
[ ] I have linked this PR to an issue
[ ] I have linked this PR to a milestone
[ ] I have linked this PR to a project
[ ] I have tested this code
[ ] I have added / updated tests (unit / functionals / end-to-end / ...)
[ ] I have updated the README and other relevant documents (guides...)
[ ] I have added sufficient documentation both in code, as well as in the READMEs

Additional comments
Please post additional comments in this section if you have them, otherwise delete it.

J'ai bougé ce qui m'a semblé être en lien avec l'audit dans cette branche. (@COTHSC  )Tu pourras checker si c'est bon (s'il y a tout comme tu as sur ta branche en lien avec l'audit). Il me semble que j'ai oublié d'exclure le commit de Roberto, mais tinquietes j'ai déjà mergé une branche avec que la doc donc tu peux git reset --hard [sha du commit de roberto] pour virer le commit de doc

In audit.csv, huge difference between the theoretical time interval between frames and the calculated time interval between frames.
Missing metadata for "220503_TPS_N2-zoom197_20ms_2" hence no data is generated in audit.csv. Calculated video length can be anormaly high due to high calculated interval between images. @COTHSC can you have a look over the results ? ty


[PowerToys Run] PowerToys Run should not show itself

Environment
Windows build number: 10.0.18363
PowerToys version: 0.18.0
PowerToy module for which you are reporting the bug (if applicable): PowerToys Run

Steps to reproduce

Open PowerToys Run
Type "Launcher"

Expected behavior
PowerToys Run doesn't shows itself
Actual behavior
PowerToys Run shows itself
Screenshots

I can confirm that this bug is present in the latest version as of now.


BRS-004 - Create all metering points and responses to market

Description
At the moment it is possible to create consumption, production and exchange metering points. When this feature is completed it will be possible to create all remaining MP types, and we will be able to handle parent/child relations. As well as send information to the balance supplier about newly created metering points.
Acceptance criteria

[x] A grid company can create all remaining metering point types (Dx MP types)
[ ] We can handle parent/child relations
[x] A grid company can receive accept/reject messages for their request
[ ] A grid company can cancel their request for create all MP types
[ ] A balance supplier can receive information about created metering points.

Test flow
A grid company sends in a request for create x MP. DH processes request and either accepts or rejects the request. Information about newly created metering points
And other domains are informed via integration event.
Scenarios

Request is accepted and MP is created. An accept message is created and can be sent to grid company
Request is rejected and MP is not created. Reject message is created and can be sent to grid company
If request is accepted and MP is created a message is created and can be sent to balance supplier.
A grid company sends in a request for cancel create MP and request is accepted. Accept message is created and can be sent to grid company
A grid company sends in a request for cancel MP and request is rejected. Reject message is created and can be sent to grid company.
Information about newly created MP's (all types) is published to an integration event so it is accessible for other domains

The teams assessment is that it will take 2 developers 2 sprints to complete this feature.

Skal slettes. er oprettet som issue og ikke epic


Multiple Invoices can be created

Build: MASTER 2016.5.30
Version: BES V16.0 Fix 4+
Test category: creative Test
[Steps to reproduce]

Login marketplace as customer;
Click on "ACCOUNT->Payment";
Click on the pen icon of payment type, modify the Display as from "Invoice" to "test1", and then click on "Save" button;
Login as administrator to blue portal, set "HIDE_PAYMENT_INFORMATION" to true;
Login marketplace as customer, select a service not free of charge to make a subscription;
Login as administrator to blue portal, set "HIDE_PAYMENT_INFORMATION" to false;
Login marketplace as customer, click on "ACCOUNT->Payment";
Now you see "Invoice" and "test1", Repeat the step 3.

[Expected result]
In Step 8, I don't expect a new "Invoice". The default used should be test 1 for the subscription created. So it is not necessary in my opinion to create a "new" Invoice, just because the display name is different.
Otherwise, in step 8, some error message should be shown because the "test1" has already exists.
Also, if it is possible to create multiple invoices,  it should then be possible to delete multiple invoices.
[Observed result]
In step 8, no additional invoice is shown.
[Details]
See screenshot of multiple Invoices

I guess this is a longer existing issue and not related to HIDE_PAYMENT_INFORMATION.
Please note that the display name is the identifier. I don't see any reason why this should be changeable for invoice. In my opinion, step 3 should be disallowed to avoid having multiple payment types with INVOICE.
The customer can have different payment types, which are directly charged by payment runs, such as credit cards, debit accounts or whatever. But there is only one type INVOICE, as alternative to directly changed. Multiple INVOICE instances do not add any value and therefore do no make sense for me.
However this might be not so easy, considering that DB migration will be required now to clean and replace the redundant invoice types in existing DBs.
Since there is no further user impact, I consider this issue as improvement request with low priority.
@mdehn
Do you agree with me?

Multiple INVOICE payment types do not make any sense. Migration of existing DBs is low priority.

This is only possible due to hide payment types. This creates a "new invoice", instead of reusing the existing one. Why now allow renaming "INVOICE"? This would be a level down.

This should be solved with [issue#101]. Making HIDE_PAYMENT_INFORMATION read-only, this use case will no longer exist.


Added possibility to disable hand mesh and joint visualization

including buttons in sample scene to toggle hand joint and hand mesh

I'll merge with some of the updates in the dev branch and layout polish. Thanks!

Polished toggle button icons and layout.

Note that this should probably be going into mrtk_development instead of mrtk_development_hl2, now that the HL2 payload is in mrtk_development.

updated the target branch


Add a health check endpoint on the search server.

Context / purpose
Add a health check endpoint on the search server. https://github.com/quickwit-inc/quickwit/issues/268
Description
Port the health check functionality from Barrel.
How was this PR tested?
$ cargo run -- serve --host=<IP_ADDRESS> --index-uri=file:///home/minoru/tmp/quickwit_data/indices/hdfslogs-idx --port=8080

$ curl 'http://<IP_ADDRESS>:8080/health/livez'
$ curl 'http://<IP_ADDRESS>:8080/health/readyz'

Checklist

[x] tested locally
[x] added unit tests
[x] included documentation

Close #268

Thanks @mosuka for the PR. But I can't merge that for the moment because:

I think we don't need HTML but only a json response
We can start by something very simple, like a 200 empty response is good
We need to define what health checks we want before

@fmassot
I had mistakenly thought that it ported from barrel.
I’ll define the health check specification.
Thanks.

Can you remove this file?

@fmassot
I have simplified the code by removing unnecessary code.
Please take another look.


Javascript Syntax Highlighting & Async & Brackets

Hello. In the code below the syntax-highlighting is broken:
	() => (
	{
		anything: async () =>
		{
			await dispatch(anything(anything));
		},
	})

minus 1 tab and it's fixed:
() => (
{
	anything: async () =>
	{
		await dispatch(anything(anything));
	},
})

or just move ( to next line:
	() =>
	(
	{
		anything: async () =>
		{
			await dispatch(anything(anything));
		},
	})

vscode: Version: 1.31.0
os: Linux Mint 18.2 Sonya

This would limitation of how tmLanguage grammar works with lookup only limited to single line. given that in most case ( followed by new line is start of arrow that's what we go with. Not doing so would break multiple other uses so this cant be fixed.


How to transfer the eos in the refund to the balance?in cleos

up

it may be automatically back to the balance when stake time is expired

If must have call refund function, then what is the cleos command?

according to the code,refund is a deferred transaction
           eosio::transaction out;             out.actions.emplace_back( permission_level{ from, N(active) }, _self, N(refund), from );             out.delay_sec = refund_delay;             out.send( from, receiver, true );

It is automatic.  The deferred transaction executes a transfer inline action when it is triggered at the end of its deferral period.

@jgiszczak My eos is still in Refund after 72 hours, do you know why?

did anyone figure out the cleos command for refund?
judging by the following in ./cleos get account <account_name> i don't think its automatic, i think you have to explicitly call eosio::refund

this did it
./cleos push action eosio refund '{"owner": "youraccountname"}' -p youraccountname

@marketstack it works, thanks!

Hi @marketstack thank you for sharing that!

./cleos -u https://node1.eoscannon.io push action eosio refund '{"owner": "youraccountname"}' -p youraccountname  full command

Did this post conclude that refunds are not automatic? Or that refunds have to be triggered manually in some circumstances?

Refunds are nominally automatic but the deferred transaction may expire before being successfully incorporated into a block.  At that point a manual refund must be invoked, as described.


config screen functionality

Works to be done in this PR:

[x] Replace the URL in the URI for each route
[x] Delete routes from config screen
[x] Alert when service is unreachable

@Harkishen-Singh Docker service is failing for some reason

After editing the route from the config screen, the changes are not visible in the monitoring screen. Consider reloading the application by passing *a.reloadConfigURLs <- struct{}. That should solve this issue.
As far as tests are concerned, the secondary libraries seem to break. We might have to switch the lib that is breaking the code if it does not pass on the second run.

@Harkishen-Singh do you mean using a modal where the route and it's options are shown ? And user can edit each one of them?

@Harkishen-Singh do you mean using a modal where the route and it's options are shown ? And user can edit each one of them?

Yes, at least according to the discussion we had.

@Harkishen-Singh that way we need to disable row customisation of mui and need to design a custom editing design

@Harkishen-Singh that way we need to disable row customisation of mui and need to design a custom editing design

If that's the only way, then we have to; if not in this PR, then let's have an issue with TODO as this.
Btw, does the current implementation support editing of params/headers/body?

@Harkishen-Singh that way we need to disable row customisation of mui and need to design a custom editing design

If that's the only way, then we have to; if not in this PR, then let's have an issue with TODO as this.
Btw, does the current implementation support editing of params/headers/body?

It doesn't. It can only allow to edit what's on the table, which in our case is the route name and the methods

Okay, then anyway we need yo make a custom one in order to match the UI and also this. That should be the correct way.
What do you say?

Okay, then anyway we need yo make a custom one in order to match the UI and also this. That should be the correct way.
What do you say?

I guess deleting works fine as it is. It is editing that we must custom build

@Harkishen-Singh TODO are all of the interface exports and type cleanups. Please try to review them once, I will change them tomortow anyways


Moving webworker to cockle

Cockle now includes the WebWorker code and handling of separate WASM and JS wrapper files (jupyterlite/cockle#38, jupyterlite/cockle#40, jupyterlite/cockle#44) and I am now trying to use that here, so I have removed the local WebWorker code in branch https://github.com/jupyterlite/terminal/tree/remove-webworker and struggling to get it all correctly working together. Loading the shell_worker.js is failing.
To reproduce it is necessary to use the main branch of cockle as the changes there have not been released yet. So get commit 41cc8b014aa8 of cockle and build it locally following the instructions it its README. If you also follow the instructions for the demo you'll be able to run it locally in a browser and confirm that commands like ls and grep work in the WebWorker. Then run npm link on cockle.
In the same micromamba environment get https://github.com/jupyterlite/terminal/tree/remove-webworker and run jlpm link <relative path to cockle directory>. Then build it in the usual way, you'll need dependencies like jupyterlite-core and so on. To serve use
jupyter lite serve --LiteBuildConfig.extra_http_headers=Cross-Origin-Embedder-Policy=require-corp --LiteBuildConfig.extra_http_headers=Cross-Origin-Opener-Policy=same-origin

When I do this I get
Uncaught (in promise) TypeError: __webpack_modules__[moduleId] is not a function
    at __webpack_require__ (bootstrap:19:1)
    at ../cockle/lib/shell_impl.js (history.ts:73:2)
    at __webpack_require__ (bootstrap:19:1)
    at ../cockle/lib/shell_worker.js (shell_impl.ts:420:2)
    at __webpack_require__ (bootstrap:19:1)
    at bootstrap:34:1
    at __webpack_require__.O (chunk loaded:23:1)
    at __webpack_require__.x (bootstrap:35:1)

in the browser console.

Now I've released cockle 0.0.7 I've updated this remove-webworker branch to use that, so it is no longer necessary to build cockle from source, just building terminal from this branch is enough.

Closing this as PR #21 is working on a fix.


[Resource page + Footer] Quick updates

Move 4/27 panel out of upcoming events to recorded live panels section, and update CTA to "See slides and recording".
CTA link:https://drive.google.com/drive/u/0/folders/1NATDm5yVsYUo8jRY7svE2fqwm1OwcpMu

Add “https://www.helpvolunteer.app/” (H.E.L.P.)  to "Funding, Volunteers, & Research Resources” section.

Add social media links to footer.
Twitter link: https://twitter.com/helpwithcovid
Facebook link: https://www.facebook.com/HelpwithCOVID
Footer design here:

Fyi - bansalnagesh is working on it! https://discordapp.com/channels/689552739797434432/689658307392307306/704552879217836072


RFM - vortex

I am mostly stepping away from chocolatey as I do not really use it anymore and don't really have time to upkeep my packages (fixing issues or checking and seeing if everything is still working as it should be) I have been maintaining for a good while now, so I am currently on the lookout for someone to take over pretty much all my packages (I'll be creating an issue for each package).

Current Maintainer

[x] I am the maintainer of the package and wish to pass it to someone else;

Checklist

[x] Issue title starts with 'RFM - '

Existing Package Details
Package URL: https://chocolatey.org/packages/vortex
Package source URL: https://github.com/JourneyOver/chocolatey-packages/tree/master/automatic/vortex

I'll pick this one up. Username is pauby.

@pauby I have added you as a maintainer (that you need to accept), thanks for taking over the package.
As per https://github.com/chocolatey-community/chocolatey-package-requests/issues/1508 I'll either fork and PR or you can manually add the packages to your repo (answer on whichever issue you want about which way you will want it to be done)

@JourneyOver thank you for the offer but I can't ask you to do that.
You've done enough as a package maintainer (and thank you for doing that!). I'll move the package over.
Do you want me to submit a PR to remove it from your repository when I've moved it over (which will likely be this week)?

Answered in #1508

@JourneyOver both this and the streamlabs-obs package have been migrated over to my repository (vortex and streamlabs-obs).
I'll go ahead and close this now.


Fix spelling/grammar errors in components

Fix various spelling/grammar errors in components.

@HaoK Any idea why Tests: Helix ARM64 failed?
Logs here: https://github.com/aspnet/AspNetCore/pull/13953/checks?check_run_id=221660157

No, we just enabled these tests today, and it looks like we don't have the proper setting that flows the secret needed for forks to properly run these, I'm just waiting for confirmation that its safe for us to enable this setting.

Closing and reopening to force a rebuild

/azp run

/azp run

Thanks for your effort, @adrianwright109.
It seems there is something wrong with how you rebased your changes, as too many commits show up in here, which are irrelevant. Can you please clean this up, so only your own changes show up?

I have created a cleaner PR #14137 which superceeds this PR - closing the PR in favour of PR #14137


[WIP] Add manually scrolling

Fixes #74

Added the scroll_to_me inside Response,
Needed to pass the center_ratio to the Context, so we can correctly centralize inside the ScrollArea`.
Still need to document the methods,
improve the demo, maybe do something similar to imgui.

Update the scroll demo (made it similar to imgui) and moved it to its own module.
Added documentation to the methods.
Added ScrollArea::scroll_offset().

Another minor addition: when clicking a button to scroll to the top of that button, I think it would make sense to add a small offset (e.g. item_spacing.y) to the scroll. Otherwise the top of the button frame will be clipped by the scroll areas clip rect. In other words, it will look better if the top and bottom scrolls always came with an offset of item_spacing.y.


bundling custom .js files

Why the pnpm run dev command doesn't use rollup to bundle custom .js files added to the project?
If this is intended behaviour (not bundling in dev mode), how can I use my custom ~/options/custom.js file in options.html in dev mode?
I confirmed that build:prod work as expected (bundling).
EDIT: My problem is when i open Options in chrome extension in the console i'm getting this error:
"GET chrome-extension://omhjadppniapnjfeehfigoillobaapek/options/custom.js net::ERR_FILE_NOT_FOUND"
because it's not present in dev folder

the projects use tsup for bundling so rollup is not needed, but I still can't use code from custom.js file inside options.html

can't find a way of bundling with js files. As a workaround i use .ts files with .js code


feature:added contact us Page

Related Issue(s)

Fixes #187

Description
This pull request adds a "Contact Us" page to the application, enabling users to send messages which will be stored in Firebase. This feature enhances user engagement and support by providing a direct communication channel between users and the app's administrators.
Changes Made

file1: Added a new contactUs.tsx component to handle the form submission.
file2: Added a  Firebase.tsx to establish a connection with firebase
file3: Modified App.tsx to include routing for the new Contact Us page.

Screenshots (if applicable)
https://github.com/oxiton-foundation/click-metrics/assets/72294811/d1b01900-e211-401f-8aec-86d6f35334ef
Checklist
Before submitting your pull request, ensure that you have completed the following tasks:

[✔] Code follows the project's style and conventions.
[✔[ Code has been tested thoroughly, and all tests pass successfully.
[✔] Documentation has been updated to reflect any relevant changes.
[✔] All new and modified code is adequately commented for clarity.
[✔] Pull request title follows the specified format: [Feature/Enhancement/Bug Fix]: Brief description of the change.

@Smitkhobragade  can you please review and label this PR?

@Swarnendu0123 can you please review and label this PR?

@Swarnendu0123 can you please review and label this PR?


Standlone Project failing

Laravel Mix Version: 1.0.0
Node Version: 8.1.1
NPM Version: 5.0.3
OS: macOS Sierra

Description:
The commit 9d2d80b removes the webpack.config.js from the standalone docs, and (as expected) on a new project, there is no webpack.config.js in the project root. As a result of this, calling webpack on the project root will obviously just fail.
Steps To Reproduce:

npm install --save-dev laravel-mix
cp -r node_modules/laravel-mix/setup/webpack.mix.js ./
Insert Mix Scripts in to package.json
npm run dev

I managed to fix this by doing the following changes in the webpack.config.js file:
require('../src/index');
and
let WebpackConfig = require('../src/builder/WebpackConfig');
changed to:
require('laravel-mix/src/index');
and
let WebpackConfig = require('laravel-mix/src/builder/WebpackConfig');

The recommended approach now is to use our config file. So you'll want to add --config=node_modules/laravel-mix/setup/webpack.config.js to your npm script.


Fix copy of a resource being appended when resource re-selected

Consider the following scenario:

The user selects a resource in the tree view (or uses the Load command).
The extension creates an untitled document containing the resource JSON.
The user leaves the document open.
Later, the user again selects the same resource (or uses the Load command to load it again).

At the moment, this has a bug where the second time, the resource JSON is appended to the existing document.  This PR loads each copy of the resource into a new document.  Documents are named e.g. deployment-foo.json, deployment-foo.1.json, deployment-foo.2.json, etc.
A nice enhancement to this would be to compare the current JSON against the content of the existing document, and simply re-show that document if the resource had not changed.  This would avoid creating a lot of temp documents that the user has to close if they are simply browsing around in the tree.  (Alternatively, if the existing document was a temp document, I guess we could overwrite its contents with the new resource state...?)

Fixes #210.

@itowlson I get why this is necessary... but would it be possible to do as you mentioned in your last paragraph and compare the current JSON of the temporary document, replacing it as necessary? I'd think a simple hash of the document contents would be a fairly reasonable approach to this. I really dislike the current behavior (as unavoidable as it is), and accidentally opening > 1 temporary document, and being prompted to save every single one would be even more annoying.

@bnookala Are you arguing for the suggestion of blatting the existing JSON in favour of the current state, or just for reactivating the document if it matches?  The latter seems safe; the former a bit trickier, and feel fraught with risks...!

@itowlson on second thought... just the latter :D


Error with new trigger: panic: index out of range

I'm trying to develop a new trigger and I'm getting the following error on runtime:
panic: runtime error: index out of range

goroutine X [running]:
github.com/TIBCOSoftware/flogo-contrib/action/flow.(*FlowAction).Run(...)
C:/Users/.../Go/src/myApp/vendor/src/github.com/TIBCOSoftware/flogo-contrib/action/flow/action.go:214 +0x3fc

Those lines are:
208	triggerAttrs, ok := trigger.FromContext(context)
209
210	if ok {
211		if len(triggerAttrs) > 0 {
212			logger.Debug("Run Attributes:")
213			for _, attr := range triggerAttrs {
214				logger.Debugf(" Attr:%s, Type:%s, Value:%v", attr.Name, attr.Type.String(), attr.Value)
215			}
216		}
217	}

So I deducted it was something to do with the output I was sending. My trigger.go, with some comments with the go type of the variables, looks like this:
data := map[string]interface{}{
	"extended": ext, // bool
	"rtr": rtr, // bool
	"error": err, // bool
	"id": id, // uint32
	"length": length, // uint8
	"payload": payload, // [8]uint8 or [64]uint8
}
startAttrs, _ := t.metadata.OutputsToAttrs(data, false)
ctx := trigger.NewContext(context.Background(), startAttrs)
t.runner.Run(ctx, action.Get(actionId), actionId, nil)

The corresponding trigger.json looks like this:
"outputs": [
    {
      "name": "extended",
      "type": "boolean"
    },
    {
      "name": "rtr",
      "type": "boolean"
    },
    {
      "name": "error",
      "type": "boolean"
    },
    {
      "name": "id",
      "type": "integer"
    },
    {
      "name": "length",
      "type": "integer"
    },
    {
      "name": "payload",
      "type": "bytearray"
    }
  ]

When I copied into my trigger.go the lines that were panic-ing, modifying the variable names and scopes as needed, I managed to print in the console:
Run Attributes:
Attr:extended, Type:boolean, Value:false
Attr:rtr, Type:boolean, Value:false
Attr:error, Type:boolean, Value:false
Attr:id, Type:integer, Value:50
Attr:length, Type:integer, Value:0

But the payload field does not get printed. I'm not sure what am I doing wrong. If you need any further information, please, ask for it.

Update: removing the payload output both in the trigger.go and trigger.json so it seems it has some problem with the [X]uint8 array. How should I pass the payload then? Or how should I specify it is an array in the trigger.json file?

Update: Setting it to "array" in the .json file seems to have solved the problem but wasn't able to find any documentation nor the part of the code where this assertion is being made. Pointers to any of those two parts would be welcome.

I'll look into the "index out of range" and output not showing.  At a minimum try to give a more constructive error to help diagnose the problem.
Also, we are working on cleaning put and adding additional documentation.  Please create a documentation issue  which we can address separately.  Thank you.

I tracked the error as much as I could but wasn't able to find more. Using "type": "bytearray" in the trigger.json file was yielding the error while "type": "array" isn't. Is there any kind of parsing being done depending on this config parameter? If the answer is yes, ¿what types am I able to use? I thought this was just some kind of meta config information that the trigger could use to parse it but that wasn't being used by the engine itself.

Yes, the issue is that we currently do not have an explicit bytearray type.  The types that you can use can be found at flogo types
We'll have to create a separate issue for type validation so you don't get this obscure errors.


Update to Fable 3.0 RC2

@jbeeko - The only difficult thing here was finding correct magical incantation to run Fable and Wrangler both in watch mode
@alfonsogarciacaro - I've found one breaking change. System.DateTime.Now.ToString() or sprintf "%A" System.DateTime.Now instead of returning nicely formated output (JS equivalent Date.now().toString()) returns just a word Date. Is this by design?

Hmm, no. sprintf doesn't match F# exactly but there shouldn't be "regressions" from Fable 2, I'll have a look, thanks!


Change CORS config key from path-prefix to path-expr; method names also

Resolves #1767
The value is, in fact, used as a pattern (expression) and not a prefix.
Signed-off-by<EMAIL_ADDRESS><EMAIL_ADDRESS>

A note for consistency - in Security, we have the following configuration:
security.web-server:
        paths:
            - path: "/noRoles"
              methods: ["get"]
            - path: "/user[/{*}]"
              methods: ["get"]
              roles-allowed: ["user"]

I use just path, even though it can be an expression (as in the example above).
I did not feel the expr was required here.
In routing, we call it pathPattern
This is adding a third option.
Please consider this - does it make sense to change all of them to expression, or use one of the existing terms?
Options:

path
path-pattern
path-expr

I have approved this PR, as we may delay that decision for a future Helidon version...

After a quick slack chat with Tomas, I am re-changing the config key name to path-pattern and associated method names, arguments, etc. to pathPattern to be consistent with similar usage elsewhere in WebServer. Update to the PR coming soon.


[5.4] Add O(n) median and nthOrder implementations to Arr class.

This pull adds the Quickselect algorithm for finding arbitrary order statistics in linear time with the nthOrder function on Arr. It also adds a median function, which amounts to sugar on top of nthOrder. Laravel's current way of finding medians takes O(n lg n) time, so this is an order-of-magnitude speedup to the process. The pull also updates Collection to use this new implementation.
For purposes of generality, the methods return the element with the nth order statistic, not just the value off of that element with the nth order statistic. A user interested in just the value should easily be able to pull it off of the element. In the case of an array of scalars, the element and value are one and the same.
The methods can search not just for numeric values, but arbitrary comparable values. This means, for instance, that the median date can be found. Since the methods can take a comparison callback, the median of any complex, arbitrary ordering can be found. The drawback to generalizing beyond numbers is that it is no longer possible to average a split median. Instead, the lower median is selected, per convention. For numeric contexts in which the numbers follow a non-linear pattern, averaging a split median would still lead to incorrect results, so switching to the lower median should be no worse than averaging, if not better.
The second commit switches the internal implementation of median on Collection to use this logic. The function retains the same signature: it returns the median value, not element, and takes an optional string argument to pluck a field off of the collection. The differences are that it benefits from the speed-up, gains the ability to take the median of non-numeric fields, which consequently means that it now uses the lower median, where applicable.
I would switch Collection to make use of the callable callback, but that would also entail switching it to return the matched element, not the matched value. While I think this preferable, it would significantly change the signature of an established method.

Add O(n)

Quick select actually has worst case complexity O(n^2). Average case is O(n). Just didn't want the description to be misleading.

Point. In the worst case, it is O(n^2). The expected running time is O(n). However, the theoretical worst case is extraordinarily unlikely to happen. Since it's a randomized algorithm, there is no specific input that would elicit the worst case. Wikipedia describes it as running in "almost certain linear time." The RNG would need to pick a specific bad pivot point with each split to have that happen.
There is another algorithm that runs in worst-case linear time by spending additional work locating optimal pivot points. However, it's considerably more complicated to implement and takes longer to run in practice. The literature suggests that this implementation is broadly preferable for these reasons.
For what it's all worth.

Yes, I agree that quickselect is a good choice, though, it was worth noting that is not an algorithm which is guaranteed to be linear time, though, due to the randomized pivot, is is linear time, with high probability. On a side note, random_int is actually faster than mt_rand

Gotcha. I've noticed that people get weird sometimes where performance is concerned, so I wanted to clarify that even though the worst case is technically O(n^2), it basically doesn't happen.

Thanks for the tip on random_int, by the way. I just switched it over to that. 👍  It sounds almost like random_int dominates mt_rand. Do you know if that's the case?

I don't know if there's interest in this, but this pull also opens the way to pulling the top m items from a collection of size n in O(n) time. Grabbing them and then sorting them would then be O(n + m lg m). If that's desired, then I'd be more than happy to build it.

Probably hold off on making any further changes for now until we establish if this change is actually wanted in the core, then we can discuss any modifications if needed, at that point. :)

I don't have any plans to add these functions to the core right now. Arr is macroable.


Dev

benchmarked one loop vertex4

Codecov Report

Merging #23 (557c504) into master (c9792e1) will decrease coverage by 0.32%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #23      +/-   ##
==========================================
- Coverage   63.53%   63.20%   -0.33%
==========================================
  Files          27       27
  Lines        1969     1965       -4
==========================================
- Hits         1251     1242       -9
- Misses        718      723       +5

Impacted Files
Coverage Δ

src/FeynmanDiagram.jl
41.66% <ø> (ø)

src/GWKT/manual/vertex4.jl
0.00% <ø> (ø)

src/expression_tree/eval.jl
94.73% <100.00%> (+1.87%)
:arrow_up:

src/parquet_builder/benchmark/vertex4_eval.jl
89.02% <0.00%> (-2.44%)
:arrow_down:

src/expression_tree/build.jl
92.00% <0.00%> (-1.34%)
:arrow_down:

src/common.jl
73.78% <0.00%> (-0.98%)
:arrow_down:

src/parquet_builder/vertex4.jl
84.58% <0.00%> (-0.80%)
:arrow_down:

Continue to review full report at Codecov.

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


Can't transform unit vectors with an Isometry

It seems like something along the lines of impl<N, D> Mul<Unit<Vector<N, D>>> for Isometry<N, D> (and all other non-scaling transforms) should exist.

Agreed, they should exist. This looks like an oversight.


zkasm: upgrade target-lexicon and move over to using zkasm target proper

This is finally also ready


Error: Robot model parameter not found! Did you remap 'robot_description'?

When starting a fresh installation I get this error.
It is thrown by the planning node.
We renamed our model to "marimbabot_ur5" but it searches for "robot_description"

I dont know why but now the planning node load the correct "robot model 'marimbabot_ur5'.
It might be because I ran some demo.launch files and re-sourcing...


CLI commands such as index/source/split don't use the QW_METASTORE_URI en variable

These commands are naturally used for making requests on the metastore.

@evanxg852000, I'm going to assign this one to myself. I'm reviving an old branch that takes care of this issue.

Fixed by #2212


docs: Added reactivate_realm management command.

Added ./manage.py reactivate_realm command within Management commands markdown referring to @timabbott suggestion.

Merged, thanks @aryanshridhar!


Is it possible to force this package to throw an error when gpu flags are specified but failed to build with gpu?

Is your feature request related to a problem? Please describe.
I'm always frustrated when trying to debug cuda issues. This package installs the cpu only version silently when it doesn't find cudatoolkit or other required files. As a result, I need to keep reinstalling llama-cpp-python and loading the model to test if gpu support is working. This is not very intuitive.
Describe the solution you'd like
Throw an error when CUBLAS flags specified but unable to find cuda.
Or warn that CPU only version is built.

Hey @gerhean there is a function in the ggml library so I can try to access that. In the meantime your best bet is going to be compiling with the --verbose flag so you can see the cmake logs.


LaTeX/KaTeX rendering issue for PDF exports only

I was testing out Marp and tried some LaTeX code for mathematical formulae.
I found that sigma notation does not seem to render correctly in PDF exports:
PDF Export:

HTML/PPTX Export:

I am running Marp for VS Code v1.5.2 on VS Code 1.70.1; device is on Windows 11 22H2.
The code for the formula I am using is:
# Some $\LaTeX$ Code

<br>

$$
\sum_{k=1}^{n}k^2 = \frac{n(n+1)(2n+1)}{6}
$$

This appears to be the case when I have not declared the math typesetting, or if it is declared as katex.
This is not the case when math typesetting is declared as mathjax, which is odd, as this says mathjax is used in rendering if there is no declaration (there is also a stylistic difference in rendering; no declaration appears to be using katex.)
PDF using MathJax:

I prefer usage of katex. Is there any "quick fix" for this, or a way in which different rendering engines could be used for different parts of the same equation?

It seems to reproduce only in Chrome if exported to HTML. Firefox and Safari does not reproduce. (Marp's PDF export is depending on Chrome)
Marp has applied auto-shrink the size to KaTeX block, and it may be a one of incompatible parts with the auto scaling feature, as same as marp-team/marp-core#159 and marp-team/marp-core#236.
Workaround
Add following global style in Markdown.
<style>
  .katex .delimcenter,
  .katex .op-symbol {
    display: inline-block;
  }
</style>

If this workaround is working well, going to consider to add into KaTeX default style by Marp Core.

This appears to be the case when I have not declared the math typesetting, or if it is declared as katex.
This is not the case when math typesetting is declared as mathjax, which is odd, as this says mathjax is used in rendering if there is no declaration (there is also a stylistic difference in rendering; no declaration appears to be using katex.)

In Marp for VS Code, use the library preferred in the extension settings if not defined math directive. You says "I prefer usage of katex" so you may be setting markdown.marp.mathTypesetting as katex. In this case, it's expected behavior that uses KaTeX when there is not set math directive.

you may be setting markdown.marp.mathTypesetting as katex

just had a look at extension settings; looks like that is the default.
the workaround seems to work well for me as well; thanks for that!


Generate library for dataform.googleapis.com

The protos are still v1alpha*, but eventually there will be a GA version:
https://github.com/googleapis/googleapis/tree/master/google/cloud/dataform

Still blocked, I only see a v1beta1 API.

Still blocked.

Doubt they will ever publish the protos.


[SPARK-32124][CORE][FOLLOW-UP] Use the invalid value Int.MinValue to fill the map index when the event logs from the old Spark version

What changes were proposed in this pull request?
Use the invalid value Int.MinValue to fill the map index when the event logs from the old Spark version.
Why are the changes needed?
Follow up PR for #28941.
Does this PR introduce any user-facing change?
When we use the Spark version 3.0 history server reading the event log written by the old Spark version, we use the invalid value -2 to fill the map index.
How was this patch tested?
Existing UT.

cc @warrenzhu25 @HeartSaVioR @dongjoon-hyun

Test build #124760 has started for PR 28965 at commit 9b9e4ee.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29371/
Test PASSed.

Test build #124760 has finished for PR 28965 at commit 9b9e4ee.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/124760/
Test FAILed.

Test build #124884 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29490/
Test PASSed.

Test build #124884 has finished for PR 28965 at commit 9dfa5c0.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/124884/
Test FAILed.

Hi, @HeartSaVioR . Could you finalize this as an Apache Spark committer? :)

@HeartSaVioR Congratulations!

retest this, please

Btw thanks @dongjoon-hyun and @gengliangwang ! I thought it's probably better to take committer's work after official announcement, but this looks to be simple and good example to try out before dealing with larger PR. Thanks again for the guidance!

Ya. That's also reasonable. Usually, the annoucement gets some delays because the invitations go out to multiple committers at the same season. You don't need to be blocked. ;) You've been waiting so long. Please do your what you want.

Jenkins doesn't seem to pick this up by request ;( Mentioned the behavior in the dev@ list.

retest this please

Wow, Congratulations @HeartSaVioR! Well deserved!

Test build #124936 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29542/
Test PASSed.

Test build #124936 has finished for PR 28965 at commit 9dfa5c0.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/124936/
Test FAILed.

Retest this please.

Test build #124960 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29566/
Test PASSed.

Test build #124960 has finished for PR 28965 at commit 9dfa5c0.

This patch fails build dependency tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/124960/
Test FAILed.

retest this, please

Test build #124972 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29578/
Test PASSed.

Test build #124972 has finished for PR 28965 at commit 9dfa5c0.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/124972/
Test FAILed.

retest this, please

Test build #125058 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29665/
Test PASSed.

Test build #125058 has finished for PR 28965 at commit 9dfa5c0.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125058/
Test FAILed.

retest this, please

Test build #125089 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29696/
Test PASSed.

Test build #125089 has finished for PR 28965 at commit 9dfa5c0.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125089/
Test FAILed.

retest this, please

Test build #125122 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29728/
Test PASSed.

Test build #125122 has finished for PR 28965 at commit 9dfa5c0.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125122/
Test FAILed.

retest this, please

Test build #125171 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29779/
Test PASSed.

Test build #125171 has finished for PR 28965 at commit 9dfa5c0.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125171/
Test FAILed.

Merged build finished. Test FAILed.

retest this please

Test build #125190 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29799/
Test PASSed.

Test build #125190 has finished for PR 28965 at commit 9dfa5c0.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125190/
Test FAILed.

retest this please

Test build #125216 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29827/
Test PASSed.

Test build #125216 has finished for PR 28965 at commit 9dfa5c0.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125216/
Test FAILed.

retest this please

Test build #125248 has started for PR 28965 at commit 9dfa5c0.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/29859/
Test PASSed.

Test build #125248 has finished for PR 28965 at commit 9dfa5c0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/125248/
Test PASSed.

Thanks! Merged to master and branch-3.0.

The very first commit merged by @HeartSaVioR!


[1.1] - Matter Controller is Unable to re-establish the sessions with End Device upon Reboot.

Reproduction steps
Take one Matter Controller and matter-supported device and follow the steps:

Pair the Matter Devices to the Controller.
Perform some actions on the device and monitor. (Plug on/off, Door open/close)
Power off the Matter Controller and Turn it ON after an Interval.

Issue:
When the Controller is powered ON again, it is unable to re-establish the Operational Sessions with the Paired Matter Devices.
We also made sure to check the Open Thread credentials as all the devices are supported. They are also included in the Open Thread Network.
We were able to re-establish the controller-device connection in Matter v1.0-branch but facing an issue in v1.1.
Bug prevalence
Consistent
GitHub hash of the SDK that was being used
v1.1-branch
Platform
other
Platform Version(s)
v1.1-branch
Type
Platform Issue
Anything else?
Log_restart.txt
PFA the Log file for reference.

it is unable to re-establish the Operational Sessions

Is the attached "Log_restart.txt" a controller log?  If so, that shows it trying to do operational instance lookups and failing:
[2023/08/28 14:42:36] [DIS] OperationalSessionSetup[1:0000000000000004]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:114: CHIP Error 0x00000032: Timeout
...
[2023/08/28 14:42:36] [DIS] OperationalSessionSetup[1:0000000000000006]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:114: CHIP Error 0x00000032: Timeout
...
etc

Does this controller, after restart, have connectivity to the relevant network?   Is it using platform dns-sd or minimal mdns?  What platform is it running on?

Hi @bzbarsky-apple, Please find the answers below,
Does this controller, after restart, have connectivity to the relevant network?
-> Yes it does establish the connection with the Relevant network
Is it using platform dns-sd or minimal mdns?
-> It is using the Platform dns-sd
What platform is it running on?
-> We are running it on iMx6 ULL platform (Custom Linux).

So this is using avahi for DNS-SD?  Can you check whether avahi is seeing the device after reboot?

We need to check that, but as far as our understanding, avahi should be able to see the device after reboot.
In this case, we will check once and update.
JFYI, all our Matter Devices are ble-thread supported, hence they primarily rely on BLE for the commissioning.

Hi @bzbarsky-apple, I can confirm that Avahi is able to see the device after Reboot.
But when the device is trying to Re-establish the session we get the log as
[2023/09/11 09:12:51] [DIS] SRV record already actively processed.
[2023/09/11 09:12:51] [DIS] SRV record already actively processed.
[2023/09/11 09:12:51] [DIS] SRV record already actively processed.
Does that mean, the Controller already has details about the Device from the previous state and it is trying to re-establish the new one but found it already existing in terms of SRV records?
We faced a similar issue during an active connection, the controller when rebooted didn't establish the session with the end device, which we resolved with some code changes and by making the configuration files accessible to the database. But we cannot access the end device code, hence this issue persists now when the end device is rebooted.

That's a question for @andy31415 : that log indicates that minimal mdns is being used here.

Could you capture the DNSSD traffic to see if the queries are actually being answered?
The `SRV record already processed' just means that DNSSD is processing some dnssd packet however it may not be the actual response to the device query or maybe the device answers with different data somehow.
I do not believe there is sufficient information in the logs to debug this - the logs seem to just say "looking for device but it does not reply to dnssd".

Hi Team,
Thanks for the Responses. I am unable to trace the packets yet.
Will Revert once done!

Hi Team,
Please Find attached the DNS Trace file for the Device,
Here the Mac address ending with 6f34 is our Matter Controller.
I am unable to upload the entire pcap file hence attaching a snap

@andy31415 Please see above

@smishra-volansys could you give me instructions on how to reproduce with the SDK examples (e.g. chip-tool/repl and one of the thread devices ... I have efr32 and nordic devices at my desk).

@andy31415 Sure!
Steps To Reproduce this Issue:

Using Chip-tool or Chip Android App, pair an event-based Matter Device.
Read a few events on the Controller end and make sure that the Commissioning has been done and the connection has been established.
Now Power off the Matter Device and power it ON again.
During this time, it will fail to establish the connection again and show the SRV records already actively processed.

Please make sure to subscribe to the events after commissioning so that you can see the events and the Logs

@andy31415, were you able to reproduce using these steps?

Hi @andy31415,
Is there any update on this?
@bzbarsky-apple

I don't know anything about minimal mdns, sorry.


Add filtering by pr labels

Hi guys,
I found your action project very useful, and was excited to use it in my project.
Since I didn't find any contribution guide for your repository - I'd like to suggest a feature via a PR.
This PR adds the capability of filtering PRs according to given labels.
The changes were tested manually both for backwards compatibility (to check that nothing broke) and the filtering according to labels.

Added tests

Rebased, and fixed linter errors

Appreciate all the reviews.
Do you think you might have an estimate on the merge and release timeline of a new version?

It's released

Wonderful - I appreciate your responsiveness!


Rename SideCI to Sider

Hi!
Now SideCI has renamed to Sider, so this fixes name and URL of Sider.
New URL: https://sider.review/
For more details, please see announce.
Thanks.

Splendid! :bulb:


Building hello_world fails for xtensa: xt-xcc ERROR parsing -Wno-address-of-packed-member:  unknown flag

This used to work fine a few days ago, but after a git pull today I get the following:
$ west build -b intel_s1000_crb samples/hello_world
source directory: /media/psf/Home/src/zephyr/zephyr/samples/hello_world
build directory: /media/psf/Home/src/zephyr/zephyr/build (created)
BOARD: intel_s1000_crb (origin: command line)
Zephyr version: 1.14.99
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.7.3", minimum required is "3.4")
-- Selected BOARD intel_s1000_crb
-- Found west: /usr/local/bin/west (found suitable version "0.5.7", minimum required is "0.5.6")
-- Loading /home/jh/src/zephyr/zephyr/boards/xtensa/intel_s1000_crb/intel_s1000_crb.dts as base
-- Overlaying /media/psf/Home/src/zephyr/zephyr/dts/common/common.dts
intel_s1000_crb.dts.pre.tmp:21.9-25.5: Warning (unique_unit_address_if_enabled): /cpus/cpu@0: duplicate unit-address (also used in node /cpus/core_intc@0)

warning: HAS_I2C_DW (defined at drivers/i2c/Kconfig.dw:9) has direct dependencies I2C with value n, but is currently being y-selected by the following symbols:
 - SOC_INTEL_S1000 (defined at /media/psf/Home/src/zephyr/zephyr/soc/xtensa/intel_s1000/Kconfig.soc:4), with value y, direct dependencies <choice> (value: y), and select condition <choice> (value: y)

warning: HAS_SPI_DW (defined at drivers/spi/Kconfig.dw:9) has direct dependencies SPI with value n, but is currently being y-selected by the following symbols:
 - SOC_INTEL_S1000 (defined at /media/psf/Home/src/zephyr/zephyr/soc/xtensa/intel_s1000/Kconfig.soc:4), with value y, direct dependencies <choice> (value: y), and select condition <choice> (value: y)
Parsing Kconfig tree in /media/psf/Home/src/zephyr/zephyr/Kconfig
Loading /home/jh/src/zephyr/zephyr/boards/xtensa/intel_s1000_crb/intel_s1000_crb_defconfig as base
Merging /home/jh/src/zephyr/zephyr/samples/hello_world/prj.conf
Configuration written to '/home/jh/src/zephyr/zephyr/build/zephyr/.config'
-- Cache files will be written to: /home/jh/.cache/zephyr
-- The C compiler identification is GNU 4.2.0
-- The CXX compiler identification is GNU 4.2.0
-- The ASM compiler identification is unknown
-- Found assembler: /home/jh/xtensa/XtDevTools/install/tools/RF-2016.4-linux/XtensaTools/bin/xt-xcc
<snip>
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jh/src/zephyr/zephyr/build
[2/93] Preparing syscall dependency handling

[8/93] Building C object zephyr/CMakeFiles/offsets.dir/arch/xtensa/core/offsets/offsets.c.obj
FAILED: zephyr/CMakeFiles/offsets.dir/arch/xtensa/core/offsets/offsets.c.obj
ccache /home/jh/xtensa/XtDevTools/install/tools/RF-2016.4-linux/XtensaTools/bin/xt-xcc -DBUILD_VERSION=zephyr-v1.14.0-1288-ga2c84ecf9e07 -DKERNEL -D_FORTIFY_SOURCE=2 -D__ZEPHYR__=1 -I../kernel/include -I/media/psf/Home/src/zephyr/zephyr/arch/xtensa/include -I../include -I../include/drivers -Izephyr/include/generated -I/media/psf/Home/src/zephyr/zephyr/soc/xtensa/intel_s1000 -I/media/psf/Home/src/zephyr/zephyr/soc/xtensa/intel_s1000/include -I../lib/libc/minimal/include -Os -g -imacros /home/jh/src/zephyr/zephyr/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -fms-extensions -D__SIZEOF_LONG__=4 -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-address-of-packed-member -Wno-main -Wno-pointer-sign -Wpointer-arith -Werror=implicit-int -fno-pic -fno-strict-overflow -ffunction-sections -fdata-sections -mlongcalls -std=c99 -MD -MT zephyr/CMakeFiles/offsets.dir/arch/xtensa/core/offsets/offsets.c.obj -MF zephyr/CMakeFiles/offsets.dir/arch/xtensa/core/offsets/offsets.c.obj.d -o zephyr/CMakeFiles/offsets.dir/arch/xtensa/core/offsets/offsets.c.obj   -c /home/jh/src/zephyr/zephyr/arch/xtensa/core/offsets/offsets.c
xt-xcc ERROR parsing -Wno-address-of-packed-member:  unknown flag
ninja: build stopped: subcommand failed.


Re-fix #54 after changing to single-activity pattern

Re-fix #54, for back-press it should close drawer firstly instead app itself.

@tiembo also , I 've readded tests .

@tiembo  I have resolved conflicts, plz check.

Thank you!


Build Zashi and Sync Old Test wallet to debug iOS issues

Opened bug about Spending before syncing https://github.com/Electric-Coin-Company/zashi-ios/issues/998

reported issues through closed beta discord


Add TLS v1.2 support to EvseV2G module

Now the module supports TLS v1.2. The TLS support and the PKI path can be configured in the manifest.yaml file of the module.

These codacy errors can be ignored


Enable setting serial number for a VM

What this PR does / why we need it:
Kubevirt currently lacks the ability to specify a serial number for a virtual machine.
This PR adds the ability to specify a custom serial number (see https://bugzilla.redhat.com/show_bug.cgi?id=918138).
Release note:

Custom serial number can be set for a VMI via the `spec.domain.firmware.serial` attribute.

Ping?

can we get a functional test for this behavior please

Sure, done


feat: Adds support for packages translation

It would be useful to use translation also with custom packages.
This pull request adds support for packages translation.

@sardoj Hey! Thanks for the PR (and sorry for the late answer)! I really like the idea!
Please let me review the code and work on a little, then I will return to you!
Thanks a lot!

Thank you !
Maybe we can also add support for a fallback locale.
if (!is_null($dirpath)) {
   if (strpos($dirpath, base_path()) === false) {
        $dirpath = base_path($dirpath.'/'.App::getLocale());
        // ===> If this locale is not supported by the package, it there will be no translations.
        // Maybe we can use config('app.fallback_locale') if '$dirpath' doesn't exist.
    }
} else {
    $dirpath = resource_path('lang/'.App::getLocale());
}

@sardoj I really appreciate your idea!
I chose another approach since you can reach all the registered package translations with their path, there is no need to pass any extra parameter to the @translations directive, it can be done behind the scenes. Also, for the fallback locale, I used a similar approach, I just saw your comment after.
Also, for changing the separator, I think it's the best if we stick with the default separator. No confusion then.
So if you don't mind I close this PR, but in the readme and the changelog, where I document the package part, I will mention you in the very first.

Hello,
Thank you for your new release!
But i've a real problem with the separator, because I use dot character in my translations :
// resources/lang/en/default.php
return [
    'test' => 'test1',
    'field.test' => 'test2',
];

It works well with Laravel if we call trans('default.test') or trans('default.field.test').
Could we do the same with your package please?

@sardoj Hi!
I see. But having a structure like this, would solve your problem, no? Or it's a bit more complicated than this?
// resources/lang/en/default.php
return [
    'test' => 'test1',
    'field' => ['test' => 'test2'],
];

@iamgergo
You're true, it works well like this. Thank you!


Multiple Datepickers

Hi,
if I integrate multiple datepickers, I can activate them all, so they overlap. Do I have the possibility to close the datepicker if click on another one and it opens?

Version 3.1.3 can not update

$('trigger').on('click',function(){
$('.picker-open').removeClass('picker-open').css({'display':'none'});
});


Lack of "d" in vhdx

@tksh164 : Thanks for your contribution! The author, @jeffgilb, has been notified to review your proposed change.

Merging typo fix


Add extended support for @see tag

This PR adds extended support for @see tag. It tries to maintain backwards compatibility with templates (see tag is still present in getOtherTags with the same structure, as before). But it is also avaiable as new  Reflection::getSee() class method, which adds possibility to create class/method/URL links.

any update on this?

@fabpot Any words on why this hasn't been merged yet? This PR is works excellently (I'm using it).

Thank you @TiS.


navigate params are not updating navigation.state.params

When doing
navigation.navigate(route, params)
The params are not reflected in the navigation.state.params
If you go to a url with parameter such as
myapp/Home?x=1 then x=1 is added to navigation.state.params
Then doing navigation.navigate('Home',{x:undefined}) will change the route to /Home
but the navigation.state doesnt change
then doing another navigation.navigate(anyroute) causes the location to change to /anyroute?x=1 (every history change the params are read from the state)

this is still happening

@509dave16

anyone?

this branch is deprecated
in react-navigation 5 handle by completely diftrent way


Add functionality for handling both encrypted and plain text access t…

…okens

You should squash your commits, too.


OOTB Rework: Need to be pure JS/HTML/CSS

JIRA Ticket(s) if any

MOB-XXXX

Description
Test Steps

Once we address the setTimeout discussion, this one is good to merge, @hardikmashru.


Upstream some list functions

This PR includes some functions for dealing with lists and property tests for those functions.

Just spoke with Brian. The haskPlutEquiv stuff is valuable for property testing Plutarch functions by piggybacking on their Haskell equivalent functions (it avoids having to write manual tests for each of them).
I feel Properties/Utils.hs's export interface could be simplified though. But it is probably not important right now, as all of these testing code will have to moved to ./plutarch-test (and thereby refactored) anyway after #276 is merged.

Moved to #304 so it can be from a different branch.


cargo report future-incompatibilities doesn't check for color support correctly

Problem
cargo report future-incompatibilities does not check for color support correctly.  If you pipe the output to a file or something like less, it is not stripping the colors. This wasn't quite the intended behavior in #9606.  The issue is here where it only checks if stderr supports color.
Steps

cargo report future-incompatibilities > some_file

Notice that some_file contains lots of escape characters
Possible Solution(s)
I'm not entirely sure of the best approach to fix this.  Perhaps just check if both stdout and stderr support color at the line noted above?  I can't imagine a scenario where that would matter.  I'd be reluctant to make this too fussy or complicated, though worst case the check to call strip_ansi_escapes::strip could be moved to the callers, but I think I'd rather avoid that.
Notes
Output of cargo version:
cargo 1.57.0-nightly (d56b42c54 2021-09-27)

I might be missing something here, but since cargo report future-incompatibilities command prints to stdout, what's the reason behind checking stderr only?

@dswij Just checking if you've had a chance to look at this, or had any questions.

I've had a look, but got distracted along the way. I'll continue working on it once I have the chance to.


[plugin]: Shortcuts plugin for the Sidebar

This is a new plugin that allows a user to add "shortcuts" that will be displayed in the Sidebar. A shortcut is a link to a page within a Backstage app and the intention is to provide a convenient way to have access to places that are often visited.

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[x] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Have you tested what happens if I add too many shortcuts and exceed the vertical sidebar space? 😆

@timbonicus 😅  I had not... For now I made it fill up the available space and then overflow with a scroll, which at least on my machine looks decent. Going forward I think adding support for organizing into folders is a better long term solution.


Create CV_Andre.html

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


Package requiring Nim devel

Hey @dom96,
Is it ok to add a package that requires Nim devel? I don't remember seeing one, so I thought I'd ask

I think it's OK as long as you will tell it in Readme of your project. And example of a library in nimble which requires devel - chronicles

https://github.com/status-im/nim-chronicles

Sure, plenty of packages that require devel. You can (and should) specify the minimum Nim version requirement in your Nimble file.


fix: validate build name format not to include forward slash

Background
pipenv run launchable record tests --build 'build-including/slash' go-test report.xml failed with 404 Client Error. this cli uses the specified build name as a part of a request path as follows:
https://{API_ENDPOINT}/intake/organizations/{ORGANIZATION_NAME}/workspaces/{WORKSPACE_NAME}/builds/{BUILD_NAME}/{SESSION_NAME}

When specifying the build name including forward slashes, GET build requests fail due to an unexpected build name or session name.
$ pipenv run launchable record tests --build 'tw/my-build-name' go-test report.xml
Build tw/my-build-name was not found. Make sure to run `launchable record build --name tw/my-build-name` before
404 Client Error:  for url: https://{API_ENDPOINT}/intake/organizations/{ORGANIZATION_NAME}/workspaces/{WORKSPACE_NAME}/builds/tw/my-build-name/test_sessions
Build tw/my-build-name was not found. Make sure to run `launchable record build --name tw/my-build-name` before `launchable record tests`
Traceback (most recent call last):
  File "/Users/username/.local/share/virtualenvs/launchable-go-qooJbKhC/lib/python3.9/site-packages/launchable/commands/record/tests.py", line 283, in run
    send(p)
  File "/Users/username/.local/share/virtualenvs/launchable-go-qooJbKhC/lib/python3.9/site-packages/launchable/commands/record/tests.py", line 250, in send
    elif build_name:
NameError: free variable 'build_name' referenced before assignment in enclosing scope

This is because the request path is built by joining strings. As a result, it seems like record tests requests include unexpected paths for the API. To fix the 404 error on record tests API requests,  there are several options.

Option1: build names should not include /
Option2: build names including / are converted other strings
Option3: change the API behavior to detect forward slashes in build names

This PR implements Option 1 which is the simplest workaround not to cause the above error.
Goal

Fix 404 errors when we specify a build name including /.

How to reproduce the error
CLI version
$ pyenv version
3.6.15 (set by /Users/takanabe/src/github.com/takanabe/go-project/.python-version)

$ pipenv graph
launchable==1.27.0
  - click [required: ~=7.0, installed: 7.1.2]
  - junitparser [required: >=2.0.0, installed: 2.1.1]
    - future [required: Any, installed: 0.18.2]
  - more-itertools [required: >=7.1.0, installed: 8.9.0]
  - python-dateutil [required: Any, installed: 2.8.2]
    - six [required: >=1.5, installed: 1.16.0]
  - requests [required: Any, installed: 2.26.0]
    - certifi [required: >=2017.4.17, installed: 2021.5.30]
    - charset-normalizer [required: ~=2.0.0, installed: 2.0.4]
    - idna [required: >=2.5,<4, installed: 3.2]
    - urllib3 [required: >=1.21.1,<1.27, installed: 1.26.6]
  - setuptools [required: Any, installed: 57.4.0]
  - tabulate [required: Any, installed: 0.8.9]

Steps

pipenv run launchable record build --name build-including/slash --source src=.
go test -v ./... | go-junit-report > report.xml with a go project
pipenv run launchable record tests --build 'build-including/slash' go-test report.xml

Thank you for your contribution!

I released v1.27.1 https://github.com/launchableinc/cli/releases/tag/v1.27.1. Thank you


Enhanced RxBus

Nice repo! Also really simple and easy approach to achieve Pub-Sub pattern in RxBus.
would you consider enhancing the example with smth like https://github.com/apptik/rxHub ?
I would be more than happy to provide a PR.

hey @djodjoni ! thanks for the pointer. honestly, i want to keep this examples as lean and crazy simple as possible. rxHub looks pretty cool but i want to stick with a drop dead Subject for this example (just so everyone understand the working better)
Cheers and thanks!


Upgrade PatternFly from 4.x.x to 5.x.x on kie-tools

Related:

https://github.com/kiegroup/kie-tools/issues/1877
https://github.com/kiegroup/kie-tools/pull/1921

uniforms-patternfly module has been updated by @lordrip here https://github.com/KaotoIO/kaoto-next/tree/main/packages/uniforms-patternfly
thanks!

@yesamer, I moved the library to a standalone repository https://github.com/KaotoIO/uniforms-patternfly. The idea is to have independent versioning after each merge to the main branch and also make it easier to bring the library back kie-tools when makes sense.

Hello @lordrip @yesamer @tiagobento , should we do the same for kogito-apps react codebase?

Hi @jomarko, what do you mean by the same?

@lordrip upgrade patternfly dependencies from 4.x to 5.x for kogito-apps

@tiagobento I generated the full list of components to updated on kie-tools. I used the command:
pnpm -rc exec "[ -d 'src' ] && npx @patternfly/pf-codemods@latest ./src || exit 0" >pf-codemods-v5.logs
Here is the list of files
Here is the full logs

@fantonangeli Nice. I guess that's gonna be the way to achieve this... Trying some things to find out what's the best strategy to tackle it. I guess it's fine to upgrade in parts.. we just need to know what packages will be done on each part

@tiagobento I think we can create a new patternfly-v5-upgrade branch, configuring syncpack to allow Patternfly v4 and v5 together.
Then we upgrade packages by packages or block of packages, depending on how many files needs to be updated.
Then open the final PR to main branch.
WDYT?

Hi @tiagobento @fantonangeli, I think you are aware, but just in case, this is the fork of uniforms-patternfly that we did for Kaoto :point_right:  https://github.com/KaotoIO/uniforms-patternfly using patternfly v5.
The reason why I mention it is because maybe it could simplify the update process a bit because perhaps you could migrate one application at a time (I don't know if this is something that you're after), despite the application using uniforms, otherwise I guess you would need to upgrade uniforms first. :thinking:

Thank you @lordrip for your very nice work.
I think we can use your uniforms-patternfly  to update @kie-tools/uniforms-patternfly

Hi everyone, I would like to understand better the approach we are going to proceed. To me, it sounds we discuss currently these options:

upgrade patternfly from v4 to v5 in small steps directly in kie-tools packages, what may bring a problem of parallel usage of different versions?
replace kie-tools/uniforms-patternfly with KaotoIO/uniforms-patternfly, I am not sure if this is somehow conforming to kie-tools strategy, I mean there is effort to have kie-tools as one mono repo

thank you for any comment, I am always happy when similar upgrades are achieved

Hi @jomarko ,

upgrade patternfly from v4 to v5 in small steps directly in kie-tools packages, what may bring a problem of parallel usage of different versions?
We are still defining the groups of packages, possibly isolated, to update, limiting the impact to other groups and how to proceed.

replace kie-tools/uniforms-patternfly with KaotoIO/uniforms-patternfly, I am not sure if this is somehow conforming to kie-tools strategy, I mean there is effort to have kie-tools as one mono repo
I was referring to import their code to kie-tools/packages/uniform-patternfly If it's an "ok way to proceed". Of course we will set again the folders following the kie-tools style.


publish<EMAIL_ADDRESS>

Requested by: @bitsandfoxes
Merge target: feat/4.0.0
Quick links:

View changes
View check runs

Assign the accepted label to this issue to approve the release.
Leave the #retract comment under this issue to retract the release (original issuer only).
Targets

[ ] nuget
[ ] github
[ ] registry

Targets marked with a checkbox have already been executed.  Administrators can manually tick a checkbox to force craft to skip it.

https://github.com/getsentry/craft/pull/505

#retract


fix alerts query wait/loading issue

Fix the bug that loading spinner is not showing for the alert page when alerts are loading.

Current coverage is 36.38% (diff: 100%)

Merging #161 into 2.1 will decrease coverage by <.01%

@@                2.1       #161   diff @@
==========================================
  Files           259        259
  Lines         14015      14015
  Methods           0          0
  Messages          0          0
  Branches       2346       2346
==========================================
- Hits           5100       5099     -1
- Misses         8201       8202     +1
  Partials        714        714

Powered by Codecov. Last update c9513dd...7deab10


Add default certificate option

Is your feature request related to a problem? Please describe.
Having to rely on a certificate per Ingress
Describe the solution you'd like
Allow the usage of a default certificate, similar to nginx with the following option
extraArgs: { default-ssl-certificate: "<namespace>/<secret>" }

Explain any additional use-cases
I believe it is much more simple to manage a single wildcard for the Ingress Class. Issuing certificate per ingress means more certificate that can expire and the potential to hit rate limiting on let's encrypt

currently you may just create a wildcard Certificate using cert-manager to account for automatic renewal, and refer to it in the TLS section of the Ingress. Multiple Ingresses may refer to a single TLS secret, and we do support wildcard certificates.

Hello @wasaga I agree that's what I did first but the limitation is that it won't work for Ingress outside the namespace, since you cannot load a secret from another namespace. Provisioning a wildcard in each of the namespace that will be using it kind of defeat the purpose.

Closed by #151


biharmonic smoother

Suggesting that we add the option of making the background smoothing biharmonic, to reduce the damping of eddy-scale curvature while still smoothing out grid point-scale noise near weakly stratified regions ...

I've just made the https://github.com/angus-g/python-ale/tree/adaptive-biharmonic branch which changes the ADAPT_MIN_SMOOTH parameter to ADAPT_BIHARMONIC_SMOOTHING (which acts like $\kappa$ in a regular diffusion equation, I think). The weighting for the density/pressure adaptivity now switches between 0 and 1, instead of 0 and 1 - min_smooth.

OK, cool - I'll take a look. Any chance you can build it for me, like the ones in your python-ale/build/ directory?

I've put it in python-ale/build-biharmonic, hopefully that works!

Trying now, but not sure it is picking up the right version, for some reason. I am using
sys.path = ["/g/data/x77/ahg157/python-ale/build-biharmonic/lib.linux-x86_64-cpython-310"] + sys.path

and made a new .toml file with the ADAPT_BIHARMONIC_SMOOTHING parameter set, but it doesn't seem to pick it up, and instead lists the old parameter:
 init_MOM_state ADAPT_ALPHA_RHO:   -1.0000000000000000
 init_MOM_state ADAPT_ALPHA_P:   -1.0000000000000000
 init_MOM_state ADAPT_TIMESCALE:    3600.0000000000000
 init_MOM_state ADAPT_MEAN_H:  F
 init_MOM_state ADAPT_SLOPE_CUTOFF:    1.0000000000000000E-002
 init_MOM_state ADAPT_SMOOTH_MIN:    0.0000000000000000
 init_MOM_state ADAPT_ADJUSTMENT_SCALE:   0.10000000000000001
 init_MOM_state ADAPT_RESTORING_TIMESCALE:<PHONE_NUMBER>0000000
 init_MOM_state ADAPT_TWIN_GRADIENT:  T
 init_MOM_state ADAPT_PHYSICAL_SLOPE:  T
 init_MOM_state ADAPT_RESTORE_MEAN:  F

Is this expected behaviour?

Also, I'm trying to set:
ADAPT_BIHARMONIC_SMOOTHING = 1.0

under the assumption there is a dependence on grid size build in.
Is that assumption correct?

Is this expected behaviour?

No, that's a bit bizarre! I can reproduce that myself though, so I'll see if I can figure out what's going on.

Is that assumption correct?

That should be correct, yes.

Okay! It was some dynamic linker silliness where it was loading libMOM6.so from the non-biharmonic build directory. Should be fixed now.

Yep, now it picks up the new parameter. I'll give it a burl and report back.

Tried to run -- it starts and seems to select the right parameters now. But it hangs, even for a single iteration, on the 10th cell in this notebook:
https://github.com/AndyHoggANU/anu-tub/blob/master/diagnostics/AG_Diagnostic_Test-biharmonic.ipynb
@angus-g -- can you reproduce this one?

Interesting that the error messages aren't coming through in the notebook, I guess because they're generated from Fortran. Anyway, running standalone I get a lot of tangles like this:
 FATAL error: MOM_regridding, check_grid_column: Negative layer thickness implied by re-gridding, in build_grid_adaptive
 k,h,hnew=          17   9.9999999999999995E-007  -1.3702797938728304E-002
 dzI(k+1),dzI(k)=  -8.9444179059934353E-004  -1.4598239729327648E-002

I think I'll need to re-think how the limiting works for the biharmonic smoothing.

Yeah, it is strange, because I get lots of other fortran print statements coming through. Also surprising it hung, rather than crashed. Anyway, I can see limiters might need to be different for biharmonic ... Let me know if you get something new to test.

We have discussed this a bit offline, but it seems possible that the inherent oscillations in a biharmonic filter might make this unsuitable for iterated application, as we're doing here. The other sources of diffusion in a running model are probably sufficient to make this approach work in that context.

I would say that we have better options than biharmonic smoothing to solve this issue, so am closing this now. See issue #11 for details.


AwsLogDriverProps interface property streamPrefix should be required

The AwsLogDriverProps interface has a property streamPrefix. This is currently not required by CDK, so you can cdk synth and attempt to cdk deploy the stack without specifying this property. However CloudFormation deployment will then fail with an error:
Fargate requires log configuration options to include awslogs-stream-prefix
to support log driver awslogs. (Service: AmazonECS; Status Code: 400;
Error Code: ClientException

Example code that reproduces the issue:
    const definition = new ecs.FargateTaskDefinition(this, 'definition', {});
    definition.addContainer('my-app', {
      image: ecs.ContainerImage.fromAsset(this, 'my-app-image', { directory: './app' }),
      logging: new ecs.AwsLogDriver(this, 'my-app', {})
    });

    // Launch the image as a service in Fargate
    new ecs.FargateService(this, 'app', {
      cluster: cluster,
      cpu: '256',
      memoryMiB: '512',
      desiredCount: 1,
      taskDefinition: definition
    });

Ideally this streamPrefix property should be marked as required by CDK for Fargate task definitions such that cdk synth and cdk deploy fail locally with an error message prior to sending the synthesized CF template off to CloudFormation
Alternatively perhaps CDK could choose to automatically fill the streamPrefix with the container name, as this is a fairly logical default.

If we have a good smart default, that's always the preferred option in the CDK.

The streamPrefix is already a required property.

Can confirm: see https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-ecs/lib/log-drivers/aws-log-driver.ts#L21


Load default roots.pem in PHP via grpc_set_ssl_roots_override_callback

This is required to not depend on user manually setting GRPC_DEFAULT_SSL_ROOTS_FILE_PATH env variable to get access to default roots. See #4834
C# implementation (for reference)
#5011

After this is implemented, the make install-certs should be removed:
https://github.com/grpc/grpc/blob/master/tools/dockerfile/grpc_interop_php/build_interop.sh#L43

Can close this?


compass: remove compass dependency

Remove compass dependency. 🐜 ❗

Also: We should definitely put something in place to build CSS from SCSS. I'll try to go with grunt-sass…

I can now say, with some certainty, that nothing inside laxar-uikit requires compass.
To validate that, I removed the @import directive referencing compass and the config file. I then built the theme.css with node-sass and postcss/autoprefixer (see changes in package.json).
To make sure that all Partials (SCSS files starting with an underscore) still work, I added another file besides the theme.scss where I imported the partials in an order that seemed sensible.
That being said, this is still a breaking change, because users might import laxar-uikit/modules/bootstrap and expect it to bring compass along. (see diff)
Some users might be fine with importing compass-mixins without having to commit to the whole Ruby/Compass toolchain. Others might have to stick with Ruby and Compass and import compass themselves.
/cc @x1B

@alex3683, @x1B, @d-voss: Review pls? Also, is it possible this change impacts something else that I missed?

@jpommerening
If I get that right, we would completely remove compass and dependencies on our side. So if a user needs compass, then because he wants to use it, not because we deliver something needing it. Right?
Using node-sass myself in another project. I'd vote for it.

@jpommerening LGTM, assuming the old @import paths (from the config.rb) are now provided for us by webpack?
Needs a big red-flaggy upgrade information entry tho.

@alex3683: exactly. This change removes Compass from the dependency chain completely. Actually, the Compass specific features were not needed at all. Because of the way Sass works, earlier versions exposed Compass when the user imported styles from laxar-uikit. Now, if a user needs Compass they'll have to import it explicitly and add it to their own dependencies in bower.json or package.json.
@x1B: The theme.css is self-contained. If the user wants to use Sass to bundle their own theme and @import stuff from laxar-uikit, they'd have to configure the sass-loader accordingly (i.e. they need to supply the includePaths option. Yes, this needs to be documented.
Alternatively we could use ~-Imports to let webpack resolve modules. That would reduce the amount of required setup, but is really webpack specific and not compatible with standalone Sass.

@jpommerening ok, I think both ways to emulate the previous import paths should be fine for us, since they dont need any framework support. :+1:

Then I'll leave it as it is. I'm not comfortable writing webpack specific imports in the SCSS files.
Since there is currently not much of a README, there also is no documentation to update. I'll open another issue for providing proper documentation (at least how to get started with either pre-built themes or how to use the SCSS files).

Implemented on master (v2.0.0)
BREAKING CHANGE
Laxar-UIKit no longer exports Compass specific mixins and functions.
We strongly recommend switching to plain Sass, as Compass is no longer maintained, alternatives (libsass, node-sass) are faster by an order of magnitude, easier to set up and integrate better with JavaScript based build tools such as webpack.
If you need Compass mixins and functions you can use compass-mixins which is compatible with node-sass and available via NPM and Bower. Refer to the Laxar-UIKit README for setup instructions.
If you absolutely need to use the original, Ruby-based, Compass, you can still do that. You just need to @import "compass"; yourself.


Cherry-pick from release into master: Cosmos DB Etag hotfix

Description
This is a cherry-pick from release into master of the Cosmos DB Etag hotfix. #2322

@artursouza no because there are commits in release 1.9 that do not belong in master.

What are those? I don't recall us getting into that situation before.


bug: ion-tabs is always in the top of the app

Type: bug
Platform: android 4.4 webview
Use
ionic start TabsAppDemo tabs

start a new ionic app. and the ion-tabs is always in the top of the app.
It looks like any XiaoMi Mobile or MIUI Mobile have this problem.

Greetings, @pantao!
We are now requiring all issues to be submitted through our custom issue form so that we have all of the information necessary to fix them as quickly as possible.
Your progress on this issue has been saved at the following url:
link to Ionic issue form
This issue will be closed if not resubmitted through the form. Please fill out the rest of the form so that we may assist you.
Thank you for allowing me to assist you.

I believe this duplicates #2584 and should be closed. Looks like this is as designed.

Thanks

Greetings @pantao!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.


OrtResult: Speed-up getFilePathRelativeToAnalyzerRoot()

When the OrtResult contains a large number of nested VCSes
Repository.getRelativePath() executes relatively slowly. In combination
with a large number of projects and packages in which case this function
gets called quite often this leads to terrible execution time.
For my real world example the evaluator took about 30 minutes while
computing the reports took around 3 hours. With this change it executes
altogether in less than two minutes again.
Signed-off-by: Frank Viernau<EMAIL_ADDRESS>

Since you have to update the commit anyway to fix the test I'll add one commit message nit: "VCSes" -> "VCSs" or "VCS's"


fix: codegen generating migrations that apply backwards

Fixes #949
BREAKING CHANGE: requires inject comment in migration/src/lib.rs to now be inject-above (and be moved to be after last item)

I didn't know if I should change CHANGELOG.md#39 since 0.12 is already out.

Looks good. I put back the "below" comment, so that older version of gen will still work against starters (which are always pointing to master).
In v<IP_ADDRESS> we're radically changing how starters are created, so that generators and starters are going to be coupled + we're going to have an amazing "new app" generator subsystem that will allow for any kind of app to be generated (using rhai scripts)


Fog/Poppy Docs

Updated with your points @ycombinator

Thanks @mdarby. LGTM.
I noticed that the update service samples are inconsistent amongst PHP, Node.js, curl, and Ruby. I'll fix them all in a separate PR. No change necessary to this PR.
@smashwilson, would you mind taking a look and merging?

Aye aye :bow:

Yup - looks good to me. :stars:


Port a couple of examples

Yes, I think so.

Let's merge it? @vigsterkr

Are there many examples left to be ported?


Remove tests for petsets with fake clientset

The way i registered PetSet objects in api.Schema conflicts
with workings of fake object tracker.

This change is

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

Comments from Reviewable

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

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

Comments from Reviewable


feat: attach/detach bound devices in tray context menu

This PR adds a "nice to have" feature.  Generally, I think that the GUI is great and it would be a mistake to put too much functionality in the system tray. Instead, users should be encourage dto open the main window where operations will be less ambiguous.
However, my day-to-day usage rarely involves inspecting unbound devices, binding devices, or setting up auto attach. I have 2 or 3 bound devices and I either want them attached or not.
And so, this PR adds the connected + bound devices in the context menu.  A check mark is displayed next to devices that are forwarded. Clicking on a device either attaches or detaches depending on the state.

I am new to Rust and this was hard for me to do. 😢 I am concerned about memory leaks. I have already resolved a stack overflow caused by the event handler closure not being unbound. It was getting added to the stack on every context menu open:
if let Some(handler) = self.menu_tray_event_handler.borrow().as_ref() {
    nwg::unbind_event_handler(handler);
}

I've tested the current implementation quite a bit now and it seems OK, but it could be totally wrong and unsafe - I simply don't have enough experience with Rust to know! Nevertheless, I think the feature is a good one.
Unaddressed issues:

No handling of devices that are auto attach. Ideally they would be greyed out since attaching/detaching is pointless.
Windows annoying lag during USB enumeration. I've seen this before, it's not a Rust problem. During attach, the context menu will become unresponsive, presumably because the thread is "busy" doing the attach. Would be nice to let the user know what's happening somehow but IMO it's not too bad.

There's one more issue though: errors while attaching are not reported to the user. We should really spawn a dialog box with the error message, see how it's done in other parts of the attaching code.

Agreed! I think that I can cause an error by opening the menu, unplugging the device, then attempting to forward it. And trying to forward with WSL shutdown.

Additionally, I've noticed that since attaching takes quite some time, once you click on a device in the menu for attaching it, the menu disappears and it won't open up until the attaching is completed. Now, I'm not even sure how to easily fix this, as every way I come up with requires complex state tracking, so maybe it's fine?

Yeah, it's the same for the main window. I hate threads and state, so my vote is to keep it simple. I see this whenever interacting with Windows USB. Their APIs must block for 200ms - 2s during attach/detach events.

I've been running this branch from morning to evening everyday at work for the last month - haven't noticed any problems.


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v2.6.32 to before v5.13.3",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ccbf035ae5de4c535160fc99f73feb44cc55b534",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d69b39d89f362cfeeb54a68690768d0d257b2c8f"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "ccbf035ae5de4c535160fc99f73feb44cc55b534",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "d69b39d89f362cfeeb54a68690768d0d257b2c8f",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "media: zr364xx: fix memory leak in zr364xx_start_readpipe\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.13.3 by commit d69b39d89f362cfeeb54a68690768d0d257b2c8f, it was introduced in version v2.6.32 by commit ccbf035ae5de4c535160fc99f73feb44cc55b534. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1001218