chore: update repo by service bot

This is a routine update from cc-service-bot based on the service.yml in your repo. This PR
should be approved and merged as soon as CI passes.

CHANGELOG
FILE NAME - CHANGED BY - COMMIT MESSAGE
Makefile - framework - chore: update repo Makefile cc-mk-include v0.1140.0
cc-mk-include/compare/v0.1139.0...v0.1140.0


x/build/cmd/coordinator: trybots don't work on golang.org/dl repo

There are two parts to this issues:

The trybot builds start, fail, and keep retrying indefinitely. It's been 2 hours since https://go-review.googlesource.com/c/dl/+/207097/1#message-2732030f20d3db705eb32433ddacbb459f630a61, and it's still doing this:

It should give up at some point and report a failure.

The builds fail due to something being misplaced, likely because golang.org/dl is the only repo that doesn't have the 'x' element in the import path.
  builder: freebsd-amd64-12_0
      rev: e77106cc54af58d3eedbb134310668c6993474c7
 buildlet: http://<IP_ADDRESS> GCE VM: buildlet-freebsd-12-0-rndfed6a2
  started: 2019-11-14 03:36:14.524802483 +0000 UTC m=+162177.592170276
    ended: 2019-11-14 03:36:46.471944701 +0000 UTC m=+162209.539312514
  success: false

Events:
  2019-11-14T03:36:14Z checking_for_snapshot
  2019-11-14T03:36:14Z finish_checking_for_snapshot after 18.9ms
  2019-11-14T03:36:14Z get_buildlet
  2019-11-14T03:36:14Z awaiting_gce_quota
  2019-11-14T03:36:14Z finish_awaiting_gce_quota after 0s
  2019-11-14T03:36:14Z create_gce_buildlet buildlet-freebsd-12-0-rndfed6a2
  2019-11-14T03:36:14Z create_gce_instance buildlet-freebsd-12-0-rndfed6a2
  2019-11-14T03:36:23Z finish_create_gce_instance after 8.29s; buildlet-freebsd-12-0-rndfed6a2
  2019-11-14T03:36:23Z wait_buildlet_start buildlet-freebsd-12-0-rndfed6a2
  2019-11-14T03:36:23Z got_instance_info waiting_for_buildlet...
  2019-11-14T03:36:41Z finish_wait_buildlet_start after 18.3s; buildlet-freebsd-12-0-rndfed6a2
  2019-11-14T03:36:41Z finish_create_gce_buildlet after 26.8s; buildlet-freebsd-12-0-rndfed6a2
  2019-11-14T03:36:41Z finish_get_buildlet after 27s
  2019-11-14T03:36:41Z using_buildlet <IP_ADDRESS>:80
  2019-11-14T03:36:41Z write_snapshot_tar
  2019-11-14T03:36:46Z finish_write_snapshot_tar after 4.42s
  2019-11-14T03:36:46Z make_and_test
  2019-11-14T03:36:46Z fetching_subrepo dl
  2019-11-14T03:36:46Z get_source
  2019-11-14T03:36:46Z finish_get_source after 0s
  2019-11-14T03:36:46Z finish_make_and_test after 86.2ms; err=runTests: failed to determine go env GOMOD value: go env error: chdir /tmp/workdir/gopath/src/golang.org/dl: no such file or directory
output:

Build log:
freebsd-amd64-12_0 at e77106cc54af58d3eedbb134310668c6993474c7 building dl at b01b4c2ff1bd61a7c9de81596442130f2ff07ca7

Error: runTests: failed to determine go env GOMOD value: go env error: chdir /tmp/workdir/gopath/src/golang.org/dl: no such file or directory
output:

The second issue is related to #30852. It seems a little more needs to be done for testing in module mode.
/cc @bcmills @bradfitz

