Support standalone Neo4J server with kundera-neo4j

Kundera currently supports embedded Neo4J server. Need to enable its support with standalone server as well.

so is neo4j server mode support right now, or not? ;)

@zazi
The support is not enabled as yet. We are yet to plan same. Shall keep updates posted.
Chhavi


Find All Duplicates in an Array

442. Find All Duplicates in an Array
Given an integer array nums of length n where all the integers of nums are in the range [1, n] and each integer appears once  or twice , return an array of all the integers that appears twice .
You must write an algorithm that runs inO(n)time and uses only constant extra space.
Example 1:
Input: nums = [4,3,2,7,8,2,3,1]
Output: [2,3]

Example 2:
Input: nums = [1,1,2]
Output: [1]

Example 3:
Input: nums = [1]
Output: []

Constraints:

n == nums.length
1 <= n <= 10^5
1 <= nums[i] <= n
Each element in nums appears once  or twice .

너무오래됐음,........삭제~


[BUGFIX] Revert broken support for multiple comments

This reverts e4c66f62c5df3f53f48d82cb30b20b3007af7574 (#672), which broke comment parsing in strict mode.
We'll need to re-implement support for multiple comments later in a way that does not break the existing comment parsing.

coverage: 38.622% (-0.03%) from 38.652%
when pulling a1a9a614cb396922ca4a7a63f633aa1463c84e86 on bugfix/comments
into e2bb6b73945285e7abc7dad79739795b57cd64ea on main.


Ecto v3.10 started to accept whitespace only characters in given data

Elixir version
Elixir 1.14.3 (compiled with Erlang/OTP 25)
Database and Version
None
Ecto Versions
3.10.1
Database Adapter and Versions (postgrex, myxql, etc)
None
Current behavior
With Ecto v3.10.1, validate_required/3 accepts whitespace only characters in given data (for Ecto v.3.9.x, this was invalid):
iex(1)> only_whitespace = %{attr: " "}
%{attr: " "}
iex(2)> types = %{attr: :string}
%{attr: :string}
iex(3)> Ecto.Changeset.change({only_whitespace, types}) |> Ecto.Changeset.validate_required(:attr)
#Ecto.Changeset<
  action: nil,
  changes: %{},
  errors: [],
  data: %{attr: " "},
  valid?: true
>

However, empty strings are still invalid (like in Ecto 3.9.x):
iex(4)> empty_string = %{attr: ""}
%{attr: ""}
iex(5)> Ecto.Changeset.change({empty_string, types}) |> Ecto.Changeset.validate_required(:attr)
#Ecto.Changeset<
  action: nil,
  changes: %{},
  errors: [attr: {"can't be blank", [validation: :required]}],
  data: %{attr: ""},
  valid?: false
>

Expected behavior
In Ecto v3.9.x, both whitespace only and emtpy strings are marked as invalid by validate_required/3 when provided in given data.
It feels like a bug but if the change in behavior is intentional in v3.10, I am curious about the reasoning behind it

Hi  @ekatt2, this is all mentioned in the CHANGELOG, including the rationale. The issues tracker should also have past discussions on the topic. :)


I met a problem: fuel.config_parser.ConfigurationError: Configuration not set and no default provided: data_path.

wangxiao@GTX980:~/Desktop/ladder-master$ ./run.py train --encoder-layers 1000-500-250-250-250-10 --decoder-spec gauss --denoising-cost-x 2000,0,0,0,0,0,0 --labeled-samples 60000 --unlabeled-samples 60000 --seed 1 -- mnist_all_bottom
/usr/local/lib/python2.7/dist-packages/theano/tensor/signal/downsample.py:6: UserWarning: downsample module has been moved to the theano.tensor.signal.pool module.
"downsample module has been moved to the theano.tensor.signal.pool module.")
ERROR:main:Subprocess returned fatal: Not a git repository (or any of the parent directories): .git
INFO:main:Logging into results/mnist_all_bottom0/log.txt
INFO:main:== COMMAND LINE ==
INFO:main:./run.py train --encoder-layers 1000-500-250-250-250-10 --decoder-spec gauss --denoising-cost-x 2000,0,0,0,0,0,0 --labeled-samples 60000 --unlabeled-samples 60000 --seed 1 -- mnist_all_bottom
INFO:main:== PARAMETERS ==
INFO:main: zestbn              : bugfix
INFO:main: dseed               : 1
INFO:main: top_c               : 1
INFO:main: super_noise_std     : 0.3
INFO:main: batch_size          : 100
INFO:main: dataset             : mnist
INFO:main: valid_set_size      : 10000
INFO:main: num_epochs          : 150
INFO:main: whiten_zca          : 0
INFO:main: unlabeled_samples   : 60000
INFO:main: decoder_spec        : ('gauss',)
INFO:main: valid_batch_size    : 100
INFO:main: denoising_cost_x    : (2000.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)
INFO:main: f_local_noise_std   : 0.3
INFO:main: cmd                 : train
INFO:main: act                 : relu
INFO:main: lrate_decay         : 0.67
INFO:main: seed                : 1
INFO:main: lr                  : 0.002
INFO:main: save_to             : mnist_all_bottom
INFO:main: save_dir            : results/mnist_all_bottom0
INFO:main: commit              :
INFO:main: contrast_norm       : 0
INFO:main: encoder_layers      : ('1000', '500', '250', '250', '250', '10')
INFO:main: labeled_samples     : 60000
Traceback (most recent call last):
File "./run.py", line 651, in
if train(d) is None:
File "./run.py", line 405, in train
in_dim, data, whiten, cnorm = setup_data(p, test_set=False)
File "./run.py", line 240, in setup_data
train_set = dataset_class("train")
File "/usr/local/lib/python2.7/dist-packages/fuel/datasets/mnist.py", line 36, in init
super(MNIST, self).init(self.data_path, which_set, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/fuel/datasets/mnist.py", line 40, in data_path
return os.path.join(config.data_path, self.filename)
File "/usr/local/lib/python2.7/dist-packages/fuel/config_parser.py", line 101, in getattr
"provided: {}.".format(key))
fuel.config_parser.ConfigurationError: Configuration not set and no default provided: data_path.
wangxiao@GTX980:~/Desktop/ladder-master$ ./run.py train --encoder-layers 1000-500-250-250-250-10 --decoder-spec 0-0-0-0-0-0-gauss --denoising-cost-x 0,0,0,0,0,0,2 --labeled-samples 60000 --unlabeled-samples 60000 --seed 1 -- mnist_all_gamma
/usr/local/lib/python2.7/dist-packages/theano/tensor/signal/downsample.py:6: UserWarning: downsample module has been moved to the theano.tensor.signal.pool module.
"downsample module has been moved to the theano.tensor.signal.pool module.")
ERROR:main:Subprocess returned fatal: Not a git repository (or any of the parent directories): .git
INFO:main:Logging into results/mnist_all_gamma0/log.txt
INFO:main:== COMMAND LINE ==
INFO:main:./run.py train --encoder-layers 1000-500-250-250-250-10 --decoder-spec 0-0-0-0-0-0-gauss --denoising-cost-x 0,0,0,0,0,0,2 --labeled-samples 60000 --unlabeled-samples 60000 --seed 1 -- mnist_all_gamma
INFO:main:== PARAMETERS ==
INFO:main: zestbn              : bugfix
INFO:main: dseed               : 1
INFO:main: top_c               : 1
INFO:main: super_noise_std     : 0.3
INFO:main: batch_size          : 100
INFO:main: dataset             : mnist
INFO:main: valid_set_size      : 10000
INFO:main: num_epochs          : 150
INFO:main: whiten_zca          : 0
INFO:main: unlabeled_samples   : 60000
INFO:main: decoder_spec        : ('0', '0', '0', '0', '0', '0', 'gauss')
INFO:main: valid_batch_size    : 100
INFO:main: denoising_cost_x    : (0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 2.0)
INFO:main: f_local_noise_std   : 0.3
INFO:main: cmd                 : train
INFO:main: act                 : relu
INFO:main: lrate_decay         : 0.67
INFO:main: seed                : 1
INFO:main: lr                  : 0.002
INFO:main: save_to             : mnist_all_gamma
INFO:main: save_dir            : results/mnist_all_gamma0
INFO:main: commit              :
INFO:main: contrast_norm       : 0
INFO:main: encoder_layers      : ('1000', '500', '250', '250', '250', '10')
INFO:main: labeled_samples     : 60000
Traceback (most recent call last):
File "./run.py", line 651, in
if train(d) is None:
File "./run.py", line 405, in train
in_dim, data, whiten, cnorm = setup_data(p, test_set=False)
File "./run.py", line 240, in setup_data
train_set = dataset_class("train")
File "/usr/local/lib/python2.7/dist-packages/fuel/datasets/mnist.py", line 36, in init
super(MNIST, self).init(self.data_path, which_set, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/fuel/datasets/mnist.py", line 40, in data_path
return os.path.join(config.data_path, self.filename)
File "/usr/local/lib/python2.7/dist-packages/fuel/config_parser.py", line 101, in getattr
"provided: {}.".format(key))
fuel.config_parser.ConfigurationError: Configuration not set and no default provided: data_path.
wangxiao@GTX980:~/Desktop/ladder-master$

