Can't create view with range query

What type of bug is this?
Unexpected error
What subsystems are affected?
Query Engine
Minimal reproduce step
For example:
CREATE VIEW test as SELECT
SELECT
  ts,
  host,
  approx_percentile_cont(latency, 0.95) RANGE '5s' AS p95_latency
FROM
  app_metrics
ALIGN '5s' FILL PREV;

It fails with:
1: Table operation error, at src/frontend/src/instance.rs:232:14
2: Failed to convert between logical plan and substrait plan, at /Users/dennis/programming/rust/greptimedb/src/operator/src/statement/ddl.rs:451:14
3: Failed to encode DataFusion plan, at /Users/dennis/programming/rust/greptimedb/src/common/substrait/src/df_substrait.rs:80:43
4: NotImplemented("Serizlize logical plan for RangeSelect")

The RangeSelect plan can't be serizlized.
What did you expect to see?
Internal error
What did you see instead?
Create success
What operating system did you use?
Irrelevant.
What version of GreptimeDB did you use?
main branch
Relevant log output and stack trace
No response

I did an initial assessment and would like to share some findings:

the relevant code fragment that should be extended is src/common/substrait/src/extension_serializer.rs

          name if name == RangeSelect::name() => {
                let range_select = node
                    .as_any()
                    .downcast_ref::<RangeSelect>()
                    .expect("Failed to downcast to RangeSelect");
                Ok(range_select.serialize())

the RangeSelect struct is already defined in src/query/src/range_select/plan.rs. I came across the circular dependency when I was trying to use it, so probably moving this code under common::query would help.

to implement the serialize method one needs to create the proto definition in greptime-proto repo.

cc @waynexia

Yep.👍🏻

If the plan seems ok I'll try looking at proto definition in the background.

If the plan seems ok I'll try looking at proto definition in the background.

That would be cool!

@etolbakov Hi, are you still working on this issue? I think it's a fatal issue that needs to be addressed.

sorry Dennis, didn't make much progress to be honest

sorry Dennis, didn't make much progress to be honest. I will have time these weekend, but I appreciate the urgency, don't want to block you.

Don't worry. I think @waynexia could help you figure out how to address this issue. Please take a look.
Subsrait with DataFusion has so many issues, that we need to push the community to address them.


Use #[expect] when possible

Draft until the next Rust Analyzer update, it shows warnings for #[expect(non_camel_case_types)] that where suppressed by allow.

This can close after https://github.com/rust-lang/rust-analyzer/pull/18081


[PDI-14375] - Incorrect time displayed in Version History after some operations with transformation/jobs in the DI repository

clear "createdDate" on renaming to force the repository to inject current time
update tests to check this condition

@mattyb149, @brosander, review it please

Changed files:
plugins/pdi-pur-plugin/src/org/pentaho/di/repository/pur/PurRepository.java
plugins/pdi-pur-plugin/test/org/pentaho/di/repository/pur/PurRepository_MoveAndRename_IT.java
Checkstyle violations:
Errors:File plugins/pdi-pur-plugin/src/org/pentaho/di/repository/pur/PurRepository.java

Message: File length is 2,870 lines (max allowed is 2,000). at Line: 1 Column: None

Unit test coverage change:
org.pentaho.di.repository.pur.PurRepository:

instructionPercentCoverageChange :-0.00%

Integration test coverage change:
org.pentaho.di.repository.pur.PurRepository:

instructionPercentCoverageChange : +0.01%

Changed files:
plugins/pdi-pur-plugin/src/org/pentaho/di/repository/pur/PurRepository.java
plugins/pdi-pur-plugin/test/org/pentaho/di/repository/pur/PurRepository_MoveAndRename_IT.java
Checkstyle violations:
Errors:File plugins/pdi-pur-plugin/src/org/pentaho/di/repository/pur/PurRepository.java

Message: File length is 2,870 lines (max allowed is 2,000). at Line: 1 Column: None

Unit test coverage change:
org.pentaho.di.repository.pur.PurRepository:

instructionPercentCoverageChange :-0.00%

Integration test coverage change:
org.pentaho.di.repository.pur.PurRepository:

instructionPercentCoverageChange : +0.01%


change delete_project_revision_and_amendments to a generic delete_project_revision mutation

###Description of the Tech Debt###
###Tech Debt Triage#
The purpose of our technical debt triage process is to analyze technical debt to determine risk level of the technical debt and the value in tackling that technical debt.
Risk Value Scoring:

Level
Value

High
3

Medium
2

Low
1

Technical Debt - Risk Types
Level
Value

Business Area Risk - Risk of business area visibility / damage to user experience

1

Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it
2

System Fault Risk - Risk of system errors or application downtime

1

Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time?

Time Sink Risk - How much will this tech debt slow the development process down
1

TOTAL SCORE:

5

Finished in PR https://github.com/bcgov/cas-cif/pull/1160


added pattern to brush style if there's effects in the clip or gap item.

Codecov Report

Merging #310 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #310   +/-   ##
=======================================
  Coverage   90.89%   90.89%
=======================================
  Files          53       53
  Lines        4512     4512
=======================================
  Hits         4101     4101
  Misses        411      411

Continue to review full report at Codecov.

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

Cool! This is just my opinion though so take it with a huge grain of salt, but I wonder if it would be nice to add something to the tooltip for these clips. I sometimes get confused in UIs where I see some marker or widgetry I don't understand or explained anywhere (and often look for a tooltip to help explain it). I wonder if the details widget would make this clear, or if adding something to the tooltip like "Has Effects" would help.
I have wanted to propose adding a lot more detail to the tooltip popup for a while (and perhaps this could wait till then), but just thought I would throw that out there.

Codecov Report

Merging #310 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #310      +/-   ##
==========================================
- Coverage   90.89%   90.85%   -0.04%
==========================================
  Files          53       53
  Lines        4512     4516       +4
==========================================
+ Hits         4101     4103       +2
- Misses        411      413       +2

Impacted Files
Coverage Δ

opentimelineio/plugins/manifest.py
90.47% <0%> (-2.03%)
:arrow_down:

Continue to review full report at Codecov.

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


Time-based groups?

Like everyone, my server is under constant DDoS. Currently ElectrumX has a simple cost-based mitigation, that works for individual sessions but also groups sessions together based on their /24 network address and also a time-window when the session was created. The network-based grouping kind of works, but I don't get the time-based bucketing.
If the server is under constant load, the time-based groups will always be over budget and therefore all sessions will get throttled, regardless whether they are legit or not. Sooner or later, they will disconnect. Am I missing something, or is this type of protection contra-productive? Is anyone using this in production anyway?
If no-one is using it, shouldn't it be removed?

I am not sure why kyuupichan thought it would be a good idea, originally.
I agree, it only seems useful if the DDOS is short-lived / burst-like, which is just not the case in practice it seems.
So yes, we can remove it.


Traffic layer on Google Maps

Can we overlay google traffic layer on Xamarin.Forms.GoogleMaps, or is there any workaround to implement this feature.
same as of google map api traffic layer
Eg . https://developers.google.com/maps/documentation/javascript/examples/layer-traffic

Hello,
I just created pullrequest for your issue.
https://github.com/amay077/Xamarin.Forms.GoogleMaps/pull/104
Could you please check that it is working for all platform? I was able to test it just on Android

Thanks!
I'll review it.

I deployed 1.7.0-beta3 that includes this.
Please check it.

It looks like it is working, please close this issue.

👍


Add support to different Haier climate

<!-- Before you open a new issue, search through the existing issues to see if others have had the same problem.

**Home Assistant version**
2021.1.5

**SmartIR version**
1.16.0
**SmartIR configuration**
`smartir:
climate:
  - platform: smartir
    name: Livingroom AC
    unique_id: livingroom_ac
    device_code: 1320
    controller_data: remote.broadlink_remote

the Haier remote that supported currently not working with my Haier air conditioner

this is the remote codes for my haier ac
1330.zip

oops  forgot to save 💯
1330.zip

Thanks!


README Tests section improvements

[x] All tests passed. If this feature is not already covered by the tests, I added new tests.
[x] This pull request is on the dev branch.
[x] I used gofmt for formatting the code before submitting the pull request.

Added -timeout 0 options to the tests command.
Modified the Tests section formating and structure.

Great feedback @yahavi. Implemented all.


first master version of the tool

I have moved the commits of branch initial-work so that they are based on the an empty master branch, for some reason now all commits show up twice in the history.

I have fixed this locally based on the backup that I took on Friday.
I won't push this until you say it is ok, as I don't want to overwrite any changes that you might have done since then.


Secrets not surviving server reboot...

I believe I'm seeing an issue where secrets are not available after server reboot.
The steps to reproduce are below.  Note that the following steps have been run on v.0.16.2:
Create the following simple secret:
# From kubernetes/examples/secrets/secret.yaml
apiVersion: v1beta3
kind: Secret
metadata:
  name: test-secret
data:
  data-1: dmFsdWUtMQ0K
  data-2: dmFsdWUtMg0KDQo=

Then create the following pod:
apiVersion: v1beta3
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: centos:centos7.0.1406
    command: [ "bash", "-c", "while [ true ]; do cat /etc/test-secret/data-1; sleep 5; done" ]
    volumeMounts:
    - mountPath: /etc/test-secret
      name: test-secret
      readOnly: true
  volumes:
  - name: test-secret
    secret:
      secretName: test-secret

After starting the pod you can see that it is correctly slowing the data-1 value from the secret
kubectl log test
2015-05-08T16:06:37.433196624Z value-1

Now reboot the server running the pod.  After reboot I see the following in the log output:
kubectl log test
2015-05-08T16:08:53.172253741Z cat: /etc/test-secret/data-1: No such file or directory

That seems to indicate to me that the pod is re-starting after the reboot but that it is unable to get the secret.  Note that after the reboot manually stopping ( kubectl stop pod test ) and re-starting the pod shows the expected results.
My expectation of the behavior is that if the server a pod is running on reboots that the pod will re-start with the same secret it had when it started previously.  If the secret had been updated since the pod had been originally started I would expect the original secret to be available.

I am out of office and won't get to this for a week or more.  Consider
reassignment.  Fyi @pmorie
On May 8, 2015 1:15 PM, "Abhi Shah"<EMAIL_ADDRESS>wrote:

Assigned #7958
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958 to
@erictune https://github.com/erictune.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#event-300583157
.

Are you running one node cluster here? We have an issue on re-joining a node back to cluster after reboot (#6949 and other related issues for detail).

I am experiencing the issue on a 3 node cluster.

I think I know the issue. The plugin writes a file that is used as a marker
to guarantee idempotency of setup. The marker file is written to the host's
disk while the secrets are written to tmpfs. I will work on a fix for this.
On Fri, May 8, 2015 at 4:31 PM asautins<EMAIL_ADDRESS>wrote:

I am experiencing the issue on a 3 node cluster.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-100353916
.

That's awesome.  Thank you.  Please let me know if you'd like me to run any
tests or provide any more data.
On Fri, May 8, 2015 at 6:10 PM, Paul Morie<EMAIL_ADDRESS>wrote:

I think I know the issue. The plugin writes a file that is used as a marker
to guarantee idempotency of setup. The marker file is written to the host's
disk while the secrets are written to tmpfs. I will work on a fix for this.
On Fri, May 8, 2015 at 4:31 PM asautins<EMAIL_ADDRESS>wrote:

I am experiencing the issue on a 3 node cluster.
—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-100353916

.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-100397066
.

@asautins will do
On Fri, May 8, 2015 at 8:18 PM asautins<EMAIL_ADDRESS>wrote:

That's awesome. Thank you. Please let me know if you'd like me to run any
tests or provide any more data.
On Fri, May 8, 2015 at 6:10 PM, Paul Morie<EMAIL_ADDRESS>wrote:

I think I know the issue. The plugin writes a file that is used as a
marker
to guarantee idempotency of setup. The marker file is written to the
host's
disk while the secrets are written to tmpfs. I will work on a fix for
this.
On Fri, May 8, 2015 at 4:31 PM asautins<EMAIL_ADDRESS>wrote:

I am experiencing the issue on a 3 node cluster.
—
Reply to this email directly or view it on GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-100353916

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-100397066
.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-100397592
.

@thockin @erictune I think there are two options here:

Make separate tmpfs mounts for the pod volume dirs and pod plugin dir for secret volumes.  The pod plugin dir is what stores the files that signify that a volume has been set up.
Make a single tmpfs mount for the pod, symlink the volume dirs and pod plugin dirs into this.

I'm leaning towards (1) because it's a lot simpler.  We can always do (2) later.
Thoughts?

option 3: make the check for ready be more than just a flag file - e.g.
test for a mountpoint and/or stat the secret file(s) ?
On Mon, May 11, 2015 at 9:32 AM, Paul Morie<EMAIL_ADDRESS>wrote:

@thockin https://github.com/thockin @erictune
https://github.com/erictune I think there are two options here:

Make separate tmpfs mounts for the pod volume dirs and pod plugin
dir for secret volumes. The pod plugin dir is what stores the files that
signify that a volume has been set up.
Make a single tmpfs mount for the pod, symlink the volume dirs and
pod plugin dirs into this.

I'm leaning towards (1) because it's a lot simpler. We can always do (2)
later.
Thoughts?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-100972563
.

that works @thockin

@pmorie - this is now affecting DNS, moved to P0.  Status?

@thockin i'll have a fix today.
On Wed, May 13, 2015 at 12:52 PM Tim Hockin<EMAIL_ADDRESS>wrote:

@pmorie https://github.com/pmorie - this is now affecting DNS, moved to
P0. Status?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-101744904
.

Quick naive question: we encountered this (as well) doing reboot e2e tests. The next e2e test we'll do is a full "blow away the nodes" test (delete each and recreate it). Will the secrete implementations (writing on the host's disk, to tmpfs) persist, or be expected to, after the node gets blown away and recreated?

@mbforbes If you delete a node and recreate it, the secrets volume plugin will set up everything again.

@thockin Is there an e2e I can use to repro this?

Tested  against #8191.  The above test case appears to have the secret mounted after reboot which is great.
One thing to note, however, is the following sequence of events:

Create secret with value 'a'.
create pod that mounts secret.  Validate it sees secret with value 'a'.
Change secret to value 'b'.
Verify pod has mounted secret of value and still has the value 'a' ( as is currently expected )
Reboot the server running the pod.
Pod now sees secret with value 'b'.

My question is, is the value seen in #6 the desired behavior?  My expectation would be that after reboot we would see the secret value that was created at the time the pod was launched ( in the above example secret value 'a' ).  In an ideal world I'd like the ability to specify the behavior of a secret ( i.e., pod-level configuration that lets me choose secret behavior during the lifetime of a pod in the event that it is moved, server is restarted, replicationController is resized, etc.  For example "latest" or "original" or something like that ).  However, I do think either behavior ( original secret or latest secret ) is reasonable as long as it is clearly documented.

Pragmatically, I don't think it's reasonable to keep the same secret value
for the life of the pod.  There has been debate about whether secrets
should auto-update when their value change in the API server.  I think it
is reasonable, but it's not implemented as such today.
On Thu, May 14, 2015 at 10:21 AM, asautins<EMAIL_ADDRESS>wrote:

Tested against #8191
https://github.com/GoogleCloudPlatform/kubernetes/pull/8191. The above
test case appears to have the secret mounted after reboot which is great.
One thing to note, however, is the following sequence of events:

Create secret with value 'a'.
create pod that mounts secret. Validate it sees secret with value
'a'.
Change secret to value 'b'.
Verify pod has mounted secret of value and still has the value 'a'
( as is currently expected )
Reboot the server running the pod.
Pod now sees secret with value 'b'.

My question is, is the value seen in #6
https://github.com/GoogleCloudPlatform/kubernetes/issues/6 the desired
behavior? My expectation would be that after reboot we would see the secret
value that was created at the time the pod was launched ( in the above
example secret value 'a' ). In an ideal world I'd like the ability to
specify the behavior of a secret ( i.e., pod-level configuration that lets
me choose secret behavior during the lifetime of a pod in the event that it
is moved, server is restarted, replicationController is resized, etc. For
example "latest" or "original" or something like that ). However, I do
think either behavior ( original secret or latest secret ) is reasonable as
long as it is clearly documented.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/7958#issuecomment-102107233
.

I think that it seems to make the most sense to use the latest secret value.  The main use case I can think of is to use secrets to deploy a database password, or some other runtime value that a containerized application needs.  The question I ask myself is: when would I change the value of such a secret?  The answer is: When I need to rotate the database credentials or change that setting.  It seems reasonable that a container restart alone should pick up the latest secret value when it starts up, such that the application has the most up to date settings it needs.  Thus, when a database password or setting needs changing, a rolling or normal container restart would have the desired behavior.

If you're talking about an auto-update of the value during the container runtime ... and if that is possible, I could see that as a valid behavior as well.  There are probably some pros and cons of either behavior, but I think that some method of getting the latest value into the container makes the most sense.

I'm fine with using the latest secret value, but I guess the question for me is when.  What I want is predictable behavior.  If the behavior I need to expect is that when a secret is updated that the pods are then immediately updated that could make sense.
What seems unexpected about the current behavior is if I have a replicationController with 3 pods and they are all running on different machines.  Let's assume I then change the secret and one of the servers reboots.  Now I have a replicationController with 3 pods, two with one secret and one with another.  Ideally as an operator of the system I'd be able to clearly define what secret the pods of a replicationController have at any given time ( i.e., they all see the first one or they all now see the new secret ).  But I think it's a little odd to say that if I have a new pod start in a replciationController ( either through a failed node or resizing the replicationController ) that it can start up differently than the other pods in the replicationController seems non-ideal.  But if it's clearly documented I'm sure it's workable.
Assuming you go the route of putting the latest secret in the container one operational thing that would be nice is to be able to get the specific version of a secret that is currently being used by a pod so an operator could tell if a new secret is now fully in rotation ( i.e., I've done a rolling restart to change to the new database password and all containers are complete ).


Fixed docstring formatting of :meth:.Scene.replace and improved its error handling

See title.

The rendered documentation now looks correct, and tests still pass. Merging!


Fix https://github.com/NixOS/nixpkgs/issues/117715

Motivation for this change
Fix https://github.com/NixOS/nixpkgs/issues/117715
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

This is really a placeholder

If you move the --without-x to the lib.optionalString stdenv.isDarwin-guarded string (a few lines below), is this still a placeholder/draft? It loooks OK to me.


Ask about https

Hello, I would like to know if the webconsole of free5gc is designed to use HTTPS. I couldn't find any related documentation and when I looked through the code, I didn't see any use of HTTPS modules.

Hi @mark6969
Currently we don't have a plan to support this feature.
But you can consider using reverse proxy to achieve your requirements, please see https://github.com/free5gc/free5gc-compose/issues/55 for more information.

Okay, I understand. Thank you.


apinger log messages even all gateways are disabled

This log message is flooded all the time:
opnsense: /getstats.php: The command '/bin/pkill -'USR1' -F '/var/run/apinger.pid'' returned exit code '1', the output was ''
I only have one gateway defined and disabled monitoring on that one. So there should not be any apinger monitoring a gateway.
Looks like I hay have found the issue. Here is what is called.
www/getstats.php -> www/includes/functions.inc.php:get_stats() -> get_gatewaystats()  ->   etc/inc/gwlb.inc:return_gateways_status()
return_gateways_status():
..
/* Always get the latest status from apinger */
killbypid("{$g['varrun_path']}/apinger.pid", 'USR1');
..
So it always tries to send a SIGUSR1 to a process with the pid listed in the old pid file of apinger even when there is no such process running. The pid file is not cleaned up when disabling apinger. I believe this could be an issue when that pid is reused by a process that maybe does something different when receiving a SIGUSR1.

Stale pid files are okay as long as the caller checks if the pid is valid. Will fix that, thanks!


Add missing source option

... so others can copy and paste the example 😉

Thanks @stefanbuck! Probably would be helpful to have a working example after changing the API :)
Also, as a note (if you're using the package), you can specify the path to the extension now, and we'll automatically zip it before upload. I'll add an example for that in a separate commit.


Callback transaction race conditions

It seems that save methods call _run_save_callbacks within the transaction, and the data may not have been written to the database by the time that a job is spawned and ran within another instance (such as resque).
You would expect that after_save callbacks would be fired after the the transaction has been completed.

Hi Josh,
I haven't used this project in ages so don't really have much motivation to
fix things. Have you been able to test and fix in a branch, or found
someone that did? Happy to pull if that's the case.
Cheers,
d.
On Tue, Nov 8, 2011 at 6:54 PM, Josh Martin <
<EMAIL_ADDRESS>
It seems that save methods call _run_save_callbacks within the
transaction, and the data may not have been written to the database by the
time that a job is spawned and ran within another instance (such as resque).
You would expect that after_save callbacks would be fired after the the
transaction has been completed.

Reply to this email directly or view it on GitHub:
https://github.com/jamesgolick/active_presenter/issues/4

I'm looking in to the issue as it is introducing race conditions in a production environment.  I should have a fix for it sometime this week.


Make sure correct license is specified in metadata

While the project license file indicates that it is licensed under the PostgreSQL license, some metadata in the project specifies a difference license is used (Apache-2.0 or MIT).
This has some effect on how pgmq is shown on sites like crates.io which says it is licensed under Apache-2.0 for example.
Here are the places I found where I think the license needs to be updated:

https://github.com/tembo-io/pgmq/blob/41f953c754c23d1f17e677c71ad49fe995f15d4f/pgmq-rs/README.md?plain=1#L164
https://github.com/tembo-io/pgmq/blob/41f953c754c23d1f17e677c71ad49fe995f15d4f/pgmq-rs/Cargo.toml#L10
https://github.com/tembo-io/pgmq/blob/41f953c754c23d1f17e677c71ad49fe995f15d4f/tembo-pgmq-python/pyproject.toml#L6
https://github.com/tembo-io/pgmq/blob/41f953c754c23d1f17e677c71ad49fe995f15d4f/integration_test/Cargo.toml#L8

Thanks @brianpursley - at one point (maybe still true) crates.io was throwing an error when we tried publishes those client libraries with "PostgreSQL" as the license value. I don't recall what happened with pypi.org (python lib). Maybe that all has changed though or I am just completely mistaken. I agree though, makes sense to update them all to PostgreSQL.

Ah ok.  No big deal, I was just looking at pgmq as an example for another extension I'm working on and noticed the difference so thought I would mention it


Switching buffers cause window to scroll

Duplicate of the auto-closed #2477.
When I switch from buffer A to buffer B and then back again, the cursor line in A is scrolled to the center of the window. This is confusing. I would like the window to display the buffer exactly as it was displayed before. I think this is the expected behavior.

When I follow a hotlink in the help to a different helpfile, and then use Ctrl-O to come back, the cursor line (if not near the top or bottom of the file) is now centered. AFAICR it's always been like that. But if you set 'scrolloff' to a large value, Vim will always keep the cursor centered (scrolling the file as needed) and going to another buffer and back will bring you just as centered as you already were.
Best regards,
Tony.

Hi Tonymec.
Once one jumps to another position in the same buffer, he knows the buffer will scroll, that's quite inevitable, so there is not much expectation to have the very same position when coming back (though it would be admitedly cool). But when switching buffers, it is actually surprising behavior.  Note how other editors and web browsers won't scroll if you change tabs.

On 2021-03-12, DieSpinne wrote:

Hi Tonymec.
Once one jumps to another position in the same buffer, he knows the buffer will
scroll, that's quite inevitable, so there is not much expectation to have the
very same position when coming back (though it would be admitedly cool). But
when switching buffers, it is actually surprising behavior. Note how other
editors and web browsers won't scroll if you change tabs.

Vim retains the cursor position and the view of a window when
changing windows in a tab or when changing tabs.  You're not
changing windows or tabs, you're changing buffers in one window.
The view into a buffer is not a property of the buffer, it is
a property of the window.  You can view a buffer in more than one
window and each window can have its own view, including its own
position in the buffer and its own cursor location.
See
:help windows-intro

for a little on this.
Regards,
Gary

Thanks Gary, I follow you there. I have recently switched from the tab-centered to the buffer-centered approach to Vim and went through those clarifications, sorry if I still slip on some details.
If one understands Vim fundamentals, it is indeed a bit naive to assume the behavior I'm requesting when switching buffers. But I don't think there is much dispute on that leaving the viewport in place (or, rather, restoring it to the original offset) is the expected thing to happen when returning to a buffer, as one has to reorient himself otherwise.
In my opinion, this is another potential reason why novice users may fall to the one file = one tab trap. They observe the behavior they expect on tabs, so they stick to them. I think this proposal would be a nice addition, but I don't want to be pressing here, I'm just trying to make my point clear.

On 2021-03-12, DieSpinne wrote:

Thanks Gary, I follow you there. I have recently switched from the tab-centered
to the buffer-centered approach to Vim and went through those clarifications,
sorry if I still slip on some details.
If one understands Vim fundamentals, it is indeed a bit naive to assume the
behavior I'm requesting when switching buffers. But I don't think there is much
dispute on that leaving the viewport in place (or, rather, restoring it to the
original offset) is the expected thing to happen when returning to a buffer, as
one has to reorient himself otherwise.
In my opinion, this is another potential reason why novice users may fall to
the one file = one tab trap. They observe the behavior they expect on tabs, so
they stick to them. I think this proposal would be a nice addition, but I don't
want to be pressing here, I'm just trying to make my point clear.

It's interesting how different people use Vim so differently.
I hardly ever use any of the buffer commands and am only starting to
use tabs more regularly.  I usually keep all the buffers I'm using
open in different windows, in different horizontal and vertical
splits.  I've also used the Rolodex technique.  I usually have Vim
occupying a full monitor, so I have plenty of space for windows.
I also use quickfix lists to jump among files in a single window,
but I don't edit more than one of those files at a time, so the
repositioning of the view into the file as I jump in the quickfix
list has never bothered me.
As I understand your issue, you'd like buffers to remember how they
were last viewed.  The problem, of course, is that each buffer can
be viewed in multiple windows so the way they were last viewed
depends on the window in which they're being re-opened.
So perhaps you could create a window-local variable as a list of
dictionaries, one dictionary for each buffer opened in that window,
with each dictionary containing the top line and the cursor line of
the buffer when last viewed in that window.  A set of autocommands
could manage that list and restore a buffer's view when re-opened in
that window.
Alternatively, you could create a couple of buffer-local variables
containing the top line and cursor line of the last window to view
that buffer.  Then whenever a buffer is re-opened in a window, it is
displayed as it was last viewed.  If the user is using only one or
a few windows, and never views a buffer in more than one window at
a time, this should work fine.  Again, this would all be managed
with a few autocommands.
Assuming that all works and meets your expectations, the problem
becomes how to make novice users aware of the plugin.
Just some thoughts.
Regards,
Gary

Duplicate of the auto-closed #2477.
When I switch from buffer A to buffer B and then back again, the cursor line in A is scrolled to the center of the window. This is confusing. I would like the window to display the buffer exactly as it was displayed before. I think this is the expected behavior.

This view reposition is annoying to me too. In the meantime you may try https://vim.fandom.com/wiki/Avoid_scrolling_when_switch_buffers


[WIP] Convert progress bar metrics to float

What does this PR do?
Fixes #5481
Will probably include some refactors. Opening this PR to run tests
TODO:

Separate train/val/test metrics
callback_metrics should copy the data as is, not as a reference from progress_bar_metrics. This way, each MetricHolder is free to make their own conversions without affecting other parts.

Before submitting

[x] Was this discussed/approved via a GitHub issue? (not for typos and docs)
[x] Did you read the contributor guideline, Pull Request section?
[ ] Did you make sure your PR does only one thing, instead of bundling different changes together?
[ ] Did you make sure to update the documentation with your changes? (if necessary)
[x] Did you write any new necessary tests? (not for typos and docs)
[ ] Did you verify new and existing tests pass locally with your changes?
[ ] Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review
Anyone in the community is free to review the PR once the tests have passed.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

[ ] Is this pull request ready for review? (if not, please submit in draft mode)
[ ] Check that all items from Before submitting are resolved
[x] Make sure the title is self-explanatory and the description concisely explains the PR
[ ] Add labels and milestones (and optionally projects) to the PR so it can be classified
[ ] Check that target branch and milestone match!

@carmocca is it still WIP or ready to go? :]

@carmocca is it still WIP or ready to go? :]

So I planned to include a larger refactor here. I think i'll commit the one-line fix to master and work on the refactor here.

So I planned to include a larger refactor here. I think i'll commit the one-line fix to master and work on the refactor here.

So I planned to include a larger refactor here. I think i'll commit the one-line fix to master and work on the refactor here.

I would rather have multiple smaller refactors, it is easier to review :]

So I planned to include a larger refactor here. I think i'll commit the one-line fix to master and work on the refactor here.

I would rather have multiple smaller refactors, it is easier to review :]

Just one request: could we move the test to the logging tests? Because the conversion doesn't happen in the progress bar therefore I propose to move this test outside the progress bar unit tests.

I disagree. The purpose of the test is to check that the progress bar correctly displays the number as a float, not a tensor. The fact that the fix is in the logger connector is independent to what we want to fix. If the logger connector was completely replaced by a different abstraction, I still want to make sure the progress bar does not change.


Fix WSL2 check

On my WSL2 installation, /proc/version prints out Linux version 5.4.72-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Oct 28 23:40:43 UTC 2020, so i made grep case-insensitive, to be able to correctly identify my machine being a WSL machine

Sounds good. Thanks for this fix @marcovannoord


[feature suggestion | rpz] local source zone

A look at the current RPZ ecosystem https://dnsrpz.info and search for free public RPZ feed provider is rather sobering. Ideally I would wish unbound for being capable to convert feeds from various sources into a RPZ  and automatically maintains/updates them, something like https://github.com/Homas/ioc2rpz does.
Short of that it would be at least helpful if unbound could leverage local RPZ files that would not need to be served through either a http server or an authoritative zone server. stub-zone: or local-zone would not seem suitable for providing a local RPZ, or would either one?
Also it would likely be easier to convert sources feeds to an RPZ file rather than converting into stub-zone: or local-zone and to dynamically update such zones after each feed conversion.

Ideally I would wish unbound for being capable to convert feeds from various sources into a RPZ and automatically maintains/updates them, something like https://github.com/Homas/ioc2rpz does.

I don't think we should add this to Unbound. The de facto standard for loading filtering policies into DNS resolvers is RPZ. In case your policy provider does not provide the information in RPZ format it makes more sense to me to have the conversion done using an external tool, like the one you mentioned. In that case, not all different resolver implementations have to support the endless number of possible formats.

Short of that it would be at least helpful if unbound could leverage local RPZ files that would not need to be served through either a http server or an authoritative zone server. stub-zone: or local-zone would not seem suitable for providing a local RPZ, or would either one?

Unbound's RPZ implementation can already load the zones from a local file, using its zonefile configuration option.

Unbound's RPZ implementation can already load the zones from a local file, using its zonefile configuration option.

I was not aware of that, apparently, reading from documentation

If  the  file  does not exist or is empty, unbound will attempt to fetch zone data  (eg.  from  the  master servers).

been under the impression that only fetched zone data (master | url) could be leveraged.


[Revise subclass] Parkinson disease

Mondo term (ID and Label)
Parkinson disease
-- should not be inborn errors of metabolism
-- should not be inherited neurodegeneration (not all cases are inherited)
-- I am not sure if all cases are synucleinopathy
@ahamosh  thoughts as to how to group inherited vs other Parkinson?
Suggested revision and reasons
Your nano-attribution (ORCID)
If you don't have an ORCID, you can sign up for one here

I removed synucleinopathy as a superclass and the other inferred superclasses went away.

I think the action item on this ticket is to review the classification of Parkinson disease. The issues above have been addressed.


[improve][pulsar-functions] Make Pulsar Admin Client accessible in source and sink functions

Motivation
Currently Pulsar functions using Context have access to PulsarAdmin client instance. By moving the getPulsarAdmin method from Context to the parent interface BaseContext we can provide the same access to source and sink functions as well. This would provide sources and sinks access to topic stats in order for them to make decisions with regards to scale and load handling, throttling, etc.
Modifications
The getPulsarAdmin method from Context to the parent interface BaseContext.
Verifying this change

[ ] Make sure that the change passes the CI checks.

This change is already covered by existing tests, such as ContextImplTest.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API: no
The schema: no
The default values of configurations: no
The wire protocol: no
The rest endpoints: no
The admin cli options: no
Anything that affects deployment: no

Documentation
Check the box below or label this PR directly.
Need to update docs?

[x] no-need-doc
The method already has Javadoc

Closed as stale. Please rebase and resubmit the patch if it's still relevant.


fix: CE-800 Do not default officer/date on outcome

Description
Please provide a summary of the change and the issue fixed. Please include relevant context. List dependency changes.
Fixes CE-800
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Assign Complain, Add Animal - Outcome Officer/Date not populated
[ ] Edit Added Animal - Outcome Officer/Date not populated

Note: This PR also fixes an unreported bug that after an outcome edit, validation messages aren't visible.
Checklist

[ ] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes

Further comments

Thanks for the PR!
Any successful deployments (not always required) will be available below.
Backend available
Frontend available
Once merged, code will be promoted and handed off to following workflow run.
Main Merge Workflow

Duplication warning on pre-existing code.


API doc: not correct display of the implemented interfaces

The ColumnCopier doc displays implemented interfaces the following way:

Note the difference:

The code snippet shows that two interfaces are implemented: Microsoft.ML.ILearningPipelineItem and  Microsoft.ML.Runtime.EntryPoints.CommonInputs.ITransformInput
The Implements section has two duplicate entries both referencing to the same page of the ILearningPipelineItem.

It looks correct in the XML:
  <Interfaces>
    <Interface>
      <InterfaceName>Microsoft.ML.ILearningPipelineItem</InterfaceName>
    </Interface>
    <Interface>
      <InterfaceName>Microsoft.ML.Runtime.EntryPoints.CommonInputs+ITransformInput</InterfaceName>
    </Interface>
  </Interfaces>

I think there could be two things that are confusing the system:

ITransformInput doesn't seem to be in the part of ML.NET that's included in API reference.
ITransformInput is nested in the CommonInputs class.

@GalOshri - any insight? Thanks!

Seems like this would also be a question to @dend and @TianqiZhang given the ECMAXML has the right information.

I found a similar page to that one above and I think this doesn't repro anymore? Although that class is no longer nested so not sure if this is the best repro.
https://docs.microsoft.com/en-us/dotnet/api/microsoft.ml.legacy.transforms.nooperation?view=ml-dotnet

I'm closing this one. If you find a new repro, please let us know @pkulikov!


Sorted README by module name

#660 Sorted README.md by module name, No any other changes

:+1:

Closed in #3d7996e -- thanks for the PR!


bedrock init error 66 :  Decompression error : ERROR_contentChecksum_invalid

I want to run a fullnode by docker, but the logs in bedrock-init shows snapshot checksum invalid.

simple-optimism-node-bedrock-init-1  | gid   |stat|avg speed  |path/URI
simple-optimism-node-bedrock-init-1  | ======+====+===========+=======================================================
simple-optimism-node-bedrock-init-1  | dfae37|OK  |   106MiB/s|//downloads/bedrock.tar.lz4
simple-optimism-node-bedrock-init-1  |
simple-optimism-node-bedrock-init-1  | Status Legend:
simple-optimism-node-bedrock-init-1  | (OK):download completed.
simple-optimism-node-bedrock-init-1  | Extracting bedrock.tar...
simple-optimism-node-bedrock-init-1  | Error 66 : Decompression error : ERROR_contentChecksum_invalid
simple-optimism-node-bedrock-init-1  | tar: Child returned status 66
simple-optimism-node-bedrock-init-1  | tar: Error is not recoverable: exiting now

This is a bug in lz4 that's installed by apt. Will try to fix it
pierrec/lz4#27

Can I fix it manually? Thank you

You can manually stop docker compose (docker compose down), extract bedrock.tar.lz4 in the docker volume folder and then start docker again (docker compose up -d)
cd to docker volume directory as root
cd /var/lib/docker/volumes/simple-optimism-node_torrent_downloads/_data

(Path may differ if not using Ubuntu)
And extract bedrock.tar.lz4 to /var/lib/docker/volumes/simple-optimism-node_op_geth/_data (Different volume)

You can manually stop docker compose (docker compose down), extract bedrock.tar.lz4 in the docker volume folder and then start docker again (docker compose up -d)
cd to docker volume directory as root
cd /var/lib/docker/volumes/simple-optimism-node_torrent_downloads/_data

(Path may differ if not using Ubuntu)
And extract bedrock.tar.lz4 to /var/lib/docker/volumes/simple-optimism-node_op_geth/_data (Different volume)

After extracting the data and rerun the docker containers, bedrock-init download the file again.

I assume it tries to download again because the bedrock-init checks for the existence of a /shared/initialized.txt file which is only created after the script has completed.
The check is made here while the file is created here.
So maybe try to create a /shared/initialized.txt file in the volume and run again?
cc @BoogalooLi @Chomtana

Yes as @0xpanoramix said create an initialized.txt file in /var/lib/docker/volumes/simple-optimism-node_shared/_data.
touch /var/lib/docker/volumes/simple-optimism-node_shared/_data/initialized.txt

Thanks a lot. I'll try it. Thanks.


GHA gui tests segfault

running the gui tests on GHA results in segfaults:
not clear exactly why, similar setup to travis (ubuntu, jwm, xvnc), but clearly some relevant difference..
2020-12-01T13:44:29.1432154Z + ./test/tests -as '[mainwindow][gui]'
2020-12-01T13:44:29.3825074Z Using O_TMPFILE
2020-12-01T13:44:29.4500190Z Using O_TMPFILE
2020-12-01T13:44:29.7439258Z + tail -n 100 gui-mainwindow.txt
2020-12-01T13:44:29.7440159Z QPainter::save: Painter not active
2020-12-01T13:44:29.7441230Z QPainter::setPen: Painter not active
2020-12-01T13:44:29.7442443Z QPainter::setPen: Painter not active
2020-12-01T13:44:29.7443215Z QPainter::setPen: Painter not active
2020-12-01T13:44:29.7444394Z QPainter::drawRects: Painter not active
2020-12-01T13:44:29.7445325Z QPainter::setPen: Painter not active
2020-12-01T13:44:29.7446120Z QPainter::drawRects: Painter not active
2020-12-01T13:44:29.7446938Z QPainter::restore: Unbalanced save/restore
2020-12-01T13:44:29.7463120Z + llvm-cov gcov -p src/core/CMakeFiles/core.dir/common/src/logger.cpp.gcno src/core/CMakeFiles/core.dir/common/src/symbolic.cpp.gcno src/core/CMakeFiles/core.dir/common/src/tiff.cpp.gcno src/core/CMakeFiles/core.dir/common/src/utils.cpp.gcno src/core/CMakeFiles/core.dir/common/src/version.cpp.gcno src/core/CMakeFiles/core.dir/mesh/src/boundary.cpp.gcno src/core/CMakeFiles/core.dir/mesh/src/contour_map.cpp.gcno src/core/CMakeFiles/core.dir/mesh/src/contours.cpp.gcno src/core/CMakeFiles/core.dir/mesh/src/image_boundaries.cpp.gcno src/core/CMakeFiles/core.dir/mesh/src/line_simplifier.cpp.gcno src/core/CMakeFiles/core.dir/mesh/src/mesh.cpp.gcno src/core/CMakeFiles/core.dir/mesh/src/triangulate.cpp.gcno src/core/CMakeFiles/core.dir/model/src/geometry_analytic.cpp.gcno src/core/CMakeFiles/core.dir/model/src/geometry.cpp.gcno src/core/CMakeFiles/core.dir/model/src/geometry_parametric.cpp.gcno src/core/CMakeFiles/core.dir/model/src/geometry_sampled_field.cpp.gcno src/core/CMakeFiles/core.dir/model/src/id.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_compartments.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_functions.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_geometry.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_math.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_membranes.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_membranes_util.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_parameters.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_reactions.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_species.cpp.gcno src/core/CMakeFiles/core.dir/model/src/model_units.cpp.gcno src/core/CMakeFiles/core.dir/model/src/sbml_math.cpp.gcno src/core/CMakeFiles/core.dir/model/src/sbml_utils.cpp.gcno src/core/CMakeFiles/core.dir/model/src/validation.cpp.gcno src/core/CMakeFiles/core.dir/model/src/xml_annotation.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/basesim.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/duneconverter.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/duneconverter_impl.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/dunefunction.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/dunegrid.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/duneini.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/dunesim.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/dunesim_impl_coupled.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/dunesim_impl.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/dunesim_impl_independent.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/pde.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/pixelsim.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/pixelsim_impl.cpp.gcno src/core/CMakeFiles/core.dir/simulate/src/simulate.cpp.gcno
2020-12-01T13:44:29.7476574Z QWidget::paintEngine: Should no longer be called
2020-12-01T13:44:29.7477655Z QPainter::begin: Paint device returned engine == 0, type: 1
2020-12-01T13:44:29.7479459Z QWidget::paintEngine: Should no longer be called
2020-12-01T13:44:29.7480423Z QPainter::begin: Paint device returned engine == 0, type: 1
2020-12-01T13:44:29.7481269Z QWidget::paintEngine: Should no longer be called
2020-12-01T13:44:29.7482078Z QPainter::begin: Paint device returned engine == 0, type: 1
2020-12-01T13:44:29.7482837Z QPainter::save: Painter not active
2020-12-01T13:44:29.7484288Z -------------------------------------------------------------------------------
2020-12-01T13:44:29.7484990Z Mainwindow
2020-12-01T13:44:29.7485503Z   shortcut keys
2020-12-01T13:44:29.7486432Z -------------------------------------------------------------------------------
2020-12-01T13:44:29.7488458Z /home/runner/work/spatial-model-editor/spatial-model-editor/src/gui/mainwindow_t.cpp:31
2020-12-01T13:44:29.7489468Z ...............................................................................
2020-12-01T13:44:29.7489853Z
2020-12-01T13:44:29.7491019Z /home/runner/work/spatial-model-editor/spatial-model-editor/src/gui/mainwindow_t.cpp:31: FAILED:
2020-12-01T13:44:29.7495528Z due to a fatal error condition:
2020-12-01T13:44:29.7496348Z   SIGSEGV - Segmentation violation signal
2020-12-01T13:44:29.7496747Z
2020-12-01T13:44:29.7497122Z ===============================================================================
2020-12-01T13:44:29.7497548Z test cases: 1 | 1 failed
2020-12-01T13:44:29.7498101Z assertions: 2 | 1 passed | 1 failed
2020-12-01T13:44:29.7573139Z
2020-12-01T13:44:29.7573682Z AddressSanitizer:DEADLYSIGNAL
2020-12-01T13:44:29.7574207Z =================================================================
2020-12-01T13:44:29.7575702Z ==19040==ERROR: AddressSanitizer: SEGV on unknown address 0x03e900004a60 (pc 0x000005c0b385 bp 0x000000000270 sp 0x7fff217835f0 T0)
2020-12-01T13:44:29.7576559Z ==19040==The signal is caused by a READ memory access.
2020-12-01T13:44:29.7579369Z     #0 0x5c0b384 in qDrawBorderPixmap(QPainter*, QRect const&, QMargins const&, QPixmap const&, QRect const&, QMargins const&, QTileRules const&, QFlags<QDrawBorderPixmap::DrawingHint>) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5c0b384)
2020-12-01T13:44:29.7582442Z     #1 0x5c28ed5 in QFusionStyle::drawPrimitive(QStyle::PrimitiveElement, QStyleOption const*, QPainter*, QWidget const*) const (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5c28ed5)
2020-12-01T13:44:29.7586716Z     #2 0x5c2e982 in QFusionStyle::drawComplexControl(QStyle::ComplexControl, QStyleOptionComplex const*, QPainter*, QWidget const*) const (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5c2e982)
2020-12-01T13:44:29.7589289Z     #3 0x5c65900 in QGroupBox::paintEvent(QPaintEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5c65900)
2020-12-01T13:44:29.7591288Z     #4 0x5b86b07 in QWidget::event(QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b86b07)
2020-12-01T13:44:29.7593257Z     #5 0x5c66b84 in QGroupBox::event(QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5c66b84)
2020-12-01T13:44:29.7595560Z     #6 0x5b4dcee in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b4dcee)
2020-12-01T13:44:29.7597772Z     #7 0x5b57d2f in QApplication::notify(QObject*, QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b57d2f)
2020-12-01T13:44:29.7600050Z     #8 0x9671c17 in QCoreApplication::sendSpontaneousEvent(QObject*, QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x9671c17)
2020-12-01T13:44:29.7602396Z     #9 0x5b7e800 in QWidgetPrivate::sendPaintEvent(QRegion const&) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7e800)
2020-12-01T13:44:29.7606330Z     #10 0x5b7f612 in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7f612)
2020-12-01T13:44:29.7610113Z     #11 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7615543Z     #12 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7619385Z     #13 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7645629Z     #14 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7649578Z     #15 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7653139Z     #16 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7656755Z     #17 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7661367Z     #18 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7664971Z     #19 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7668515Z     #20 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7672101Z     #21 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7678177Z     #22 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7682129Z     #23 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7728239Z     #24 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7732531Z     #25 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7737446Z     #26 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7741131Z     #27 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7744729Z     #28 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7748363Z     #29 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7751931Z     #30 0x5b802d2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b802d2)
2020-12-01T13:44:29.7755724Z     #31 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7759498Z     #32 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7763266Z     #33 0x5b801b5 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, QList<QObject*> const&, int, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b801b5)
2020-12-01T13:44:29.7769287Z     #34 0x5b7ee2b in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion const&, QPoint const&, QFlags<QWidgetPrivate::DrawWidgetFlag>, QPainter*, QWidgetRepaintManager*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b7ee2b)
2020-12-01T13:44:29.7772110Z     #35 0x5b8c826 in QWidgetRepaintManager::paintAndFlush() (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b8c826)
2020-12-01T13:44:29.7774459Z     #36 0x5b8d0eb in QWidgetRepaintManager::sync(QWidget*, QRegion const&) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b8d0eb)
2020-12-01T13:44:29.7777871Z     #37 0x5bac603 in QWidgetWindow::handleExposeEvent(QExposeEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5bac603)
2020-12-01T13:44:29.7781018Z     #38 0x5bad00f in QWidgetWindow::event(QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5bad00f)
2020-12-01T13:44:29.7783282Z     #39 0x5b4dcee in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b4dcee)
2020-12-01T13:44:29.7786577Z     #40 0x5b57d2f in QApplication::notify(QObject*, QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5b57d2f)
2020-12-01T13:44:29.7789310Z     #41 0x9671c17 in QCoreApplication::sendSpontaneousEvent(QObject*, QEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x9671c17)
2020-12-01T13:44:29.7792307Z     #42 0x8f9377e in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x8f9377e)
2020-12-01T13:44:29.7796527Z     #43 0x8f939d8 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x8f939d8)
2020-12-01T13:44:29.7801057Z     #44 0x8f70da3 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x8f70da3)
2020-12-01T13:44:29.7803514Z     #45 0x9385009 in xcbSourceDispatch(_GSource*, int (*)(void*), void*) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x9385009)
2020-12-01T13:44:29.7805252Z     #46 0x7f2d33f77196 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4a196)
2020-12-01T13:44:29.7806396Z     #47 0x7f2d33f773ef  (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4a3ef)
2020-12-01T13:44:29.7807561Z     #48 0x7f2d33f7749b in g_main_context_iteration (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4a49b)
2020-12-01T13:44:29.7811886Z     #49 0x96ceac0 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x96ceac0)
2020-12-01T13:44:29.7818208Z     #50 0x8fd8656 in bool QTest::qWaitFor<QTest::qWaitForWindowExposed(QWindow*, int)::'lambda'()>(QTest::qWaitForWindowExposed(QWindow*, int)::'lambda'(), int) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x8fd8656)
2020-12-01T13:44:29.7822046Z     #51 0x8fd8a82 in QTest::qWaitForWindowExposed(QWindow*, int) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x8fd8a82)
2020-12-01T13:44:29.7823989Z     #52 0x4e75ab2 in waitFor(QWidget*) /home/runner/work/spatial-model-editor/spatial-model-editor/test/test_utils/qt_test_utils.cpp:16:8
2020-12-01T13:44:29.7825692Z     #53 0x549861f in ____C_A_T_C_H____T_E_S_T____0() /home/runner/work/spatial-model-editor/spatial-model-editor/src/gui/mainwindow_t.cpp:40:5
2020-12-01T13:44:29.7828235Z     #54 0x5f041ce in Catch::RunContext::runCurrentTest(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5f041ce)
2020-12-01T13:44:29.7830840Z     #55 0x5f04461 in Catch::RunContext::runTest(Catch::TestCaseHandle const&) (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5f04461)
2020-12-01T13:44:29.7832939Z     #56 0x5f0af12 in Catch::Session::runInternal() (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5f0af12)
2020-12-01T13:44:29.7835077Z     #57 0x5f0b3bd in Catch::Session::run() (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x5f0b3bd)
2020-12-01T13:44:29.7836376Z     #58 0x36866cb in int Catch::Session::run<char>(int, char const* const*) /opt/smelibs/include/catch2/catch_session.hpp:41:30
2020-12-01T13:44:29.7838313Z     #59 0x36854d1 in main /home/runner/work/spatial-model-editor/spatial-model-editor/test/main.cpp:26:33
2020-12-01T13:44:29.7839732Z     #60 0x7f2d3358883f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f)
2020-12-01T13:44:29.7842438Z     #61 0x35d6028 in _start (/home/runner/work/spatial-model-editor/spatial-model-editor/build/test/tests+0x35d6028)
2020-12-01T13:44:29.7843375Z

resolved by adding -screen 0 1280x800x24 to the Xvfb call - apparently the default screen resolution / color-depth is not supported by qt


Custom Copiers #8 of 8: Changes and Tests for MockSupportPlugin

in order to support copiers to copy non-native types.
Attempt to break up the work by @jgonzalezdr and myself (#676 and #675) into smaller, more manageable chunks.
This is the last PR for custom copiers. At this point, there should be no difference to #676.

Closing these PRs as they are no longer needed.


Add requestOptions to OpenAI provider HTTP calls

Validations

[x] I believe this is a way to improve. I'll try to join the Continue Discord for questions
[x] I'm not able to find an open issue that requests the same enhancement

Problem
Hi guys!
Thanks for your awesome tool! I'm currently using a custom vLLM endpoint with basic auth in front of it and I'm using the OpenAI provider.
It seems the requestOptions configuration is not injected in this provider (in fact, it's only used in the LlamaCpp provider). This prevents from injecting custom headers inside each request performed against the LLM endpoint in case you are using the OpenAI provider.
Solution
Add the requestOptions in the OpenAI provider fetches (or maybe make it even more generic in every provider?)

@64q we do in fact use requestOptions for all LLM providers by injecting the same fetch to all of them (code here ).
I'm wondering if you're seeing this problem because you're trying to add an Authorization header? This will be overridden by the apiKey property, which translates into "Authorization": "Bearer xxx". I believe LlamaCpp may just be the only one which doesn't use the apiKey property, which is why it seemed to work. More information here: https://continue.dev/docs/model-setup/configuration#authentication

this does bring up a good point though that we probably ought to have the custom headers override apiKey, rather than the other way around!

@64q we do in fact use requestOptions for all LLM providers by injecting the same fetch to all of them (code here ).
I'm wondering if you're seeing this problem because you're trying to add an Authorization header? This will be overridden by the apiKey property, which translates into "Authorization": "Bearer xxx". I believe LlamaCpp may just be the only one which doesn't use the apiKey property, which is why it seemed to work. More information here: https://continue.dev/docs/model-setup/configuration#authentication

You are completely right, I'm adding an Authorization header and the OpenAI provider seems to override the header with the Bearer one, even if I've a custom Authorization header already declared in my config file.
Thank you for your quick answer!

this does bring up a good point though that we probably ought to have the custom headers override apiKey, rather than the other way around!

If you have any idea whether you will address this issue, please do not hesitate to let me know. 🤗

@64q This has now been addressed in a recent commit! https://github.com/continuedev/continue/commit/e150f7d26fb076bcdfb1832013ecbff2b93b060d


⚠ Bofrost.lu has degraded performance

In 8bd4a07, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2208 ms

Resolved: Bofrost.lu performance has improved in 38734cc after 6 minutes.


Change Incidents to have just one location

For now, Frederic said to just worry about Incidents with one location. The way we implemented multi-location Incidents may not be how he wants it (seems like he's not totally sure yet) because he may want different descriptions, etc on each location. He way just want it so that he can group existing Incidents into a single entity, which we would handle differently.

Done


.return is available in cases where it shouldn't

void Bar()
{
  this.return{caret}
}

Fixed in upcoming 2.2


Use the one true format for CHANGELOGs

Note! this PR goes to #1019 - this should be merged first.

:+1:


docs: easy to read

Oh grand day! Thank you kindly for the PR, I shall approve the README updates and get these merged in! :smile: :bow:


fix: Replace default IDs for forked application with destination resource IDs

Description

When the application is forked to destination organization, default resource IDs are not getting updated as per new application

Fixes #9873
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

JUnit TC
Manual Test

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/ok-to-test sha=994c630


Implement getObservedResourceCondition function

Description of your changes
Adds new function to make it easier to access the conditions of observed resources. With that function, you can check a status in a one line if condition, making the code much more visible.
Previously:
{{ $networkStatus := "Unknown" }}
{{ if .observed.resources }}
  {{- with (index .observed.resources "network").resource.status.conditions }}
    {{ range . }}
      {{ if eq .type "Ready" }}
        {{ $networkStatus = .status }}
      {{ end }}
    {{ end }}
  {{ end }}
{{ end }}

Now:
{{ $networkStatus := (getObservedResourceCondition . "network" "Ready").Status }}

Fixes #19
I have:

[x] Read and followed Crossplane's contribution process.
[x] Added or updated unit tests for my change.(Examples for crossplane beta render)

@ezgidemirel @phisco Hi, it seems i'm not able to request  a review using GitHub (missing permissions?) so please consider this PR as ready to be reviewed :-)

Thanks @jan-di! FYI: we usually already consider non-draft PRs as "ready for review" 😉

@phisco  Updated the function:

Now it takes a resource as input, and therefore is compatible with composed and the composite resource
Switched order of parameters, to support pipelining the function, as it feels more natural
Added a few more usage examples in the example files


Non-deterministic molecular orbitals in DHF/RHF with multiple threads

Dear PYSCF Community,
running some DHF calculations I notice that molecular orbitals (mo_coeff) are non-deterministic if more cores are used. They do not just differ by a phase (sign) but they actually vary by several order of magnitude in absolute value between two subsequent runs.
The problem doesn't appear if only 1 thread is used (OMP_NUM_THREADS=1).
The energy on the other hand is stable to the right value.
Below you find the input to reproduce the error:
mol = gto.Mole()
mol.build(
atom = 'H 0 0 0; H 0 0 0.9',  # in Angstrom
verbose = 1,
basis = 'cc-pvdz,
#charge = -1,
#spin = 1,
#symmetry = True,
)
mf = mol.DHF()
mf.kernel()
print (np.sum(abs(mf.mo_coeff)))
print (mf.e_tot)
The problem can be observed to a minor extent also for standard RHF calculations.
Any idea why this behaviour could be happening?
I thank you in advance for your reply.
Bests
Enrico

Are there degenerate MOs? If so, any linear combination of degenerate MOs is possible.

Thank Tim for the super quick reply,
your point makes a lot of sense and in fact for the test case I sent there are several MOs that are doubly degenerate.
What is surprising me is that it only happens in multi-threads calculation. In principle your argument is valid also for 1 core calculations.
Do you have any idea for this?
Bests
Enrico

My unsophisticated explanation is just that multithreading is one extra degree of non-determinism. Beyond this, I think it's hard to say anything concrete about the origin.

Floating point maths is non-commutative, so the order of operations changes the floating point error. Without multithreading the operations are done in the same order, but with multithreading the order of operations depends on the state of the machine etc., so the order of operations in multithreaded calculations is not guaranteed to be the same each time.


docs Fix typos.

Delete unnecessary \n
Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

Hi Waterkin, thanks for your contribution.
Since 2024-03-18, the Document has been moved to doris-website. If you still have problems using the document, please submit your commits to the new repository and we will handle them ASAP.


新しいMacのセットアップ

[ ] Request form
[ ] Fix title
[ ] Ask in Slack
[ ] JIRA issued
[ ] Prepare with the organizer
[ ] Setting the goal
[ ] Slides
[ ] Movies preparation
[ ] The day!
[ ] PDF release in SlideShare
[ ] Publish the movie
[ ] Subtitle to the movide
[ ] Publish the blog

Details of request

朝8:00-予定


fix: add transferOwnership() to proxy abi list

Description
This adds the abi definition for _transferOwnership(address) next to the other common proxy functions under PROXY_ABI, as we ran into an issue decoding a call on a proxy contract as part of CGP156
Other changes
N/A
Tested
Tested that the _transferOwnership() calls under CGP156 json can be decoded

PR-Codex overview
This PR focuses on adding the transferOwnership() function to the proxy ABI list in the @celo/contractkit package.
Detailed summary

Added TRANSFER_OWNERSHIP_ABI definition with parameters for newOwner of type address.
Included TRANSFER_OWNERSHIP_ABI in the PROXY_ABI array.
Updated the patch information in the .changeset/dirty-crabs-trade.md file.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

isnt _transferOwnership an internal call?  and transferOwnership is the external ?

isnt _transferOwnership an internal call? and transferOwnership is the external ?

nope they are two different calls, one for the proxy admin and one for the implementation

isnt _transferOwnership an internal call? and transferOwnership is the external ?

They are different calls, one for the proxy and one for the  implementation

@nvtaveras could you please share how did you test it exactly? ideally a list of commands we could run as well, thanks!

isnt _transferOwnership an internal call? and transferOwnership is the external ?

https://github.com/celo-org/celo-monorepo/blob/faca88f6a48cc7c8e6104393e49ddf7c2d7d20e3/packages/protocol/contracts/common/Proxy.sol#L90-L92
The external call on the Proxy contract is _transferOwnership it's done this way as to not clash with the transferOwnership the implementation could add.

@nvtaveras could you please share how did you test it exactly? ideally a list of commands we could run as well, thanks!

If you try to decode the latest proposal, celocli governance:show --proposalID 196, you get:
Could not decode proposal, displaying raw data: Error: Unable to parse {"value":"0","to":"0x765DE816845861e75A25fCA122bb6898B8B1282a","input":"0xd29d44ee000000000000000000000000890db8a597940165901372dd7db61c9f246e2147"} with block explorer

You will see that 0xd29d44ee is the call to _transferOwnership on the proxy.
If you try to decide on @nvtaveras 's branch it will work, because the explorer package adds the PROXY_ABI in ContractKit to all other core contract ABIs in case they are a proxy: https://github.com/celo-org/developer-tooling/blob/eba89a3102706cfe6492b0dc44f583a36d320a15/packages/sdk/explorer/src/block-explorer.ts#L56

I can confirm that with the changes the proposal is parsed and displayed in human-readable format 👍

trying to figure out the failures

I can confirm that with the changes the proposal is parsed and displayed in human-readable format 👍

Thanks for reviewing @shazarre 🙏 Would it be possible to release a new version of the CLI with these changes soon after merging? Since the proposal is already out and people would need it for reviewing and voting. Even a beta version would be good enough.
Let me know if there's any way we can help push this forward 🙏

closing this one in favor of https://github.com/celo-org/developer-tooling/pull/467 as it can run all the required checks
@nvtaveras beta release should be out either later today or tomorrow


Wrong logic in the analytic rule: Sign-in attempts by IP via disabled accounts

Describe the bug
This rule produces false positive. If the user tried to log in to a disabled account that has been subsequently reactivated and then tries to log in again, the rule will be still triggered without considering that they are both the same account.
To Reproduce
Steps to reproduce the behavior:
This is the rule -  SigninAttemptsByIPviaDisabledAccounts.yaml
Expected behavior
If the user tries to log in to a disabled account and that account got reactivated, a subsequent attempt by the same user should not trigger the rule.

Hi @OmarEfat, Thanks for flagging this, we will look into this and will back to you on this.

Hi @OmarEfat we have reached out to the concerned team with your feature request, will update you once we hear back from them, thanks!

@OmarEfat We are still waiting to hear back from the concerned team, thanks!

Hi @OmarEfat we haven't heard back from the concerned team yet, will update you once they respond, thanks!

Hi @OmarEfat we have got suggestion from team that as this issue does not occur very often, we need confirmation from query author before making this change, we will update you once we get confirmation from the query author, thanks!

Hi @OmarEfat we are still waiting to hear back from the query author, thanks!

Hi @OmarEfat we are still waiting to hear back from the query author, thanks!

Hi @OmarEfat we are still waiting to hear back from the query author, thanks!

Hi @OmarEfat, we are still waiting to hear back from the query author, thanks!

Hi @OmarEfat, we are still waiting to hear back from the query author, thanks!

Hi @OmarEfat, we are still waiting to hear back from the query author, thanks!

Hello @OmarEfat, we receive update from query author with modification in "analytic rule". We are working on this and will provide next update by 09-08-2023. Thanks!

Hi @OmarEfat, the query author's PR has been merged into the master. We are working on adding changes into the solution, and we'll let you know when it goes live. Thanks!


feat: Adopt segment custom metadata on write

Segment custom metadata, introduced in KIP-917, will be adopted by plugin to collect additional processing metadata for further usage.
Initial fields:

total bytes: Including manifest and indexes sizes to log segment size.
object key and prefix: for further usage on read path.

Depends on #354
To do:

[x] Using trunk snapshot to get access to latest APIs.
[x] Add custom fields to configuration.
[x] Test RSM with custom metadata.

Apart from the comments I left, all LGTM. @jeqo how do you think we should deal with this code? Merge or keep the branch until 3.5 is released?

Thanks @ivanyu! Let's fix #354 and #353 before merging this one.


Define requests based on existing OpenAPI spec

That's something that Insomnia does and makes it much faster to define requests. Is it something that is on your roadmap?

Hi! It's not on the immediate road-map but I haven't looked into how much work it'll be either.
I'll close this, but feel free to post it in the discussions and we'll see if more are interested in this (and possibly get their hands dirty too :).


Bridge NSTimeZone and CFTimeZone

[NSTimeZone setAbbreviationDictionary:[NSDictionary dictionary]];

Does this influence the results of the tests between the set and re-set?

Refers to: tests/unittests/Foundation/NSTimeZoneTests.m:90 in d9f18be. [](commit_id = d9f18beef4cd3025352a46c3c6bd95ce78f481e8, deletion_comment = False)

[NSTimeZone setAbbreviationDictionary:[NSDictionary dictionary]];

Yyyup, this is what I was talking to you about earlier.

In reply to: 236052217 [](ancestors = 236052217)

Refers to: tests/unittests/Foundation/NSTimeZoneTests.m:90 in d9f18be. [](commit_id = d9f18beef4cd3025352a46c3c6bd95ce78f481e8, deletion_comment = False)

[NSTimeZone setAbbreviationDictionary:[NSDictionary dictionary]];

Wait wait; I thought you meant that the clear/re-set influenced separate test runs! Here, I meant lines 91-133. It worries me that the following tests rely on having no abbreviations :(

In reply to: 236052318 [](ancestors = 236052318,236052217)

Refers to: tests/unittests/Foundation/NSTimeZoneTests.m:90 in d9f18be. [](commit_id = d9f18beef4cd3025352a46c3c6bd95ce78f481e8, deletion_comment = False)

[NSTimeZone setAbbreviationDictionary:[NSDictionary dictionary]];

Both are true - separate test runs are influenced, but also 91-133 seem to specifically be written to depend on having no abbreviations?

In reply to: 236054045 [](ancestors = 236054045,236052318,236052217)

Refers to: tests/unittests/Foundation/NSTimeZoneTests.m:90 in d9f18be. [](commit_id = d9f18beef4cd3025352a46c3c6bd95ce78f481e8, deletion_comment = False)

[NSTimeZone setAbbreviationDictionary:[NSDictionary dictionary]];

seems reasonable for a negative test case (although unlikely to have 0 entries in abbreviationDictionary).

In reply to: 236057250 [](ancestors = 236057250,236054045,236052318,236052217)

Refers to: tests/unittests/Foundation/NSTimeZoneTests.m:90 in d9f18be. [](commit_id = d9f18beef4cd3025352a46c3c6bd95ce78f481e8, deletion_comment = False)

:shipit:

:shipit:

:shipit:


Array Manipulation in C++

🚀 Feature
Array manipulation is one of hackerrank problems. It is a nice variation of the prefix sum problem.
Question link: https://www.hackerrank.com/challenges/crush/problem
Have you read the Contributing Guidelines on Pull Requests?
Yes.
Motivation
While solving this problem I learned a new optimization technique, Which can be used in many problems in various contests to reduce the time complexity.
Pitch
This problem will teach us a new optimization technique and it is a nice variation of the prefix sum problem.
I would like to contribute my approach to this problem using c++.
Hey, @ankitaggarwal23  please look into this issue and please assign this to me under GSSOC2021.
Thank you.

Hey @anushkrishnav please look into this issue and please assign this to me under gssoc2021
Thank you.

Hey @ankitaggarwal23 please look into this issue and please assign this to me under gssoc2021
Thank you.

All the best.

Thank you @bhav09 for assigning this issue to me


error LNK2019: unresolved external symbol

Getting errors about he externals link during the compile made it a fail:

** Visual Studio 2019 Developer Command Prompt v16.8.0
** Copyright (c) 2020 Microsoft Corporation

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise>cd \temp\donut
C:\temp\donut>nmake -f Makefile.msvc
Microsoft (R) Program Maintenance Utility Version 14.28.29333.0
Copyright (C) Microsoft Corporation.  All rights reserved.
Could Not Find C:\temp\donut\mmap-windows.obj
Could Not Find C:\temp\donut\lib\libdonut.lib
Building exe2h
    cl /nologo loader\exe2h\exe2h.c loader\exe2h\mmap-windows.c

exe2h.c
mmap-windows.c
Generating Code...
Building loader
    cl -DBYPASS_AMSI_A -DBYPASS_WLDP_A -Zp8 -c -nologo -Gy -Os -O1 -GR- -EHa -Oi -GS- -I include loader\loader.c hash.c encrypt.c loader\depack.c loader\clib.c

loader.c
hash.c
encrypt.c
depack.c
clib.c
Generating Code...
link -nologo<EMAIL_ADDRESS>-entry:DonutLoader -fixed -subsystem:console -nodefaultlib loader.obj hash.obj encrypt.obj depack.obj clib.obj
exe2h loader.exe
[ Found valid DOS and NT header.
[ Locating .text section.
[ saved code to loader_exe_x86.h
[ saved code to loader_exe_x86.go
Building generator
    rc include/donut.rc

Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.
    cl -Zp8 -nologo -DDONUT_EXE -I include donut.c hash.c encrypt.c format.c loader\clib.c lib\aplib64.lib include/donut.res

donut.c
hash.c
encrypt.c
format.c
clib.c
Generating Code...
donut.obj : error LNK2019: unresolved external symbol _aP_pack referenced in function _compress_file
donut.obj : error LNK2019: unresolved external symbol _aP_workmem_size referenced in function _compress_file
donut.obj : error LNK2019: unresolved external symbol _aP_max_packed_size referenced in function _compress_file
lib\aplib64.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
donut.exe : fatal error LNK1120: 3 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\bin\HostX86\x86\cl.EXE"' : return code '0x2'
Stop.
i did git clone in a fresh folder.
anything i do wrong ?
thanks

for me using the "x64 Native Tools Command Prompt for VS 2019" instead of the default "Developer Command Prompt for VS 2019" worked

for me using the "x64 Native Tools Command Prompt for VS 2019" instead of the default "Developer Command Prompt for VS 2019" worked

for me using the "x64 Native Tools Command Prompt for VS 2019" instead of the default "Developer Command Prompt for VS 2019" worked

Thanks!  Just ran into this as well.  Wasn't exactly sure how to switch the build to x64 since there is no solution file.  This worked perfectly.

for me using the "x64 Native Tools Command Prompt for VS 2019" instead of the default "Developer Command Prompt for VS 2019" worked

Thanks!  Just ran into this as well.  Wasn't exactly sure how to switch the build to x64 since there is no solution file.  This worked perfectly.


Executing "./tools/k8s-helper.sh setup-namespaces" ----> error: Task 'artifactId' not found in root project 'jenkins'.

Hi,
Executing "./tools/k8s-helper.sh setup-namespaces" ----> error: Task 'artifactId' not found in root project 'jenkins'.
I think that the problem is because now is used "export -f retrieveAppName" into pipeline-gradle.sh file, therefore is invalidated the function defined into k8s-helper.sh file

Now I get error "substituteVariables: command not found", because setup-namespaces needs substituteVariables function to work and this one is found pipeline.sh. Sorry

Keep on going ;)

Fixed via https://github.com/CloudPipelines/jenkins/commit/d5f07c320efec7d0f8b60644839835a775beeebe

Now, no execute createnamespace. It must have a problem with retrieveAppName function. The code execution finish in  "$(retrieveAppName)" of the pipeline.sh
if [[ "${PROJECT_NAME}" == "" || "${PROJECT_NAME}" == "null" ]]; then
PROJECT_NAME="$(retrieveAppName)"
fi
Log:
Picked PAAS is [k8s]
Current environment is [PROD]
Project name []
No pipeline descriptor [cloud-pipelines.yml] found. Will fallback to [sc-pipelines.yml]
No legacy pipeline descriptor [sc-pipelines.yml] found - will not deploy any services
Pipeline descriptor missing
No descriptor or module found for project with name [], project setup [SINGLE_REPO]
Language needs to be guessed from the sources
Failed to guess the language type!
No projectType/pipeline-projectType.sh found

It may be that I am doing something wrong

Have you pulled the latest changes? Cause now it should fetch the values from tools/k8s/build.gradle

The same is better to get this util function (substituteVariables) out of pipeline.sh into other script and call her from both

substituteVariables is in pipeline-k8s.sh not in pipeline.sh

Yes, I execute "./tools/k8s-helper.sh setup-namespaces" from command line.

Now work. Thanks


yarn build failed in windows

Are you reporting a bug?
Yes

Environment

react-static -v: 5.7.2
node -v: v8.7.0
yarn --version or npm -v: 1.1.0
Operating system: windows 10 x64
Browser and version (if relevant): chrome 63.0.3239.132 x64

Steps to Reproduce the problem
Base your steps off of any freshly installed react-static template!

react-static create an-project
make a route as like /foo/:param
yarn build

Then, I got an error E:\somepath\:param contains invalid WIN32 path characters.
Expected Behavior
Build successful

Any code example how you make a route?

Maybe this is a related issue https://github.com/nozzle/react-static/issues/206

@rohmanhm
For example in static.confg.js
getRoutes: () => {
  return [
    {
      path: '/foo/:param',
      component: 'src/some/component',
    }
  ];
}

This route can run successfully in dev mode, but failed when build.
I try it in centos (linux), both mode can be successful. But got an 404 error when refresh page in product mode.

You cannot have statically-exported dynamic route paths in a static website. You can however, use the <Route> component to handle dynamic routes in your app at runtime, but these routes will not be statically exported unless a route that uses them is defined in the static.config.js

Ok, thanks!


Unable to open table file ./data/pretrain_model/VGG_imagenet.npy: Data loss: not an sstable (bad magic number): perhaps your file is in a different file format and you need to use a different restore operator?

@ghost Could you also comment how you run then met this error?


error opening neovim matchit.vim path not found

Problems summary
on  arch linux error on neovim open  -matchit.vim
Environment Information

OS: linux manjaro

neovim :version output: neovim 4.0 nightly build

:checkhealth or :CheckHealth result(neovim only):

How to reproduce the problem from neovim startup (Required!)
open neovim on linux

foo
bar
baz

Screenshot (if possible)
NOTE: solution is here:  https://github.com/neovim/neovim/issues/5193
the package path on linux is not /usr/local/share/nvim/... as on OSX is
but
usr/share/nvim/...
so add to init.vim
set packpath=/usr/local/share/nvim/runtime
solve the problem.

see here i didnt load it
https://github.com/hardcoreplayers/ThinkVim/blob/master/core/init.vim#L69

I deleted all entries and installed Thinkvim as you suggest
git clone ...
initial nvim install all packages and e-thing is OK!
I close nvim and type
nvim again Now
This is error when I type nvim at prompt
Error detected while processing /usr/share/nvim/runtime/plugin/matchit.vim:
line    2:
E919: Directory not found in 'packpath': "pack/*/opt/matchit"
Press ENTER or type command to continue
After that I add to init.vim file path to matchit.vim path
Now my init.vim is
execute 'source' fnamemodify(expand(''), ':h').'/core/vimrc'
▎  set packpath=/usr/share/nvim/runtime,~/.local/share/nvim/site
▎
and Now error E919 disappear.
P.S. I do not know why only matvhit.vim is looking at /usr/local/share/runtime/...
Thanks for pronpt reply and Good Luck!

hi @smikeblog  can you tell me which neovim version do you used.

Hi, Of course
This one
https://aur.archlinux.org/packages/neovim-nightly

please use the latest nightly neovim version https://github.com/neovim/neovim/releases/
check vim version by :version .

NVIM v0.4.0-1534-g24fb7eefa
It is compiled today

it is compile daily from
source=('https://github.com/neovim/neovim/releases/download/nightly/nvim-linux64.tar.gz')

Apropos.
The error appeared 2-3 days ago.

then you open nvim . the thinkvim install successful when you see coc extensions installed at your nvim cmdline.

ok when i update the latest version , i got your problem.

@smikeblog   i used this version it works well NVIM v0.4.0-1426-g0e23ee3cc,maybe its a bug of neovim.

OK!
If smb has the same problem my solution at the moment is:
mkdir ~/.thinkvim.d
cd ~/.thinkvim.d
touch local_plugins.yaml
echo ' set packpath=/usr/share/nvim/runtime,~/.local/share/nvim/site ' >> local_settings.vim

yes you can add it to .thinkvim.d folder. but i think its a bug of neovim.

@smikeblog   i got the reason of problem .check this neovim commit .https://github.com/neovim/neovim/commit/5342342426777160300a431ef8c9200fb151f793

@smikeblog  fixed.please update.

OK!
Thanks!


wtf happened to the bypass

it now gives me the vac error... prob gonna get banned rip

any updates?

No updates
you need to update it yourself. Valve just used back the old modules and remove some of the leaks

vac error is cheat error not bypasser error. learn before posting

if u have a problem with verification vac . u should reinstall game or check game files first.

this is my old acc btw


[spiral/pagination] Paginator doesn't calculate countPages correctly in constructor

Description
The current implementation of the Paginator class has an issue in the constructor when we pass the $count argument. The problem is with the $countPages property which should be calculated based on the $count property, but it doesn't. This can cause incorrect pagination calculations.
Steps to Reproduce:
Create an instance of the Paginator class with a non-zero count argument
$paginator = new Paginator(limit: 25, count: 100);

Expected Result:
The countPages property should be calculated based on the count property and return the correct value.
$this->assertSame(100, $paginator->count());
$this->assertSame(4, $paginator->countPages());

Fixed


Add Makefile rules for connecting to remote NH instances

The command fails with:
$ AWS_PROFILE=zola-infra SERVICE=device ENV=staging make shell
aws ecs execute-command \
	--cluster nerves-hub-staging \
	--task arn:aws:ecs:eu-west-1:005352568091:task/nerves-hub-staging/015217b9f6b24da5b9f05b7e83705aa9 \
	--container nerves_hub_device \
	--interactive \
	--command "/bin/sh"

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

An error occurred (InvalidParameterException) when calling the ExecuteCommand operation: The execute command failed because execute command was not enabled when the task was run or the execute command agent isn’t running. Wait and try again or run a new task with execute command enabled and try again.
make: *** [Makefile:102 : shell-aws] Erreur 254

I suppose this come from task configuration.
@slow-1oris any idea ?


added google developer philippines organization #26

This is my first contribution to your open source repo

@joamarderije   thanks for making your first contribution, I will be merging your Pull Request, also look at the issues so that you can get a chance to win a limited community Swag from me.
If you like the project and Repo please give it a star and Follow me on Github (would be appreciated)


Radio button should be removed if device contain single VC while sharing.

Describe the bug
Radio button should be removed if device contain single VC while sharing.
Prerequisite Download VC in sharing phone.
To Reproduce

unlock the app
Open qr code in requesting device.
Open scanner in sharing device and scan the qrcode
select VC to share

Current behavior
Even when device has single VC, while sharing radio button is added on VC for selection.
Expected behavior
Radio button should be removed if device contain single VC while sharing.
Screenshots

Smartphone (please complete the following information):

Device: iPhone7 & iPhone XR
OS: 15.4.1
Inji app version: 0.4.0 (16) in test flight
MOSIP Version: 1.2.1
MOSIP server: qa-121.mosip.net

Additional context
Same issue is observed in cross platform sharing as well.

The above Issue was fixed by removing check-box reacthnative-element in singleVcItem.tsx module. Now radio button will be not there while sharing if, single VC in device.
Respective Screenshot

Verified on:
Device: iPhone 8 & iPhone 11
OS: 16.0.2 (20A380), 15.6.1
Inji app version: 0.4.1 (7) -> Testflight
MOSIP Version: <IP_ADDRESS>
MOSIP server: qa5.mosip.net
Able to replicate the issue

@Anushree09-N The above Issue was rectified, Raised and shared respective PR #392

As per the latest design radio button is removed instead we have vc selection via green border on selected vc. Hence closed.
Attaching the screenshot for the reference: