Crash when using both dpdk and rawsock interfaces

Upon initializing a packet rawsock interfaces do not set pkt->cache, and it could point to anything.
In my case pkt->cache seemed to point to the local cache of a dpdk worker thread.
(I guess the packet of rawsock was allocated at the memory, used to store a packet of dpdk before.)
As a result, two threads were using the same cache structure at once.
Cache overflow and reallocation in one thread caused memory corruption and crash in the other one.
The problem was gone after I have inserted an explicit pkt->cache setting in src/dataplane/mgr/sock_io.c:
pkt = alloc_lagopus_packet();
pkt->cache = NULL;

Thank you for suggestion.
We are going to fix this pkt-> cache code in next release.
The current implementation of raw-socket mode uses single thread for all packet processing, so the issue you mentioned is not critical for usual usecase now. But we need to fix it for the future version, which more flexible dataplane for various type of network I/O.
Thanks,

Hi @eugene-che,
We have fixed the issue you mentioned and modified cache-related code to be more general as follows:
This patch is to be included at lagopu version 0.2.6.
---
 src/dataplane/mgr/sock_io.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/dataplane/mgr/sock_io.c b/src/dataplane/mgr/sock_io.c
index b18620d..c6074e3 100644
--- a/src/dataplane/mgr/sock_io.c
+++ b/src/dataplane/mgr/sock_io.c
@@ -39,6 +39,10 @@
 #include "thread.h"
 #include "lock.h"

+#ifdef HAVE_DPDK
+#include "dpdk.h"
+#endif /* HAVE_DPDK */
+
 static struct port_stats *rawsock_port_stats(struct port *port);

 #define NUM_PORTID 256
@@ -46,12 +50,10 @@ static struct port_stats *rawsock_port_stats(struct port *port);
 static struct pollfd pollfd[NUM_PORTID];
 static int ifindex[NUM_PORTID];

-#ifndef HAVE_DPDK
 static bool no_cache = true;
 static int kvs_type = FLOWCACHE_HASHMAP_NOLOCK;
 static int hashtype = HASH_TYPE_INTEL64;
 static struct flowcache *flowcache;
-#endif /* HAVE_DPDK */

 static bool volatile clear_cache = false;

@@ -636,13 +638,11 @@ dp_rawsock_thread_loop(__UNUSED const lagopus_thread_t *selfptr,
     return rv;
   }

-#ifndef HAVE_DPDK
   if (no_cache == false) {
     flowcache = init_flowcache(kvs_type);
   } else {
     flowcache = NULL;
   }
-#endif /* HAVE_DPDK */

   dparg = arg;
   running = dparg->running;