Running into the same problem. The only exception is that I tried it using the mnist_all_full.

Update: Tried downgrading Theano to version 0.7 [the version that probably would have been used around the time the code was published]. The Tensor warning has been suppressed, but the error reported in this issue still persists.

But the auther of the paper did not even release a email address to us, I could not contract with him ! It is really confused me ...
Hope the auther could give us a replay ...

I am not the author @wangxiao5791509 but that is not related to the ladder network implementation, but to the Fuel package used by the authors.
You need to define that to a file which is not the most elegant way imho:
http://fuel.readthedocs.io/en/latest/built_in_datasets.html#environment-variable
# ~/.fuelrc
data_path: "/first/path/to/my/data:/second/path/to/my/data"

or you can add these 2 lines in run.py:
from fuel import config
config.data_path = '/path/to/your/data'

@Wakeupbuddy Adding those lines ended up working after all. Thanks. @petteriTeikari I found that documentation yesterday, but the method you described didn't work for me. Thanks though.

I am new to python and I don't know how to solve it. Well, thanks for your answer and I will try it later. @petteriTeikari

@petteriTeikari  I have one question: Do you know how to use this ladder network to run other classification datasets ? such as caltech-256 or cifar-100 ?  Just use that package Fuel ??

Hi!
Ladder master is just updated with blocks and fuel 0.2 support. The fuel configuration should be set prior to running the code according to the configuration page:
http://fuel.readthedocs.io/en/latest/built_in_datasets.html
In fuel 0.2, there are more datasets supported, and it should be straightforward to test it with the ladder codebase.
@wangxiao5791509 Could you please try update your master, configure fuel and then try out some of the examples that are in the README? Please let me know if you have any issues! Also, if the issue is resolved, could you also please close this issue?
Sorry for not responding, and we will try to respond to the issue faster going forward!


(docs): intra device scheduling

Summary
This notebook shows an example of intra-device scheduling where more than one circuit is executed in parallel on a hardware, and the result for each is obtained by marginalising.
Details and comments

The first version only shows executing two random circuits in parallel and obtaining the individual probability distributions by marginalising over the other.
Immediate next step: show how to do the same when we want to calculate expectation value of observables instead of distributions.


2023-07-10 - KDB Project Call Meeting Agenda

Date
Monday, July 10, 2023 - 9:30am ET / 2:30pm UK
// Second Monday of every month
Attendees

Fullname
Affiliation
GitHub Username

Meeting notices

FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

(5 min) Convene, roll call, welcome new people.
[ ] Display FINOS Antitrust Policy summary slide
[ ] Review Meeting Notices (see above)
(5 min) Approve previous meeting minutes.
(5 min) CCLA / KX Open Source Updates
(2 min) verbose.q
(30 min) KX Con 23 Discussion Continued

KX Con [23] Recordings

https://kx.com/kx-con-23-recordings/

AWS FinSpace
PyKX on Snowflake
KX and LLMs

(5 min) Zenith SIG and LLMs.

https://github.com/finos/zenith/issues/33
Next Zenith SIG call is on July 13th at 10 AM EDT.

(5 min) AOB, Q&A, Adjourn.

Decisions Made

Decision 1
Decision 2
...

Action Items

Action 1
Action 2
...

WebEx info
Webex

https://finos.webex.com/finos/j.php?MTID=me61719ca3c3295a7cc76762d78392bc3

Dial-in and Project Materials

US: +1-415-655-0003 US Toll
UK: +44-20319-88141 UK Toll
Access code: 2704 417 0390
GitHub Repos:

https://github.com/finos/kdb
https://github.com/finos/kdb-studio

Wiki Page:

https://finosfoundation.atlassian.net/wiki/spaces/DT/pages/329383945/kdb+Project

KDB Metrics on FINOS

https://metrics.finos.org/goto/033b15c80f0d08cab70f40f4358932f6

hi

James McLeod / FINOS

Alvin Shih / Morgan Stanley

Gary Davies / Data Intellect

Simon Frazer / Data Intellect

Connor Gervin / KX

@alvin-c-shih I would like represent kuki, the K Ultimate pacKage Installer in next meeting. Do you mind allocate 20mins for this?

@jshinonome I would certainly be interested, although it's an unfortunate name choice for Hungarian speakers.

@jshinonome I would certainly be interested, although it's an unfortunate name choice for Hungarian speakers.

Ah, naming is so difficult... please think it as cookie