For part 1 of this issue, the problem is as follows.
In runSubrepoTests, we're doing the work of determining if we're invoked in module mode or not:
func (st *buildStatus) runSubrepoTests() (remoteErr, err error) {
	[...]
	// Determine if we're invoked in module mode.
	// If using module mode, the absolute path to the go.mod of the main module.
	// If using GOPATH mode, the empty string.
	goMod, err := st.goMod(importPathOfRepo(st.SubName), goroot, gopath)
	if err != nil {
		return nil, fmt.Errorf("failed to determine go env GOMOD value: %v", err)
	}
	[...]

A failure to determine go env GOMOD is currently being reported as a "communications failure" rather than a "real test failure". This was chosen because we didn't know of a way in which go env GOMOD can fail due to a real problem in the source code.
The reason it's failing now is because the directory corresponding to the root of the module does not exist (for some reason, determining that reason is part 2 of this issue):
failed to determine go env GOMOD value: go env error: chdir /workdir/gopath/src/golang.org/dl: no such file or directory

It is intentional to keep retrying "communications failures" forever, because the expectation is that they should eventually succeed. There is a special case where some repeated communication errors are promoted to terminal errors:
// If a build fails multiple times due to communication
// problems with the buildlet, assume something's wrong with
// the buildlet or machine and fail the build, rather than
// looping forever. This promotes the err (communication
// error) to a remoteErr (an error that occurred remotely and
// is terminal).
if rerr := st.repeatedCommunicationError(err); rerr != nil {
	remoteErr = rerr
	err = nil
	doneMsg = "communication error to buildlet (promoted to terminal error): " + rerr.Error()
	fmt.Fprintf(st, "\n%s\n", doneMsg)
}

In this case, it's a bug in coordinator that's causing go env GOMOD to fail. We shouldn't promote it to a "real test failure" because it isn't a problem in the golang.org/dl module, it's a bug somewhere in coordinator. Once we fix this, this will not happen again.
(It is an option to add a "knownInternalCoordinatorBugError" helper that would promote a "failed to determine go env GOMOD value" error to be terminal, but I don't think it's worth doing at this time.)
So, what's left here is to understand why part 2 is happening and fix it.

I see where the problem for part 2 is.
One of the first steps in runSubrepoTests is to:
// Check out the provided sub-repo to the buildlet's workspace.
// Need to do this first, so we can run go env GOMOD in it.
err = buildgo.FetchSubrepo(st.ctx, st, st.bc, st.SubName, st.SubRev)
if err != nil {
	return nil, err
}

That call is placing the golang.org/dl module in the wrong place. It's being placed in go/src/golang.org/x/dl instead of go/src/golang.org/dl.
The fix is trivial.

It is intentional to keep retrying "communications failures" forever, because the expectation is that they should eventually succeed.

I'm seeing now that this isn't quite true, so there is some room for improvement here. I opened issue #36226 about it for tracking purposes, but it's not a high priority.


typoadd FAQ for broker load error: Cannot locate default realm

Proposed changes
add FAQ for broker load error: Cannot locate default realm

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...

run buildall


⚠ Cioos National CKAN has degraded performance

In 304a4a9, Cioos National CKAN (https://catalogue.cioos.ca/) experienced degraded performance:

HTTP code: 200
Response time: 6176 ms

Resolved: Cioos National CKAN performance has improved in f45be70 after 5 minutes.


DBus Codegen

What does the pull request do?
Use Tmds.DBus.Protocol directly instead of relying on the System.Reflection.Emit backend.
This will greatly help with trimming and in aot-scenarios.
Note that it's currently using a submodule (hence WIP) since a) Tmds.DBus.Protocol isn't released on NuGet yet and b) sending large buffers is currently broken (e.g. sending tray icon images)
What is the current behavior?
Usage of the S.R.E backend,  which breaks when using trimming/aot.
What is the updated/expected behavior with this PR?
Trimming/Aot should work.
How was the solution implemented (if it's not obvious)?
Checklist

[ ] Added unit tests (if possible)?
[ ] Added XML documentation to any related classes?
[ ] Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation

Breaking changes
None(?)
Obsoletions / Deprecations
None
Fixed issues
#2359
#10069

You can test this PR using the following package version. 11.0.999-cibuild0027960-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

Are you using some codegen tool to generate implementations? If so, it would be way better to have it as a Roslyn Generator.

Are you using some codegen tool to generate implementations? If so, it would be way better to have it as a Roslyn Generator.

I'm currently working on a proper roslyn code generator for this purpose, but a first proof-of-concept I used the Tmds.DBus.Tool dotnet tool.

You can test this PR using the following package version. 11.0.999-cibuild0028463-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0028472-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0028634-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0028831-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0028872-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0028971-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

Is there an easy way to test this on an app? Using the 'all' nuget feed gives
'Unable to find package Tmds.DBus.Protocol. '

Is there an easy way to test this on an app? Using the 'all' nuget feed gives 'Unable to find package Tmds.DBus.Protocol. '

I'm afraid not, at least at the moment aside from using Avalonia as a git submodule and referencing it with a ProjectReference.
There's a MyGet feed for the Tmds.DBus.Protocol package, but  my required PR has been pending for over a month now. Besides, I strongly dislike the current style of the project since it passes Exception objects as parameters, which is discouraged by Microsoft, so I'm thinking about forking it.

You can test this PR using the following package version. 11.0.999-cibuild0029057-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0029117-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

I tested this using the pr feed and a local project reference to Tmds.DBus.Protocol with the pr applied.  All looking good.

You can test this PR using the following package version. 11.0.999-cibuild0029180-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

You can test this PR using the following package version. 11.0.999-cibuild0029242-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

@kekekeks are we good to merge it with submodules, or should we wait until it's available on the nuget?

We need to somehow internalize all public types from DBus libs. Otherwise there will be name conflicts later.

Tmds.DBus.Protocol is probably going to be published on NuGet "earyl next week", see https://github.com/tmds/Tmds.DBus/issues/79#issuecomment-1423939333.
Once that's done I'll adapt the source generator to use the package and try to upload it to NuGet too (in case I can figure out how to sign a package by then)

@affederaffe in general I think it's enough to create a key and sign from the Visual Studio project properties page.
Other than that, you can set AssemblyOriginatorKeyFile and SignAssembly properties like here https://github.com/tmds/Tmds.DBus/pull/82/files#
Not sure what's advantage of adding PublicSign property though.

I don't quite understand why and how render tests are failing on this PR for all platforms.

You can test this PR using the following package version. 11.0.999-cibuild0030315-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

After this PR dbus callbacks are executed on some random thread instead of dispatcher one


[DOC]update getting started guide doc for aws-emr670 release[skip ci]

update getting started guide doc for aws-emr670 release
https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-670-release.html

verified by running jupyterLab

build


Add quic_server_stats_impl.h to QUICHE platform implementation.

Description:
Add quic_server_stats_impl.h to QUICHE platform implementation, with everything being no-op.
This allows code rely on quic_exported_stats.h and/or quic_server_stats.h to compile.
Risk Level: minimal: code not used yet
Testing:
bazel test test/extensions/quic_listeners/quiche/platform:quic_platform_test --test_output=all --define quiche=enabled --experimental_remap_main_repo
Docs Changes: none
Release Notes: none
[Optional Fixes #Issue]
[Optional Deprecated:]

/assign @danzh2010

The description says importing quic_client_stats_impl.h but I didn't see it anywhere.
That's a copy-paste error, it should be quic_server_stats_impl.h, fixed.

I think quic_exported_stats.h won't build in this case.
Good catch, I just tried, it doesn't compile because QUIC_HISTOGRAM_TIMES missed some semicolons. I just sent a internal change to fix it. I'll update this PR when the fix lands in QUICHE.


Enable specifying Ceph cluster-id instead of MON list in storage class

This commit provides the option to pass in Ceph cluster-id instead
of a MON list from the storage class.
This helps in moving towards a stateless CSI implementation.
Tested the following,

PV provisioning and staging using cluster-id in storage class
PV provisioning and staging using MON list in storage class

Did not test,

snapshot operations in either forms of the storage class

Signed-off-by: ShyamsundarR<EMAIL_ADDRESS>

Attn.: @rootfs @gman0 @Madhu-1
Had a discussion with @rootfs, around the various review comments, and here are the salient points around which this PR will be reworked (in addition to code review comments provided by @Madhu-1 and others),

We, for now, assume we will support only k8s as the CO, hence k8s specifics are allowed in the code (retaining options where needed to not use them at run-time)

Change the configuration from passing of cluster-config and secrets as volumes to a fetch mode, i.e reading and watching for k8s objects using the k8s APIs

Helps avoid the need to pod restart when configuration changes
We will still retain the file based config, based on an option to the driver, for possible non-k8s systems

Merge the config-map and secrets into a single secret object (call it ceph-cluster-<fsid>-secret)

Lesser objects to deal with
Also, the pool list will be removed from this secret, hence it would contain, [MONs, adminID, adminKey] only for use

The ceph-cluster-<fsid>-secret will still be present in the same namespace as the CSI driver and be readable by the Controller and Node services

In short, the change from the existing implementation is,

use APIs to fetch and watch config objects, rather than map them into the pods as volumes
merge the secret and config map into a single secret object

... hence k8s specifics are allowed in the code ...

and

Change the configuration from passing of cluster-config and secrets as volumes to a fetch mode, i.e reading and watching for k8s objects using the k8s APIs

This is directly against the goal of the CSI interface. Having to resort to this suggests a fatal flaw either in the CSI spec or the driver design. If others are able to create CSI drivers w/o a tight coupling to the CO, it suggests a fundamental problem w/ our approach.

... hence k8s specifics are allowed in the code ...

and

Change the configuration from passing of cluster-config and secrets as volumes to a fetch mode, i.e reading and watching for k8s objects using the k8s APIs

This is directly against the goal of the CSI interface. Having to resort to this suggests a fatal flaw either in the CSI spec or the driver design. If others are able to create CSI drivers w/o a tight coupling to the CO, it suggests a fundamental problem w/ our approach.

I will try to lay it down as follows, which may possibly help elicit where the problems are,
There are 2 parts we are attempting to move away from the StorageClass to the CSI plugin, secrets and Ceph configuration information

We want the configuration to move to the CSI plugin, because,

other than the CSI verbs CreateVolume and CreateSnapshot, this information from the StorageClass does not reach the other CSI verbs
configuration information cannot be stashed in the volume_context (which is returned by the plugin on Create requests), as this is NOT mutable as per the spec and hence if MON information changes we cannot update the volume_context map
there is no other place to stash the information and also keep it updated (i.e other than the config map of volumes provisioned that is currently in the code, and even then the new MON information needs to be updated across each volume in the config map (think 10k volumes in the map and that may overflow the config map store capacity as well))

We want the secrets to move to the CSI plugin, because,

secrets from the StorageClass are not passed to the ListVolumes and ListSnapshots RPC verbs
other verbs that do not pass secrets are workable, as we do not need them to perform the required operation (e.g. unstage, unpublish)

So till now, we can consider secrets not being passed to ListVolumes and ListSnapshots as deficiencies of the CSI spec. BUT, these (List ops) are internal requests generated by the CSI driver (plugin here is the storage specific implementation (say ceph) and driver is the CO specifc implementation (say, CSI parts that interface with k8s)), and as a result do not flow from a StorageClass to the driver, which results in no viable secrets available to the driver to pass to the plugin.
Hence the above verbs lacking secrets is not a deficiency of the CSI spec IMO.
NOTE1: There is an option at this point in the discussion NOT to support LIST capability from the Ceph CSI (it is an explicit capability that the plugin can choose not to implement as per the CSI spec), and hence retain secrets in the StorageClass itself. BUT the cluster config still needs to be passed to the CSI plugin.
So the problem moves into, how we pass the cluster config and secrets to the CSI plugin.

As long as there is a single Ceph cluster, this is relatively simple, we pass the config and secrets once to the pod and we are done
When there are multiple Ceph clusters in play, if we use a single config or secret file for all clusters, the secrets will leak across Ceph cluster namespaces, which could be a security concern.

NOTE2: The cluster config can still be a single file (and hence a single config map that can be mapped into the pod), this still means that editing this file is permissible across Ceph cluster namespaces. If this is not a concern and we choose not to support LIST capability, then we have a solution without introducing CO specific implementation into the plugin.
This leaves us with 2 options to share these configuration entities,

Run an instance of CSI driver per Ceph cluster, or simplify the problem as always dealing with a single Ceph cluster per CSI instance
OR,
Let each Ceph cluster namespace own it's secrets and config, and grant the CSI driver read permissions to the same. IOW CSI plugin gets a config and secret per Ceph cluster

The latter is where we are at, although as a side note the current design or implementation does not preclude configuring it as the former.
In the case of the latter, when we add a new Ceph cluster, we map in new volumes (config and secret) to the CSI pods. The concern is that this needs a pod restart,

The restart, if using ceph-fuse, would mean node mounts going unavailable
The restart of the controller is a temporary loss of provisioning and possibly publishing capability (a more minor concern)

This restart happens each time a Ceph cluster is added to a CO, IOW should not be that frequent. Also, if node mounts are not impacted (say we default to kernel ceph-fs), then we can get away with a restart of the pods, as the above concerns are addressed.
BUT, to prevent these restarts altogether,  the thought is to fetch/watch the configuration and secrets, using k8s APIs.
So, in short, the k8s specific change is because it helps avoid pod restarts, if we can live with pod restarts, we should not have to worry about any CO specific implementation in the Ceph CSI plugin implementation.
OR, if we can agree to NOTE1 and NOTE2 related points, we can again have an implementation that is no CO specific, and further simpler.
@rootfs does this explain where we are at or are there points I am missing?

@gman0 @Madhu-1 @rootfs PTAL
Post this PR, the intention is to add code to change the VolID encoding, such that information can be composed and decomposed from the same.
The intention of this PR is to address (mostly) user facing configuration changes, hence apart from adding a watch to the secrets (instead of reading it each time) I consider this PR complete. The watch functionality would come in later, as another PR, to keep things simple.
If the scope of this PR was not clear, hope the above clarifies the same. Let me know if anything else is expected around this PR.

This PR follows the named return convention, but current in ceph-csi code base we don't use named return, I think we need to decide do we really need to do named return, IMO mixes both the approaches makes really hard to read the code

I do not see a hard and fast rule that we need to use only one style, this being my first go program ever, I liked the naked returns as long as we retain sensibilities around where we use them (smaller functions and such). Unless there is a edict that the style of this repo disallows naked returns, I would like to retain the code as is.

Request a review or any disagreements to this patch, as I have the next patch that implements the removal of the config map and also adds the volume ID encoding bits as needed here.
I do not want to squash that patch into this, as review would be very tedious (I think it already is as the other patch has a delta of +1600/-450 odd lines). I thought I could do stacked PRs but need a branch to pull that off (and ability to create branches as well in this repository).
 The next patch as linked above, brings in the code functionality. A follow-up to that patch would be the documentation and other changes, but again, in order to not risk the patch sizes being larger I would like to take it in steps.
If there are other ways my patches need to land, do let me know.
@gman0 @rootfs @Madhu-1 PTAL and let me know if this patch needs more work, or how I can get the other patch as well into the review queue. Thanks!

Sans the merge conflict, this LGTM

Sans the merge conflict, this LGTM

@gman0 rebased and resolved the merge conflict. Also, retested the patch.
csi-v1.0 branch is currently broken due to the attacher yaml changes to communicate on csi-provisioner.sock instead of csi.sock as before, so attach fails when pods with PVC are started. This is a separate issue to this PR, but just mentioning it here.

Ping @rootfs @gman0 PR is now mergable, request feedback so that I can rebase and post the next PR around the same topic.

LGTM! If @rootfs or anyone else doesn't oppose, let's merge this so we can move forward...

@rootfs @ShyamsundarR the current changes in yaml files need to be incorporated in rook also?

@rootfs @ShyamsundarR the current changes in yaml files need to be incorporated in rook also?

With this change it is not required, as the change is compatible with the older manner of configuration, with the next pr it would need changes to Rook, and possibly also for us not to push images to quay for every PR merge, so that such things can be coordinated.


MPASS_core.pl Illegal divide by 0 with $line_num

Good morning, and thank you in advance.
I am also running a few samples through your MPASS_core.pl script but I'm running into a consistent issue, specifically at line 543 where I'm receiving an illegal divide by 0.  Since the alleged 0 is the sum of $line_num and $cov, I'm concerned it's not reading my fasta file contig names correctly?  $cov is the coverage of query genes of the metaSPAdes output, and I have verified that every scaffold name in my test files follow the correct scheme (>gene_1_NODE_1_cov216.0836_length401202).  I have also set $line_num = 1 (line 456) as an additional test, but I still received an illegal divide by 0 on line 543.
I apologize for the constant questions, but any help is immensely appreciated!

Thank you for your question. I appreciate questions like these as they give me ideas for improvement of the script.
First, your scaffold name (>gene_1_NODE_1_cov216.0836_length401202) is correct.
Second, concerning the error on line 543, I haven't encountered this error in my previous analysis and script checks. Thus, I may not be able to provide precise advice. It's possible that the files used in this step (.asm files) were not created correctly in the previous step, resulting in empty .asm files. If .asm files for this step lack content, the original script with $line_num set to 0 would cause an "illegal divide by 0" error. You can check the contents of .asm files using --out2devalue option of MPASS_core.pl (--out2devalue  Directory_name).
However, if $line_num is set to 1, this error should not occur, so there might be another possibility (unfortunately, I'm not sure why this might be the case).
I've uploaded example files for you to verify if MPASS_core.pl functions in your PC environment. In this directory, you'll find six protein FASTA files (G1_a_aa, G1_b_aa ... G3_b_aa). Please attempt to run MPASS_core.pl using these protein FASTA files. If everything is functioning correctly, a matrix file for creating a dendrogram with three clades, G1, G2, and G3, will be generated. Matrix file can be converted to tree file with neighbor program in PHYLIP package, BIONJ or ITOL softwares or other tree construction softwares.


Windows Support

The VertxVaadin initSockJS method uses the java.nio.Paths class to attempt to assemble a path. Unfortunately, it assembles a "/" with a "*". Under Windows, * is not a valid character, and as such, the Paths.get() call fails with an illegal character exception.
I think that it'd be better to just assemble the path using Strings to make it work on both Windows and Linux-based environments.

Thanks for suggestion; I'll fix and also check for other potential wrong usages of Paths.get(...)

Fixed on vaadin-13 branch; snapshot published on bintray, but not yet released on maven central.
Change may also be backported on other branches

Published vertx-vaadin-flow 13.0.1 that fixes the issue


Add minimal tests

Before starting any major changes (including high priority ones such as #6), we need a way of testing that our changes do not break the basic functionality of the library. Simply put, I'm afraid to move or touch some files as it is unclear to me whether something will break.
For this, I suggest we start with minimal tests that consist in compiling a handful of scenes, put them in a new file called test/test_example_scenes.py, and we run the test by manually running manim over them. If the scenes look the way they should, then we are good to go. These scenes can be the ones that currently live in sample_scenes.py, for example.
Of course, this is no replacement for a full testing framework, but it should at least be a minimal guarantee that our coming changes are not completely screwing up the library.

Simply put, I'm afraid to move or touch some files as it is unclear to me whether something will break.

Manim has never had any tests and is pretty much always broken. That's just the way we've been doing it so far. Not to say that it makes any sense at all, but if the code sort of looks reasonable to you it's already up to the current manim standard, so you shouldn't feel too scared to change it.
That said those tests would be a big help.

That's a great idea. I take care of that

#28 doesn't improve the testing situation over running the example scenes manually. The goal is to write a suite which can be run in pytest, nose2, or the like in order to ensure basic functionality.

As per #86, there is now a (very very minimal) set of tests in place with pytest. I will close this in favor of all the other issues already mentioning tests.


feat: 达梦数据库添加select top查询解析

Author:    TwoBrother<EMAIL_ADDRESS>

达梦数据库特有top语法，默认解析 select top 10 column1,column2 from table，会出现语法错误。

请参考SQLServer Parser的实现

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.9 out of 10 committers have signed the CLA.:white_check_mark: a364176773:white_check_mark: linceln:white_check_mark: patience00:white_check_mark: GeorgeAnson:white_check_mark: yanhuqing666:white_check_mark: digitalsonic:white_check_mark: ralphhuang:white_check_mark:<PHONE_NUMBER>:white_check_mark: TwoBrother2020:x: wenshaoYou have signed the CLA already but the status is still pending? Let us recheck it.

这个PR还是等公共数据类型抽象出来再考虑吧，先不要继续复制粘贴重复代码了
@lizongbo

这个PR还是等公共数据类型抽象出来再考虑吧，不要继续复制粘贴重复代码了
@lizongbo

代码冲突，请重新基于最新代码提交pr


Fluffy missions more fixes

The many tabulators after YOU: in the bomb conversation are needed to put the text of the bomb and you on the same position. Everything else is fine

Took all changes to my local plugin, except the YOU-tabs, and the paragraph tabs, since i think i like them more without(also there was inconsistent use of it).
Giving you credit on the new published plugin. Thx again.


Make ItemsControl.Items readonly.

What does the pull request do?
#10590 added the ItemsControls.ItemsSource property to make our controls more like WPF and UWP, but left in a setter for the ItemsControl.Items property for compatibility reasons.
From the discussion in that PR and with customers we decided that it's acceptable to remove this setter and make ItemsControl.Items read-only. This will mean that clients will have to change any code that binds/sets Items to use ItemsSource when upgrading to Avalonia 11.
This PR also reverts the change to InheritDataTypeFromItems in #10590, meaning that it's only legal to apply a single one of these attributes to a property again.
Breaking changes
ItemsControl.Items is now readonly.

Hey, I think there was a huge oversight with this pr because let's say I have items bound and I want to upgrade (to nightly with this pr or future versions).
There's actually no indications at compile time that this is no longer supported. I was trying to test an unrelated issue with a sandbox project on lattest masters with this pr and I didn't know that this was a problem because it gave me stuff like this (all of these UI elements were using items instead of itemsSource):

Here is the xaml:
<UserControl xmlns="https://github.com/avaloniaui"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:s="clr-namespace:Sandbox"
             mc:Ignorable="d" d:DesignWidth="800" d:DesignHeight="450"
             x:CompileBindings="True"
             x:DataType="s:FirstViewModel"
             x:Class="Sandbox.FirstView">
  <StackPanel Orientation="Horizontal">
    <ListBox Items="{Binding Models}">
      <ListBox.ItemTemplate>
        <DataTemplate DataType="s:ObservableModel">
          <ComboBox Items="{Binding Strings}"
                    SelectedIndex="{Binding MyField}"/>
        </DataTemplate>
      </ListBox.ItemTemplate>
    </ListBox>
    <DataGrid AutoGenerateColumns="False"
              Items="{Binding Models}">
      <DataGrid.Columns>
        <DataGridTemplateColumn Header="Field">
          <DataTemplate DataType="s:ObservableModel">
            <ComboBox Items="{Binding Strings}"
                      SelectedIndex="{Binding MyField}"/>
          </DataTemplate>
        </DataGridTemplateColumn>
      </DataGrid.Columns>
    </DataGrid>

  </StackPanel>
</UserControl>

Obviously, changing these to use ItemsSource fixes the problem, but my issue more has to do with the fact an unsuspecting developer could take forever to find out what is wrong with their bindings. There's not even anything logged in the console.
Shouldn't we consider having a more clear message that this will not work?

Definitely need a clearer error message here. @kekekeks do you think we need to special-case this in the xaml compiler (and is this behaviour even correct?)

Maybe we can special-case this as a warning instead of error?

I'm not sure that adding a Binding object to the items collection will ever be something the user intended, so makes more sense as an error to me.

How about some axaml playgrounds/galleries that want to demonstrate the result of binding a Binding object to the Items collection?

How about some axaml playgrounds/galleries that want to demonstrate the result of binding a Binding object to the Items collection?

OneWayToSource could be a valid Binding, I guess. But we should probably do this discussion in a new issue. Should I open one and move the comments there @grokys?

Issue created https://github.com/AvaloniaUI/Avalonia/issues/10946


strings listed by function list_value_xml are shorter than the string in argument 2

Reported by ansley b manke on 8 Aug 2014 19:35 UTC
See LAS ticket http://dunkel.pmel.noaa.gov/trac/las/ticket/1640
The length of the string we're writing is over 700 characters, the length that's listed in the output is 512 characters.
Where expocode is 09AR20121217, 09AR20130113, 09AR20130228, PAT520130814, PAT520130730, PAT520130720, PAT520130719, PAT520130715, PAT520130702, PAT520130618, PAT520130608, PAT520130607, PAT520130603, PAT520130521, PAT520130508, PAT520130427, PAT520130426, PAT520130422, PAT520130408, PAT520130325, PAT520130315, PAT520130311, PAT520130227, PAT520130212, PAT520130201, PAT520130128, PAT520130113, PAT520121218, PAT520121209, PAT520121207, PAT520121203, PAT520121121, PAT520121107, PAT520121026, PAT520121022, PAT5
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/2190

Comment by ansley.b.manke on 8 Aug 2014 23:49 UTC
Fixed. There were fixed-length variables in string handling utility functions in ef_utility, in utl/get_string_element.F, and in efi/list_value_xml.F


[Feature][UI Next] Add project workflow monitor.

Purpose of the pull request
#7928

Brief change log

Verify this pull request

This pull request is code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Codecov Report

Merging #7991 (e40cd6c) into dev (b9b0722) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev    #7991      +/-   ##
============================================
- Coverage     41.28%   41.27%   -0.01%
+ Complexity     3722     3720       -2
============================================
  Files           637      637
  Lines         27128    27128
  Branches       3081     3081
============================================
- Hits          11200    11198       -2
  Misses        14852    14852
- Partials       1076     1078       +2

Impacted Files
Coverage Δ

...er/master/dispatch/host/assign/RandomSelector.java
77.77% <0.00%> (-5.56%)
:arrow_down:

...e/dolphinscheduler/remote/NettyRemotingClient.java
52.81% <0.00%> (-0.71%)
: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 b9b0722...e40cd6c. Read the comment docs.


document how to enable colors in no tty

Expected Behavior
To have a colored output.
Observed Behavior
Colors have gone 👻
Proposed fix
I think you do that on purpose when no tty is detected, which is perfectly fine because it makes easier to process the output if needed.
That said, in some use cases (like mine) one might just want to forward your output. To do so it would be nice to have a flag to force colored output (others do --ansi or --colors).
Thanks!
Bonus Points! Code (or Repository) that Reproduces Issue
import { spawn } from 'child_process'

spawn('nyc ava', { stdio: 'inherit' })

Environmentt
$ node --version
v6.9.1
$ npm --version
3.10.8

Have you tried passing --color as a command line flag? Or FORCE_COLOR as an environment variable?
https://github.com/chalk/supports-color#info
If that does work, it would probably be worth adding this to the docs somewhere. Maybe under Running Reports?

@mlrawlings --color works indeed! Thanks 👌
It would be worth mentioning it in the docs.

@ngryman 👍 if you're bored feel free to take a stab at the docs :) otherwise let's leave this open as a feature request.

--color doesn't work anymore. Where's the love for CI pipelines?

I ran into this same issue. Apparently the flags are order sensitive. I'm only using two CLI flags, --colors and --nycrc-path:

If I put --colors after my --nycrc-path cli flag, nyc errors out
If I put --colors before my --nycrc-path cli flag, everything works great and I get colors.


idea: interface validation

Many people use interface as a design tool.
perhaps it is possible to use Nim's when compiles(...) feature
to expand something like checkImpl(myClass, ISomeInterface)
where ISomeInterface will be scanned (typetraits perhaps) for the public procs and fields, and then for each it will be checked in the (hidden by template) when compiles block. then we get a compiler error message, that this proc was not yet implemented.
What do you think of this idea? btw, very cool lib. just came across it!

That's nice idea. I've been thinking about interface for a while and I was going to implement it like this:
# `interface` is a reserved word so `protocol` is used instead.
protocol IFly:
  proc fly() =
    discard

class Bird impl IFly:
  proc fly() =
    echo "I'm flying!"

and then it's converted below like nim-interface-implements:
type IFly = tuple
  fly: proc()

type Bird = ref object

proc fly(self: Bird) =
  echo "I'm flying!"

proc toProtocol(self: Bird): IFly =
  return (
    fly: self.fly()
  )

I'm interested in your idea, but I can't think of a way to implement it. Can you tell me the details?

I see. very nice. the syntax looks very clean and clear.
There is (yet) another interface implementation called iface from yglukhov.
The details need to be fleshed out. I am not sure it works.
Nim has a compiler feature to check if code compiled (checked during compile time)
https://nim-lang.github.io/Nim/system#compiles%2Cuntyped
when compiles(3 + 4):
echo "'+' for integers is available"
so if we do:
check_bird_fly
when not compiles(new Bird().fly()):
{.error "fly proc not yet implemented for Bird type".}
perhaps it's a simple solution. maybe make it more explicit like:
checkImpl(Bird,IFly), then it will expand to try all the IFly defined procs for Bird.
is that clearer now? None of the code was checked, it was just an idea. see if u can get it to work... Thanks!

I see, I understand.
So the type of the first argument of checkImpl() is typed, right?
I think I can implement it well, so I'll try. Thanks!

I just created an issue based on this page.

cool :-)


Issue with angular beta-4

Hey!
I took my repo and did npm install on a different computer and am now getting an error (no code changes, nothing). A package had to have updated that hasnt before. Any help with this would be much appreciated.
The error is:
ERROR in Error encountered resolving symbol values statically. Calling function 'OpaqueToken', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol CONFIG_OBJ in /Users/Au/Projects/AU/M/app.io/node_modules/ng2-restangular/dist/esm/src/ng2-restangular.module.d.ts, resolving symbol RestangularModule.forRoot in /Users/Au/Projects/AU/mo/app.io/node_modules/ng2-restangular/dist/esm/src/ng2-restangular.module.d.ts, resolving symbol AppModule in /Users/Au/Projects/AU/mo/app.io/src/app/app.module.ts, resolving symbol AppModule in /Users/Au/Projects/AU/mo/app.io/src/app/app.module.ts
My app.module looks like this:
export function configFunc (RestangularProvider, http) {
  RestangularProvider.setBaseUrl('...');
}

@NgModule({
    declarations: [
        AppComponent,
    ],
    imports: [
        BrowserModule,
        TranslateModule.forRoot(),
        SharedModule,

        RoutingModule,
        RestangularModule.forRoot([Http], configFunc)

    ],
    providers: [],
    bootstrap: [AppComponent]
})
export class AppModule { }

I am using:
Angular 4.0.0-beta.4 and   angular-cli 1.0.0-beta.26
Thanks!

Is this package still not compatible with angular 4? We are at rc.4 now and I would love to use it, but no dice so far. :)

@zenkkor team is working on it - my expectation that we will finishing next week.

@tairezzzz thanks for the response. Look forward using it!

Hi @zenkkor, We add version 1.0.0-beta.2, you can install it with tag "beta".

@logvinoleg89 thanks, works great!

Thanks @logvinoleg89 - will test it out today! :) Awesome


tour: [Confusing method name Abs in example]

Context: https://tour.golang.org/methods/1
Starting on slide 1 of the Methods tour, the examples frequently use a method:

func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

Shouldn't this be called Hypotenuse() or Hypot()?
Abs() is typically understood as "absolute value".   This discrepancy makes the examples in the tour very confusing.
In another example in the tour, there is a function Abs that actually implements absolute value...
Context: https://tour.golang.org/methods/3
func (f MyFloat) Abs() float64 {
	if f < 0 {
		return float64(-f)
	}
	return float64(f)
}

Then in the next slide, it goes back to an Abs method that implements hypotenuse instead
Context : https://tour.golang.org/methods/4
func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

This should also be named Hypotenuse.
There may be more examples of this misnomer.  I suspect that someone got a bit overzealous with a refactoring and renamed some functions incorrectly.

This has been brought up in the past. See my comment at https://github.com/golang/tour/issues/536#issuecomment-401058809.

Ahah, I see.   In that case, perhaps rename Vertex to Vector, and do away with the previous references to Hypot()?

Perhaps consider just give it a different name in both cases, because unfortunately, it really looks consistently wrong as it is now. Seconding the request to rename Vertex to Vector, I think that would help a bit. But even then I would rename the function, e.g. to something like Length() (not ideal as a shared function name, but I'd honestly prefer it), or really anything that doesn't carry the associative baggage that Abs() comes with. Other options that come to mind: Magnitude(), Distance(), DistanceToZero()... I'm not very creative here, sorry.
I think it's worth observing that this seems to crop up again every once in a while (and I was tempted to create a ticket, myself), so I think it's really strongly worth considering a change.


Github actions can't find this action

Hi,
A few days back I was able to successfully run the action but when I run today Github is unable to find the action.
Error Message:
Unable to resolve action papeloto/action-zip@v1, unable to find version v1

Same here, our deployment pipelines currently fail due to this

same here

@radugroza @rico-ocepek I think it's because the repo changed owner/name to vimtor
Check pull request #13

Surprise. It is breaking changes. Hope it will never happens again.

This is happening because someone clever decided to create an organization named papeloto and call this a hack...
See here.

Guys, just use vimtor/action-zip@1


Test branch

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


#720 Highlight matched text

Issue

close #720

Overview (Required)

Add hilight-matched-title feature.

Screenshot

Before
After

Thanks! We are talking about the design. Please wait 🙏

@S-H-Y-A
Thanks for challenging this implementation!

The designer suggest using pattern B. But if it is difficult can you implement B?

@S-H-Y-A
Thanks for challenging this implementation!

The designer suggest using pattern B. But if it is difficult can you implement A?

Ok, I'll try to implement pattern B.

I' ve done it!
Look at The pictures below and give me some advice if you have.
Screenshot

Light Theme
Dark Theme

@S-H-Y-A
Could you take a look a test for merging this?
> Task :app-android:testDevDebugUnitTest

io.github.droidkaigi.confsched2023.KaigiAppTest > checkNavigateToStampsShot FAILED
    java.lang.NullPointerException at KaigiAppTest.kt:76

io.github.droidkaigi.confsched2023.KaigiAppTest > checkNavigateToBookmarkShot FAILED
    java.lang.NullPointerException at KaigiAppTest.kt:123

> Task :feature:sessions:testDebugUnitTest

It should work now!

I found a fact that NullPointerExcption are thrown when value class is used as Default argument in Jetpack Compose
This is an example project.

😮


Test: Identify tests failing intermittently

The upgrader test that checks if disconnect and connect events are being emitted fails intermittently as well as https://github.com/libp2p/js-libp2p/actions/runs/5117265449/jobs/9200220113?pr=1779 as result of a stream reset which seems to be related to the identify tests not closing streams.
It also results in our node tests occasionally hanging which eventually get shutdown by Github's CI.
As @achingbrain mentioned perhaps we could instrument the setup of the tests with why is node running so that we could have a log dump when CI kills prolonged running tests. This isn't ideal as the logs will still be quite noisy but it can be a start.

I've turned on debug logging in this PR and the tests have obliged by failing:
libp2p libp2p is stopping +15ms
libp2p:transports closing listeners for @libp2p/websockets +15ms
libp2p:connection-manager closing 1 connections +16ms
libp2p:transports all listeners closed +1ms
libp2p:yamux sending GoAway reason=InternalError +874ms
libp2p:connection-manager stopped +1ms
libp2p:yamux sending GoAway reason=InternalError +2ms
libp2p libp2p has stopped +3ms
libp2p libp2p is stopping +0ms
libp2p:transports closing listeners for @libp2p/websockets +3ms
libp2p:connection-manager closing 1 connections +3ms
libp2p:transports all listeners closed +0ms
libp2p:connection-manager stopped +0ms
libp2p libp2p has stopped +2ms
libp2p:transports adding transport @libp2p/websockets +2ms
libp2p:transports adding transport libp2p/circuit-relay-v2 +0ms
libp2p libp2p is starting +2ms
libp2p importing self key into keychain +0ms
libp2p:connection-manager started +3ms
libp2p:connection-manager dial 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +3ms
libp2p:connection-manager:auto-dial not enough connections 0/50 - will dial peers to increase the number of connections +24ms
libp2p:connection-manager:auto-dial selected 0/0 peers to dial +1ms
libp2p:websockets dialing <IP_ADDRESS>:15001 +1ms
libp2p:upgrader Starting the outbound connection upgrade +22ms
libp2p:upgrader encrypting outbound connection to 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +2ms
libp2p:plaintext write pubkey exchange to peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +31ms
libp2p:plaintext read pubkey exchange from peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +3ms
libp2p:plaintext plaintext key exchange completed successfully with peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +0ms
libp2p:upgrader /yamux/1.0.0 selected as muxer protocol +3ms
libp2p:upgrader Successfully upgraded outbound connection +0ms
libp2p:connection-manager:connection-pruner checking max connections limit 1/300 +33ms
libp2p:circuit-relay:transport:reservation-store add relay 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +24s
libp2p:connection-manager dial 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +20ms
libp2p:connection-manager had an existing connection to 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +1ms
libp2p:mss:handle respond with "na" for "/ipfs/id/1.0.0" +209ms
libp2p:upgrader:error @http://<IP_ADDRESS>:32975/bundle-out.js:57457:38 +219ms
libp2p:circuit-relay:transport:reservation-store created reservation on relay peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +25ms
libp2p libp2p has started +52ms
libp2p:transports adding transport @libp2p/websockets +2ms
libp2p:transports adding transport libp2p/circuit-relay-v2 +0ms
libp2p libp2p is starting +1ms
libp2p importing self key into keychain +1ms
libp2p:connection-manager started +30ms
libp2p:transports no addresses were provided for listening, this node is dial only +2ms
libp2p:connection-manager:auto-dial not enough connections 0/50 - will dial peers to increase the number of connections +51ms
libp2p libp2p has started +2ms
libp2p:connection-manager dial 12D3KooWNvSZnPi3RrhrTwEY4LuuBeB6K6facKUCJcyWG1aoDd2p +3ms
libp2p:connection-manager:auto-dial selected 0/0 peers to dial +2ms
libp2p:connection-manager dial 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +3ms
libp2p:connection-manager:dial-queue loading multiaddrs for 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +2ms
libp2p:websockets dialing <IP_ADDRESS>:15001 +1ms
libp2p:upgrader Starting the outbound connection upgrade +44ms
libp2p:upgrader encrypting outbound connection to 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +4ms
libp2p:plaintext write pubkey exchange to peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +55ms
libp2p:plaintext read pubkey exchange from peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +3ms
libp2p:plaintext plaintext key exchange completed successfully with peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +0ms
libp2p:upgrader /yamux/1.0.0 selected as muxer protocol +3ms
libp2p:upgrader Successfully upgraded outbound connection +1ms
libp2p:connection-manager:connection-pruner checking max connections limit 1/300 +60ms
libp2p:mss:handle respond with "na" for "/ipfs/id/1.0.0" +59ms
libp2p:upgrader:error @http://<IP_ADDRESS>:32975/bundle-out.js:57457:38 +55ms
libp2p:mss:handle respond with "na" for "/libp2p/circuit/relay/0.2.0/stop" +12ms
libp2p:upgrader outbound: starting new stream on [ '/echo/1.0.0' ] +1ms
libp2p:upgrader No abort signal was passed while trying to negotiate protocols [ '/echo/1.0.0' ] falling back to default timeout +0ms
libp2p:upgrader:error @http://<IP_ADDRESS>:32975/bundle-out.js:57457:38 +22ms
libp2p:connection-manager:auto-dial not enough connections 0/50 - will dial peers to increase the number of connections +66ms
libp2p:connection-manager:auto-dial selected 1/1 peers to dial +1ms
libp2p:connection-manager:auto-dial connecting to a peerStore stored peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +2ms
libp2p:connection-manager dial 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +67ms
libp2p:connection-manager:dial-queue loading multiaddrs for 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +45ms
libp2p:websockets dialing <IP_ADDRESS>:15001 +0ms
libp2p:yamux sending GoAway reason=NormalTermination +134ms
    1) should emit connect and disconnect events
libp2p libp2p is stopping +82ms
libp2p:transports closing listeners for @libp2p/websockets +83ms
libp2p:transports closing listeners for libp2p/circuit-relay-v2 +2ms
libp2p:connection-manager closing 1 connections +14ms
libp2p:transports all listeners closed +1ms
libp2p:upgrader Starting the outbound connection upgrade +62ms
libp2p:yamux sending GoAway reason=NormalTermination +29ms
libp2p:connection-manager stopped +19ms
libp2p libp2p has stopped +22ms
libp2p libp2p is stopping +0ms
libp2p:transports closing listeners for @libp2p/websockets +21ms
libp2p:transports closing listeners for libp2p/circuit-relay-v2 +0ms
libp2p:connection-manager closing 0 connections +4ms
libp2p:transports all listeners closed +2ms
libp2p:connection-manager stopped +1ms
libp2p libp2p has stopped +7ms
libp2p:upgrader encrypting outbound connection to 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +22ms
libp2p:plaintext write pubkey exchange to peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +93ms
libp2p:plaintext read pubkey exchange from peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +3ms
libp2p:plaintext plaintext key exchange completed successfully with peer 12D3KooWHFKTMzwerBtsVmtz4ZZEQy2heafxzWw6wNn5PPYkBxJ5 +0ms
  191 passing (35s)
  1 pending
  1 failing
  1) libp2p.upgrader
       should emit connect and disconnect events:
     stream reset

Yamux is selected as a muxer, but then the interesting thing here is that it fails to negotiate identify and circuit relay/stop over the connection.  Yamux then closes the connection which I would imagine is what causes the reset.
libp2p:upgrader /yamux/1.0.0 selected as muxer protocol +3ms
libp2p:upgrader Successfully upgraded outbound connection +1ms
libp2p:mss:handle respond with "na" for "/ipfs/id/1.0.0" +59ms
libp2p:upgrader:error @http://<IP_ADDRESS>:32975/bundle-out.js:57457:38 +55ms
libp2p:mss:handle respond with "na" for "/libp2p/circuit/relay/0.2.0/stop" +12ms
libp2p:upgrader outbound: starting new stream on [ '/echo/1.0.0' ] +1ms
libp2p:upgrader No abort signal was passed while trying to negotiate protocols [ '/echo/1.0.0' ] falling back to default timeout +0ms
libp2p:upgrader:error @http://<IP_ADDRESS>:32975/bundle-out.js:57457:38 +22ms
libp2p:yamux sending GoAway reason=NormalTermination +134ms

So there may be a race condition on startup - are connections being opened before the protocol handlers are registered?

Should have been fixed by #1795 please reopen if it reoccurs.


[Event Request] Codeunit 80 - Sales-Post

Hello, we need a modification on standard publsiher "OnAfterFinalizePostingOnBeforeCommit". We need to have access to global variables "GenJnlLineDocNo", "GenJnlLineExtDocNo", "GenJnlLineDocType" and "SrcCode"
Is possible to modify event property GlobalVarAccess to YES ?
Some days ago I requested the same modification but in C90 https://github.com/Microsoft/ALAppExtensions/issues/161
Thanks,

In request #161 I made a new commentary. I don´t know if you are advised about messages written on closed requests.

Usually, closed issues aren't revisited. It's always better to create a new issue (or reopen the issue), if you have further questions.

Already done


Updates the plugin to work with PyQuil 2.13 and PennyLane 0.6

Description of changes:

Version bump to 0.6.0, updated requirements and setup.py

The way measurement statistics works has changed in the latest version of PennyLane. Now, rather than shots=0 referring to 'analytic' mode, there is a separate analytic argument. Further, the num_shots argument has been removed from Device.samples().

Tests that are no redundant due to the above change have been removed.

Drawbacks:
Note that there are two outstanding issues related to versions of PyQuil >= 2.11:

PyQVM is significantly slower compared to PyQuil 2.10

QubitUnitary no longer works with the NumPy Wavefunction Simulator (see https://github.com/rigetti/pyquil/issues/1059).

Once merged, a new release should be made to PyPI.

The test that fails (test_sample_values_hermitian) is a notoriously stochastic integration test 🙂 Re-triggering the build should fix it. The tolerance on that test is already quite high, and I'm not sure of the best way to make it 'more deterministic'?

It is pretty odd since the tolerance factors seem to respect calculated standard errors of the mean. Locally, I also see more frequent passes than fails. And yet on Semaphore I've seen only fails so far with the rebuilds. If all else fails, maybe just increase the no. of shots even more, or fix a random seed? I don't really have a better suggestion than that I'm afraid.

@josh146 I created a new branch with a much greater number of shots, but that too seems to be failing on the same test. I'm pretty convinced though that this is not an issue with the functionality itself, and am totally ok with merging this in to master. That will also unblock other PRs that need to start making their way in now.

Hmm this is really odd. As far as I can tell, the stochasticity from sampling should not lead to such frequent failures as we are seeing...
But yes, if it can be merged, we can look into it separately!

Looks like I finally have passing tests! Created PR #27 to merge into this branch, so we'll end up with passing tests here and then master.

Thanks for getting this passing @msohaibalam!


Incorrect link to the playground in the home page

The main web page:
https://www.npmjs.com/package/bootprint-openapi
contains a wrong link to bootprint-openapi playground. The link is
http://bootprint.knappmeier.de/
But the right one (I believe) should be
https://bootprint.knappi.org/

Should be fixed now, thanks


CopyNode is redundantly instantiated

Considering that CopyNode is extremely sparse, it seems a waste to instantiate it physically. In fact, this just became an issue for me since it turns out that Numpy does not allow tensors with more than 32 dimensions (probably reasonable), which prevents a CopyNode of that order (unproblematic) from being constructed. Use case-wise this crops up when using tensor networks for probabilistic models.
Is the tensor just being built to satisfy the Node superclass? Or is there a deeper reason?
Controversially, the core Node class should maybe not contain tensors by default to facilitate the construction of structured nodes (e.g. subnetworks, symmetric nodes, etc). This seems to be touched upon in #62.

We can (and should) actually do this pretty easily now.
We set node.tensor to be a @property already, so all we would need to do is override it in the CopyNode class to be a lazy creation, and if someone uses the contract_copy_node method, then we never create the tensor at all.
On a higher level though, sparse and semetric Tensors are really poorly supported at the moment. We had a guy who was working on it (author on the other issue) but he is out on paternity leave right now.

Haha, we have a TODO to do exactly what you want.
https://github.com/google/TensorNetwork/blob/f86d8357b6365f31a0b8dc80967aff05cae5bae8/tensornetwork/network_components.py#L299
I likely won't have time to get to this until late August/September, but I agree this should get fixed.

@Thenerdstation I have some time next week, if you want, you can assign the lazy-evaluation of copy-node to me.

@Thenerdstation, just curious, what's the plan for supporting (block) sparsity?

Making the tensor lazy makes great sense, but I am a bit unsure how to handle the call to super() in the CopyNode constructor? Since the standard Node class requires a tensor in its constructor, we'll either need to feed it a dummy or make it an optional parameter (or make the tensor node a subclass of some AbstractNode class). The dummy option seems less than ideal IMO.

what's the plan for supporting (block) sparsity?

We welcome PRs.
I'm a little busy with a research project right now, so don't expect any big updates from me until September

@MichaelMarien Sure! Go ahead and try to take this up.
There are 2 ways of going about it.

Either set node._tensor to None, or
Do what @Bonnevie suggesting and refactor the code slightly to allow for inheritance.

I would prefer option 2, though it will be more work.

added first try in #197 , let me know what you think

That was quick! Was playing around with my own implementation yesterday, and it looks very similar to what you arrived at (well, yours is cleaner :) )
Is there any reason you are still hanging on to set_tensor and get_tensor on top of the property methods? It seems redundant and like a potential pitfall.
Either way, thank you for reacting so promptly to the issue!

@Bonnevie I kept the set_tensorand get_tensormethods for backward compatibility (although now that I come to think of it, in the base class this is not needed). I seem to recall the plan is to deprecate these methods all together in favour of just using the tensorproperty.  Perhaps @Thenerdstation can confirm this.

One possible issue with the new implementation: the reordering methods will have to instantiate a tensor, which might not be necessary. Instead, you could store the effective permutation on the original _tensor and then apply the permutation when the tensor is constructed/retrieved.

@Bonnevie, first of all, you are definitely right and this would be an improvement! But for the CopyNode, I'm not sure how relevant these methods are anyway, as it is completely symmetric, i.e. no real use case for permuting? On the other hand, the BaseNode class can be used as a starting point for other "special" tensors for which this need may be more pressing. Given other priorities, I'd take it up only then, when the need is more clear, but feel free to add this enhancement!


Proposal - changing structure.refreshed signal and logic

NGL supports updating atomic coordinates (there's an updatePosition method on structure, and the trajectory viewer works this way). Currently however, there's not really a consistent way to listen for coordinate changes. A StructureComponent can have a trajectory, and listens for frameChanged to updates representations.
This is problematic when you have multiple parts of your app that might update coordinates, but all of which need to know when coordinates change.
This PR assumes Structure.updatePosition is the public API for updating atomic coordinates. This method has a new refresh parameter (default true, set to false for old behaviour) which will call Structure.refreshPosition, this recalculates bounding boxes etc and fires the refreshed signal which triggers representation rebuilds and which other code (i.e. your application) can subscribe to.
This also means StructureComponent doesn't need to listen for frameChanged on trajectory any more.
The main problem I can foresee if developers are already doing something clever calling updatePosition and then manually choosing what gets updated - in this case passing in false as the second argument will restore old behaviour
const structure = stage.compList[0].structure
newCoords: number[] = calcNewCoords(structure)
structure.udpatePositions(newCoords, true) // All representations updated automatically

const structure = stage.compList[0].structure
newCoords: number[] = calcNewCoords(structure)
structure.udpatePositions(newCoords, false)
// Manually choose which repr to rebuild etc.

Comments etc very welcome!

Thanks Fred for this!
What happens then in the case of a trajectory? If I understand correctly, the spatial hash would be recomputed which might hinder performance when playing a trajectory? This is a guess, I don't know what is actually the time penalty for this. Maybe this could be made an option for trajectories as there are limitations with the current situation which could be acceptable tradeoffs in most of the cases (e.g. contacts can not be computed consistently between trajectory frames if one does not explicitly trigger structure.refreshPosition() which is a limitation, but maybe there are few use cases).
As an aside, the secondary structure is only calculated once, at parse time, and it could be interesting to optionally "refresh" this information as well. Once again, this comes at a computational cost.

Let's talk about this with reference to editing as well, but one idea would be to upgrade the boolean refresh parameter to an object (cf. the what parameter in updateRepresentations)
type RefreshOptions {
  representations: boolean,
  secondary: boolean,
  hash: boolean
}
updatePosition (position: Float32Array|number[], refresh: boolean | RefreshOptions = true)

I've done some benchmarking using a trajectory on a medium sized system (400 residues, no water displayed)
The re-computation of the spatial hash is only perceptible in the profiling tools if I throttle the CPU. Then it takes less that 1% of the rendering time. I take into account the whole refresh routine (incl. bounding box...) it's 3%. In absolute value it's 0.6ms out of 18ms rendering time. I've compared with the previous version (without refresh) and it's consistent with the measured timings.
So, I think it's fine to simply do the refresh as you suggested in this PR.
But, I've also tried to run the NGLviewer using the ?debug=y url parameter. In the console.log, I can see multiple calls to getBoundingBox (x3) and to StructureView.refresh (x8) for the same frame, see the comparison bellow (times should not be compared due to throttling)

I don't know if this should be investigated? Are StructureView.refresh() somehow also triggered by each representation?

After some more digging in the code, a StructureView object is created for each representation and each one attaches to Structure.signals.refreshed. The listener is the StructureView.refresh() function which updates some properties of the StructureView such as the boundingBox, center and some atomSets. This refresh function was apparently previously only triggered when a change of selection was being made.
It seems genuine to update the coordinates of the bounding boxes for each representation in the context of what this PR does, so I don't really think there is an issue here (except the unnecessary recomputation of the atoms sets).
I'll investigate what can be done for the secondary structure update.
I also would like to check what is happening for the contact representations.


Fix for not all CREATE/DELETE Relationship requests coming through, during submission entity lookup

Description
The entity lookup modal used during submission has options to create/remove multiple relationships at a time. Currently however, REST is sometimes overwhelmed by getting too many of these requests at once, and some relationship creations/deletions might not come through.
This PR ensures that the requests are sent synchronously. This makes it so REST only receives them one at the time, and can process them one by one.
Ideally, these type of issues can be avoid all together with the proposed submission refactor ( #858  ).
Instructions for Reviewers
List of changes

Removed the "Select/Deselect all" options from the dropdown in the DynamicLookupRelationSearchTab template, as well as the select button next to the dropdown.

Until #858 is resolved, the load would be too high anyways.
Users can still choose a larger page size, choose "Select page", and create a large amount of relationships that way.

Added a requestQueue to RelationshipEffects.
The constructor starts the executeRequestsInQueue() method, which listens to the queue and calls either addRelationship() or removeRelationship(). It'll only start with the next request, after the previous one has completed.
Added a RelationOperationType enum and RelationOperation interface. This is how the queue gets its relationship info and knows what to include in the request.
Instead of calling addRelationship() or removeRelationship() directly, the effect just adds Operations to the queue.

How to test

Make sure entities are enabled.
Make sure you already have multiple, local Person entities.
Start a submission in a collection which has the submission-process "Publication" configured.
Open the author lookup modal (and the Network tab in DevTools).
On the tab "Local Authors", when clicking "Select page", verify the POST request are being sent one by one, and don't overlap.
On the tab "Local Authors", when clicking "Deselect page", verify the DELETE request are being sent one by one, and don't overlap.

Checklist

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
[x] My PR passes ESLint validation using yarn lint
[x] My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
[x] My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
[x] My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
[x] If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[x] If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
[x] If my PR fixes an issue ticket, I've linked them together.

@nona-luypaert : Apologies for the delay in getting to this PR.  Would it be possible to also create a port of this PR for the main branch?  That'd make it easier for me to test this also on 8.x to ensure it works for both 7.x & 8.x.

Hi @tdonohue , opened following PR for main: #3040


test release

Pull Request Test Coverage Report for Build 4a41a339063e142beaf3dfee274e770c8113132d-PR-32

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

Totals

Change from base Build 4f51b8a977e8efae6e34699329a77909a115a237:
0.0%

Covered Lines:
173

Relevant Lines:
182

💛  - Coveralls


Patch onOutsideClick default value in the DayPickerSingleDateController

Fixes #1114
Whoops, I changed the way the DayPickerSingleDateController onOutsideClick prop looked to better match the DayPickerRangeController, but did not update the default prop value.
to: @ljharb @ricardobrandao

Coverage remained the same at 84.824% when pulling 083f1c0120e4fb14e8055c26a5f7927f11f1792b on maja-patch-onOutsideClick-defaultProp-value into db0c49bb64543a451b096cc6d9ffdc007d04ee56 on master.

@ljharb I think this requires both a full mount and actually simulating an outside click on the component to test... :/ I will think about how best to approach this problem.


Documentation for Gradient Ascent in DIGITS

Don't Merge!
Documentation for Gradient Ascent in DIGITS

Closing for now, since I also closed https://github.com/NVIDIA/DIGITS/pull/968.
I've backed up this work at https://github.com/lukeyeager/DIGITS/tree/backup/lucas/gradient_ascent_docs.


90 Add to_dict to DockerImage class

Add to_dict method to DockerImage class
This method returns a python dictionary representation of the DockerImage and the derived Image class.
Resolves: #90
See also: #87
Signed-off-by: TileThePlane<EMAIL_ADDRESS>

@nishakm I have squashed the two previous commits and revised for the message limit. Thanks for reviewing!

@TileThePlane I cannot merge this until you fix the author of your git commit to match the email in your Signed-off-by:
commit 4cc868c5d3fbc086123b6c39a721c3f3de676a18 (HEAD -> TileThePlane-90-Add-to-dict)
Author: Kyle<EMAIL_ADDRESS><-- author part
Date:   Mon Oct 1 03:21:11 2018 -0700

    90 Add to_dict to docker_image.py

    Add to_dict, DockerImage

    Signed-off-by: TileThePlane<EMAIL_ADDRESS><-- Signed-off-by does not match Author

You can changes your Signed-off-by and update your PR.
Otherwise, the code works. Thanks for working on this issue!

@TileThePlane if you want to update the Author of the commit you can do git commit --amend --author="Your Name<EMAIL_ADDRESS>The string "Your Name<EMAIL_ADDRESS>should match your Signed-off-by. Then the dco-required label will go away. I hope this helps

@TileThePlane your Signed-off-by email needs to be in < >
commit f216779d1295d5f39baa201c9520afc4cbd5e430
Author: Kyle<EMAIL_ADDRESS>Date:   Mon Oct 1 03:21:11 2018 -0700

    90 Add to_dict to docker_image.py

    Add to_dict, DockerImage

    Signed-off-by: Kyle<EMAIL_ADDRESS><--- needs to be<EMAIL_ADDRESS>
Have you setup your gitconfig yet? See here: https://github.com/nishakm/puns#how-to-configure-your-git

@nishakm The dco-required label is now removed. Thanks for your patience. I appreciate your opening an issue for a good first PR. Cheers!

@TileThePlane Thank you! It looks good to me 👍 Contribute here anytime!


Memory leak?

index.js:1 Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.
in CalendarDataProvider (created by FullCalendar)
in FullCalendar (at View.jsx:62)
in FullCalendarBlockView (at DefaultView.jsx:46)
in div (at DefaultView.jsx:39)
in DefaultView (created by Context.Consumer)
in injectIntl(DefaultView) (at View.jsx:233)

I haven't actually run the addon (although it looks really good), I think it may be due to the setTimeout() call here:
      setTimeout(() => {
        if (!isFullCalendarLoading && calendarRef.current) {
          let events = calendarRef.current.getApi().getEvents();
          setStoredEvents(events);
        }
      });

When setting state you need to check if the component is still mounted. See https://usehooks-typescript.com/react-hook/use-is-mounted


Create HTML Page

Handlebars template.
Image
Nav Bar
Mobile First
Add initial styling to css
Section for each part of the page that are siblings of each other.
Media queries for all devices

Mostly completed by Brian W. Will continue with minor edits. Everyone contributed small portions to this.


Dockerizing activity feed app for ESM integration

Pull requets cancelled as Feature shuld be merged against develop in 1st instance instea dof moving tyo Master.


Clean up components for demo

Tour

Moved the larger props out into constants so the Joyride component is more easily interpreted. I would suggest folding the tourCallback and tourSteps since they're not super important to get the point across.
Another thing that would be good to do here is give some brief context on what react-joyride is. Referring to it as "an open source tour UI library" and likening it to tour components that the prospect would have in their codebase would be good.
Chip

Updated the chip look to make it more visible in the UI.

Created a new component called ChipTip to house (and obfuscate) the decoration aspects of the chip so we can more easily map SB state and SDK methods to modify state to the UI.
Here we can point to how the visible prop consumes SB state and the onClose prop initiates the state change via the SDK.

Looks great! A logical next step might be hacking together some hooks for accessing switchboard state to simplify those bits but we can probably hold off on that until we get more feedback.


[SRO] Add LC card UI

Describe your changes

create proper LightConeCard UI
create string translations for light cones and add them to card and editor
fix LightConeEditor to be able to edit/update existing light cones properly
fix Erudition path svgicon to no longer have invalid path code embedded inside
fix relic localization strings to reference Relic instead of GO Art
extreme style/nit: change from mixing translated string calls as t`string` to strictly using t('string') in LC/relic

Notes:

Superimposition TL string does not use <1>{value}</1> to add 1/2/3/4/5 on the cards anymore: the original is not reusable with the SuperimposeDropdown component, and the visual clarity from bolding the number seems minimal from inspection that we could simply make the TL string more reusable
Added the Lv. portion of a level to be a TL string: I don't know if this matters, but if "Level" is a different word in multiple languages, would it make sense to assume that its abbreviation "Lv." would also be abbreviated differently and therefore translated differently? Does this matter at all?
LightConeEditor is still following RelicEditor closely in terms of UI: currently, there's no way to load light cone sheets as UI data yet. Not sure if adding this ability to edit existing light cones in the manner it's written right now will be worth since it's handled differently in GO, and if we want exact parity with GO on this case, it'll probably end up being removed in a later PR
Still missing ways to save DB UI settings in SRO so we can add sort/filter options to relics/LCs

Issue or discord link
Part of resolving #2314.
Testing/validation
New light cone card UI

Editing existing light cone

Light cone inventory after editing Bronya LC from S3 -> S1 and Lv. 60/70 -> Lv. 80/80

Checklist before requesting a review (leave this PR as draft if any part of this list is not done.)

[ ] I have commented my code in hard-to understand areas.
[ ] I have made corresponding changes to README or wiki.
[ ] For front-end changes, I have updated the corresponding English translations.
[x] I have run yarn run mini-ci locally to validate format and lint.
[ ] If I have added a new library or app, I have updated the deployment scripts to ignore changes as needed

extreme style/nit: change from mixing translated string calls as t`string` to strictly using t('string') in LC/relic

@tiffanynwyeung Can you elaborate why you prefer the latter style? I would honestly prefer the template literal notation for translations, its more compact.

extreme style/nit: change from mixing translated string calls as t`string` to strictly using t('string') in LC/relic

@tiffanynwyeung Can you elaborate why you prefer the latter style? I would honestly prefer the template literal notation for translations, its more compact.

I've never seen us use the tag template notation for anything the function notation doesn't cover. And function notation is more well known imo. Just my 2c

@frzyc

There are existing Lv. translations in DM as well, I am not sure if we have handling in our pipeline to handle the {SPACE} syntax

Good catch on that + the other DM string suggestions, I keep forgetting that we can use DM translations out of there and I should make sure to remember to use that option more often. As far as I can see, we do have Lv already extracted in sheetHashData but not used anywhere at the moment, but I also can't find any processing to extract any of the {SPACE} syntax in certain langs in that file or anywhere else. I could try and look into how to do this in another PR after switching to those DM strings in this one?

Can you elaborate why you prefer the latter style? I would honestly prefer the template literal notation for translations, its more compact.

To piggyback on what @nguyentvan7 added, outside of function notation being more well-known, we already fall back to using it when needing to load certain values into a translation, e.g. in SubstatInput component we have this line:
https://github.com/frzyc/genshin-optimizer/blob/3a570923699d19499a0f27b1558edc1a0dab4ea9/libs/gi/ui/src/components/artifact/editor/SubstatInput.tsx#L78
which seems necessary as the TL string requires a custom number value passed in. (And I assume we'll have other similar cases as we port more features.)
My preference is if we could make notation usage more consistent overall. Since we use function notation by default in those cases, I thought it would be better to use that as the standard even with static strings. I'm also open to reverting this style commit and preemptively grouped most of those changes as such if we want to move this to a separate PR/overlook this style refactor, but my initial assumption was that this would seem somewhat excessive as its own PR when we could introduce it in small, iterative commits. Open to feedback about any of this, of course!

You are right, they are already translated in sheet_gen.json, you can use them directly:

I guess I don't have as much reservations towards the notation direction, as long as we are consistent.
Currently, in the repo, there are 426 instance of t`, that you will have to eventually address if you prefer the functional style (i think we can do it via a simple regex search and replace)

Sounds good, I'll do the notation regex-replace in a future PR, but leave the current notation changes in for now


Use portable script sourcing

Checklist

[X] Closing issues: #80
[X] Mark this if you consider it ready to merge
[ ] I've added tests (optional)
[ ] I wrote some documentation

Description
Replaced the non-portable calls to source in the Makefile with ..

Thank you


Array OOB access should be a compile error

E.g.
script;

fn main() -> u32 {
    let ary = [1, 2, 3, 4];
    let idx = 45;
    ary[idx]
}

This compiles fine but it shouldn't, at least in situations where idx is const-evaluatable.

This surprises me considering https://github.com/FuelLabs/sway/tree/master/test/src/e2e_vm_tests/test_programs/should_fail/array_oob
The only difference is the indirection via the idx var.  Obviously it's enough.

Yeah idx is considered a dynamic index, unless we run the const-evaluator on it.

I checked the code that returns the OOB access compiler error sway-core/src/ir_generation/function.rs#L1688.
In the case of the example above, the index_expr is compiled to an Instruction::Load with the value Instruction::GetPointer().
Maybe we can check the current block for an Instruction::Store of a const to the same pointer.

@esdrubal one way to do this is to leverage the const evaluator in https://github.com/FuelLabs/sway/blob/master/sway-core/src/ir_generation/const_eval.rs.

If the const evaluator passes on the index, then we can just replace the value with the evaluated constant and do the OOB checks on it.
If the const evaluator fails (it can only do so much, and not every expression is const-evaluatable), then we just don't do anything.

@mohammadfawaz Thanks for pointing me out to const_eval.rs. While using compile_constant_expression_to_constant I noticed that it is able to compile to a constant when index is a Literal. When it is a VariableExpression it doesn't know about variables in the scope and may try to compile to the value of a global const over shadowing local variables.
I am working on a solution for this and will send a PR later today.


For science I killed one of my Type-3 Chihiro media boards. These were issued with Ver13.05.bin firmware.

From digging at the 3.17 firmware a lot of those don't exist in the handler, and some of them do but only have functionality gated to Triforce/Chihiro. Did you reverse a different firmware to get them? Maybe 4.01? Essentially, can you describe your fact-finding for posterity, it helps me to understand the net dimm more and give insight into other vectors of understanding.

Ah, I see you claim 13.05, Not familiar with that revision, it must be a Chihiro firmware that includes a netdimm version? What version does the netdimm in it report when you ask it for info using netdimm_info?

My method was quite crude, I simply edited your script to issue the commands 0x00~0xFF and watched the serial output of the net board.
The media board firmware is the hacked firmware (4.02?), and the net board firmware is 13.05 (although it has a set of jumpers to use a backup 11.0X version).

Oh by the way. I have a thread on AP with some random info about Chihiro Type-3, perhaps you'd be interested. Has serial logs from the netboard in the first post.
https://www.arcade-projects.com/threads/random-chihiro-type-3-info-thread.13466/

Ah yeah, I was using the debug serial to try to RE the internet IOCTLs to try to add network support to Naomi homebrew games.

Perhaps you'd be interested in my 2nd post, I'm fairly certain there's a dev net firmware for Type-1's in the firmware update util for Chihiro. See: main.0317xd, has some interesting strings compared to it's counterpart main.0317 and never gets flashed.

Possibly it would help. I'm like 200% sure that my mis-handling of the control response is the root of all of my IOCTL troubles. I'm pretty sure the structure pointed at by that is where the netdimm reads params for IOCTLs and writes responses. The style of code they used for the Naomi BIOS as well as the netdimm, however, uses a lot of code pointers and as a result Ghidra struggles. Also, MAME does HLE of the netdimm board so watching traffic between the two isn't really possible. Maybe I'll figure it out someday.

So coming back to this... I personally find it easier to work with C++ so I rewrote this and extended to my needs. https://gist.github.com/GXTX/1ece7ba9449cfa7094682c1035f52da6
There's actually a hidden command at 0x22, and from my testing I think I finally understand it...
It seems like it's a 0x04 but causes the Mediaboard to erase the entire contents of the RAM before writing it's contents.
I confirmed this by:

Download address 0x0~0x80
Issue 0x22 with an offset of 0x0 and data (0xAA55AA55)
Download address 0x0~0x80

The original download request will have what ever contents were stored in RAM (aka random garbage on a bootup), the second will only contain 0xAA55AA55 and then 00's for the remaining 0x7C bytes.

Bit more poking around with the commands. A fair few are just NOP, at least on Chihiro. Updated list.
https://gist.github.com/GXTX/1ece7ba9449cfa7094682c1035f52da6#file-a-cpp-L43
Also documented the DIMM_MODE stuff for Chihiro. It appears that it only spawns some type of "Coin" thread.

Documented and tested out both WRITE_TO_FLASH & 2NDBOOT_UPDATE.
https://gist.github.com/GXTX/1ece7ba9449cfa7094682c1035f52da6/revisions
Still unsure of 0x22, appears to have a max offset of 0x100000? Did you play around with this at all @DragonMinded ?

No I didn't. My focus was mostly on reverse engineering the state management and control stuff so that I could have kiosk mode working flawlessly, port a gdb stub to my libnaomi library for on-target debugging and also allow PC->homebrew and homebrew->PC communication for the on screen menu.


Build Problems With Flutter_Quill

Hi All,
I have a problem, and i cannot found any reasonable solution.
My currently pubspec.yaml status is
dependencies:
  flutter:
    sdk: flutter
  flutter_localizations: # Add this line
    sdk: flutter
  shared_preferences: ^2.0.5
  webview_flutter: ^1.0.7
  font_awesome_flutter: ^9.0.0
  http: ^0.13.1
  intl: ^0.17.0
  focused_menu: ^1.0.5
  path_provider: ^2.0.1
  open_file: ^3.1.0
  flutter_quill: ^1.1.8
  universal_html: ^2.0.8

Only added flutter quill and universal_html,
But now, i cannot build up project, giving to me an error, there is no implementation of "TextSelectionDelegate.userUpdateTextEditingValue" method.
Platform -> Android 11 (emulator), Android 5 (real device)
Problem occurs in Gradle Build,
Stack is;
/E:/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_quill-1.1.8/lib/widgets/raw_editor.dart:95:7: Error: The non-abstract class 'RawEditorState' is missing implementations for these members:
 - TextSelectionDelegate.userUpdateTextEditingValue
Try to either
 - provide an implementation,
 - inherit an implementation from a superclass or mixin,
 - mark the class as abstract, or
 - provide a 'noSuchMethod' implementation.
class RawEditorState extends EditorState
      ^^^^^^^^^^^^^^
/E:/flutter/packages/flutter/lib/src/services/text_input.dart:822:8: Context: 'TextSelectionDelegate.userUpdateTextEditingValue' is defined here.
  void userUpdateTextEditingValue(TextEditingValue value, SelectionChangedCause cause);
       ^^^^^^^^^^^^^^^^^^^^^^^^^^
/E:/flutter/.pub-cache/hosted/pub.dartlang.org/flutter_quill-1.1.8/lib/widgets/raw_editor.dart:1025:8: Error: The method 'RawEditorState.hideToolbar' has fewer positional arguments than those of overridden method 'TextSelectionDelegate.hideToolbar'.
  void hideToolbar() {
       ^
/E:/flutter/packages/flutter/lib/src/services/text_input.dart:829:8: Context: This is the overridden method ('hideToolbar').
  void hideToolbar([bool hideHandles = true]);
       ^

Usage;
import 'package:flutter_quill/flutter_quill.dart';
import 'package:flutter_quill/widgets/controller.dart';
import 'package:flutter_quill/widgets/editor.dart';
import 'package:flutter_quill/widgets/toolbar.dart';
.....
....
...
QuillToolbar.basic(controller: quillController),
Expanded(
  child: Container(
    child: QuillEditor.basic(
      controller: quillController,
      readOnly: false, // true for view only mode
    ),
  ),
),

and their imports.
Also tried on empty project. Result is same.
Done before opening issue,

Searched on Google
Inspect on OpenSource code
Readed Document well (over and over) (Pub.dev, Github )
Tested on Empty Project (Android)
Searched same issue on Github
Try to change and fix to problem

Sorry, i cannot found any solution.
Thanks for any answer.

Which Flutter version do you use?

Flutter 2.1.0-12.2.pre • channel beta • https://github.com/flutter/flutter.git
Framework • revision 5bedb7b1d5 (4 weeks ago) • 2021-03-17 17:06:30 -0700
Engine • revision 711ab3fda0
Tools • Dart 2.13.0 (build 2.13.0-116.0.dev)

Yes the problem is that you are on the beta channel. We currently don't support the Flutter beta channel. If you can, I recommend you to switch to the stable channel.

Thank you. It's fixed


Removed "using namespace std;"

Removed all occurences of using namespace std;, all of which were in headers.
Generally using namespace std; isn't really, uhh... good
(Event removed it from external libraries cause we include them <3 )

From which external libraries did you remove this?


Fix generation for UUID type

managementserverid has been added as a parameter in some APIs (listAsyncJobs, readyForShutdown, etc.) in 4.19. Generated output doesn't have the setters for managementserverid field in toURLValues() method.

@weizhouapache @rohityadavcloud Please review.


Update data doesn't works

Hi guys,
i'm trying to update my data, but when i execute update doesn't works. Why ? Any suggestions ?

Difficult to find the problem without code sample.

You right. I have this array of data, something like that:
$data = [
'code' => 'it',
'en' => [
'title' => 'en title',
'description' => 'en descrive'
.....
]
];
and then
$this->model->fill($data)->save() or $this->model->update($data)
What i'm forgot to to?

Use the fill method directly on the main model:
$this->model->fill($data)->save();

Ok, i'll try, Thank for that awesome package for now!!!


What is the meaning of data processing

I’m looking at your data processing tutorial, but I don’t understand what this process is doing. I think many people who use REINVENT need to understand. Do you have data processing documentation and why do you want to process data like this?

Thanks for highlighting this. Will add some clarification to the notebook.
To answer your question: there are two main reasons to clean up the training data.

Get rid of unusual compounds that are clearly not drug-like (too big, reactive groups and etc.). There is normally no point training your model on such examples. And if you still need to reach some unorthodox location of  the chemical space your scoring function can take you there during the reinforcement learning.
There is a number of tokens that occur only for some instances. Again, these are rare compounds and can be seen as outliers. Excluding them frees a slot in the vocabulary and makes it smaller. Smaller vocabulary means faster training and less memory. As a result removing compounds that introduce rare tokens to the vocabulary speeds up your model.

There might be a good reason to include certain compounds and tokens that we have excluded and in that case you can re-run the notebook with your specific criteria.
However, the data used as an input in the current example is already purged so you cant see much difference between the input and the output. If I have the time I will re-run the notebook on some raw chembl input to show the clear contrast. Still, only a small portion of ChEMBL is actually removed.
Again, we appreciate the feedback so please, let us know if you find other parts of the tutorial unclear.


Navigation fixes & documentation

https://csc-guide-preview.rahtiapp.fi/origin/breadcrumbs-documentation/

LGTM, what's new breadcrumb issue was a good catch!

#1480 coming back to haunt us! :grimacing:


refactor: icon to icons for toasts component

SUMMARY
This component migrates the icons for the toast component to the new icons.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS
Manually pulling the branch to hack the toast to present would be the easiest to test as hacking error in ephemereal envior nment is much harder.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

/testenv up