@@ -655,12 +655,10 @@ dp_rawsock_thread_loop(__UNUSED const lagopus_thread_t *selfptr,
       err(errno, "poll");
     }
     for (i = 0; i < portidx; i++) {
-#ifndef HAVE_DPDK
       if (clear_cache == true && flowcache != NULL) {
         clear_all_cache(flowcache);
         clear_cache = false;
       }
-#endif /* HAVE_DPDK */
       flowdb_rdlock(NULL);
       port = dp_port_lookup(DATASTORE_INTERFACE_TYPE_ETHERNET_RAWSOCK,
                             (uint32_t)i);
@@ -681,11 +679,8 @@ dp_rawsock_thread_loop(__UNUSED const lagopus_thread_t *selfptr,
       if (port->bridge != NULL &&
           (port->ofp_port.config & OFPPC_NO_RECV) == 0) {
         pkt = alloc_lagopus_packet();
-#ifndef HAVE_DPDK
-        if (flowcache != NULL) {
-          pkt->cache = flowcache;
-        }
-#endif /* HAVE_DPDK */
+        pkt->cache = flowcache;
+
         /* not enough? */
         (void)OS_M_APPEND(pkt->mbuf, MAX_PACKET_SZ);
         len = read_packet(pollfd[i].fd, OS_MTOD(pkt->mbuf, uint8_t *),
@@ -769,6 +764,11 @@ dp_rawsock_thread_init(int argc,

 lagopus_result_t
 dp_rawsock_thread_start(void) {
+#ifdef HAVE_DPDK
+  no_cache = app.no_cache;
+  kvs_type = app.kvs_type;
+  hashtype = app.hashtype;
+#endif /* HAVE_DPDK */
   return dp_thread_start(&rawsock_thread, &rawsock_lock, &rawsock_run);
 }

Could you check it on your environment?

Hi @ynkjm,
The patch works as expected. Thank you!
The only thing that bothers me, the patched code does not handle failures of alloc_lagopus_packet.
I have encountered a crush at this site, while debugging my patch to fix the queue handling.
Eugene

I have inserted the patched switch into another testbed. Unfortunately, it crashes.
The problem seems to be somewhere in cache:

gdb show instructions extracted from the cache point to a wrong piece of memory.
if I reapply my modification pkt->cache = NULL (which practically disables caching for rawsock interfaces) the switch stops crashing

I do not have any guesses for the source of error right now.

Hi @eugene-che,
Thank you for your detail report. We are going to fix this segfault issue by reference to your patch.

HI @eugene-che,
We have submitted a series of bug fix patch to the Lagopus 0.2.8 release.
We have fixed this issues by reference of your patch code.
Thanks,
Yoshi


Submodel Capability

I am not able to open the submodel capability (https://github.com/admin-shell-io/submodel-templates/blob/main/development/Capability/1/0/CapabilitySubModelTemplate_V1.3.aasx) in AASXPackageExplorer https://github.com/admin-shell-io/aasx-package-explorer/releases/tag/v2023-09-12.alpha. (Error: Object reference not set to an instance of an object.). The aasx file content may be exported to XML and reviewed manually. Is it not possible to open the file directly in AASXPackageExplorer? Other Submodel Templates may be opened without any problem.

@miriamschleipenEKS Please try to open it with newest version of Package Explorer and also the  newest version of SMT Capability which you can find in our Repo


Closing this issue.


Display an error when historical requests are not supported

We using the "memory" backend for graph, we should display an error when doing a "g.Context...."

http://softwarefactory-project.io/r/5269


Add default acronym mapping

Add default acronym mapping, autorest.md can overwrite them
Add InputAcronymTransformer.UpdateAcronyms
Add InputUrlToUriTransformer.UpdateSuffix
Add InputRenameTimeToOnTransformer.Update to InputNamespaceTransformer

A few comments. After this is merged, could you please also migrate this change (or the needed part of this change) to MGC? I believe they need to have this change as well

Actually, I am not sure about the plan for MGC, because if we are planning to have naming checks for models and properties in typespec CI, and let the user to take over the renaming. We don't need these transformers for typespec input anymore. I think that's better and doable, but it takes time to get all rules implemented.

A few comments. After this is merged, could you please also migrate this change (or the needed part of this change) to MGC? I believe they need to have this change as well

Actually, I am not sure about the plan for MGC, because if we are planning to have naming checks for models and properties in typespec CI, and let the user to take over the renaming. We don't need these transformers for typespec input anymore. I think that's better and doable, but it takes time to get all rules implemented.

I am also not sure - if you have any thoughts, let us put them in this issue: https://github.com/microsoft/typespec/issues/3707


Incorrect caption on "Quick Calculation" button

The caption on the "Quick Calculation" button is no longer correct if TaxBrain is using taxcalc 0.13.2.
Suggest changing it to say "small sample" instead of "2% sample".

Issue #747 was resolved by pull request #759.


Unable to change labels/keys dynamically

We have a dashboard where we use angular-morris-chart to display various graphs, with the user being able to change the graph data dynamically. When such a change is initiated, we need to change the xkey/ykeys/lineData/lineColors.
With the current implementation, changing only the lineData is allowed. I've proposed a fix in PR #24 . Please review and merge.

merged @venkatramachandran
thx


[USPTO] Problems with a few documents

We have problems with the following files:

[ ] US07057742-20060606.XML
[ ] US20220240351A1-20220728.XML
[ ] US07062920-20060620.XML
[ ] US20220240350A1-20220728.XML

@cconzen could you have a look why we can not process them.
I send the files via chat.

docdb and open alex now


Support Promotion Code resource and allow promotion_code when creating a subscription

Closes: #774
This adds the Promotion Code API as well as support for the promotion_code parameter on a subscription.
Per the docs, restrictions have been included to match Stripe's restrictions on promotion codes.

@gciampa Thanks for this work! - I found a minor issue, it seems that the promotion_code is not associated to the discount object in a subscription, even though when created from there. It seems to find the proper coupon from a promo code.
You should easily replicate using:
stripe_customer.subscriptions.create({
  promotion_code: '<my promo id>',
  items: [ { plan: '<my plan id>'} ]
})

stripe_customer.subscriptions.first.discount.promotion_code # Throws error for unknown method 'promotion_code'

I can provide more details if it isn't clear enough.

@gciampa are you able to look into the above issue?

@juanfer0002 Sorry for the delay on getting back to this! Thanks for catching that. I've removed the promotion codes from the discount object on subscription. Let me know if there's anything else needed. Happy to get this wrapped up this week.


CORGI-738 match more variants via brew tags

This allows matches between variants and streams for extra streams including openshift-4.13.z as in the description of CORGI-738.

@RedHatProductSecurity/corgi-devs please review. I added some details of comparing stream and variants from supported_cpe_map to CORGI-738


Fix error for java 11/12 compatibility

Description
Fixed error for java 11/12 compatibility.

update Hibernate ORM(5.2.12.Final -> 5.4.3.Final) & Hibernate Search (5.5.5.Final -> 5.11.1.Final) version
upgrade commons-lang3 version (3.5 -> 3.8.1)

Related Issue : #1704
How Has This Been Tested?
All of the default functions were tested search as Ingestion, Dashboard
Need additional checks?
All of the data crud processing must be checked.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have read the CONTRIBUTING document.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have added tests to cover my changes.

Additional Context

run build
deploy to 6

run build
deploy to 6

run build
deploy to 6

run build
deploy to 6


TinyClient not functioning properly

When using yhe pyroreceiver and tinyclient to sent packets, localhost works flawlessly with 500ns per packet (200B).
However when doing this across 2 carnet computers, it fails to even recognise the other exists, even though i confirmed eith netstat that the server is indeed online and listening on the correct address and port.

Marked as obsolete.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Support link and typos.

Added support link in top navigation.
Fixed some typos in german page.

Remember to update the Spanish version, @Revokee


Is it possible to play audio when Do Not Disturb mode is on, but not in silent mode?

Are there AudioSessionConfiguration recipes that make it such that audio will not play while the phone is in silent mode but will play while in "Do Not Disturb" mode?
For example: AudioSessionConfiguration.music() will play in both silent mode and do not disturb mode.
I have audio configurations that will respect silent mode, but then sound will not play while do not disturb mode is on.
Is the behavior I'm asking for something that is possible on iOS and/or Android?
Thanks for your help!

I can't provide advice on how to use Android's and iOS's APIs, although you might be able to find the iOS/Android expertise by asking (2 separate questions) on StackOverflow (or searching existing questions). Since the native APIs are wrapped, you will be better off asking questions about the native APIs than asking specifically about Flutter.


Language server middleware support in VS LSP

We want to have a way for C# LSP server to ask Razor for the correct location in the original for every given projected document.
We already have support for that in OmniSharp to enable VS Code scenarios. We want to do the same in VS.
@NTaylorMullen @ryanbrandenburg

No longer applicable.


Update apiextensions to v3

Checklist

[ ] Update changelog in CHANGELOG.md.

crdstorage needs some ❤ to use the latest version of apiextensions otherwise we cannot introduce lates AWS GS v1alpha3CR's in api. it is currently breaking see:
service/service.go:474:4: cannot use k8sClient.G8sClient() (type "github.com/giantswarm/apiextensions/v3/pkg/clientset/versioned".Interface) as type "github.com/giantswarm/apiextensions/v2/pkg/clientset/versioned".Interface in field value:
	"github.com/giantswarm/apiextensions/v3/pkg/clientset/versioned".Interface does not implement "github.com/giantswarm/apiextensions/v2/pkg/clientset/versioned".Interface (wrong type for ApplicationV1alpha1 method)
		have ApplicationV1alpha1() "github.com/giantswarm/apiextensions/v3/pkg/clientset/versioned/typed/application/v1alpha1".ApplicationV1alpha1Interface
		want ApplicationV1alpha1() "github.com/giantswarm/apiextensions/v2/pkg/clientset/versioned/typed/application/v1alpha1".ApplicationV1alpha1Interface

That error is coming from crdstorage Config
var storage microstorage.Storage
	{
		c := crdstorage.Config{
			G8sClient: k8sClient.G8sClient(),
			K8sClient: k8sClient.K8sClient(),
			Logger:    newLogger,

			Name: "cluster-service",
			Namespace: &apiv1.Namespace{
				ObjectMeta: metav1.ObjectMeta{
					Name: "giantswarm",
				},
			},
		}


Simplify conv localizer code for contacts

No need to parse the assertion there. Every processed contact will have assertion field that's generated during syncing and it has to match chat assertions because they are used to create these SBS chat convos.
Pass participant list as argument and modify participants in place rather than returning new list.
Fix contactsFetched not being set to true in the loop, causing contacts to be reloaded for every participant in the list.
Another change - the subject of the ticket - is not to localize participant name if more than one contact matches an assertion. Because we are not saving which contact exactly was used to make the conversation, we can't risk picking the wrong one and confusing the user.

cc @buoyad


Increase the length of server error message

Increase the maximum length of the error message from the server that is
displayed by the client incase of a handshake error. 64 characters
wasn't enough to show a network magic missmatch.

bors r+


Avoid use of hard-coded password in Open Liberty configuration

See:  https://github.com/eclipse/microprofile-starter/issues/335  though the fix there broke the project tests, so was reverted.

Back to the drawing board. The previous PR #336 did cause JWT tests to fail though. A different solution needs to be provided.

It seems like there could be two directions to go in, to enable the Open Liberty config change made in https://github.com/eclipse/microprofile-starter/pull/336.

Have the automated test generate the certificates using the password generated by the Open Liberty runtime.  It looks like they might be generated here https://github.com/eclipse/microprofile-starter/blob/master/gencerts.sh  but this might be done with a static, fixed key using "atbash" as password.     This might require some rework/reordering of the test logic.   I'm not too familiar with any of this.  ((I noticed too it was:  https://github.com/eclipse/microprofile-starter/blob/master/src/main/resources/files/TestSecureController.java.tpl    where the JWT code loads the keys.)

Accept that the Open Liberty server config during the test is going to be different from that generated from the MicroProfile starter, and accept that that is "close enough" or acceptable.     In this approach, we're OK taking the config actually generated and overriding it using a configDropin or similar override mechanism to test using something like the existing config, with the pre-generated certificate.

But in either case, I'm suggesting adjusting the tests rather than adjusting the config Open Liberty generates.
Hope that moves the discussion forward a bit.

and use p12 instead of JKS

@Emily-Jiang Is this still an issue?


2to3 on candig-server: progress and problems

This will be the ticket that will used down the road for candig-server's codebase migration.
Now we have 7 errors and ~32 failing tests. The number of failing tests varies mainly due to the failing tests under test_simulated_stack, though all of the failing tests under test_simulated_stack are failing for the same thing..
`
FAIL: testGetBiosample (tests.unit.test_simulated_stack.TestSimulatedStack)
Traceback (most recent call last):
File "/home/travis/build/CanDIG/candig-server/tests/unit/test_simulated_stack.py", line 1249, in testGetBiosample
self.verifyGetMethodFails(path, badId)
File "/home/travis/build/CanDIG/candig-server/tests/unit/test_simulated_stack.py", line 320, in verifyGetMethodFails
self.assertObjectNotFound(response)
File "/home/travis/build/CanDIG/candig-server/tests/unit/test_simulated_stack.py", line 288, in assertObjectNotFound
self.assertEqual(404, response.status_code)
AssertionError: 404 != 500`

Bug report: when access level is not 4, we see some 400 on /count
Bug report: Are access levels still handled correctly?

Total
Skip
Error
Fail
Success
Fail rate
Build #

788
82
175
12
519
23.73%

822
82
46
23
671
8.39%

822
82
30
33
677
7.66%

822
82
26
32
682
7.06%

822
82
11
33
696
5.35%

822
82
6
32
702
4.62%

822
82
7
31
702
4.62%
922

822
82
6
28
706
4.14%
923

822
82
6
20
714
3.16%
927

Now we have 7 errors and ~32 failing tests. The number of failing tests varies mainly due to the failing tests under test_simulated_stack, though all of the failing tests under test_simulated_stack are failing for the same thing..
`
FAIL: testGetBiosample (tests.unit.test_simulated_stack.TestSimulatedStack)
Traceback (most recent call last):
File "/home/travis/build/CanDIG/candig-server/tests/unit/test_simulated_stack.py", line 1249, in testGetBiosample
self.verifyGetMethodFails(path, badId)
File "/home/travis/build/CanDIG/candig-server/tests/unit/test_simulated_stack.py", line 320, in verifyGetMethodFails
self.assertObjectNotFound(response)
File "/home/travis/build/CanDIG/candig-server/tests/unit/test_simulated_stack.py", line 288, in assertObjectNotFound
self.assertEqual(404, response.status_code)
AssertionError: 404 != 500`

Now that all tests are passing, we are in the process of fixing all of the bugs and issues etc. We will be submitting this for review sometime in July. Before that, a couple things will happen

Make sure we have the namespace issue sorted out
Backport some import patches to the current master/develop branch
Archive the existing master branch after releasing a v0.9.4, potentially the last release of python 2 codebase; archive can live in another branch

Bug report: when access level is not 4, we see some 400 on /count
Bug report: Are access levels still handled correctly?

Turns out the issues are with some mock dataset having the patientId incorrectly set to something > 0.

2to3 branch merged & archived. Closing issue!


Updated to work with XR plugin management (non-legacy)

Edited the WebXRCamera.cs and WebXRController.cs scripts to work with modern XR plugin management (non-legacy).
Also updated the readme for In-Editor VR testing.

Thanks for the PR.
Which versions of Unity this change supports?

2019.1 and later.
On Sat, May 30, 2020, 6:23 AM De-Panther<EMAIL_ADDRESS>wrote:

Thanks for the PR.
Which versions of Unity this change supports?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MozillaReality/unity-webxr-export/pull/406#issuecomment-636330513,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE4RZ5HZTKVRC2ILC7W263LRUECG3ANCNFSM4NNSS5FA
.

@fernandojsg maybe it's time to drop the support for 2018.4?
But even then, how many devs use the old APIs rather than the new one?
A solution could be:

Remove the current WebXRCamera and WebXRController. Let the dev get the Pose of camera/controllers, and let him decide how to implement them in his project.
After removing the current classes, adding our own samples of implementing them, that works with both the old and new APIs. We can use Unity's Assembly Definitions files to determine which API is currently active, and select the relevant API to use.
Adding Assembly Definitions files to this PR and use them to select which API to use.

What does the both of you think?

Those are good ideas. However, I believe that Unity's 2019.x APIs support
the legacy XR use as well without any changes.
I loaded my project without adding the modern Unity XR Plugins, and it
worked just fine on my Oculus Quest (on Link). Of course, it does then
still need the deprecated Project Settings checked.
(By the way, thanks for the excellent hooks into WebXR. I think this is an
exciting direction for releasing VR apps.)
--
Robert LiKamWa
Assistant Professor, Arizona State University
School of Arts, Media and Engineering
School of Electrical, Computer and Energy Engineering
http://meteor.ame.asu.edu
On Sat, May 30, 2020 at 10:26 AM De-Panther<EMAIL_ADDRESS>wrote:

@fernandojsg https://github.com/fernandojsg maybe it's time to drop the
support for 2018.4?
But even then, how many devs use the old APIs rather than the new one?
A solution could be:

Remove the current WebXRCamera and WebXRController. Let the dev get
the Pose of camera/controllers, and let him decide how to implement them in
his project.
After removing the current classes, adding our own samples of
implementing them, that works with both the old and new APIs. We can use
Unity's Assembly Definitions files to determine which API is currently
active, and select the relevant API to use.
Adding Assembly Definitions files to this PR and use them to select
which API to use.

What does the both of you think?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MozillaReality/unity-webxr-export/pull/406#issuecomment-636360617,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE4RZ5F6644H7JQZQY4GGJ3RUE6VPANCNFSM4NNSS5FA
.

I'm ok with deprecating support for the older version and both the legacy XR API.
WebXR is a fairly new API and it's continually improving so I believe they should understand that it's ok to be updated to the latest browser as well as to the latest Unity.
Also due to the scope of this project, it should be easier to maintain with less backwards compatibility, adding support for something that is going to be deprecated soon enough it's something I don't think we should use our limited time for.
So +1 to the proposal by @De-Panther

+1 on the assembly definitions

Ok, so lets start with this PR. which use the new API, and if someone will want to add support for the older API using Assembly Definitions, they are more than welcome.


[gui error report] FetchError: request to http://<IP_ADDRESS>:5001/api/v0/repo/gc failed, reas

👉 Please describe what you were doing when this error happened.
Specifications

OS: win32 10.0.25300
IPFS Desktop Version: 0.26.1
Electron Version: 19.1.9
Chrome Version: 102.0.5005.167

Error
FetchError: request to http://<IP_ADDRESS>:5001/api/v0/repo/gc failed, reason: net::ERR_CONNECTION_REFUSED
    at ClientRequest.<anonymous> (C:\Program Files\IPFS Desktop\resources\app.asar\node_modules\electron-fetch\lib\index.js:1391:14)
    at ClientRequest.emit (node:events:526:28)
    at ClientRequest._die (node:electron/js2c/browser_init:101:8492)
    at SimpleURLLoaderWrapper.<anonymous> (node:electron/js2c/browser_init:101:7229)
    at SimpleURLLoaderWrapper.emit (node:events:526:28)

Thanks for submitting this error report @HammaSolutions .
Can you describe more about what happened when you received this error? Did ipfs-desktop continue running or abort when this failure happened? Is ipfs-desktop able to continue running after restarting the app?


cannot remotely debug arm linux

Seems like its using the local x86 gdb (host computer running windows)
Does not seem to be a way to specifie using arm tool chain arm-none-eabi-gdb.exe
top error;
Failed to attach: Remote 'g' packet reply is too long:<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
console error:
warning: while parsing target description (at line 10): Target description specified unknown architecture "arm"
warning: Could not load XML target description; ignoring

Try changing the gdbpath option in the debugger config to arm-none-eabi-gdb.exe then

Nice. undocumented feature. knew there to be one somewhere,
How do i set gdb commands like sysroot?

Thats much better but not hitting breakpoints.
Getting bogus error msg from arm-none-eabi-gdb.exe path not found
Any ideas
No source file named c:\src\orange\WiringOP-Zero\examples\hello.c.
Reading /root/src/WiringOP-Zero/examples/hello from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB.  Attempting to continue with the default arm settings.
Reading /root/src/WiringOP-Zero/examples/hello from remote target...
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB.  Attempting to continue with the default arm settings.
Reading symbols from target:/root/src/WiringOP-Zero/examples/hello...
done.
0xb6fd7a40 in ?? ()
Not implemented stop reason (assuming exception): undefined
No source file named c:\src\orange\WiringOP-Zero\examples\hello.c.
[Inferior 1 (process 1928) exited normally]

Need to add some way to rewrite paths there

This can be accomplished via the autorun configuration:
"autorun": [                 "set substitute-path /root ."             ]

I have the same problem trying to connect to gdbserver running on an ARM7 32bit CPU:
"failed to attach: remote 'g' packet reply is too long (expected 312 bytes, got 328 bytes) "
I am able to connect successfully on the command line with gdb-multiarch. My host environment is Ubuntu 20.04.
I edited the ~/.vscode/extensions/webfreak.debug-0.25.1/package.json and changed the gdbpath from "gdb" to "gdb-multiarch".
Still getting the error popup.
What am I missing?

I edited the ~/.vscode/extensions/webfreak.debug-0.25.1/package.json and changed the gdbpath from "gdb" to "gdb-multiarch".

You have to adjust the gdbpath in your launch configuration, not in the extension.
If you still have issues after doing so, please post your launch configuration and...

I am able to connect successfully on the command line with gdb-multiarch. My host environment is Ubuntu 20.04.

... what you do exactly to connect on the command line. This should be enough data to analyze more.

Rewriting the remote paths work now fine using the sourceFileMap setting. Please recheck with current release for possible open points.
Side note: instead of using a target specific gdb like arm-none-eabi-gdb.exe you may want to check using gdb-multiarch.exe from MSYS2 project -> one to rule them all, with full python support.


Fix GHA: Grafana Importer issues

Description
This PR allows insecure connection establishment, thus allowing
this workflow to complete successfully
Signed-off-by: Krishna Harsha Voora<EMAIL_ADDRESS>

HI @rsevilla87 ptal


NR filter_chain_not_found error with set host in gateway, with wildcard works fine.

Bug Description
I have a problem with Istio. When I install istioctl in kind or in minikube I always receive the below error when I try to connect with tls.
kubectl logs -n istio-system istio-ingressgateway-75f744967f-7r68j

[2022-10-12T05:43:16.541Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 1 - "-" "-" "-" "-" "-" - - <IP_ADDRESS>:8443 <IP_ADDRESS>:35812 - -
[2022-10-12T05:43:40.630Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 1 - "-" "-" "-" "-" "-" - - <IP_ADDRESS>:8443 <IP_ADDRESS>:35934 - -
[2022-10-12T05:43:46.927Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 1836 - "-" "-" "-" "-" "-" - - <IP_ADDRESS>:8443 <IP_ADDRESS>:62931 - -
[2022-10-12T05:43:52.426Z] "- - -" 0 NR filter_chain_not_found - "-" 0 0 785 - "-" "-" "-" "-" "-" - - <IP_ADDRESS>:8443 <IP_ADDRESS>:19021 - -

For reproduce error please use tutorial from istio website:
https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/
This don't work
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - httpbin.example.com
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      credentialName: httpbin-credential
      mode: SIMPLE

but when I change hosts in gateway to wildcard everything works fine
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - "*"
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      credentialName: httpbin-credential
      mode: SIMPLE

Probably something is wrong with SNI, but I don't know what.
Version
Istioctl
client version: 1.15.2
control plane version: 1.15.2
data plane version: 1.15.2 (1 proxies)

Kubectl
Client Version: v1.24.2
Kustomize Version: v4.5.4
Server Version: v1.24.1

Affected product area

[ ] Ambient
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
[ ] Multi Cluster
[ ] Virtual Machine
[ ] Control Plane Revisions

Is this the right place to submit this?

[X] This is not a security vulnerability
[X] This is not a question about how to use Istio

I resolved this by fix curl command:
curl -vk -HHost:httpbin.example.com --resolve "httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST" \
 "https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418"

Error was because when run command with curl I have to use --resolve parameter.

Great!


fix lint rules

Signed-off-by: Ke Xu<EMAIL_ADDRESS>
Description

Checklist

[ ] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

Codecov Report

Merging #1714 (3336928) into main (352c30c) will increase coverage by 4.78%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1714      +/-   ##
==========================================
+ Coverage   92.09%   96.87%   +4.78%
==========================================
  Files          86       12      -74
  Lines        4263      160    -4103
==========================================
- Hits         3926      155    -3771
+ Misses        337        5     -332

Flag
Coverage Δ

unittests
96.87% <ø> (+4.78%)
:arrow_up:

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

Impacted Files
Coverage Δ

...tabalanceanalysis/distribution_balance_measures.py

...ranalysis/erroranalysis/analyzer/error_analyzer.py

...leai/responsibleai/databalanceanalysis/__init__.py

responsibleai/responsibleai/_tools/__init__.py

...leai/responsibleai/modelanalysis/model_analysis.py

responsibleai/responsibleai/managers/__init__.py

...ponsibleai/responsibleai/rai_insights/constants.py

...ranalysis/erroranalysis/_internal/matrix_filter.py

...ai/responsibleai/_tools/causal/causal_constants.py

...sibleai/responsibleai/_tools/shared/base_result.py

... and 64 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


[audio] Music struct requires being updated inside functions

Some weeks ago raudio module was completely reviewed and Music struct redesigned, it was changed from an opaque pointer to a public struct, like all the other structs available in raylib.
It was long time I wanted to do this change, not only to expose functions parameters or make its bindings easier but also to make it consistent with all the other structures in raylib. Most raylib functions receive data by value, it was a design decision and I try to stuck to it.
Unfortunately, Music struct includes sampleLeft parameter that requires being updated as long music is being played.
Functions that update sampleLeft parameter:
void UpdateMusicStream(Music music);      // Updates buffers for music streaming
void StopMusicStream(Music music);        // Stop music playing

Here we have two possible solutions:

Require those functions to receive musicby reference:

void UpdateMusicStream(Music *music);     // Updates buffers for music streaming
void StopMusicStream(Music *music);       // Stop music playing

This change will break all code-bases using previous versions of raylib... I use to review functions without worrying much about "small" breaks but in this case I think it really affects simplicity and ease-of-use...

Move sampleLeft somewhere else.
Music struct includes stream.buffer pointer that it's actually the audio buffer containing and processing the data to be played, maybe samplesProcessed could be moved there... I need to investigate that AudioBuffer more in depth...

Feedback and opinions are welcome!

Music is highlevel, samples and audio buffers are lower level, so even if samples left is only used when an audio buffer is playing music (as opposed to samples and effects) I think it makes sense to put it in the audio buffer, and it will mean that you don't have to break the API.
Where sampleleft needs to be accessed, will there need to be extra API calls to access this, or will audiobuffer struct become public ?

One of raylib's benefits is the simplicity of its API. Which option would keep the API simple to use? Bindings can fix/update as needed.
Makes sense to have Update use pointers, similar with UpdateCamera(Camera *camera). If sampleLeft moved elsewhere, that'd be cool too.

I haven't looked, but does user code mess with Music's contents? If not, we could do typedef struct Music Music[1]. Maintains source level compatibility, but each use of Music turns into a &Music.
(IMHO, I don't think passing structs by value is something that should be encouraged anyway, but I just wanted to note this as an extra possibility)

@a3f Actually, that was the previous implementation of Music (as a pointer), changed it for consistency with all other raylib functions where, despite unpopular, I pass data usually by value.

Music struct reviewed on commit https://github.com/raysan5/raylib/commit/fc95ceadf0143ad6c0f720d26bb28a45889f86d1.
Some issue now with looping and it seems there is some inconsistency with frames vs samples.

After some testing it seems it works ok.


Button "Export to cTMS" was renamed to "Export Commit"

Issue description
The documentation mentions the Button "Export to cTMS" but in my BTP ABAP environment it seems that this button was renamed to "Export Commit":

The screenshot and text needs to be adjusted accordingly.
Feedback Type (Optional)
outdated information
Page Title on SAP Help Portal (prefilled)
How to Export Using SAP Cloud Transport Management
Page URL on SAP Help Portal (prefilled)
https://help.sap.com/docs/btp/sap-business-technology-platform/how-to-export-using-ctms?q=ctms

Thank you for your feedback! We’ll look into it and come back to you if we have any questions.

We've changed the documentation accordingly. Thank you for your feedback!

https://people.sap.com/gregorw


Archive testenv properties

Issue: #3084

Grinder

hmm, not sure if it is related to docker, I do not see any file attached in the above Grinder.
We are expecting to see both testenv.properties and SHA.txt archived.

(Grinder)[https://ci.adoptopenjdk.net/job/Grinder/2301/]
Let me know if this one doesn't work either.

This looks good. https://github.com/adoptium/aqa-tests/pull/3085#issuecomment-956770132

No, I still do not see any archived files. I am not sure it is related to your PR. Need investigation.
This is what I am looking for:

https://ci.adoptopenjdk.net/job/Grinder/2309/

I believe I see the files in https://ci.adoptopenjdk.net/job/Grinder/2301/. But today when I looked again, no files. Rerun it's there https://ci.adoptopenjdk.net/job/Grinder/2326/

I can see some other earlier grinder doesn't have sha.txt archived.

https://ci.adoptopenjdk.net/job/Grinder/2309/ doesn't have that files https://github.com/adoptium/aqa-tests/pull/3085#issuecomment-957512716. Did the build 2309 have that txt files before?
Is there configuration about only a specific number of builds archive will be kept? As I saw only the latest five grinder have the archived files.

Yes, I believe that jenkins some default configuration. The build https://ci.adoptopenjdk.net/job/Grinder/2322/ is the fifth latest jobs and have that .txt files archived.

Then when it became the sixth latest I can't find the archived files any more.

Yes, I do not think the issue is related to this PR. Grinder at Openj9 worked as expected
https://openj9-jenkins.osuosl.org/view/Test/job/Grinder/337/

FYI I updated the Max # of builds to keep with artifacts in Grinder to 30.


Compare Iris test timings (1 man days' effort)

Compare runtimes of the Iris tests, comparing the master branch with the dask branch.
Testing to not be run on Travis.
Ref #2371.

Not really finished, but I put it in 'review' to get notice...
See: #2371 for progress


Deployment Strategies

HI, I'm trying to understand the Canary Release Deployment Strategy in detail but am finding the documentation confusing, sorry.
I am trying to parse the "Gated canary promotion stages" bullet list, but the structure seems inconsistent.
For example, here...

- check primary and canary deployment status
  - halt advancement if a rolling update is underway
  - halt advancement if pods are unhealthy

...I assume that both "halt advancement" bullet points are evaluated?
But here...

- call pre-rollout webhooks and check results
  - halt advancement if any hook returns a non HTTP 2xx result
  - increment the failed checks counter

...I assume that the failed checks counter isn't always incremented?
Overall, it would be excellent if it were possible to replace the bulleted list with some sort of flow - perhaps a Mermaid diagram or similar that's supported by GitHub? (although I appreciate that you render you docs as hosted pages too so may have other considerations).
I'm also confused by the use of "halt advancement" throughout the stages. Does this mean that the rollout just halts and "hangs" in whatever state it's in? Or does "halt advancement" include scaling the Canary deployment back to zero and/or any other cleanup tasks?
Finally, I am struggling to understand the relationship between a Canary rollout and the testing: config options, but this isn't mentioned at all on this page so I wonder if this is documented somewhere else.

Just for clarity, the specific documentation page I'm talking about is
https://fluxcd.io/flagger/usage/deployment-strategies/
which I think is also published as
https://docs.flagger.app/usage/deployment-strategies
Thanks

does "halt advancement" include scaling the Canary deployment back to zero and/or any other cleanup tasks?

I think the use of "halt advancement" is deliberate, the wording implies nothing beyond what it says. It's especially not meant to signify the cleanup tasks, since iterations can resume the advancement assuming the failure condition abated:

increment the failed checks counter

As long as there are more than 1 configured allowed failed check, the halting of the advancement simply means that the progressive delivery's progress is not incremented. If you have a current canary weight of 0 and the advancement is halted, that might mean simply the canary isn't ready yet, or it might signify an error that results in the termination of the canary rollout. I think until the failed checks counter is exhausted, no termination will happen.

I haven't quite yet evaluated the page you're talking about to understand the docs issue that I think you're really meant to be reporting here. Can you provide a reference to what testing: config options you mean? Flagger supports load testing as well as integration testing with Helm and other tests. https://fluxcd.io/flagger/usage/webhooks/
I think we like Mermaid docs here, I certainly agree with adding more of them throughout the docs since they are easier to keep up to date than the graphically produced diagrams – though they might not be as pretty! If you want to suggest a new diagram, I'd be happy to review and iterate with you. I'm still learning Mermaid syntax but I've found that ChatGPT can often produce a pretty decent diagram when prompted with enough detail and patient reassurance about what the topic should convey.


═══════ Exception caught by rendering library ═════════════════════════════════ The following assertion was thrown during performLayout(): 'package:flutter/src/rendering/stack.dart': Failed assertion: line 613 pos 12: 'size.isFinite': is not true. stack.dart:613 2  Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause. In either case, please report this assertion by filing a bug on GitHub:   https://github.com/flutter/flutter/issues/new?template=2_bug.md  The relevant error-causing widget was Stack homepage.dart:18 When the exception was thrown, this was the stack

Hi,
When opening an issue, please try to provide all or some of the information indicated in the template.

Issue Template
If you are looking for support, please check out our documentation
or consider asking a question on Stack Overflow:
- https://flutter.dev/
- https://api.flutter.dev/
- https://stackoverflow.com/questions/tagged/flutter?sort=frequent

If you have found a bug or if our documentation doesn't have an answer
to what you're looking for, then fill our the template below. Please read
our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports

Steps to Reproduce

Please tell us exactly how to reproduce the problem you are running into.

Please attach a small application (ideally just one main.dart file) that
reproduces the problem. You could use https://gist.github.com/ for this.

If the problem is with your application's rendering, then please attach
a screenshot and explain what the problem is.

1. ...
2. ...
3. ...

Please tell us which target platform(s) the problem occurs (Android / iOS / Web / macOS / Linux / Windows)
Which target OS version, for Web, browser, is the test system running?
Does the problem occur on emulator/simulator as well as on physical devices?

Target Platform:
Target OS version/browser:
Devices:

Run your application with `flutter run --verbose` and attach all the
log output below between the lines with the backticks. If there is an
exception, please see if the error message includes enough information
to explain how to solve the issue.

Run `flutter analyze` and attach any output of that command below.
If there are any analysis errors, try resolving them before filing this issue.

Finally, paste the output of running `flutter doctor -v` here.

Closing this issue, since no information has been provided.
Thank you.


Inquiry Regarding Input Data and Initialization Model Implementation

Hello,
Firstly, I would like to express my appreciation for the outstanding work you have shared. I have a few queries concerning the input data and the implementation of the initialization model.

Understanding the Processed Data Structure:
I have examined the parse_data() function in trafficgen/scripts/trans20.py, which provided clarity on the values within 0.pkl, including all_agent and others. However, the InitDataset utilized in class TrafficGen processes 0.pkl through the process_data_to_internal_format function, yielding new data with keys such as
dict_keys(['agent', 'agent_mask', 'center', 'center_mask', 'bound', 'bound_mask', 'cross', 'cross_mask', 'rest', 'rest_mask', 'vec_based_rep', 'agent_vec_index', 'agent_feat', 'lane_inp', 'lane_mask', 'gt_bbox', 'gt_distribution', 'gt_long_lat', 'gt_speed', 'gt_vel_heading', 'gt_heading', 'other']).
Could you please elucidate the precise meaning of these keys and the elements they encompass? Especially the value used in the function inference() of class initializer.

Generating New Traffic Scenarios:
As per your paper, "After training, TrafficGen takes m as input and generates tau' as a totally different scenario." Could you provide guidance on only the HD map as input, without the inclusion of any vehicles. How is this accomplished?

Context Vector Usage:
In the class initializer, there are two class CG_stacked: self.CG_agent and self.CG_line. Additionally, within the forward() function, the following operations are performed:
context_agent = self.agent_feature_extract(data['agent_feat'], data['agent_mask'], random_mask)
feature = self.map_feature_extract(data['lane_inp'], data['lane_mask'], context_agent)

The agent_feature_extract function takes agent_feat and creates an all-one vector as the context vector c, then generates an updated context vector c'. This c' is subsequently used in map_feature_extract to produce line_enc and context_line, and somehow obtain the feature by concate these two variable. I am somewhat perplexed by this approach, as it seems to diverge from the description in your paper. Could you offer some insight to help me comprehend this design choice?

Thank you very much for your valuable assistance.

'agent' means vehicle states. ; center/bound/etc mean map states; 'vec_based_rep' means agent states in the map vector coordinates
During training and inference, you can use a random initialized embedding to represent that the map is empty.
Concatenating features is like doing the residual connection. The CG encoder takes a context embedding as input so at the very beginning the context should be all one. You can refer to multipath++ for this part.


Upgrade dependencies

Pull Request Test Coverage Report for Build 5921

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 35.309%

Totals

Change from base Build 5799:
0.0%

Covered Lines:
1839

Relevant Lines:
4813

💛  - Coveralls


Is this project still be maintained?

It's almost half a year since the last PR was merged

Yeah sorry, busy and it's getting more complicated with different use cases. But a lot of Prs have been merged now, al still active


autopopulate makecode editor with pxt-jacdac?

Can we pre-load a makecode editor with the pxt-jacdac extension?
It is a bit cumbersome to open the side by side, then add the pxt-jacdac extension, then add the packages for your modules.

We don't intend to maintain a separate instance of makecode so no.

why would we require a separate instance of makecode? could we just open a default project with pxt-jacdac?

try explaining all the steps to someone who has not used makecode before. It is a bit overwhelming!

So lets have two buttons that say "open existing jacdac project" and "create new jacdac project"

Where do you want those buttons?

So we could create a set of makecode tutorials for jacdac.

This would require a change in the makecode editor, not happening. We've beefed up the docs on getting started with jacdac.


Create template for pull requests

[x] I'm ready to merge

What's the context for this pull request?
As per our discussion about cresting a pull request template in the gitter chat.
What's new?
I've made a template for our pull requests
What should a reviewer feedback on?
@KirstieJane check that you like it
Does anything need to be updated after merge?
(e.g the wiki or the WhitakerLab website)
nope :cake:

Reminder to @KirstieJane to check out this pull request :candy:

APPROVED - MERGING! ✨

@Islast - do you have a link to a resource that explains how to do this? I'd like to share it 😄


GET /blocks/

https://ethereum.github.io/beacon-APIs/#/Beacon/getBlockV2

[x] #891
[ ] Get block root by ID
[ ] Get block attestations by ID

@rodrigo-o can i take this ?

Yes! Thanks @mahmudsudo!


Fixing the bundle diff check removing unique metadata fields

Signed-off-by: jonahjon<EMAIL_ADDRESS>Issue #, if available:
Description of changes:
Remove the metadata.Annotations and metadata.Name field before doing the diff check on the bundle files.
Tested locally using a builder-base image, and works. Applying change to Dev and Staging first to verify.

/approve


Mysterious behavior

Why are these analyses at least not somewhat compatible (slightly edited)?
$ target/debug/sonalyze load --host=c1-10 -f 2d --none --raw -- tmp/*.out
HOST: c1-10
date        time   cpu   mem  gpu  gpumem
2023-08-23  09:38  4707  402  0    0
2023-08-23  09:39  5107  403  0    0
2023-08-23  09:39  4947  403  0    0
2023-08-23  09:39  4734  402  0    0
2023-08-23  09:39  4620  402  0    0
2023-08-23  09:40  4814  402  0    0
$ target/debug/sonalyze jobs --host=c1-10 -u - --fmt=job,user,duration,host,cpu,mem,cmd -f 2d -- tmp/*.out
job     user         duration  host   cpu-avg  cpu-peak  mem-avg  mem-peak  cmd
280386  ec-aleksgro  0d 0h 2m  c1-10  109      307       12       25        python, slurm_script, srun
280387  ec-aleksgro  0d 0h 2m  c1-10  119      307       13       25        python, srun, slurm_script
281451  ec-clarew    0d 0h 2m  c1-10  43       100       2        3         slurm_script, julia
281452  ec-clarew    0d 0h 2m  c1-10  43       100       2        3         julia, slurm_script
281453  ec-clarew    0d 0h 2m  c1-10  43       107       2        3         julia, slurm_script
281455  ec-clarew    0d 0h 2m  c1-10  43       100       2        3         slurm_script, julia
281456  ec-clarew    0d 0h 2m  c1-10  43       107       2        3         julia, slurm_script
281495  ec-larstha   0d 0h 2m  c1-10  29       100       1        1         tsp_mpi, sonar, sonarloop.sh

The "load" view says around 50 cores is being used at almost any time.  The "jobs" view says that on the average, very little happens (and I'm dismayed about my own 29% utilization, which is definitely not right).
Going to label this a bug until I know what's up.

The "29% utilization" for my own job is an artifact of how utilization is computed for multi-process jobs, along with the fact that sonar and sonarloop.sh are almost 100% idle.  Sonarloop runs the entire time but sleeps mostly, it wakes up once every 15s to run sonar, its cumulative CPU usage is basically zero over its entire runtime.  Sonar runs once and then manages to generate one record, which has 0% CPU utilization (because that is a measure that only makes sense inter-record).  Together with #44, the data come out pretty wonky.  The easy hack is to exclude these programs from the data, the utilization jumps to 84% which is in line with what's expected (taking #44 into account).

This is really the mystery:
$ sonalyze jobs --job=281495 -f8d -b -- ../tmp/fox-logs/*.out
jobm     user        duration  host                                 cpu-avg  cpu-peak  mem-avg  mem-peak  gpu-avg  gpu-peak  gpumem-avg  gpumem-peak  cmd
281495<  ec-larstha  0d 0h 2m  c1-[5,8-10,12-14,20-21,23-24,26-28]  218      700       1        1         0        0         0           0            srun,slurm_script,sonarloop.sh,tsp_mpi,sonar
$ sonalyze jobs --job=281495 -u- -f8d --exclude-command=sonarloop.sh --exclude-command=slurm_script --exclude-command=sonar --exclude-command=ps --exclude-command=srun -b -- ../tmp/fox-logs/*.out
jobm     user        duration  host                                 cpu-avg  cpu-peak  mem-avg  mem-peak  gpu-avg  gpu-peak  gpumem-avg  gpumem-peak  cmd
281495<  ec-larstha  0d 0h 2m  c1-[5,8-10,12-14,20-21,23-24,26-28]  1216     1400      2        2         0        0         0           0            tsp_mpi

These two lines are for the same job, from the same log files.    These apparently pollute the data, by lowering the averages (first run).

The reason for the mystery is that when the sonarlog layer reads data, it will merge the event streams for multiple processes that are running the same job on the same host.  This is by design.  But there are two problems:

the batching code for for the jobs command cannot deal with these co-timed events: it will consider, for its synthesized sample, at most a single sample per host per time.  This means that peaks and sums per sample become diluted, generally, when the "computational" task of one host is summed with a "background" task of another, and in the next step, vice versa.  That would be fine, were it not for the second problem:
the aggregation code for a job does not sum values with the same timestamp in its sample stream.
The latter is arguably the real bug.  The former would be good to fix, to keep the volume of synthesized events to a reasonable level, but is probably not important for correctness.

This has been fixed with a fairly large rewrite (on branch w-dont-cross-the-streams) but needs some more testing.


UI/payments manual entry

Notion card
https://www.notion.so/saeloun/Frontend-User-should-be-able-to-add-payments-entry-manually-against-and-invoice-c65e211eeb9748c38e60ee26d9c2ff4d
Summary

UI for Manual payment entry added.

Preview

https://www.loom.com/share/ef9b7c94de804851a471a0ab9ff7d77e
Type of change

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

How Has This Been Tested?

Checklist:

[ ] I have manually tested all workflows
[ ] I have performed a self-review of my own code

@Shruti-Apte On selecting invoice , the invoice number - client name should be populated. Also the invoice amount should be automatically populated. Is this something that will be handled during integration work on can be handled with this PR ?
Please see the designs

@Shruti-Apte On selecting invoice , the invoice number - client name should be populated. Also the invoice amount should be automatically populated. Is this something that will be handled during integration work on can be handled with this PR ?
Please see the designs

Yes...With integration PR. I need data from backend to do that!

@onkar-saeloun @ajinkyaa Please review this PR . @apoorv1316 Please test


camera: Camera probe failed with error 0x106

using esp32_camera from this project and same hal config

solved 🥵


#42 PutMarkLogicRecord logging now reports the correct number of docu…

…ments inserted
I have an rjrudin/42-fix-logging branch as well, but that has a lot of refactoring on it. Submitting this so that the change is isolated and easy to understand.
Will wait to add an integration test to verify this (I think we can do it by inspecting the provenance report) until PR 35 is merged into develop, which has support for JUnit5-based tests.

Replaced by https://github.com/marklogic-community/marklogic-nifi-incubator/pull/4


DO NOT MERGE: Python implementation of cobyla

This is a placeholder PR while I work on the Python implementation. When I'm ready to merge I'll close this one and open up a new one. Having this one open allows for progress on the implementation to be visible, and to discuss any technical issues that come up as we develop the Python implementation.
Current status:

Most of the code for cobyla has been hand-translated to Python
The "if debugging" sections have been skipped for now. I expect that for the basic example they won't be triggered if everything is working correctly. They will be added later
I'm not dealing with storing the history at the moment, I will explore that later, since I think it will require some thought as to how to structure the Python interface.
It does not work at the moment. Since Python and Fortran differ in both array indexing and in the way they treat size (numpy does not differentiate between row and column vectors), among other things, there will be issues, and I am slowly working on diving through these.

Also, there will be a folder name conflict with @jschueller's C interface, since we are both using the python folder name. I propose @jschueller changes his branch to use the folder name python_c_interface?
Normally I wouldn't post half-finished work like this, but this will be a fairly big PR that is difficult to split into smaller chunks, so I figured it would be better to get it out into the open earlier rather than later.

Thank you @nbelakovski for your work.
I just want to give a quick comment on this point:

The "if debugging" sections have been skipped for now. I expect that for the basic example they won't be triggered if everything is working correctly. They will be added later

This is EXTREMELY important. Code should be battle tested before it becomes software.

I expect that for the basic example they won't be triggered if everything is working correctly.

This is unfortunately wrong. My experiences in the past years have taught me one thing: We do not know what kind of (floating-point) exceptions will occur until we have tested the code on excessively many randomized TOUGH problems for a sufficiently long time.
In this way, the modern Fortran version of PRIMA has been tested on a large class of problems (the CUTEst problems) for more than 20 years (summing up the time of all the parallel tests). In this process, numerous exceptions and bugs have been spotted and fixed.
I insist that any porting / translation of PRIMA should go through the same level of tests. Otherwise, we cannot be sure whether it is correct.

https://github.com/nbelakovski/prima/blob/e46e9192f9a5f80b1ba146120774d21a35e87344/python/src/prima/cobyla/geometry.py#L140C1-L141C1
This is strange. Which version of COBYLA is this based on? This definition of weight is wrong. It was used by an old version of COBYLA, but corrected several months ago.

I insist that any porting / translation of PRIMA should go through the same level of tests. Otherwise, we cannot be sure whether it is correct.

I agree, I fully intend to add the "if debugging" sections as well as rigorous testing.

https://github.com/nbelakovski/prima/blob/e46e9192f9a5f80b1ba146120774d21a35e87344/python/src/prima/cobyla/geometry.py#L140C1-L141C1
This is strange. Which version of COBYLA is this based on? This definition of weight is wrong. It was used by an old version of COBYLA, but corrected several months ago.

Hm, not sure how that happened. Maybe I opened the wrong geometry.f90 file at one point. Will fix.

https://github.com/nbelakovski/prima/blob/e46e9192f9a5f80b1ba146120774d21a35e87344/python/src/prima/cobyla/geometry.py#L140C1-L141C1
This is strange. Which version of COBYLA is this based on? This definition of weight is wrong. It was used by an old version of COBYLA, but corrected several months ago.

Hm, not sure how that happened. Maybe I opened the wrong geometry.f90 file at one point. Will fix.

This is a bit worrying, as there might be other similar discrepancies.  We need a systematic way to spot and fix them. Otherwise, it is hard to verify the correctness of the implementation.
In addition, we must be very clear about which version of PRIMA is the Python implementation referring to. Mixing subroutines from different versions will not work. Moreover, without knowing the version number, we will not be able to improve the Python version when improvements are made in the Fortran reference version.
The implementation of derivative-free optimization methods is quite delicate. Seemingly small changes may turn out significant to the performance. This is what I have learned in the past 15 years while working on derivative-free optimization.

Thank you @nbelakovski for your work.
I just want to give a quick comment on this point:

The "if debugging" sections have been skipped for now. I expect that for the basic example they won't be triggered if everything is working correctly. They will be added later

This is EXTREMELY important. Code should be battle tested before it becomes software.

I expect that for the basic example they won't be triggered if everything is working correctly.

This is unfortunately wrong. My experiences in the past years have taught me one thing: We do not know what kind of (floating-point) exceptions will occur until we have tested the code on excessively many randomized TOUGH problems for a sufficiently long time.
In this way, the modern Fortran version of PRIMA has been tested on a large class of problems (the CUTEst problems) for more than 20 years (summing up the time of all the parallel tests). In this process, numerous exceptions and bugs have been spotted and fixed.
**I insist that any porting / translation of PRIMA should go through the same level of tests. Otherwise, we cannot be sure whether it is correct. **

I just want to give a quick comment on this point:

The "if debugging" sections have been skipped for now. I expect that for the basic example they won't be triggered if everything is working correctly. They will be added later

This is EXTREMELY important. Code should be battle tested before it becomes software.

I expect that for the basic example they won't be triggered if everything is working correctly.

This is unfortunately wrong. My experiences in the past years have taught me one thing: We do not know what kind of (floating-point) exceptions will occur until we have tested the code on excessively many randomized TOUGH problems for a sufficiently long time.
In this way, the modern Fortran version of PRIMA has been tested on a large class of problems (the CUTEst problems) for more than 20 years (summing up the time of all the parallel tests). In this process, numerous exceptions and bugs have been spotted and fixed.
I insist that any porting/translation of PRIMA should go through the same level of tests. Otherwise, we cannot be sure whether it is correct.

I would like to add a  bit more about the importance of testing and verification, motivated by a conversation with a friend who uses PRIMA in his projects.
Someone may think that it is unnecessary to test solvers in the way that PRIMA does. In most cases, one would test a few problems and observe whether the result is expected. If yes, then "the implementation is correct". It seems that many people are happy with such a test. For me, this is a joke.
This friend refers to his projects as "critical projects", which are directly related to the life and death of humans --- imagine, for example, the designing of a new medicine (although this is not what my friend works on). The robustness of the solver and the reproducibility of the solution can never be exaggerated in such projects. This is quite different from the machine learning problems whose objective is only to decide how to post advertisements --- nobody will die if the solver does something wrong. In critical projects, however, people may die.
So, what kind of tests are sufficient for PRIMA, which is designed for critical projects?
No test will be sufficient. I can only tell that the following tests are necessary.

A large number (e.g., hundreds) of test problems, which can represent as much as possible different challenges that may occur in applications.
TOUGH tests. In applications, function evaluation may fail, it may return NaN or infinity from time to time, and it is very likely contaminated by noise. Any test is insufficient without trying such problems.
Randomized tests. It is impossible to cover all the possible difficulties with a fixed set of problems. Some bugs occur only under very particular conditions that are difficult to encounter without randomization. Therefore, tests must be randomized, and the random seed must be changed periodically (daily or weekly).
Stress tests. If a solver is designed to solve 100-dimensional problems, then we must test it on (randomized) 1000-dimensional problems and make sure that it does not crash.
Automated tests. It is not enough to randomize the tests. Randomized tests must also be executed automatically every day and night, for example, using GitHub Actions.
Tests on various platforms under different systems using all compilers/interpreters available. Our software should not crash on any platform. Without thorough tests, the only thing I know is that we do not know what will happen.
A sufficiently long time of testing. In general, I do not feel confident about a solver if the accumulated testing time is below 10 years.

Comparing this with "testing a few problems and observing whether the result is expected", I suppose it is clear what I meant by "it is a joke". Recalling that the solvers may serve projects that decide human life, I guess it is clear why such a joke is not enough.

@nbelakovski I wrote the above comments very quickly. They are mostly general comments that are not specific to the Python translation.
Apologies if I overlooked something. I am open to discussions. Tell me if there is anything not clear.
Thank you very much for your great efforts!

Hi @nbelakovski ,
A new release of PRIMA is made. The Fortran implementation of COBYLA now accepts more general constraints. The Fortran code is modified, although the algorithm stays essentially the same.
I will be very happy to provide more information if needed.
Many thanks for your huge efforts. I know it is HARD, and I hope you are doing well. Tell me if I can help.
Best regards,
Zaikun

https://github.com/nbelakovski/prima/blob/e46e9192f9a5f80b1ba146120774d21a35e87344/python/src/prima/cobyla/geometry.py#L140C1-L141C1
This is strange. Which version of COBYLA is this based on? This definition of weight is wrong. It was used by an old version of COBYLA, but corrected several months ago.

Hm, not sure how that happened. Maybe I opened the wrong geometry.f90 file at one point. Will fix.

This is a bit worrying. It implies that there are probably other discrepancies. We need a systematic way to spot and fix them. Otherwise, it is hard to verify the correctness of the implementation. (For me, "verification by human eyes" is not trustworthy at all due to my bitter experiences in the past years.)

It looks like what happened is that when I used VSCode's right-click -> Go to definition, it would open up files in benchmark/rescue_idz/norma/fortran/cobyla and I did not realize this. It appears to have happened for several files, so now I am going back through and redoing them.

In addition, we must be very clear about which version of PRIMA is the Python implementation referring to. Mixing subroutines from different versions will not work. Moreover, without knowing the version number, we will not be able to improve the Python version when improvements are made in the Fortran reference version.

Do you mean referencing a release version number? Maybe it's better if I reference a githash in the README of the Python section, otherwise we'd have to either release the Python version separately or the Python version is always a release point behind.

Someone may think that it is unnecessary to test solvers in the way that PRIMA does. In most cases, one would test a few problems and observe whether the result is expected. If yes, then "the implementation is correct". It seems that many people are happy with such a test. For me, this is a joke (sorry to say so).

Just to be clear, more testing and more thorough testing is great, but I am taking a milestone based approach here to make this a more manageable project. First I want to get to a point where I can test a few problems and observe that the result is as expected, THEN I plan to go back and add all of the if DEBUGGING code, THEN we'll be in a position where we can do more thorough tests. Some of these things can be re-ordered, but one thing at a time please :).

The code is still very messy but I have some progress to report. The COBYLA examples for chebyquad and hexagon now run and provide answers that are close to the FORTRAN version. They are not quite the same, but the difference is greater than machine precision. For example, in chebyquad, here are the results:
Fortran:
x(1) = 0.06687201625695266
x(2) = 0.28872054433564054
x(3) = 0.36668681233017669
x(4) = 0.63330363432938008
x(5) = 0.71126615229302259
x(6) = 0.93312277720964698
f = 3.9135366518694255e-10
Python:
x[0] = 0.06688196439284098
x[1] = 0.2887610493288529
x[2] = 0.36668226015206873
x[3] = 0.6333320849097046
x[4] = 0.7112583722245663
x[5] = 0.9331254078707577
f = 3.8259601181730434e-10
The first position in x differs by 9.948135888e-6, so it's further away than machine precision, but
it's possible that the difference is the result of accumulation of machine precision errors.
But I think that the fact that these are so close (and that results for hexagon, which has constraints, are similarly close) indicates that the vast majority of indexing errors are taken care of.
I noticed that the main loop of cobylb runs 387 times in the FORTRAN code but 564 times in the Python code for chebyquad. My next step is to investigate this difference. I might try replacing the default numpy matrix multiplication with a Python implementation of the matprod function from the FORTRAN code.
After that there is more work to do to add all the pre- and post- conditions and clean things up, but I think this is a nice milestone, it's very satisfying to have results that look like they're in the ballpark.

The code is still very messy but I have some progress to report. The COBYLA examples for chebyquad and hexagon now run and provide answers that are close to the FORTRAN version. They are not quite the same, but the difference is greater than machine precision. For example, in chebyquad, here are the results:
�
�
1
�
2
�
3
�
4
�
5
�
6
FORTRAN	3.9135366518694255e-10	0.06687201625695266	0.28872054433564054	0.36668681233017669	0.63330363432938008	0.71126615229302259	0.93312277720964698
Python	3.8259601181730434e-10	0.06688196439284098	0.2887610493288529	0.36668226015206873	0.6333320849097046	0.7112583722245663	0.9331254078707577
Difference	8.76E-12	-0.000009948135888	-0.00004050499321	0.000004552178108	-0.00002845058032	0.000007780068456	-0.000002630661111
The first position in x differs by 9.948135888e-6, so it's further away than machine precision, but it's possible that the difference is the result of accumulation of machine precision errors.
But I think that the fact that these are so close (and that results for hexagon, which has constraints, are similarly close) indicates that the vast majority of indexing errors are taken care of.
I noticed that the main loop of cobylb runs 387 times in the FORTRAN code but 564 times in the Python code for chebyquad. My next step is to investigate this difference. I might try replacing the default numpy matrix multiplication with a Python implementation of the matprod function from the FORTRAN code.
After that there is more work to do to add all the pre- and post- conditions and clean things up, but I think this is a nice milestone, it's very satisfying to have results that look like they're in the ballpark.

This is very impressive. I guess the discrepancy in the results reflects something more than rounding errors. In addition, we should have a systematic way to verify the implementation.
This is what I did to verify the Fortran implementation (the verification is done via the MATLAB interface):
https://github.com/libprima/prima/blob/main/matlab/tests/verify.m
https://github.com/libprima/prima/blob/main/matlab/tests/private/isequiv.m
BTW, the language is Fortran rather than FORTRAN since 1990s. It is better to avoid using the latter unless you want to emphasize that you are working on some extremely old code, which I hope is not the case. :)
Thanks.

I found that I had been starting from a different x for the chebyquad example due an an off-by-one error (I believe that we may never get to 0 off-by-one errors, there will always be at least 1). Fixing that doesn't get to the same point as the fortran code, it actually gets to a somewhat better point, but with a different number of loops and function evaluations. I watched the x and the step vector d between the two implementations, and they seemed about the same for ~200 iterations, but then they start to slowly diverge (in direction, in magnitude they remain similar). So it looks like accumulation of machine precision error. I'm not too concerned about this at the moment because it looks like the main algorithm is coded correctly.
I'm about to start adding in the pre/post conditions that I skipped and I have some questions I'd like to get some comments on.

I think that with Python we do not need to add the string afterwards, i.e. Python can just be assert n>=1 as opposed to assert n>=1, "n >= 1", srname. When a Python assertion is thrown it will show the assertion that failed along with the call stack. Not including the string also make the translation a bit easier, as it's annoying to have to copy the assert, change it to work with Python, and then change the string as well. Any objections?

On the topic of the "if (DEBUGGING)" statements, I'm tempted to just leave them out. Some of the asserts are doing some calculations, but most are just checking sizes so I don't imagine they're contributing to the runtime cost very much, or at least not more than some other more meaningful operations. Should we decide to keep the "if (DEBUGGING)" statements, I would propose we have a line in prima/common/consts.py that reads like DEBUGGING = False or os.getenv("PRIMA_DEBUGGING"). Or we could skip the False or part of it. Thoughts?

Besides adding in the pre/post conditions I'm also working on adding in the history vectors which I had left out, as well as implementing printing.

One more question: in a lot of the Python code I chose to use num_vars and num_constraints instead of n and m. I felt it was easier to read certain expressions if I knew that it was related to the number of constraints as opposed to m. It also makes it easier to see for someone new to the algorithm which parts depend on the constraints, since you can highlight all usages of num_constraints but it's much harder to find all usages of m.
Thoughts on this? The code should be consistent across implementations, so I can go in and make the same changes to Fortran code if we like this, but likewise I can revert the changes in Python if we don't like this approach.

I've added just about all the relevant pre/post conditions. There may be some stragglers. I've also implemented [f/rho/ret]msg and savehist, although the hist is a little bit crude for starters.
I think we're getting close to the point where we can have a real PR. @zaikunzhang what do you think needs to be done in terms of verification? I'll start looking at the link you gave above and seeing if it's feasible to adapt it for testing this Python implementation.

Hello @nbelakovski Nickolai,
First of all, my apologies for being out of the loop recently. Works on my side have been complicated, which will likely continue for a while.
Thank you very much for your huge efforts, which are highly appreciated. What you have achieved is truly nontrivial and impressive.
Here are a few quick comments.

Which commit or release of the Fortran code is the Python implementation based on? It does not seem to be based on the latest one. For example, check the signature of trstlp.  I hope it will not be too difficult to catch up on the recent updates in the Fortran code.

To implement the tests and verifications, please first refer to
https://github.com/orgs/libprima/discussions/39
for the general idea.
2.1. The native Python implementation has a quite different nature from a Python interface, and it is much more difficult to confirm the correctness of the former. Thus, we need many many tests, which should be randomized and run repeatedly.
2.2. From now on, we need a facility to verify that two versions of the Python code produce exactly the same results. After making any kind of changes to the code, no matter how insignificant the change seems to be, we have to first perform the verification to make sure that our changes do not introduce unwanted differences between the old and new versions. Believe me, this is really necessary. This is done for the Fortran code (via the MATLAB interface) in the following way:
https://github.com/libprima/prima/blob/main/matlab/tests/verify.m
https://github.com/libprima/prima/blob/main/matlab/tests/private/isequiv.m
The verification should be based a a large set of test problems (at least 100; verification on a few problems is a joke) automated (run by GitHub Actions daily and after each commit) and randomized (the random seed is altered every week).
2.3. CUTEst is the standard test set. It has a Python binding named PyCUTEst, which can be used in GitHub Actions.
2.4. Obviously, we must test the performance of the Python implementation against the Fortran version (via the Python interface of the latter). The standard tool is the Performance Profile. Tom @ragonneau and Cunxin @OptHuang are developing OptiProfiler for producing such profiles. I think it is usable now. You may ask them for help if needed.
2.5. TOUGH test, stress test, recursive test, and parallel test must be done. See, e.g., https://github.com/cobyqa/cobyqa/issues/127

Thank you very much for your tremendous effort again!
Best regards,
Zaikun

One more question: in a lot of the Python code I chose to use num_vars and num_constraints instead of n and m. I felt it was easier to read certain expressions if I knew that it was related to the number of constraints as opposed to m. It also makes it easier to see for someone new to the algorithm which parts depend on the constraints, since you can highlight all usages of num_constraints but it's much harder to find all usages of m.
Thoughts on this? The code should be consistent across implementations, so I can go in and make the same changes to Fortran code if we like this, but likewise I can revert the changes in Python if we don't like this approach.

This is a reasonable idea, but I do not think it is urgent. Since I am a bit busy now, I hope to postpone it. Thanks.

1. Which commit or release of the Fortran code is the Python implementation based on? It does not seem to be based on the latest one. For example, check the signature of `trstlp`.  I hope it will not be too difficult to catch up on the recent updates in the Fortran code.

Since I started working on this in July, I've kept things based on b83c8ca642312f4cf4354c5effec3f7569877751. I will update to the latest, but first I want to figure out the testing situation.

   https://github.com/libprima/prima/blob/main/matlab/tests/verify.m
   https://github.com/libprima/prima/blob/main/matlab/tests/private/isequiv.m
   The verification should be based a a large set of test problems (at least 100; verification on a few problems is a joke) automated (run by GitHub Actions daily and after each commit) and randomized (the random seed is altered every week).

I'll take a look at these and work towards implementing them. I may need write access to this repo in order to be able to trigger tests, can you add me please?

Since the Python implementation and the Python interface will co-habit in prima/python, I guess we need to bring @jschueller Julien in the loop. The two have to be consistent.

I think it would make more sense to have two folders, python_native and python_c_interface since these two things are trying to accomplish different goals, in spite of their common language.

Right now I'm working on resolving an issue where the basic test_constrained and test_unconstrained produce slightly different results in CI (on Linux) as compared to my local machine (Mac). For example, in CI the unconstrained test performs 533 function evaluations as compared to 547 on Mac, even with the same Python version. I've managed to somewhat reproduce the issue locally in the python:3.11.6-bookwork docker container - it performs 519 function evaluations. I noticed this a couple weeks ago and was able to replicate the issue exactly using act, but the same procedure today gives me 519 evaluations.
I work with my local reproduction and see if I can nail it down, and hopefully that also leads to a resolution of the issue in CI.


[CI] Use nightly-build status in README.md

Old:

New:

Coverage remained the same at 34.07% when pulling 83a1ebd92a2ab9e791b815e8bedb927b75dbfb69 on yiyi/ci/add_nightly_build_status_to_readme into ea3d04443f00023932abd009918935171bd34240 on master.

Will it be visible to those who are outside Microsoft's network?

Will it be visible to those who are outside Microsoft's network?

Looks OK on my mobile phone without login github/azure.

Please also change https://github.com/microsoft/pai/blob/master/docs/index.md and https://github.com/microsoft/pai/blob/master/docs_zh_CN/index.md , thanks

Please also change https://github.com/microsoft/pai/blob/master/docs/index.md and https://github.com/microsoft/pai/blob/master/docs_zh_CN/index.md , thanks

Done.


Passwords not working

I'm using Cloudscribe ID server ef -- and login is not working when I create a New Site, on that site.
I get "Unexpected error" when I enter that site and click login.
Made sure that I'd logged completely out of the admin before trying.
Any ideas why it's not working?

I'm not able to produce the problem. There should be no need to log out of one tenant to login to another.
I suggest login to the root tenant and check the log for the error details under Administration > System Info > System Log
maybe with the error detail I would know what the problem is.

Here's what's happening - not showing up in error logs...
https://www.screencast.com/t/TbSI5bA2x
Sent from my iPhone

On Apr 13, 2017, at 4:32 PM, Joe Audette<EMAIL_ADDRESS>wrote:
I'm not able to produce the problem. There should be no need to log out of one tenant to login to another.
I suggest login to the root tenant and check the log for the error details under Administration > System Info > System Log
maybe with the error detail I would know what the problem is.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

thanks for the screencast to clarify.
try making the folder name for the second site all lower case and keeping it lower case in the url
/testcontent and see if that makes any difference. I do think it is case sensitive and maybe the error is a 404.
It is recommended to use lower case urls and configured for that in startup so the folder name for the site should also be lower case.
from the site list you should be able to open the other site by right clicking the link and open in new tab and you should not have to logout of the first site

can you confirm if changing to lower case folder name solved the problem?

I have confirmed by my own testing that I could produce the problem by using mixed case folder name and could solve the problem by changing the folder segment to lower case and restarting the app.
I have implement a change to force the folder segment to always be lower case, so this will be solved in the next nuget publish. Technically it would work with mixed case folder segment if it was not configured for the routing to change it to lower case. However then the user would always have to use the correct mixed case or it would not resolve the tenant and would lead to errors. In general it is best to always use lower case urls for seo reasons and also for cross platform reasons since urls are case sensitive on linux but not on windows, so if you start with mixed case urls on windows and later move to linux hosting it could be problematic. In any case the folder segment lookup in the db for tenant resolution is case sensitive.
I am closing this issue, thanks for reporting the problem


installing package dependencies in Read-Through Caching

Describe the bug
When I install a package from nuget.org source it installs all package dependencies, but when I install the package from baget source(in Read-Through Caching mode) it installs only the package itself not its dependencies.
What is the probelm?

Which package are you trying to restore?

No matter package, I tried many packages.
Once I try NuGet directly it installs the package and all of its dependencies, But When I try BaGet to install exact the same package, it only installs the package itself not its dependencies.


[Regression] rancher/lb-service-haproxy:v0.9.13:  Malformed encoding found in chunked-encoding (v0.9.11 is ok)

What kind of request is this (question/bug/enhancement/feature request): bug
Steps to reproduce (least amount of steps as possible):
When using rancher/lb-service-haproxy:v0.9.13, getting this error with curl on our backend:
curl: (56) Malformed encoding found in chunked-encoding

Result:
Works fine with rancher/lb-service-haproxy:v0.9.11.
Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v1.6.29
Installation option (single install/HA): single

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): hosted

Machine type (cloud/VM/metal) and specifications (CPU/memory): metal

Docker version (use docker version):

Client:
 Version:           18.09.9
 API version:       1.39
 Go version:        go1.11.13
 Git commit:        039a7df9ba
 Built:             Wed Sep  4 17:24:10 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.9
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.11.13
  Git commit:       039a7df
  Built:            Wed Sep  4 16:19:38 2019
  OS/Arch:          linux/amd64
  Experimental:     false

Hi may be there are some correction to do into custom haproxy.cfg because of haproxy 2.0.5 ?
the previous rancher/lb-service-haproxy:v0.9.11 has bring with haproxy  1.8.19
root@abac4b6b0483:/# /usr/sbin/haproxy -v
HA-Proxy version 2.0.5-1ppa1~xenial 2019/08/16 - https://haproxy.org/

I tried with and without custom config, none work fine in v0.9.13. Here is the custom config we use:
defaults
compression algo gzip
compression type application/json text/html text/plain

The issue prevents responses with "Transfer-Encoding: chunked" from being properly downloaded from our server. The load balancer seems to truncate the response.

I tried rancher/lb-service-haproxy:v0.9.13
I think like jloisel there is a regression.
I have 2 haproxy :

the first receive external IP  with HTTPS TLS 1.2 and backend on another haproxy
the 2de use himself HTTPS TLS 1.2

On the 1st haproxy I get error "SD" error
And see on de 2de en error "CD"
 CD   The client unexpectedly aborted during data transfer. This can be
      caused by a browser crash, by an intermediate equipment between the
      client and haproxy which decided to actively break the connection,
      by network routing issues between the client and haproxy, or by a
      keep-alive session between the server and the client terminated first
      by the client.

 SD   The connection to the server died with an error during the data
      transfer. This usually means that haproxy has received an RST from
      the server or an ICMP message from an intermediate equipment while
      exchanging data with the server. This can be caused by a server crash
      or by a network issue on an intermediate equipment

I tested with haproxy 2.0.9 and the result is better
root@cc338474ab06:/# haproxy -v
HA-Proxy version 2.0.9-1ppa1~xenial 2019/11/17 - https://haproxy.org/
When you look https://www.haproxy.org/download/2.0/src/CHANGELOG
there  was a BUG/MAJOR : ssl: ssl_sock was not fully initialized since 2.0.6+
Please release a correction into the dockerfile :
RUN add-apt-repository -y ppa:vbernat/haproxy-2.0
&& apt-get update
&& apt-get install -y haproxy=2.0.9-1ppa1~xenial

Yaybe someone can help me to add acl white-ip.lst into balancer while running as Volume or something else?
Because I find only one solution - build own rancher/lb-service-haproxy ...


Added XRP ticker and tested to make sure it works with alerts

Looks like everything works when I added XRP. This is a great project!

Thank! Will review it shortly!


[Custom Field] VfgTheMask - Masked input using Vue The Mask

As suggested by Custom Fields docs, I'm providing a new custom field we've created here at NOALVO: https://github.com/NOALVO/vfg-the-mask
It uses Vue The Mask and apply a mask to the input. It needs a schema property named mask. Example:
{
    model: 'mydate',
    type: 'vfg-the-mask',
    mask: '##/##/####'
}

@ggondim Isn't this custom field similar to the existing cleave field? https://vue-generators.gitbook.io/vue-generators/fields/optional_fields/cleave

@muschottkey it is, but he’s providing it as an alternative third party field.
If your project already relies on mask, installing cleave as an added dependency doesn’t make sense.


After being told to healthcheck down, changeserver needs to proactively flush longpollers

One thing we discovered early on with our existing implementation of the changeserver is shutting down, if you don't proactively shut down the clients, causes a storm of broken connections in the logs.
What we need is:

A command line switch that sets the proactive flush delay time
A gofunc that is launched when a healthcheck down is initiated that sleeps for the delay time and then ejects all the connected clients cleanly.

The goal of the delay time is to allow for the load balancer to remove the changeserver from the pool before ejecting the clients.

Should the long pollers also be flushed when the change-server is marked as down?

👍

Yep!
This change needs to happen in two places:
The code in the "30x/goscaffold" should be changed to send a notification
to a listener when the server is marked down. Doing this via a channel
would be a nice pattern to use. There would probably only ever be one
listener to that event. I was trying to make "goscaffold" a generic library
-- that part of it should exist there and be independently tested.
Second, when it happens, you can call "close" on the "tracker" in
changeserver. That should cause all the waiting pollers to return, at which
point they will query the storage layer and see that there is nothing
there, and then finally they will return.
The trick is that we might want to see if there is a degenerate case in
which the tracker is closed, but a new API call comes in right after. That
should be either an error or something that causes the tracker to return
immediately.
This code is a little intricate and I built it all but if you want to work
on it, I'm happy to review and make sure it's well tested.
On Wed, Nov 23, 2016 at 7:11 AM, Kris Wehner<EMAIL_ADDRESS>wrote:

👍
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/apigee-labs/transicator/issues/21#issuecomment-262540726,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAf0aw-wwOHAjHuZy21LUlt6DzCfXnpjks5rBFeJgaJpZM4Kyyjz
.


Destructured exports no unused modules

Fixes https://github.com/benmosher/eslint-plugin-import/issues/2037

Coverage increased (+1.9%) to 71.423% when pulling 1ca4fef9ce3631d4d39f231e523665b6853d5eb5 on KristjanTammekivi:destructured-exports-no-unused-modules into e871a9a2e18fd4d67a5a237789131b44cc705b5b on benmosher:master.

I don't see how export const { a } = { a: 5 }; is not destructuring? In MDN there's an example of destructured assignments
// Exporting destructured assignments with renaming
export const { name1, name2: bar } = o;

Ohh, i misunderstood! Thanks.

(Note that merging this is blocked on #1986)

This was actually fixed by #1997, but I've rebased this to keep the test.

Hey @ljharb, I don't think this was fully fixed by #1997 as it only addresses object type destucturing, not including array types. You can see it in the code:
https://github.com/import-js/eslint-plugin-import/pull/1997/files#diff-7d2908b010ec724c0f3a0d7615cb91f4673d765d52c6ba6607501e23470f2966R85
I'm seeing this in the code with the version 2.28.1, which has the fix with #1997. Here is a code chunk I have:
export const [authUserLoading, authUserError] = createLoadingAndErrorSelectors(
  AUTH_USER
);

and here is the error I get:
error  exported declaration 'undefined' not used within other modules  import/no-unused-modules

@emreboga interesting - would you mind filing a new issue about that one?

@ljharb Sure! Please see https://github.com/import-js/eslint-plugin-import/issues/2930


Catch 404 error when deleting QueuedResource

Description
If the TPU has already been deleted by the TPU cleanup job, we should not return an error status.
Checklist
Before submitting this PR, please make sure (put X in square brackets):

[x] I have performed a self-review of my code.
[x] I have necessary comments in my code, particularly in hard-to-understand areas.
[x] I have made or will make corresponding changes to the doc if needed.

Do you know why the resource deletion request can be lost during the clean up process?

We don't actually monitor the individual delete operations, we monitor the parent QueuedResource to see if it goes into SUSPENDED. (There's actually some lag between when the nodes are all gone and we can delete the QR).


how to init uart3 in stm32_dev_min

i learn the /sample and api refrense, but i didn't see how to init a uart port in codes, can anybody help me?

i add->"CONFIG_UART_STM32_PORT_1=y" in prj.conf
#include <uart.h>

void initUSART(void){
	struct uart_config config={
			.baudrate=115200
	};
	usart_dev = device_get_binding("UART3");
	uart_configure(usart_dev,&config);
}
void sendUartData(void){
	uart_poll_out(usart_dev,0xff);
}

i init like above, but it turned wrong after i flash into stm32_min_dev board

Create stm32_min_dev.overlay
&usart3 {
    status = "ok";
};

Add "CONFIG_UART_3=y" in prj.conf

Create stm32_min_dev.overlay
&usart3 {
    status = "ok";
};

Add "CONFIG_UART_3=y" in prj.conf

i had add this config, what i mean is that how to init receiver from uart3 & how to send data by uart3? can you help me?

Try this, it's sould be work.
#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

static struct device *uart_dev;

void main(void)
{
	u8_t c;
	struct uart_config config;

	uart_dev = device_get_binding("UART_3");

	uart_config_get(uart_dev, &config);

	config.baudrate = 115200;

	uart_configure(uart_dev, &config);

	while (true) {
		if (uart_poll_in(uart_dev, &c) == 0)
			uart_poll_out(uart_dev, c);
	}
}

Try this, it's should be work.
#include <zephyr.h>
#include <misc/printk.h>
#include <uart.h>

static struct device *uart_dev;

void main(void)
{
	u8_t c;
	struct uart_config config;

	uart_dev = device_get_binding("UART_3");

	uart_config_get(uart_dev, &config);

	config.baudrate = 115200;

	uart_configure(uart_dev, &config);

	while (true) {
		if (uart_poll_in(uart_dev, &c) == 0)
			uart_poll_out(uart_dev, c);
	}
}

great! it does work,ths!

@fghjhuang , great you managed to work it out. Please tell us when we can close this point.