I’ll definitely slot into the agenda!
Thanks!
ACS
From: Jo Shinonome @.>
Sent: Thursday, August 03, 2023 5:39 AM
To: finos/kdb @.>
Cc: Shih, Alvin (Technology) @.>; Mention @.>
Subject: [EXTERNAL] Re: [finos/kdb] 2023-07-10 - KDB Project Call Meeting Agenda (Issue #94)
@jshinonomehttps://github.com/jshinonome I would certainly be interested, although it's an unfortunate name choice for Hungarian speakers.
Ah, naming is so difficult... please think it as cookie
—
Reply to this email directly, view it on GitHubhttps://github.com/finos/kdb/issues/94#issuecomment-1663638409, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE7MRELEV42KBBY6MYS45DTXTNWTZANCNFSM6AAAAAA2C7R24E.
You are receiving this because you were mentioned.Message ID: @.***>

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. By communicating with Morgan Stanley you acknowledge that you have read, understand and consent, (where applicable), to the Morgan Stanley General Disclaimers found at http://www.morganstanley.com/disclaimers/terms. The entire content of this email message and any files attached to it may be sensitive, confidential, subject to legal privilege and/or otherwise protected from disclosure.

Thank you @alvin-c-shih !


[$1000] Language is switching repeatedly  on network failure simulate

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open setting page.
Go to preference.
Switch language to another and switch back to previous one.
Stay on Preference page and wait for few seconds.

Expected Result:
Shouldn’t switch repeatedly and last selected language should be applied.
Actual Result:
Language is switching repeatedly.
Workaround:
unknown
Platform:

Where is this issue occurring?

iOS

Version Number: 1.2.38-0
Reproducible in staging?: y
Reproducible in production?:  Toggle is not in production
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/207074281-ded66068-5177-47d6-8378-aa51cecf1d4b.mov
https://user-images.githubusercontent.com/43996225/207074387-e9a20342-7961-4423-9fee-f7f34402064b.MP4
Expensify/Expensify Issue URL:
Issue reported by: @jatinsoni
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1670659690749749
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~013bfd3daf304f1d20
Upwork Job ID:<PHONE_NUMBER>372060672
Last Price Increase: 2022-12-12

Proposal
Root clause: When switching between 2 languages, 2 API called at the same time and the api property canRetry is always true, so when 2 API requests were calling and retrying at the same time. As I can see it retried 10 times, so you can see 1 API retry to set language to English, the another one tried to set language to Espanol. That's why you can see it's switching repeatedly.
Solution
If this problem only happens with ios, we can fix that by using the onDonePress, we can only change the language once onDonePress is fired, we can also add a loading while changing language since changing App Locale will need time to change.
Option 1:
Update the current LocalPicker.js for separate logic between IOS and other platform:
diff --git a/src/components/LocalePicker.js b/src/components/LocalePicker.js
index aafb06ea6..0119016d1 100644
--- a/src/components/LocalePicker.js
+++ b/src/components/LocalePicker.js
@@ -2,6 +2,7 @@ import _ from 'underscore';
 import React from 'react';
 import {withOnyx} from 'react-native-onyx';
 import PropTypes from 'prop-types';
+import {Platform} from 'react-native';
 import compose from '../libs/compose';
 import * as App from '../libs/actions/App';
 import withLocalize, {withLocalizePropTypes} from './withLocalize';
@@ -42,15 +43,23 @@ const localesToLanguages = {
 };

 const LocalePicker = (props) => {
+    const [currentLocale, setCurrentLocale] = React.useState(props.preferredLocale);
     if (!Permissions.canUseInternationalization(props.betas)) {
         return null;
     }

     return (
         <Picker
+            onDonePress={() => {
+                if (currentLocale === props.preferredLocale || !currentLocale) {
+                    return;
+                }
+                App.setLocale(currentLocale);
+            }}
             label={props.size === 'normal' ? props.translate('preferencesPage.language') : null}
             onInputChange={(locale) => {
-                if (locale === props.preferredLocale) {
+                setCurrentLocale(locale);
+                if (locale === props.preferredLocale || Platform.OS === 'ios') {
                     return;
                 }

@@ -58,7 +67,7 @@ const LocalePicker = (props) => {
             }}
             items={_.values(localesToLanguages)}
             size={props.size}
-            value={props.preferredLocale}
+            value={Platform.OS === 'ios' ? currentLocale : props.preferredLocale}
         />
     );
 };
diff --git a/src/components/Picker/index.js b/src/components/Picker/index.js
index 62cb9c2b4..2c613ed41 100644
--- a/src/components/Picker/index.js
+++ b/src/components/Picker/index.js
@@ -191,6 +191,8 @@ class Picker extends PureComponent {
                             }
                             this.props.innerRef(el);
                         }}
+                        // eslint-disable-next-line react/jsx-props-no-spreading
+                        {...this.props}
                     />
                 </View>
                 <FormHelpMessage message={this.props.errorText} />

Option 2:
Create LocalPicker.ios.js and implement the logic similar with above code but only logic for IOS.

Proposal
Reason:  Repeatedly switching happen due to retry cycle. Haven't found any existing way to cancel and remove previous request and replace with new. Generally there are 2 types of request one is Take Every and another one is Take Latest. So this type of requests are take latest type in which old request will cancel and new one apply. Currently there is no direct way to do this.
We can add request config object in write function and pass it down to request. in persistRequests we can check if request is takeLatest type then we can remove old one.
diff --git a/src/libs/API.js b/src/libs/API.js
index d86fc099a0..1426fdf250 100644
--- a/src/libs/API.js
+++ b/src/libs/API.js
@@ -17,8 +17,11 @@ import CONST from '../CONST';
  * @param {Object} [onyxData.optimisticData] - Onyx instructions that will be passed to Onyx.update() before the request is made.
  * @param {Object} [onyxData.successData] - Onyx instructions that will be passed to Onyx.update() when the response has jsonCode === 200.
  * @param {Object} [onyxData.failureData] - Onyx instructions that will be passed to Onyx.update() when the response has jsonCode !== 200.
+ * @param {Object} requestConfig - Request configuration will be use to identify
+ *                                 request behavior (cancelable, shouldRetry, takeLatest)
+ * @param {boolean} [requestConfig.takeLatest]
  */
-function write(command, apiCommandParameters = {}, onyxData = {}) {
+function write(command, apiCommandParameters = {}, onyxData = {}, requestConfig = {}) {
     // Optimistically update Onyx
     if (onyxData.optimisticData) {
         Onyx.update(onyxData.optimisticData);
@@ -34,6 +37,7 @@ function write(command, apiCommandParameters = {}, onyxData = {}) {
     // Assemble all the request data we'll be storing in the queue
     const request = {
         command,
+        ...requestConfig,
         data: {
             ...data,

diff --git a/src/libs/actions/App.js b/src/libs/actions/App.js
index 1e3afedb35..d357397699 100644
--- a/src/libs/actions/App.js
+++ b/src/libs/actions/App.js
@@ -85,7 +85,7 @@ function setLocale(locale) {

     API.write('UpdatePreferredLocale', {
         value: locale,
-    }, {optimisticData});
+    }, {optimisticData}, {takeLatest: true});
 }

 function setSidebarLoaded() {
diff --git a/src/libs/actions/PersistedRequests.js b/src/libs/actions/PersistedRequests.js
index 260526c13b..549b9f68d7 100644
--- a/src/libs/actions/PersistedRequests.js
+++ b/src/libs/actions/PersistedRequests.js
@@ -21,6 +21,9 @@ function clear() {
  * @param {Array} requestsToPersist
  */
 function save(requestsToPersist) {
+    if (_.first(requestsToPersist).takeLatest) {
+        persistedRequests = _.filter(persistedRequests, request => request.command !== _.first(requestsToPersist).command);
+    }
     persistedRequests = lodashUnionWith(persistedRequests, requestsToPersist, _.isEqual);
     Onyx.set(ONYXKEYS.PERSISTED_REQUESTS, persistedRequests);
 }

Note: This issue is not just about iOS and language change everywhere where only latest request should apply creating this issue. example for pin/unpin.

Will be reviewing proposals later today.

@Santhosh-Sellavel turn off network failure simulate and refresh app. once app loaded turn on network failure simulate and try to change language.

Thanks, @jatinsonijs!

@deetergp
@s77rt proposal makes sense to me, please let me know your thoughts!

If there is no reason to actually send the request and treat it as failed, we can just treat it as failed without sending the request. <-- Alternative proposal 3

This makes sense too!
cc: @neil-marcellini As you implemented the preference, Any thoughts?

This issue can happen rarely in real case. But if it is happened will create wired behaviour as shown in video.
and I don't think disabling the pusher event will solve it. as network failure simulate toggle only for testing purpose. It will be not exist in production.
This can happen request send to server => server trigger pusher event => request failed for some reason. So if it can happen in real case you should consider my proposal. but if cannot happen in real case then I think its not needed.

@jatinsonijs Here the problem is caused because the Request was a success -> We received a pusher event and we treated it as Failed even though the request was succeded. But in real-time if the request failed we don't get a pusher notification I expect things would work normally.

This can happen request send to server => server trigger pusher event => request failed for some reason.

I believe that's not possible if that happened so we don't have anything to do and client-side!

You can reproduce this even without the Simulate failing network request turned on. If you have it turned on, turned it off then reopen the app. Try to switch it (any preferences) repeatedly quickly. I explained the problem here. It is easier to notice when the network fail simulate is on because as the others explained, the request is actually success, but we treat it as an error, therefore the request is retrying max 10 times "successfully", so we receive 10 Pusher API updates.
You can try to remove the Pusher subscription and the issue will be gone. (I'm not saying we need to remove it as the solution)
I don't put proposal title because I believe it need to be worked internally.
Here is my reproduction btw
https://user-images.githubusercontent.com/50919443/207756462-ff13ced3-b8cd-4945-87e5-1d2c1e3686b5.mp4

@Santhosh-Sellavel

I am unable to reproduce this consistently

That's okay, this is due to the response timing, we are sending requests to change the language to either en or es and sometimes we get the responses in the "right" sequence that you don't notice the frequent switch i.e.: en -> en -> en -> es -> es -> es Other times the response timing is en -> es -> en -> es -> en -> es

@jatinsonijs @Santhosh-Sellavel
The scenario @jatinsonijs described may actually happen since the pusher ws connection and the requests are independent. However if the request failed that's probably because the client just went offline so he won't receive the pusher notification anyway. Even if he did, it's not a problem because it will just make the change once (no rapid switching behaviour)

@jatinsonijs Your solution will hide the bug not fix it and it has some issues.

If we remove the optimisticData feature and change the language while failure simulation is on, the language should not be changed.

You are relying on persistedRequests which may be empty i.e. the request has been already sent.

@bernhardoj This is a slightly different issue and not that critical as it won't lead to that annoying rapid switching, it will switch a predicable n times based on your toggles events (2 switches at max in this case). If you double-click the toggle button:

optimisticData will set the value to off
Initiate a request (A) to set that value
optimisticData will set the value to on
Initiate a request (B) to set that value
Receive a pusher notification (initiated by A) and  set the value to off
Receive a pusher notification (initiated by B) and  set the value to on

This can be fixed but it's more or less complex that I feel it's not worth it

With every request add two fields idempotent and timestamp
Have the pusher return those two fields with relevant notifications
Before applying any Onyx update, check if idempotent is true, if it's then only apply the update if the timestamp is greater than the current stored one

@jatinsonijs

I didn't say you did, I was just trying to show you where the hidden bug is
Still, this does not cover the case where the request is sent already

Yes @s77rt  for already sent request its need to be discuss with backend for best approach. for frontend we can do thinks like debounce or cancel request if still pending etc...

@s77rt It's totally not a different issue. What I'm explaining is the root cause of the issue. You already explained it yourself in steps that when we switch on once and then off once, it will result in on twice and off twice. But why it keeps switching multiple times when we turn on simulate network fail? It is because it keeps retrying successfully and we keep receiving the Pusher update 10 times.
What if the user has a low connection and he toggle the switch 100 times? The optimisticData will apply the state correctly, but then after the request success, the Pusher will switch it 100 times again, which will be the same case as you turn on the simulate network fail.

@bernhardoj It's similar but not the same

Why it keeps switching multiple times when we turn on simulate network fail?

Because we are changing the onyx value multiple times. Simple as that. Nothing is wrong here.
The issue is the fact that we are changing the value in the first place where we should not.

What if the user has a low connection and he toggle the switch 100 times? ... the Pusher will switch it 100 times again, which will be the same case as you turn on the simulate network fail.

This is independent of the connection, the max is always 2

Bugs

The bug here is due to applying a "nonexistent" notification
The bug you are referring to is due to applying an outdated notification

"nonexistent" notification
Notifications that we get from the pusher should not exist because the requests "failed"
outdated notification
Notifications that replace a new value with an old value are considered outdated
Solutions

https://github.com/Expensify/App/issues/13521#issuecomment-1351145889
https://github.com/Expensify/App/issues/13521#issuecomment-1352998536

I think it will help to understand the issue here by "fixing" bug 2. Comment this line: https://github.com/Expensify/App/blob/a414d1a30c1726ae6dcfd44d4f28e1ccaf3b7cdf/src/libs/API.js#L24

The issue here is because we update the state (by calling Onyx.update) from Pusher subscription which we should not receive. When you turn on the simulate network fail, reopen the app, and then switch any preferences repeatedly, why we can't reproduce it? (Ref https://github.com/Expensify/App/issues/13521#issuecomment-1352401524). Because the Pusher failed to subscribe (haven't check why it failed), therefore it does not receive any API update and does not call Onyx.update().

If this is not affecting production then I agree it seems like a low priority item. I'm actually not too sure how useful the "simulate failing network requests" thing is. So yes, maybe we can just remove it?
At a high level - I think it is best to have QA focus on testing an environment that is as close to production as possible. I don't think they should be using this feature or forcing the app into offline mode. They should be turning off their Wi-Fi to test offline IMO.

I agree with what @neil-marcellini and @marcaaron have said. This doesn't seem particularly useful since it won't affect production/end-users. I am going to close this one out. Maybe we'll care about it more once we're on the other side of WAQ.


Some minor issues on the functions and procedures summary tab

Some minor issues on the functions and procedures summary tab:

ISSUE 1: Remove the blank lines at the beginning and end of the source
ISSUE 2: Remove the AS declaration from the source

This issue is also reproducible on Domains, Database Triggers, DDL Triggers, Triggers and Views.

with version <IP_ADDRESS> I cannot open any procedures for editing. Had to go back to version <IP_ADDRESS>1
Get an error -206, Column does not belong to referenced table.
Column seems to be RDB$FIELD_NAME

with version <IP_ADDRESS> I cannot open any procedures for editing. Had to go back to version <IP_ADDRESS>1
Get an error -206, Column does not belong to referenced table.
Column seems to be RDB$FIELD_NAME

Hi @steveh454,
I retested using the  <IP_ADDRESS> Snapshot and I was not able to reproduce the issue mentioned by you.
Could you please confirm the steps to reproduce the issue?
Right mouse click on a stored procedure and then select Alter.

with version <IP_ADDRESS> I cannot open any procedures for editing. Had to go back to version <IP_ADDRESS>1
Get an error -206, Column does not belong to referenced table.
Column seems to be RDB$FIELD_NAME

Hi @steveh454
The error is you version of firebird. Please confirm if you used FB 2.1 or minor.
I made the mistake of not validating the firebird version

Sorry for delay, I have more info on the versions of Firebird and FlameRobin.
Using 32 bit Firebird v2.5
The screenshots show the 2 versions of FlameRobin 0.9.3 and 0.9.2. I have taken screenshots of the Firebird engine version, how the 2 versions look when connected to a database, and what happens when trying to Alter the same procedure with 0.9.2 and 0.9.3
Notice the icons are different for procedures in 0.9.3, also if I try to edit any procedure in 0.9.3 I get a big error. But editing the same procedure with 0.9.2 works fine.

This issue is still reproducible on FlameRobin version 0.9.6.

So, looks like the space is simply some margin of 10px that (I think) wxWidget 3.2 introduced
TODO: add style="margin-top: 0px;margin-bottom: 0px;" to <pre> tags in every template with related problem


Broken with Python 3

I was trying to use this addon with the scrapy:1.3-py3 stack and it blows up with the exception below.
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/twisted/internet/defer.py", line 1299, in _inlineCallbacks
    result = g.send(result)
  File "/app/python/lib/python3.6/site-packages/scrapy/core/downloader/middleware.py", line 43, in process_request
    defer.returnValue((yield download_func(request=request,spider=spider)))
  File "/usr/local/lib/python3.6/site-packages/twisted/internet/defer.py", line 1276, in returnValue
    raise _DefGen_Return(val)
twisted.internet.defer._DefGen_Return: <200 http://www.example.com/robots.txt>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/app/python/lib/python3.6/site-packages/scrapy/core/spidermw.py", line 42, in process_spider_input
    result = method(response=response, spider=spider)
  File "/usr/local/lib/python3.6/site-packages/scrapy_pagestorage.py", line 59, in process_spider_input
    self.save_response(response, spider)
  File "/usr/local/lib/python3.6/site-packages/scrapy_pagestorage.py", line 78, in save_response
    self._set_cookies(payload, response)
  File "/usr/local/lib/python3.6/site-packages/scrapy_pagestorage.py", line 110, in _set_cookies
    for x in response.headers.getlist('Set-Cookie')]:
  File "/usr/local/lib/python3.6/site-packages/scrapy_pagestorage.py", line 110, in <listcomp>
    for x in response.headers.getlist('Set-Cookie')]:
TypeError: a bytes-like object is required, not 'str'

This should work fine now that #5 has been merged into the master branch (0.2.2 release).
@vshlapakov I think this issue can be closed.


ci: add check-generated job

Pull Request Test Coverage Report for Build 433987667

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 39.504%

Totals

Change from base Build 433987112:
0.0%

Covered Lines:
2279

Relevant Lines:
5769

💛  - Coveralls


Issue on 'mock_data_core'

Just started to take a look at the new version of code for computing the indicators (I started with indicator #1). It's good!!! Moreover, in the light of the last meeting, in general the code needs to be integrated with the suitable test(s).
In order to test the resulting code on 'real data', provided guide suggests to use 'mock_data_core', but it contains rows with the same cig (ID contract) and this definitely affects the final results. This can be fixed in two ways:
i. by envisaging the code to remove dupliated rows according to the variables needed for computing the indicator;
ii. by building test data so that one row = one contract and using columns with nested objects when relationship 1-n arises (e.g., for winner companies, modifications) --> preferred by me, but I'm afraid it weighs too much, doesn'it?

Correct me if I am wrong, is the problem of this kind?
tibble(
contract = c("A,"A"),
field_1 = c(1,NA),
field_2 = c(NA,2)
) -> A

Because if this is the issue we just need a function to compact the mock + the data management process.
First thing coming into my mind:
A |>
group_by(contract) |>
mutate(across(everything,first_not_na))
)

(right now I do not remember how to express first_not_na but you got it).
I am sure there is even more implicit code in dplyr::.

@simonedelsa is definitely right about that, we need to keep it unique in order to generate indicators. There are duplicates because, in the pipeline I wrote, when you join tables with cf_stazione_appaltante (upper tables cluster: CENTRI DI COSTO,  MODALITA REALIZZAZIONE,  TIPO SCELTA CONTRAENTE) from ANAC, and for id_aggiudicazione (left tables cluster, FONTI FINANZIAMENTO,  QUADRO ECONOMICO  etc) sometimes you are going to have more than 1 results for the same cig. But since I also deselected some of the columns (they are not of interest for us) you are not going to notice it and as a result they look exactly the same rows.
Either we do something like @giuliogcantone suggests or we modify the pipeline such that we only retain the first result. We might want also to exclude upper and left tables so that we avoid row duplicated by design.


hi

u gonna fix it or what

hi, did you encounter a bug?

yes please fix

^ I've also encountered this bug

lmao

hello i am still waiting for the fix

ok bye


Updated download.html

Updated to grin-wallet 5.3.1 and grin 5.3.2. Removed Niffler and Ironbelly and added Grim.

I also removed info about homebrew and snap installs as I don't believe they are still maintained

Sorry, just looking at site updates now after someone pointed out that changes need to be merged. I just merged the ironbelly removal at author's request in #269, and I'm about to undertake a retag and build of grin and grin wallet. Can we wait until all of these are done and then update the download page with very latest releases, remove niffler and add and Grim?

-Afaik Niffler works Rust node, you can add external nodes also it works atm. If GUI wallet releases, it can be replaced.
-Grin++ banning/blacklisting peers. Not updated for a long time.
-Grim can be added instead of ironbelly imo.

Sorry, just looking at site updates now after someone pointed out that changes need to be merged. I just merged the ironbelly removal at author's request in #269, and I'm about to undertake a retag and build of grin and grin wallet. Can we wait until all of these are done and then update the download page with very latest releases, remove niffler and add and Grim?

Sounds good to me, I'll touch base with you in a bit when the new versions are ready I'll update the downloads page then.

-Afaik Niffler works Rust node, you can add external nodes also it works atm. If GUI wallet releases, it can be replaced. -Grin++ banning/blacklisting peers. Not updated for a long time. -Grim can be added instead of ironbelly imo.

I removed Niffler since I've only seen it mentioned when folks have downloaded it and had problems. I admittedly haven't been around long so I'm not familiar with it's status beyond seeing a few posts for help with running it and those people being recommended a different solution.


[UnitTest] Refactor BE unit test script

Proposed changes
Refactor the run-ut.sh

Rename run-ut.sh to run-be-ut.sh
Find all test files from build dir instead of declaring separately in the script
Add gtest output to collect the result of unit test.

Also comment out some unit test which are not running anymore.
Types of changes

[x] Bugfix (non-breaking change which fixes an issue)
[x] Code refactor (Modify the code structure, format the code, etc...)

Checklist

[x] I have create an issue on (Fix #4265), and have described the bug/feature there in detail
[x] Compiling and unit tests pass locally with my changes

Hi, @morningman Can we support run specify UT like sh run-be-test.sh --run xxx_test?

Hi, @morningman Can we support run specify UT like sh run-be-test.sh --run xxx_test?

Ok, I will add it

est instead of only build

I'm not sure changing the default behavior is ok. This script has same behavior like run-fe-ut.sh


v1.7.10 requires a module by the wrong version

<EMAIL_ADDRESS>requires<EMAIL_ADDRESS>Commit google/go-github@dd29b543e14c shows a go.mod with path github.com/google/go-github/v18 so it can't be used with v0.0.0 and naked github.com/google/go-github import path.
Go 1.13 notices and breaks.
go<EMAIL_ADDRESS>requires
<EMAIL_ADDRESS>invalid version: go.mod has post-v0 module path "github.com/google/go-github/v18" at revision dd29b543e14c

In other words<EMAIL_ADDRESS>doesn't exist, that commit is<EMAIL_ADDRESS>

Thanks for the report @FiloSottile.
@e-dard introduced go.mod in into the 1.7 branch in cbae66e70765bacc15f22dad7474b18c86a84b53, via https://github.com/influxdata/influxdb/pull/15863 -- there was no mention of go.mod in the commit message or in the PR comments by reviewers @jacobmarble nor @benbjohnson.
I noticed we also still have Gopkg.lock. My suspicion is that we weren't intending to migrate to modules for influxdb 1.7 yet. But now that we've published 1.7.10 with modules, it seems like we ought to fix up go.mod in 1.7.11.
I did try deleting github.com/google/go-github v0.0.0-20181009003523-dd29b543e14c line from go.mod and then running go get github.com/google/go-github/v18@dd29b543e14c, but that ran into the next error: go<EMAIL_ADDRESS>go.mod has non-....v2 module path "github.com/russross/blackfriday/v2" at revision v2.0.1.
Then, deleting the gopkg.in/russross/blackfriday.v2 v2.0.1 line from go.mod allows go get github.com/google/go-github/v18@dd29b543e14c to run successfully, but it also updates many of the referenced modules' versions.
@dgnorton let's see if we can get modules set up properly for 1.7.11.

Looks like the go.mod was created with go mod init which printed errors about those v2 modules, but they were not fixed.
The reason it looks like it's updating stuff when you run it is that go mod tidy will report in your go.mod the version that's actually being used based on the dependency graph.
For example, you require<EMAIL_ADDRESS>but also<EMAIL_ADDRESS>which requires<EMAIL_ADDRESS>so go mod tidy just reports it correctly.
$ go mod graph
github.com/influxdata/influxdb<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

I prepared a cleaned up go.mod with no updates (beyond the ones forced by transitive dependencies) in #16903. I imagine it will not be enough as a PR, so feel free to just take the go.mod from it.

this is causing builds to fail on homebrew: https://github.com/Homebrew/homebrew-core/pull/49900

This is causing a downstream issue where the compilation of external plugins written in golang for influxdata/telegraf will fail with the exact same error.

I'm sorry. I didn't get. How should I fix this?

@korjavin, add this to your go.mod file:
// TODO: Keep this until this is fixed and released (>1.7.10):
// https://github.com/influxdata/influxdb/issues/16901
replace github.com/influxdata/influxdb => github.com/influxdata/influxdb v1.7.9

Fixed with the release of 1.7.11


[bug] Getting an error (set.2.value) is required when trying to enable Karpenter addons using Terraform

Describe the bug
I am getting
Error: Missing required argument

  with helm_release.karpenter[0],
  on karpenter.tf line 104, in resource "helm_release" "karpenter":
 104: resource "helm_release" "karpenter" {

The argument "set.0.value" is required, but no definition was found.

Error: Missing required argument

  with helm_release.karpenter[0],
  on karpenter.tf line 104, in resource "helm_release" "karpenter":
 104: resource "helm_release" "karpenter" {

The argument "set.2.value" is required, but no definition was found.

while I am trying to enable the karpenter
What is the current behavior?
I am already using other addons like metrics-server  and it's working absolutely fine but when I try to enable Karpenter, I am getting the error.
How to reproduce? Please include a code sample if relevant.
karpenter = {
    enabled = true
  }

What's the expected behavior?
The module must not throw any errors
Environment details

Affected module version: 15.3.0
OS: macOS
Terraform version: Terraform v1.5.2 on darwin_arm64
Kubernetes version: 1.28

Any other relevant info
It's kind of very similar to this issue.

Hi, @rahul799 I'm also having the same problem, Are there any updates on it?

@rahul799 @fabiocruzcoelho is the issue still present ?

@rahul799 @fabiocruzcoelho is the issue still present ?

Yes @ArchiFleKs


update license  v0

V0

[ ] GPL license

[ ] Update all policies by taking inspiration from Chatwoot policies (https://github.com/chatwoot/chatwoot)

v1

Take inspiration from Mozilla on this (https://www.mozilla.org/en-GB/about/legal/)
Explore https://github.com/mozilla/glean/blob/main/LICENSE

https://choosealicense.com/no-permission/


undefined: grpc.ForceCodec

has the error:
go-micro/client/grpc/grpc.go:116:65: undefined: grpc.ForceCodec
when I execute cmd: go get github.com/micro/go-micro

Run go get -u as grpc has a ForceCodec function here https://godoc.org/google.golang.org/grpc#ForceCodec


Text regression

Add text regression task. Implement three metrics: SegKtauCorr, SysPearsonCorr, RootMeanSquareError.

Hey, @qinyiwei  thanks a lot for the PR. It would be nice if you could fix these continuous integration errors based on corresponding suggestions.

To make it easier to fix those errors, I'd suggest running pre-commit install, which will install pre-commit checks for formatting and type-checking. I think these things should be easy to check.

These conflicts could be resolved manually.

hi, @qinyiwei

"explainaboard   --task text-regression --custom_dataset_paths ./data/system_outputs/text_regression/wmt20-DA/cs-en/data.tsv --system_outputs ./data/system_outputs/text_regression/wmt20-DA/cs-en/score.tsv --output_file_type tsv --output_dir output/cs-en --source_language en --target_language en --metrics SysPearsonCorr SegKtauCorr RootMeanSquareError"

This seems cannot work, detailed logs:

Hi, @neubig just re-named it.


docs(owc-dev-server): improve various bits

As I already had the editor open to add a note on the package name (see previous discussion on slack), I couldn't help but felt like adding and tweaking a bit here and there.

Can this be merged?

This PR dragged on for a long time, really sorry about that :(
We've completely overhauled the dev server now: https://github.com/open-wc/open-wc/pull/520 if we want to make improvements let's do it on the readme of that project.
Again sorry and thanks for the work you did on this.


Sorting of p-orbitals (-DPYPZPX flag)

It seems like the flag for changing the ordering of the p-orbitals (-DPYPZPX=ON) does not have any effect.
I also could not find the corresponding preprocessor variable in the code, so I guess this behavior is not surprising.
Am I missing something?
Best,
Marvin

Hi, I'm using it and I confirm it works.
Try the syntax
cmake -DPYPZPX=1 ..
That's what I use.
Fabien

I found the problem. I had mol.cart = True in my test script, and it does not work with this. The flag seems to only affect integrals that end with _sph.
(ON and 1 should be the same, according to the docs.)

Test setup
import pyscf
import numpy as np

mol = pyscf.gto.Mole()
mol.atom = """
    Li 0.0  0.0  0.0
    H  0.0  0.0  2.0
"""
mol.unit = "B"
mol.basis = {
    "H": pyscf.gto.basis.parse(
        """
        H    S
            7.611997      0.185361
            1.392902      0.237717
            0.386963      0.186322
            0.128430      0.044590
    """
    ),
    "Li": pyscf.gto.basis.parse(
        """
        Li    s
            15.31972151296465       -0.02291026138662078
            2.8094811665593564      -0.03196871915609773
            0.7895248193180717      -0.030744486291675623
            0.11290380206527327      0.046451810947854666
            0.05124268926165842      0.043147173309934214
            0.02443734894454437      0.00754582412111015
        Li    p
            1.723363201952989        0.022303261655455882
            0.44941807744596446      0.0269813123597847
            0.1608060702089178       0.027555346420133024
            0.0672200111289616       0.019758486084400048
            0.030737568155688608     0.0073608364905450524
            0.014531637702150497     0.0007564657049769052
    """
    ),
}
#mol.cart = True

mol.build()

print("mol.cart default")
print(mol.intor("int1e_ovlp"))

print("\nint1e_ovlp_sph")
print(mol.intor("int1e_ovlp_sph"))

print("\nint1e_ovlp_cart")
print(mol.intor("int1e_ovlp_cart"))

Output
mol.cart default
[[1.         0.         0.         0.         0.51771495]
 [0.         1.         0.         0.         0.        ]
 [0.         0.         1.         0.         0.42802969]
 [0.         0.         0.         1.         0.        ]
 [0.51771495 0.         0.42802969 0.         1.        ]]

int1e_ovlp_sph
[[1.         0.         0.         0.         0.51771495]
 [0.         1.         0.         0.         0.        ]
 [0.         0.         1.         0.         0.42802969]
 [0.         0.         0.         1.         0.        ]
 [0.51771495 0.         0.42802969 0.         1.        ]]

int1e_ovlp_cart
[[1.         0.         0.         0.         0.51771495]
 [0.         1.         0.         0.         0.        ]
 [0.         0.         1.         0.         0.        ]
 [0.         0.         0.         1.         0.42802969]
 [0.51771495 0.         0.         0.42802969 1.        ]]


React Native 63 not showing remote or static images with iOS 14

Description
I'm using react native 63 with Xcode Version 12.0 beta (12A6159) and iOS 14. I'm trying to use the react native image component. The simulator isn't showing any of my static image assets. Nor is it showing remote images.
<Image source={require('../assets/img/cardsAdCardsVersion1.png')} style={{resizeMode:'cover', width, marginTop:1.5}} />
or
<Image source={{uri: 'https://reactjs.org/logo-og.png'}} style={{width: 400, height: 400}} />
None of the Above show the image instead show an empty white background. Using iOS13 in the simulator shows the image. Problem is with iOS 14.
React Native version:
System:
OS: macOS 10.15.5
CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
Memory: 2.70 GB / 16.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 14.5.0 - /usr/local/bin/node
Yarn: Not Found
npm: 6.14.5 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.7.5 - /usr/local/bin/pod
SDKs:
iOS SDK: Not Found
Android SDK: Not Found
IDEs:
Android Studio: 3.6 AI-192.7<IP_ADDRESS>41897
Xcode: /undefined - /usr/bin/xcodebuild
Languages:
Java: 1.8.0_242 - /usr/bin/javac
Python: 2.7.16 - /usr/bin/python
npmPackages:
@react-native-community/cli: Not Found
react: 16.13.1 => 16.13.1
react-native: 0.63.0 => 0.63.0
npmGlobalPackages:
react-native: Not Found
Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.

Using react native Image component
<Image source={require('../../../assets/img/cardsAdCardsVersion1.png')} style={{resizeMode:'cover', width, marginTop:1.5}} />
or <Image source={{uri: 'https://reactjs.org/logo-og.png'}} style={{width: 400, height: 400}} />

Expected Results
Should show the image and instead shows a white background.

Closing this issue. The solution that worked for me was https://github.com/facebook/react-native/issues/29279#issuecomment-658244428

Real solution
https://github.com/facebook/react-native/issues/29279#issuecomment-658244428


fix deadlinks of c++ api infer doc, test=develop

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.System Administrator seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Cluster deletion may take long because chart-operator deletion is attempted when Kubernetes cluster is already down

In https://github.com/giantswarm/roadmap/issues/1719#issuecomment-1354678213, we found that cluster deletion works but is quite slow (taking 15 minutes or more until all manifests and resources are gone). The chart-operator app on the management cluster persisted even after the workload Cluster/AWSCluster objects were gone.
Since waitForAppDeletion does not log errors in multiple locations, I could not find out whether the attempted deletion of App/andreas1-chart-operator led to cluster deletion taking very long, or why it took long to delete chart-operator at all. Quite likely is that the Kubernetes cluster was simply already gone. CAPI doesn't have a mechanism to delete in-cluster stuff first, and then the cluster itself.
Deleting Kubernetes before applications running on it may not be a real issue given that CAPA deletes owned resources that are left behind. I rather think of this observation as something that customers/developers may find confusing – "why would cluster deletion take 15 minutes?". Let's please check if the deletion of chart-operator could influence how long that takes. If we don't find something, maybe we can at least improve error logging so this could be troubleshooted more easily through logs.

Here's the template I used to deploy the workload cluster on golem:
apiVersion: v1
items:
- apiVersion: v1
  data:
    values: |
      aws:
        region: eu-west-2
      bastion:
        enabled: false
      proxy:
        enabled: true
        http_proxy: "http://internal-a1c90e5331e124481a14fb7ad80ae8eb-1778512673.eu-west-2.elb.amazonaws.com:4000"
        https_proxy: "http://internal-a1c90e5331e124481a14fb7ad80ae8eb-1778512673.eu-west-2.elb.amazonaws.com:4000"
        no_proxy: "test-domain.com"
      clusterName: andreas1
      controlPlane:
        replicas: 3
      machinePools:
      - instanceType: m5.xlarge
        maxSize: 10
        minSize: 3
        name: machine-pool0
        rootVolumeSizeGB: 300
        availabilityZones:
        - eu-west-2a
        - eu-west-2b
        - eu-west-2c
      network:
        # Stealing Alex's uppermost subnet while he agreed to not need it (see poll https://gigantic.slack.com/archives/C04AJ5FJHEK/p1668678373098049)
        vpcCIDR: <IP_ADDRESS>/16
        topologyMode: GiantSwarmManaged
        availabilityZoneUsageLimit: 3
        vpcMode: private
        apiMode: private
        dnsMode: public
        subnets:
        - cidrBlock: <IP_ADDRESS>/18
        - cidrBlock: <IP_ADDRESS>/18
        - cidrBlock: <IP_ADDRESS>/18
      organization: giantswarm
  kind: ConfigMap
  metadata:
    labels:
      app-operator.giantswarm.io/watching: "true"
      giantswarm.io/cluster: andreas1
    name: andreas1-userconfig
    namespace: org-giantswarm
- apiVersion: v1
  data:
    values: |
      clusterName: andreas1
      organization: giantswarm
  kind: ConfigMap
  metadata:
    labels:
      app-operator.giantswarm.io/watching: "true"
      giantswarm.io/cluster: andreas1
    name: andreas1-default-apps-userconfig
    namespace: org-giantswarm
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
---
apiVersion: v1
items:
- apiVersion: application.giantswarm.io/v1alpha1
  kind: App
  metadata:
    labels:
      app-operator.giantswarm.io/version: 0.0.0
      app.kubernetes.io/name: cluster-aws
    name: andreas1
    namespace: org-giantswarm
  spec:
    catalog: cluster
    config:
      configMap:
        name: ""
        namespace: ""
      secret:
        name: ""
        namespace: ""
    kubeConfig:
      context:
        name: ""
      inCluster: true
      secret:
        name: ""
        namespace: ""
    name: cluster-aws
    namespace: org-giantswarm
    userConfig:
      configMap:
        name: andreas1-userconfig
        namespace: org-giantswarm
    version: 0.20.2
- apiVersion: application.giantswarm.io/v1alpha1
  kind: App
  metadata:
    labels:
      app-operator.giantswarm.io/version: 0.0.0
      app.kubernetes.io/name: default-apps-aws
      giantswarm.io/cluster: andreas1
      giantswarm.io/managed-by: cluster
    name: andreas1-default-apps
    namespace: org-giantswarm
  spec:
    catalog: cluster
    config:
      configMap:
        name: andreas1-cluster-values
        namespace: org-giantswarm
      secret:
        name: ""
        namespace: ""
    kubeConfig:
      context:
        name: ""
      inCluster: true
      secret:
        name: ""
        namespace: ""
    name: default-apps-aws
    namespace: org-giantswarm
    userConfig:
      configMap:
        name: andreas1-default-apps-userconfig
        namespace: org-giantswarm
    version: 0.12.3
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

cc @piontec

Hey @AndiDog ! Some things about your report are not clear to me, can you please check and confirm some stuff?

you mention different operators: the title says cluster-operator, the description chart-operator. I'm assuming it's chart-operator
If it's chart-operator, I don't really follow: chart-operator for a WC runs on the WC directly, not on the MC. On MC, there's the app-operator that bootstraps and manages chart-operator on MC
if you think the problem is related to when chart-operator is deleted from WC, can you please provide more info about how the WC looks like when it's 'stuck', esp. what's the status of chart-operator deployment and what Chart CRs are present in the API?

I fixed the title.
This is about the chart-operator App on the MC. Does the linked https://github.com/giantswarm/roadmap/issues/1719#issuecomment-1354678213 make it clearer? So when the WC was already gone, we still have kubectl get app -n org-giantswarm andreas1-chart-operator listed. That seems strange since the chart-operator, as you said, runs on the WC, and should therefore at best 1) be deleted before the Kubernetes cluster is unreachable (which is hard because we can't tell CAPA to wait for deletion), or at least 2) not delay the whole deletion duration. I did not dig deep enough to find out whether it's really the deletion of App/chart-operator that takes so long, but I had observed those leftovers for many minutes and therefore assumed that it could be a problem.

OK, what you see is reasonable: the andreas1-chart-operator app CR (it's app CR, that's the important part) tells app-operator on MC to deploy chart-operator on WC. Now, if the target WC just 'disappears' and someone requests a deletion of an app from the target WC, app-operator tries to connect and delete it as requested. The problem is it doesn't know if the cluster is gone for good (deleted) or just temporarily unavailable (connectivity issues, downtime period). That's why AFAIR there's some timeout and wait before app-op gives up the deletion.
Does it make the situation clearer?

That's what I assumed would happen. So only after the timeout, app-operator gives up and removes the finalizer operatorkit.giantswarm.io/cluster-apps-operator-cluster-controller from the Cluster object so it can eventually die. I guess we don't really have a chance to improve this easily, so feel free to close at your discretion 😉

OK, closing then :) Let us know if you find something suspicious :)


Links on near.org are broken, go to about:blank

Describe the bug
All of the links on DevHub such as in the navigation bar are redirecting to about:blank rather than the correct route.
NOTICE: This only occurs on near.org and is not an issue on near.social.
To Reproduce
Steps to reproduce the behavior:

Go to https://near.org/devhub.near/widget/app
Click on "/communities" in the navbar
Notice redirect to about:blank

This must be related to the recent reported security vulnerability where we need to check that href is typeof string before linking.
Near.social fixed it with this solution: https://github.com/NearSocial/viewer/blob/91e1739d6ebb39e6cbbb35198608412a6695fc9c/src/App.js#L80C3-L80C3
Near.org solution is more intense: https://github.com/near/near-discovery/commit/d107f816e2d96d2e3d471f308b3ed228c08da165
We are creating valid links. Opening up an issue in near.org gateway

Pinging near.org team again


Batch gears

Closes #604.
Review Checklist

Tests were added to cover all code changes
Documentation was added / updated
Code and tests follow standards in CONTRIBUTING.md

There is one "gotcha" with this design - if a job fails, we no longer have it's "current" job id in the array stored on the batch job. I have a few ideas for this, @kofalt maybe we can discuss later today.

There is an issue with the aboa tests generated from the raml - Docker fails with an unhelpful error. I'll add those as a follow up PR as to not hold up these changes.


Empty annotation elements trigger Math Processing Error

See also https://github.com/mathjax/ctop/issues/29.
I'm wondering if MathJax can be more graceful than a full Math Processing Error for the entire equation? The way I read the spec, empty annotation elements are valid (but I might be wrong).
  <math>
       <semantics>
          <annotation>
          </annotation>
        </semantics>
   </math>

I was writing a test when I noticed that the issue affects the CommonHTML output as well. Should I open a new item?

On second thought, perhaps #1006 is already suitable.

I'm not sure I see the connection to 1006.  In any case, I've pushed a commit that resolves the issue for semantics.

Works for me. (I mentioned #1006 because that's also an issue about dealing with invalid MathML so I wasn't sure if they're related.)

==> In Testsuite
MathMLToDisplay/ErrorHandling/issue805.html