Metadata or log file with description of image design process

(The tool is really great as is! I'm enjoying using it a lot!)
It would be nice to see a line-by-line description of the process I used to create an image, so that I can learn which prompts and settings led to a good final image, for future reference.
Describe the solution you'd like
For each Dream or Img2img action that is successfully performed, create a line of text in a log file including:

the current Prompt Text (positive and negative)
name of Model file used (and Hypernetwork, if active)
Seed
Sampler
Steps
CFG
Resolution
Whether txt2img HRfix is turned on
if img2img, include Denoising Strength
(other relevant settings I might have forgotten about)

In case of a Mask being drawn, or use of Color Brush, or Layer manipulation, or any other actions, add a short line of text equivalent to what is recorded in the History bar.
(Optional: Remove log lines when its action is undone, but keep recently undone lines ready to add back in case of "redo". Alternatively, include the fact that "undo/redo" was used in the log file.)
When the user clicks "Save canvas", write out a log file with the same name as the image output file (different extension). Or, if the image file format is compatible, write the log text to the image metadata ("caption").

Sorry for taking so long!
Your idea of logging information about the edit history sent me through a rabbit hole and in the end I decided to implement a full session management system on top of this request!
For now (sadly) I have not implemented logging yet, but you can now save the current workspace state and load it later from the save file.
Now it is probably easier than ever to implement your request, so I will get to that tomorrow!

Should be on main already, so will be putting to eval.

Will be closing this issue as the feature has been implemented. If there are any changes you would like, @Kextrii, just send a message here or open a new issue!

Nice! It took me a minute to figure out that I needed to click on the scroll icon in the history sidebar. That's extremely helpful!
What about having a check box next to the "Save canvas" that would automatically save the log file at the same time as saving the image?

Will give this a look


Artemis removes stack traces from failure output

Describe the bug
Artemis removes stack traces from failure output.
To Reproduce

Let a test fail with:

fail(stacktrace);

Expected behavior
Artemis should not magically remove parts of the failure message.
Screenshots
Actual:

Manually replaced the tab characters in the stack trace with spaces (preventing the Pattern to match):

Environment

https://github.com/kit-sdq/Artemis-SAML2-Test-Docker
@dfuchss

The lines with the stack trace get intentionally removed here
https://github.com/ls1intum/Artemis/blob/5f09c792d47a74a7215bd05bd3c909ceecfcc429/src/main/java/de/tum/in/www1/artemis/repository/FeedbackRepository.java#L188
to reduce the failure message to only the most relevant part with the actual message.
If you replace the tab with spaces the lines no longer match \tat  and are not removed.

Thanks @b-fein.
I am the strong opinion that the instructor should actually decide how much information the students get.
If I explicitly fail the test with
fail(somemsg)

I would expect that that is the message the students get. Instead, Artemis "magically" alters the string. For somebody not familiar with the internals this seems a lot like a Bug (like it did to me).
My proposed solution would be:

Removing the filtering from Artemis, or at least make it adjustable with a property.
Add an annotation @HideStackTrace to "The Artemis Java Test Sandbox".

What's your opinion on this? @b-fein @krusche @dfuchss

Keep in mind that Artemis is mainly used by programming beginners who might have no clue about programming.
There are basically two reasons why we decided to remove stack traces. (By the way: this is not really magical, we just remove everything after the first line, at least this was the initial implementation, which might have become a bit more complex since then).

Provide beginner-friendly error messages. In my experience, stack traces and programming language error messages are most of the times hard to understand. The designers of a programming exercise should take some time and try to come up with explanations for error messages that can be understood by the students at their specific level. On the other hand, good feedback should be short and should not reveal the solution. If students receive too much and too detailed feedback, they might not read it.

Stack traces might reveal some test internals and might make it easier for students to identify the solution. Let's assume you have a test case with a method name that reveals some information about what the test does. Then, instructors typically do not want to reveal the name in the feedback.

I agree that it might be desirable for the instructor to specify how much details in the feedback are shown, but the question would be on which level. Do you want to specify this for each test case (could be quite time-consuming) or on an exercise or even on a course level? Also keep in mind, that each configuration option makes it more difficult to use Artemis.

(By the way: this is not really magical, we just remove everything after the first line, at least this was the initial implementation, which might have become a bit more complex since then).

I meant magical in the sense of on the first impression there was no obvious filtering (I could fail with multiline messages) but then Stack-Traces were cut off. Firstly, I assumed a bug in the test.

1. Provide beginner-friendly error messages. In my experience, stack traces and programming language error messages are most of the times hard to understand. The designers of a programming exercise should take some time and try to come up with explanations for error messages that can be understood by the students at their specific level. On the other hand, good feedback should be short and should not reveal the solution. If students receive too much and too detailed feedback, they might not read it.

That is true. But on the other hand the instructor knows at which level his course is and may create his tests accordingly. We like to provide Exceptions because it gives a hint on where a mistake in the program could be.

2. Stack traces might reveal some test internals and might make it easier for students to identify the solution. Let's assume you have a test case with a method name that reveals some information about what the test does. Then, instructors typically do not want to reveal the name in the feedback.

In our tests the exceptions thrown in submissions are caught and the part of the stack trace containing test classes gets cut off (See screenshot). The modified Exception is then rethrown.

I agree that it might be desirable for the instructor to specify how much details in the feedback are shown, but the question would be on which level. Do you want to specify this for each test case (could be quite time-consuming) or on an exercise or even on a course level? Also keep in mind, that each configuration option makes it more difficult to use Artemis.

I think the best solution is to disable filtering in Artemis completely because

It provides full control on the instructor. fail(msg) would exactly print msg to the students
AJTS provides an annotation @PrivilegedExceptionsOnly to disable submission Exceptions
Then running mvn clean test yields the same results.
No changes in the Artemis UI are needed, the changes in the server are minimal.
New instructors may face the same question I did, especially if they are not familiar with Artemis internals

Hello all,
First of all, the views have advantages and disadvantages as mentioned in all posts.
I would recommend that no matter what solution is chosen for the issue, changes to the original message should be made clear.
For example, if deleting the stack trace, a line could be added to the end of the new message "[stack trace omitted]".
Then it would have been clear that Artemis removed the stack trace.


Outline Select I

@siriwatknp I'm starting on this. Should I do 5 different Select Styles? Also should we put the datepicker design in its own category on the website?

I think the "Download" design and 3 dot icon designs are Menus not Selects.
The datepicker design is like a mix of Select and Datepicker. So should this go under Styles Custom Component section?
I'm not really sure how to make the "Unit" design that lets you type in the input of the select. But I do think it belongs in Select category.
The "sort by name" select seems the most straight forward. I'll do that first.

I have completed one of the five designs:

Should I create a pull request for this and create 4 more github issues to track the other designs? @siriwatknp

I agree with you. Let's open PR for this design.

I think the download one is quite similar, so you can open another issue with the name you like!

Sounds good. I'll do that now.


Format graphs

The c3js graphs need further modification to make them look better and readable

So far they seem to fit the need. However it would have been nice to consider other libraries however it seems we are running out of time and thus we might not be able to do that. Closing it for now.


Slack channel

Would you be interested in creating a Slack channel (or similar) for development discussions?

sure thing, join https://d3-slackin.herokuapp.com/ (https://d3js.slack.com) and hop in thhe the #vx channel


feat(stat-plot): stat plot shows sub stats

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Refactor diagram import and export code

I noticed that the diagram import/export code from #25 contains a lot of repeated code. This PR does some refactoring:

Move import/export/error dialogs to a seperate file dialogs.py
Define enum FileFormat for supported file format instead of relying on stringly typing
Utility method show_error_msg to display error messages

Yeah it is probably best to split it up into other files like this.
I think it would also be good to have a "any supported filetype" option, but that is an additional feature while this is a refactor, so that is maybe best reserved for another PR.


Polyline route doesn't adjust itself when map is rotated by fingers

Here, I'm attaching the issue recording video. You'll see that path remains in the same position if we rotate the map by pinching it.
https://drive.google.com/file/d/1vZsoDD-szx1ZzJToeq-U7jnTonZgCQNO/view?usp=drivesdk
Can you help?

Support for rotation is added in a newer version that is yet to be pushed.
My github account is not accessible for some time now. Just contacted
github support. We will resolve this soon.
On Fri, Aug 21, 2020 at 11:23 AM irfan-429<EMAIL_ADDRESS>wrote:

Here, I'm attaching the issue recording video. You'll see that path
remains in the same position if we rotate the map by pinching it.
https://drive.google.com/file/d/1vZsoDD-szx1ZzJToeq-U7jnTonZgCQNO/view?usp=drivesdk
Can you help?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/amalChandran/trail-android/issues/28, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBO2CDJM42ENGFU3GI2K43SBYDXDANCNFSM4QG5SIJA
.

--
Amal

Sure thanks, once updated. Let me know here. I'll close the issue.

How much will it take to update to new version?


dockerclient: copying a directory from another stage should discard perms

Copying a directory from another stage shouldn't preserve the permissions of the directory itself, to be compatible with the behavior we see in docker build.

LGTM
@flouthoc @TomSweeneyRedHat @umohnani8 @flouthoc PTAL

Sorry I missed this yesterday. But PR LGTM


reuse of existing ingress load balancer fails in a weird way

I've noticed a problem of hetzner-k3s in combination with ingress-nginx. I'm not sure wether this is a problem of hetzner-k3s or the
hetznercloud/csi-driver, so I'm posting it here.
Basically the problem is as follows:

create cluster with hetzner-k3s create, without any resources pre-existing
configure ingress as described in the Wiki (steps 7 - 11); load balancer is created and becomes healthy
destroy cluster using hetzner-k3s delete (the ingress load balancer is not deleted)
repeat steps 1 and 2
new targets for the load balancer won't be set up, ingress dysfunctional, without any targets

This obviously means that recreating a cluster will leave it in a bad shape. I also wonder what will happen when nodes are added/replaced during the lifetime of a cluster since the targets configuration apparently is not very stable.
Detailed description to reproduce
I'm using hcloud-k3s Version 1.1.4 (even if --version reports 1.1.3, but that's expected).
My cluster_config.yaml:
---
cluster_name: lb-targets-test-cluster
kubeconfig_path: "../kubeconfig"
k3s_version: v1.28.2+k3s1

public_ssh_key_path: "~/.ssh/id_ed25519.pub"
private_ssh_key_path: "~/.ssh/id_ed25519"

use_ssh_agent: false
ssh_allowed_networks:
  - <IP_ADDRESS>/0
api_allowed_networks:
  - <IP_ADDRESS>/0
private_network_subnet: <IP_ADDRESS>/16
disable_flannel: false
schedule_workloads_on_masters: false

cloud_controller_manager_manifest_url: "https://github.com/hetznercloud/hcloud-cloud-controller-manager/releases/download/v1.18.0/ccm-networks.yaml"

# NOTE: I've also tried version 2.5.1 instead of 2.4.0
csi_driver_manifest_url: "https://raw.githubusercontent.com/hetznercloud/csi-driver/v2.4.0/deploy/kubernetes/hcloud-csi.yml"

system_upgrade_controller_manifest_url: "https://raw.githubusercontent.com/rancher/system-upgrade-controller/master/manifests/system-upgrade-controller.yaml"

masters_pool:
  instance_type: cpx21
  instance_count: 3
  location: nbg1
worker_node_pools:
  - name: small-static
    instance_type: cpx21
    instance_count: 4
    location: fsn1

My ingress-nginx-annotations.yaml:
controller:
  kind: DaemonSet
  service:
    annotations:
      load-balancer.hetzner.cloud/location: nbg1
      load-balancer.hetzner.cloud/name: lb-being-tested
      load-balancer.hetzner.cloud/use-private-ip: "true"
      load-balancer.hetzner.cloud/uses-proxyprotocol: 'true'
      load-balancer.hetzner.cloud/http-redirect-https: 'false'

      load-balancer.hetzner.cloud/hostname: doesnt.matter.example.com

I create the cluster using hetzner-k3s create --config cluster_config.yaml and that works fine, a total of 7 servers is started and the lb-targets-test-cluster-api load balancer is started/configured and is healthy.
Then I configure the Ingress and it's Load Balancer:
helm upgrade --install \
  ingress-nginx ingress-nginx/ingress-nginx \
  -f ./ingress-nginx-annotations.yaml \
  --namespace ingress-nginx \
  --create-namespace

This creates the lb-being-tested load balancer, which after a while becomes healthy.
Then I destroy the cluster using hetzner-k3s delete --config cluster_config.yaml. All servers are being destroyed, the API load balancer is deleted but the lb-being-tested load balancer remains (as expected).
Then I re-create the cluster using hetzner-k3s create --config cluster_config.yaml again, which brings up (different) Hetzner servers, of course. The API load balancer is recreated and becomes healthy again.
Then I install ingress-nginx using Helm, just like before.
I would expect that the existing Load Balancer (and, most importantly, it's public IP address) is reused. However, no targets are configured on the load balancer, thus it doesn't become healthy. So, no ingress.
Side note: weird LB behavior after deleting the cluster
When deleting the cluster using hetzner-k3s without manually removing targets from the load balancer, the lb-being-tested load balancer configuration is left as-is (as it is not managed by hetzner-k3s). Targets disappear very slowly (supposedly garbage collected by Hetzner itself) but the Hetzner UI shows inconsistent information about the targets, see here:

Here it says "4 servers" but also "no targets".
Workaround
The problem is avoided by manually removing all targets from the load balancer, before deleting the cluster.
for id in $(hcloud load-balancer describe lb-being-tested -o json | jq '.targets[].server.id') ; do hcloud load-balancer remove-target lb-being-tested --server "$id" ; done

Note that even if targets are not manually removed, the load balancer will eventually show "no targets" automatically after deleting the cluster. This takes a few minutes(!). However, the load balancer is still not reconfigured properly after re-creating the cluster.
Detailed commands, logs
See here: https://pastebin.com/raw/XLe85iNr

Hi, I just tested twice and I wasn't able to reproduce your issue. Each time I deleted the cluster, the targets were removed from the load balancer as soon as the servers were deleted as expected. When I recreated the cluster and reinstalled ingress-nginx, the existing load balancer was reused just fine and the new targets were added. Seems to work correctly for me. Perhaps you could raise this on the Hetzner Cloud Controller Manager project .

It should work like a charm. I use it very often, because I lock my LBs to not loose the public IP (like you).
I've a bit different controller config (type: LoadBalance):
controller:
  config:
    use-proxy-protocol: "true"
  service:
    type: LoadBalancer
    annotations:
      load-balancer.hetzner.cloud/name: my-name
      load-balancer.hetzner.cloud/location: fsn1
      load-balancer.hetzner.cloud/use-private-ip: true
      load-balancer.hetzner.cloud/algorithm-type: least_connections
      load-balancer.hetzner.cloud/uses-proxyprotocol: true
      load-balancer.hetzner.cloud/hostname: my-hostname

But I don't think this will make any difference.
I'll try it again, my be an issue with current version of hetzner cloud controller.
See this Issue:
https://github.com/hetznercloud/hcloud-cloud-controller-manager/issues/521

I'll convert this to a discussion since it doesn't seem to be a problem with hetzner-k3s. Thanks @derlinuxer for confirming it works for you too :)


microk8s inspect  on macOS 12.0.1 does not produce inspection report file

Whilst debugging microk8s issues testing on my MBP, I discovered that the inspect file is not actually created, or at least not where it says. I also tried sudo microk8s inspect, but that didn't make any difference.
% microk8s inspect
Inspecting Certificates
Inspecting services
  Service snap.microk8s.daemon-cluster-agent is running
  Service snap.microk8s.daemon-containerd is running
  Service snap.microk8s.daemon-apiserver-kicker is running
  Service snap.microk8s.daemon-kubelite is running
  Copy service arguments to the final report tarball
Inspecting AppArmor configuration
Gathering system information
  Copy processes list to the final report tarball
  Copy snap list to the final report tarball
  Copy VM name (or none) to the final report tarball
  Copy disk usage information to the final report tarball
  Copy memory usage information to the final report tarball
  Copy server uptime to the final report tarball
  Copy current linux distribution to the final report tarball
  Copy openSSL information to the final report tarball
  Copy network configuration to the final report tarball
Inspecting kubernetes cluster
  Inspect kubernetes cluster
Inspecting juju
  Inspect Juju
Inspecting kubeflow
  Inspect Kubeflow

Building the report tarball
  Report tarball is at /var/snap/microk8s/2645/inspection-report-20211118_123313.tar.gz
% ls /var/snap/microk8s/2645/inspection-report-20211118_123313.tar.gz
ls: /var/snap/microk8s/2645/inspection-report-20211118_123313.tar.gz: No such file or directory

Thank you for reporting this @NathanDotTo.
The path to the inspection tarball mentioned here is the path inside the multipass microk8s-vm.
We are about to merge a PR that would pull the tarball in your current directory.

The patch is fixed and will be available on the next installer release. For now the workaround is to pull the inspection tarball with: multipass transfer microk8s-vm:/<path to tarball> .


implementing block1 in client and server

I'm just opening this issue to signal that I'm working on implementing block transfer mode for
block1 (request side).

The coap gem now lives at: https://github.com/nning/coap
(And there is active work going on there...  PR would be appreciated.)


Updating monarch_context

Hey @cthoyt, thanks for putting all of this together. I think for now I will pass prefix_map manually. I tried out the monarch_context, but as expected, some of it is out of date.
All I really checked for was to see if the OMIMPS (OMIM Phenotypic Series) prefix appeared, but it doesn't; I didn't really check for anything else.
I could place the onus on @matentzn to help with this at some point.

It's currently pointing to a resource in https://github.com/prefixcommons/prefixcommons-py. If you have a better URL for a more up-to-date JSON-LD context, I will happily update it

I don't, but I think Nico probably will know.

@joeflack4 while we are still working out the details of the new Mondo pipelines, we do not know exactly what we need yet. We will keep using this here: https://github.com/monarch-initiative/mondo-ingest/blob/4f03c3682b24a1541f9fbd9442e7dfbb27a4b43b/src/ontology/config/context.json (on your exclusion table branch)  until we have covered everything we need, and then make a concerted effort to add all missing prefixes to prefix commons or directly to bioregistry.
One particularly annoying problem we have is the fact that some of our data sources do not have official PURLs, so we need to be a bit flexible to switch out the URI expansion part whenever we change our serialisation. For example, right now we are using bioportal ICD10CM as a source in mondo, which has bioportal purls. Tomorrow we may use another source with, say, WHO uri prefixes.

Can you inform me when https://github.com/monarch-initiative/mondo-ingest/blob/4f03c3682b24a1541f9fbd9442e7dfbb27a4b43b/src/ontology/config/context.json is merged into the main branch? I'd rather link without a version so the most recent one can be retrieved

Yeah we will tell you when this is stable - right now its in a state of massive flux while we are setting up the first round of our syncing pipeline!

It turns out that this context file is already available on the main branch https://github.com/monarch-initiative/mondo-ingest/blob/main/src/ontology/config/context.json so I pointed the PR there and will merge. It'll be up to you to get it updated nicely

Wait before you use this - this file is a garbage bin for internal use at the moment. I will let you know once the correct one is there. Also, this is not monarch related. This is purely about mondo!

So what was in the prefixcommons-py repository was a misnomer? Right now I think the right move is probably just close the PR and label this issue blocked upstream

I will reopen this issue when the time comes - for now, its fine to close!


Add hidden --ignore-lock escape hatch

This is obviously dangerous, but arguably has been the default behavior of SwiftPM for many years, so offering an escape hatch seems appropriate.

@swift-ci please smoke test

@swift-ci please test


Cant add additional objectStores because new version it' required

To add a new object store in IndexedDB using the idb library, you need to increment the database version. This is a fundamental behavior of IndexedDB, not specific to the idb library.
When you create a new object store, it must be done during the upgrade phase. Incrementing the database version triggers the onupgradeneeded event, allowing you to modify the database structure, such as creating new object stores or indexes.
Example with idb
Suppose you have an existing database and want to add a new object store:
import { openDB } from 'idb';

const db = await openDB('MyDatabase', 2, {
  upgrade(db, oldVersion, newVersion, transaction) {
    if (oldVersion < 2) {
      // Create a new object store in version 2
      db.createObjectStore('NewStore', { keyPath: 'id' });
    }
  },
});
console.log('Object store successfully added');

Details:
Database version: The version is updated from 1 to 2. Incrementing the version is mandatory for making structural changes.
createObjectStore method: This can only be called during the onupgradeneeded event.
Backward compatibility: If you have users running a previous version of the database, the logic if (oldVersion < 2) ensures that the new object store is created only when needed.
Note:
If you don’t increment the version and try to add an object store, you’ll get an error because structural changes are not allowed during a normal transaction.

That's a good summary of the behavior of IndexedDB and idb. I agree that the library should support multiple object stores without raising errors.
Your previous PR introduced dynamic version number changes, which I do not believe is a good practice. In my view, the application author should have direct control over the versioning process.
What are your expectations around this issue? Do you just need the error resolved, or do you have specific requirements to satisfy?
If you just need the library's current problem with creating more than one store fixed, my first thought is that the service registration could be changed to require all object stores to be provided during initial service registration. The openDB call in the TypeScript file could be revised to create all stores upon initial access, instead of just the one being queried. This would be a fairly simple change for me to implement.

The goal is to allow the creation of multiple object stores, and I agree with doing this at the beginning of the database creation process and relative to the version specified during initialization.
However, I believe there is a structural issue that persists. What would happen if a user wanted to add an object store at a later time ? As the library is currently structured, this would not be possible because there is no control over version updates, which risks making the library less flexible and therefore unsuitable for more complex and realistic application contexts.
This is why, in my opinion, dynamic version updates could also be important.

That's an interesting question.
My current thinking is that dynamic schema updates would not be considered in-scope for this library as a built-in feature. I would typically expect schema changes to occur in between deployments as part of a larger code/architecture change.
That said, dynamic object store creation would be possible without introducing dynamic versioning behavior to the library itself. The service could simply be re-registered using the new version number, along with the new set of required object stores.
Would that satisfy your requirements for dynamic store creation? Or is there a reason you would need in-built library support for the feature?

It would also be fine to re-register the service by incrementing the version number and adding the new objectStores.
It would also be interesting to implement, if not already available, a dynamic addition of objectStores using reflection, based on the version specified during initialization. Something similar to how migrations work in Entity Framework. Anyway thanks for your replay.

Okay, based on our agreement on the requirements I'll produce a new version of the library that resolves this bug as discussed.
Regarding dynamic object store discovery: reflection is not available in AOT scenarios, so I would prefer to avoid it. A source generated solution might be possible, but I don't think I will attempt that as part of this issue. If you have a strong need for it, please open a new issue.

Version 5 has now been published with the discussed changes.


Blazor: Unexpected HTML warnings on Visual Studio 2022 preview

Visual Studio shows assumingly unexpected warnings
Case 1

Severity
Code
Description

Warning (active)
CSS039
Unexpected character sequence in property value.

It occurs when I dynamically insert value from C# to style.
Here is a minimal example.
<div style="display: @Display">
</div>

@code {
     string Display = "block;";
}

I thought it is not expected behavior because Microsoft Doc shows an example of inserting C# code.
Case 2

Severity
Code
Description

Warning (active)
HTML0209
'~~~~~~~~~' is not a valid value of attribute 'checked'.

It occurs when I insert C# value to HTML attributes which value is generally restricted, ( for example, checked of checkbox, required or checked  )
Here is an example.
<input type="checkbox" checked=@_checked />

@code {
    bool _checked = true;
}

To Reproduce
.NET version: 6.0.100-rc.1.21463.6
Visual Studio version: 17.0.0 Preview 4.1

Create Blazor Server Project
In any razor file, copy upper example(s)
Check warnings on Error List window

I would like to make sure if these warnings are by design or just bug. ( I also take into account that these warnings can be side effects of Analyzer improvements in VS2022)
And if this is bug, I'd like to know if there are any plan to fix this.

Thank you for your reported issue! This issue should be fixed in 17.0-Preview5 once released!


Serverless code testing

Is it possible to use taskcat for testing cloudformation templates that contain serverless code or the transform tag?
My organisation has an application that is launched by nested cloudformation templates that contain serverless code. When I try to test the templates through taskcat it gives me the following error:-
[ERROR  ] :An error occurred (ValidationError) when calling the CreateStack operation: CreateStack cannot be used with templates containing Transforms.
If it is possible to test cloudformation templates containing transform tag, how can we achieve it?

@ritwik-singh-yash taskcat does a strick syntax check to validate json and yaml templates. The purpose behind this is to ensure that we can load the object as base json or yaml for linting purposes. For example, in json if there is a trailing comma validation will fail (cfn validation does not take trailing commas into consideration).
Is it possible for you to provide a sample or copy of your template so I can reproduce the error and work on a fix?

@avattathil you can access it at below location...
https://github.com/aws-quickstart/quickstart-datalake-yash/pull/1

@ankur-jain-yash I have made pull request https://github.com/aws-quickstart/taskcat/pull/89 for this. While that is being reviewed, please use this fork as a workaround. To test with the forked version of taskcat, you can do the following:

Checkout taskcat fork and quickstart-datalake-yash in the same parent directory e.g.

projects
|
+-- taskcat
|
+-- quickstart-datalake-yash

From the root directory (i.e. projects in the example above) execute:
 python3 taskcat/taskcat.py -c quickstart-datalake-yash/ci/config.yml -n

The solution is being worked in https://github.com/aws-quickstart/taskcat/pull/89 by @vsnyc

@vsnyc any further update needed here?

Verified that the latest taskcat works with Serverless transforms. Closing.


Handle error if the API response contains a status value of false

Handled error if the API response has a status key with a value of false #42

@sethumadhavan-k  gramatical issue on message "Inference save unsuccessful"
At the same time can we make the message more meaningful instead generic


SAX callback errors not handled

Currently errors raise in SAX callbacks are displayed, but not otherwise handled in SAX callbacks. For example:
use LibXML::SAX::Handler::SAX2;
use LibXML;

class MySax is LibXML::SAX::Handler::SAX2 {
    use LibXML::SAX::Builder :sax-cb;
    method startElement($name, |c) is sax-cb {
        die "nah: $name";
    }
    method endElement(|c) is sax-cb {...};
}

my $string = '<xxx></xxx>';
my LibXML $parser .= new;
$parser.sax-handler = MySax.new;
my $x = $parser.parse: :$string;
not "alive";

Outputs:
Entity: line 1: error: nah: xxx
<xxx></xxx>
    ^
alive

These errors should be kept and reported back and raised in the parser context.

Fixed in LibXML 0.7.10 release, along with a similar issue in XPath expression evaluation.


⚠ ClamAV has degraded performance

In 0480578, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 84 ms

Resolved: ClamAV performance has improved in 33d6b10.


nightlies not publishing ivy style launcher

A couple of things with the nightlies:
Firstly, I had to add this to my project/plugins.sbt, but it would be really nice if this was added automatically (just for nightlies! obviously not for release versions). If not automatically added, it should be added to the docs at http://www.scala-sbt.org/0.13/docs/Nightly-Builds.html
resolvers += Resolver.url("sbt-nightlies", url("https://dl.bintray.com/sbt/ivy-snapshots"))(Resolver.ivyStylePatterns)

(@dwijnand tells me we can use Resolver.bintrayIvyRepo("sbt", "ivy-snapshots") now)
I'm also adding this to the build definition (also be good if it was automated), but even then, an update fails when trying to resolve sbt-launch. It tries to resolve this
https://dl.bintray.com/sbt/ivy-snapshots/org.scala-sbt/sbt-launch/0.13.10-20160115-062758/ivys/ivy.xml

but the contents of https://dl.bintray.com/sbt/ivy-snapshots/org.scala-sbt/sbt-launch/0.13.10-20160115-062758/ is just a single sbt-launch.jar.
This can all be reproduced by trying to use the scripted plugin with a nightly, e.g. use 0.13.10-20160115-062758 for https://github.com/fommil/sbt-big-project

Thanks for opening and filling out the report.

Well with the two performance fixes recently I'd be insane not to be using them! :smile:

See #2338 Include sbt-ivy-snapshots to launchconfig.
We should update the doc too.
sbt-launch.jar is a launcher app intended for human consumption. Why are you depending on them?

I'm not, it seems to be pulled in transitively by scripted.


Between the two pages how to use Vue to pass information

Triggers a click event, how to go through the Vue to listen to the other page
like this
page1.html
click
new Vue({
el:'',
methods:{
showInfo:function () {
// TODO 。。。。
}
}
})
How to receive this event in Page2 by Vue;

Hi, thanks for filling this issue, however the issue tracker is reserved for bug reports and feature requests only, and we encourage you to use our dedicated gitter or forum to ask questions or for discussion. Thanks!


css vendor prefixing not working

I have same issues described here https://github.com/callemall/material-ui/issues/4280

@gutenye for me, it was a user-agent issue for server side rendering. Adding this radiumConfig worked for me:
`
<StyleRoot
radiumConfig={{userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36'}}

...
`

Closing this as a duplicate of #602. Thanks!


Web Pairing Code lasts a very short time

Hello friend, first of all I wanted to congratulate you for such excellent work, and take the opportunity to ask you if it is possible for the pairing code to last longer? Because when I finally manage to write it it has already expired and is of no use. On WhatsApp it doesn't allow you to write it quickly.

Hello friend, first of all I wanted to congratulate you for such excellent work, and take the opportunity to ask you if it is possible for the pairing code to last longer? Because when I finally manage to write it it has already expired and is of no use. On WhatsApp it doesn't allow you to write it quickly.

Can you try with cobalt 0.0.3?

I didn't know there was a 0.0.3 version. It's a matter of trying


[release/1.6] Update container with sandbox metadata after NetNS is created

Backport https://github.com/containerd/containerd/pull/7481 to release/1.6
Testing
ENABLE_CRI_SANDBOXES="" CONTAINERD_RUNTIME=runc FOCUS=TestRunPodSandboxAndTeardownCNISlow make cri-integration

/ok-to-test

/cc @fuweid @samuelkarp @estesp


Dashboard final touches

Add radio buttons to bar charts to filter by sale timeframe
Added some subheadings
Add line graph for album sales for a chosen artist
Closes #145

Updated branch

From what I can see, I don't see anything wrong. Good that you added filters for timerange now. Was there a reason limit wasn't a variable anymore?

From what I can see, I don't see anything wrong. Good that you added filters for timerange now. Was there a reason limit wasn't a variable anymore?

Because using an f string to pass the timeframe means that you are no longer to pass the limit as a variable. This limit variable wasn't being changed at any point so I decided to input the limit manually.

I guess? If it's not being changed, makes sense why it's hard coded. Approving pull request now.


Link to directory extension redirected to MS graph schema extension, which is not the same for AAD graph directory schema extension

In here: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-schema-extensions#registering-and-using-directory-schema-extensions
The second way to "Registering and using directory schema extensions" has link to MS graph schema extension overview. However it is not the right link. It should be the AAD graph directory extension link: https://docs.microsoft.com/en-us/previous-versions/azure/ad/graph/howto/azure-ad-graph-api-directory-schema-extensions

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b33020a9-498d-f282-2a96-f42cc5912dda
Version Independent ID: 69b1e48f-9cc2-7ba2-2458-ca010870a184
Content: Use Azure AD schema extension attributes in claims - Microsoft identity platform
Content Source: articles/active-directory/develop/active-directory-schema-extensions.md
Service: active-directory
Sub-service: develop
GitHub Login: @rwike77
Microsoft Alias: ryanwi

@shanjin90 Thank you for your feedback.
Below section on the link you are referring to, includes information on schema extension using both Azure AD Graph and Microsoft Graph.

Azure AD supports a similar type of extension, known as directory schema extensions, on a few directoryObject resources. You can use the Microsoft Graph API to manage the extension property definitions and add, get, update and delete data in the properties of these extensions.

Also, Azure AD Graph is marked as legacy api in Azure Portal and the recommendation is to use MS Graph.

@shanjin90 Closing out the issue now. Feel free to tag me in your reply if you have any further question.


Doesn't work with bun.js because require.extensions[template.defaults.extname] = extension; looks like it's not supported

Hi no speak chinese :)
Apparently this line of code is deprecated.  It doesn't work with Bun.js.  Is there a workaround?  Thank you! This is a great library
const template = require('./lib/index');
const extension = require('./lib/extension');

template.extension = extension;
>>> require.extensions[template.defaults.extname] = extension;

module.exports = template;

TypeError: undefined is not an object (evaluating 'import.meta.require.extensions[template.defaults.extname] = extension')

这里是付剑伟您的来信已收到我会尽快给您回复


ubuntu err msg

It's better to add this as a package dependency rather that logging into console.

Closing due to lack of activity, if you still wish this PR to go through please rebase onto current master and follow up with the provided comments


Fixed there should not be any success message while trying to delete system attributes #3693

BUGS:
Issue: https://github.com/bagisto/bagisto/issues/3693

done


Don't provide both documentChanges and changes

Inside rename code action workspaceEdit
Fixes #755

Oops. Merge when CI passes.


STYLE: Make code consistent with future clang-format defaults

Rigorous enforcement of newer clang-formatting options.
Ran clang-format19 followed by the approved clang-format8 to trigger code changes that are not enforced yet.
The clion IDE has clang-format-19 as a built in option (which is very convenient), but it introduced changes that are not enforced, but accepted by clang-format-8.
This series of changes will make future code changes easier to keep un-related code changes out.
PR Checklist

[x] No API changes were made (or the changes have been approved)
[x] No major design changes were made (or the changes have been approved)

From my understanding, not everything. But this set of changes is compatible with both.

I guess that now (gearing up to 6.0) is a good time to switch code style to a newer version of clang format. Assuming that there is will and time to do that.


Compatible with Original Zik and Sierra?

I found this to be prettier that the original parrot status. Just installed it, the status app launches, I connect to the zik, it flashes rapidly the "connected" and green icon but then it exists without any info being displayed.
So, before filling it as a bug, is it compatible with Original Zik?
Tested all releases, from the first alpha to the latest 0.46.1-alpha bugfix.

Same problem with the Original Zik (v1) and Sierra :(

Having the same issue with Zik 1.0 on 10.12.6 (16G29)
2018-07-10 11:29:52.506 ParrotStatus[79881:9020721] -[NSURL init] called; the NSURL object has been released and nil returned. Please use one of the documented NSURL initialization methods instead (initWithString:, initFileURLWithPath:, etc.). This message shown only once.
2018-07-10 11:29:52.552 ParrotStatus[79881:9020721] David's Headphones V1.10 is Connected
2018-07-10 11:29:52.554 ParrotStatus[79881:9020721] [establishKernelConnection] Received an error from IOServiceOpen() - 0xe00002c7.  NULLing out io_service_t.
2018-07-10 11:29:53.719 ParrotStatus[79881:9020721] David's Headphones V1.10 is Open
2018-07-10 11:29:53.730 ParrotStatus[79881:9020721] connection completed, Initializing...
2018-07-10 11:29:53.730 ParrotStatus[79881:9020721] David's Headphones V1.10 was successfully Initialized
<?xml version="1.0" encoding="utf-8" standalone="no"?>
<answer path="/api/software/version/get">
	<software version="1.10" />
</answer>
fatal error: unexpectedly found nil while unwrapping an Optional value
[1]    79881 illegal hardware instruction  /Applications/ParrotStatus.app/Contents/MacOS/ParrotStatus```


Validation of large deletions calling in bcbio with HuRef benchmark compared to ERDS and CNVNator

Hello, Brad!
Thanks for the great pipeline!
Currently among read-depths CNV callers only CNVkit is supported in bcbio. In our experience ERDS and CNVNator perform better than CNVkit. What would be your thoughts to include them? We can put some developing efforts from our side.
Thanks!
Sergey

Sergey;
Thanks for starting this discussion. We currently support TitanCNA as an alternative tumor/normal callers and are also planning to work on PureCN for tumor only calling. We've been considering incorporating the new GATK4 germline and somatic CNV callers.
As a more general discussion, what issues are you finding with the current CNVkit caller that ERDS and CNVNator improve on? What type of sample inputs are you dealing with (WGS, exome, tumor...). Do you have any test cases we could incorporate to help motivate both improvements to CNVkit as well as incorporation of new methods?
We're always open to including new tools but try to do this in a way where we cover gaps and understand the strengths and weaknesses of approaches. Thanks again for the discussion.

Hi Brad! We are mostly focused on the germline CNV calling using WGS. @bjtrost will post more details soon. Sergey

Hi Brad,
Although I have not tested or used it myself, my understanding from reading the CNVkit documentation and paper abstract is that it is primarily designed for performing tumour-normal comparisons using pooled references from capture data. It would also be useful to include CNV-detection algorithms designed for germline WGS data and work on single simples (the "single sample" aspect is desirable because, in our experience, the use of pooled references can result in deletion calls where there are common duplications and vice-versa). In a recent paper, we describe a workflow for germline CNV detection from WGS data. Part of this paper is comprised of an evaluation of six read depth-based CNV callers, and we identified ERDS and CNVnator as the best ones. Thus, I think it would be valuable to add ERDS and CNVnator to bcbio for the purposes of performing germline CNV calling from WGS data. Our paper is here:
https://www.sciencedirect.com/science/article/pii/S0002929717304962?via%3Dihub
Cheers,
Brett

It looks like the main improvement ERDS and CNVnator offer over CNVkit is the segmentation algorithm. CNVkit uses CBS by default, which is reliable for panel and exome data, whereas:

ERDS uses a paired HMM to segment read depths and SNPs simultaneously
CNVnator uses a fast implementation of the mean-shift algorithm, which is more of a heuristic approach but seems to work well

Other recently developed callers like CLAMMS and GATK4 were not evaluated -- both of those use HMMs for segmentation, so I'd be interested to see how they stack up.
CNVkit also recently rolled out an HMM-based segmentation method, but it hasn't been evaluated thoroughly yet. Other users report better results with CNVkit's "flasso" (fused lasso) method over the default CBS, so if there is a certain WGS benchmark dataset that is relevant to a lot of users, I'd be happy to work with someone to tune CNVkit's segmentation to work better on that dataset.

My recent WGS germline SV validation shows, unfortunately, that CNVkit is not very useful in this case:

Hi,
Just wanted to note that CLAMMS is only for exome data ("Please note that CLAMMS is not intended to be used with whole-genome sequencing data"), and the CNV-detection functionality in GATK4 seems to be just for somatic, although they are testing functionality for germline (https://gatkforums.broadinstitute.org/gatk/discussion/11344/current-status-of-gatk4-germlinecnvcaller-tools-and-best-practices).
Cheers,
Brett

Brett, Sergey and Eric;
Thanks for all this discussion and pointers to the paper. This is great work and I'd read it but not put together all the connections.
Is it possible to extract a couple of the test cases from that paper that we could use as a starting point for evaluating CNV calls on single sample germline calls? I'd really like to have this included in the bcbio validations so we can consistently evaluate. Sergey, is that validation done against the NA12878 calls? That's not a great test case for CNVs unfortnately, since it's all based on split/paired style callers (hence their better performance). I suspect other read depth based callers would also not look great on small events or on specificity. I've been hoping to develop a better evaluation metric for this and would love to have this tie in with Brett's paper so we can compare/contrast to the work that is already done.
I'd be keen to explore the GATK4 in progress HMM approaches or adjusting CNVkit as first passes with this validation in place. Practically, ERDS has an academic only license and is only for WGS, and CNVnator does not seem to be under active development. As you mention CLAMMS is exome only. Since it's a ton of work to integrate and support methods for the long term, we'd ideally picks ones we can work with the authors on like we currently do with Eric and CNVkit.
If adjusting CNVkit or integrating GATK4 would get us equivalent calls on some of your benchmarks that would be a best case outcome. What do y'all think about this as a plan? I'd be happy to hear your feedback and thoughts.

Sergey -- thanks so much for the help with this, those plans sound perfect.
My take on the calling method are that both depth based and split/paired methods are useful can capture different events, hence are complementary. The NA12878 example above uses a lot of short read split/paired methods as inputs so will miss some depth-only events and isn't meant to be fully comprehensive.
In general, short reads can only capture a component of all the events. Genome in a Bottle has been working on a new truth set with NA24385 and more long read technologies and this is a comparison of methods like manta which tries to quantify this:
https://github.com/bcbio/bcbio_validations/tree/master/NA24385_sv
Having a germline CNV specific validation based on Brett's work would be an incredible help to compare and improve methods in bcbio. I've been working on a tumor/normal CNV one based on HCC2218 (https://github.com/Illumina/canvas#demo-tumor-normal-enrichment-workflow) and generally working on making common sets of validations available (https://github.com/bcbio/bcbio_validation_workflows).
Thanks again for this great discussion.

A few more comments:
(1) Re: "do you think it is worth using read-depths CNV calling methods for single sample WGS, given that the best methods (ERDS and CNVkit) discover 51% and 44% events in the best case (filtered), having a lot of false discoveries (59% and 32%) (table 1 in Brett's article), compared to split/paired methods with 80-90% events discovered and 20-40% of false positives (see my picture above)." - I don't think it is very meaningful to compare these numbers. The benchmarks used in the CNV paper were mostly orthogonal to the methods being tested, whereas the GIAB set (as you mention) is biased toward SR/PEM methods.
(2) I agree that the read depth callers and the SR/PEM callers are complementary, so it would be good to have both represented in bcbio. In particular, the read depth methods are better at caller larger variants, which are more likely to be clinically relevant.
(3) ERDS, as with CNVnator, is no longer maintained.
(4) Another good source of benchmarks may be a recent paper by Charles Lee's group, currently on BioRxiv:
https://www.biorxiv.org/content/early/2017/09/23/193144
The authors kindly provided me with PacBio benchmarks for the children of the three trios described in this paper.
Cheers,
Brett

Brad,
I agree that having HuRef SV benchmark in bcbio would be very useful. I'm not the owner of the dataset, and I've made a request to open it. Hopefully, I would be possible to release raw input WGS data. I'll keep you posted. The truth set is already available as supplementary files here
http://www.cell.com/action/showImagesData?pii=S0002-9297(17)30496-2
File S1: HuRef CNV benchmark (GCRh37/hg19 coordinates).
File S2: HuRef CNV benchmark (GCRh38/hg38 coordinates).
In the meanwhile, I have added erds/cnvnator results from @bjtrost's article to the validation picture.
Same benchmark, same validation script, so we can compare now.

Read-depth methods (erds, cnvnator) start performing well at 1000bp, cnvkit at 10000.
Overall (regardless of the deletion size)
93% of erds TP deletions and 77% of cnvnator's are captured by metasv/filtered.
95% and 82% by metasv/unfiltered.
In the [1000, 10000] bin it is 95% (erds) and 83% (cnvnator)
So, I'm satisfied with metasv, and I think that using erds and cnvnator will not boost the sensitivity to 100%. However, you may see that the overall precision/sensitivity in HuRef benchmark is much lower than in GIAB benchmark, so there is a room for improvement.
@etal , I think it would be crucial to improve cnvkit's performance in the [1000,10000] bin, where erds and cnvnator perform much better.
I'm trying to use segmentation algorithms you suggested. My approach is very primitive - I've dumped bcbio commands into script:  https://github.com/naumenko-sa/crg/blob/master/crg.cnvkit.sh, checked that the default segmentation works and produces the same result as in bcbio,
and then I altered segmentation with -m flasso or -m hmm-germline. The default segmentation was very fast, I have not recorded the running time, 10 min or so. With flasso segmentation run over the walltime of 10 hours and has been killed. I submitted it again, but even if it finishes in 15-20 hours, it would be too slow to use by default. With -m hmm-germline I passed the segmentation step, but I'm stuck with segmetrics - also takes 10 hours. Please advice me how to improve the running time.
Sergey

@etal sorry, in my hands -f hmm-germline shows the same results as the default segmentation method. Hopefully, flasso will show better results, but, again it is too slow for practical use in WGS.

@naumenko-sa Thanks for the details. It's suspicious that the 'hmm-germline' results were identical to the default 'cbs' method; do you think CNVkit may have run 'cbs' in both cases due to some bug?
For the 'flasso' and 'segmetrics' runtimes, it sounds like there's a bottleneck in the code that is worst on WGS data, specifically when a lot of segments are produced. WGS and exomes seem to require more stringent p-values (-t) to avoid over-segmenting. So, maybe a more stringent p-value of e.g. 1e-6 for 'flasso' might help avoid the bottleneck. You can watch the per-chromosome log messages for a couple minutes to see if you're getting hundreds or thousands of segments, or very slow segmentation, and kill the process early if that's the case. (The 'flasso' method is not parallelized, since doing so triggers an obscure error related to memory-mapped files used by the underlying R package.)
I'll profile the code to see if there's a hotspot shared by segment and segmetrics that I can speed up.

Quarterly update: The segment and segmetrics commands are now significantly faster in the development version of CNVkit. For the flasso method, most of the time seems to be spent within R, and I don't think I can speed it up further, though -t 1e-6 should still help.
I'll see if I can run these benchmarks myself and troubleshoot the hmm-germline situation.

Hi @etal ! Thanks for the update! I will try to run the test with the latest version. Unfortunately, you will not be able to run this, as you don't have input WGS data. The owners have not released it yet, I hope it will happen at some point, but for now I should it by myself. But I have permission to share results :)

Hi everyone!
Sorry for the long silence. Good news - HuRef WGS fastq just has been published:
https://www.ncbi.nlm.nih.gov/sra/SRX5395595[accn] making those validations reproducible.
Some thoughts:

hopefully, SV calling improved in bcbio since the last year - will see, at what extent
we called SVs in a cohort of samples with metaSV(manta,lumpy,what,cnvkit). metaSV uses spades, which is a great assembler, but assembling all SVs across the genome takes a while.
recently smoove/duphold were introduced to bcbio. What is their interaction with metaSV? Could anybody comment on the logic?

Sergey

Sergey;
Thanks for continuing to look at this and for the great news about HuRef accessibility. We haven't done any specific work with MetaSV and the Smoove/Duphold update so I'm not sure about the interaction. The outputs should be fairly similar (although hopefully more precise and sensitive) but I don't typically use MetaSV due to the speeds and focus on the prioritization approach when combining multiple callers. Thanks again for keeping these comparisons going.

Hi Brad!
I've traced (using bcbio-nextgen-commands.log) what happened when running the below config file (a fragment):
variant_regions: /path/regions.bed
sv_regions: /path/regions.bed
svcaller:
- lumpy
- manta
- cnvkit
- metasv
- wham
variantcaller: false

Roughly:
1.regions.bed cleaning
2.Coverage calculation for regions.bed with mosdepth and hts_nim_tools
3.cnvkit fed by coverage information
4.smoove-lumpy-duphold
5.manta-duphold
6.wham
7.metasv combined calls from 4 tools
Smoove helps lumpy to make less noisy calls, and duphold adds coverage information to vcf called by lumpy and manta (break point algorithms).
It looks like regions.bed affects only cnvkit, i.e. the other 3 tools are doing calls genome-wide.
Would it make sense to restrict calling in manta/lumpy/wham by sv_variants regions too?
Use cases: quickly call SVs in a region, not waiting for genome-wide calling. Might also be as a test for this module.
If so, what would be the best place to add this?

bcbio/structural/lumpy.py: _run_smoove: add whole_genome.bed/sv_regions.bed to excluded regions
bcbio/structural/manta.py: _prep_config: use --callRegions=sv_regions.bed
it looks like wham would require to subset a bam file to feed into it.

Sergey

Sergey;
Thanks for looking at this. The general idea behind not excluding regions tightly to variant or SV regions is that you'd want to capture long range events that span, or only partially overlap, the regions of interest. Lots of people have interests in fusions or other long range events that only span part of the SV regions, so we don't want to lose these by being overly exclusive. In general it's really hard to effectively call SVs in capture regions, so trying to give us the best chance to pull something out if it's there. Hope this helps explain the current logic.

Hello!
I revisited SV validations in a year, adding Delly.  See the results here:
https://github.com/naumenko-sa/bcbio_validations/tree/master/huref_sv
There is an improvement, but overall progress in SV calling is very slow.
I also created a PR:
https://github.com/bcbio/bcbio_validations/pull/1
Sergey

Sergey;
Thanks so much for keeping this up to date and for writing it up. This is really helpful. I'm agreed with your conclusions that we're near the point of diminishing returns for short read variant detection. We also haven't focused much on this in bcbio and the major update with incorporating smoove to do lumpy calling. I appreciate you continuing to look at this and ensure it's tuned and validated.


fix: useNavigate subscriptions

there shouldn't be a need to subscribe useNavigate to useMatch to read the pathname, because we just need it inside the callback, we can read it imperatively
also, there was likely a stale closure problem if location changed, as useMatch would re-render the component, but useCallback wouldn't see the fresh value

I think there is a similar problem in useMatchRoute:
https://github.com/TanStack/router/blob/c5c325d817a75c7e964b83bf051262af01835822/packages/react-router/src/Matches.tsx#L388-L392
Imho the useRouterState subscription doesn't do anything: it will re-render all components that use useMatchRoute when location changes, but the returned callback function will always be the same. Even if matchRoute from useRouter changes, that wouldn't do anything.
@tannerlinsley you explicitly added this here:
https://github.com/TanStack/router/commit/0d4092fdec0d2949a38e1f2381d9c52910a01f21#diff-4cfd6abe2272d72c1dd073ec37936ad823bcd1f9418b466a9dea8b50214448f8R223
but I think it should be safe to remove it - all it does is create re-renders of components, which is not what this hook is for. Consumers should use useMatch if they want that.


DataSaturday 0046 - Vienna 2024 (first try)

Hi DataSaturday team,
my first try for our upcoming DataSat in january 2024

Hey Wolfgang, it looks like it's ok. This page is a bit empty, maybe try to add links to schedule.
Cheers!


Change let module to mod keyword.

Change let module to mod keyword.
Rust uses the word mod to declare a module. This really doesn't matter at all to me, but if others think it's an improvement, it's a trivial change to make.
Here's an example: https://doc.rust-lang.org/reference.html#modules

I think we can close this one.


Added support for hovering cells

Adds support for a 'hovered' status to cells

I'm closing this branch as the changes here are impacted by drag and drop support as well.. I'll create a new pull request with those.


Update Sedon Core images in track/1.15 - (DO NOT MERGE)

Cherry pick commit from main
Update Seldon Core images
ROCK images were published with updated names. This PR updates required resources to point to newly published images.
Summary of changes:

Updated configmap and metadata with published ROCK images.

Incorrect PR. Closing.


Question about P2~P4 data

when are you post the rest of the data? It will be very helpful to me, thank you
Regards,

Sorry for the late response. The data of P1 to P4 are released at ./data folder. Please feel free to use them.


Parse error when sanitizing "<1K"

The package throws an exception when I try to run it on "<1K" string, which seems perfectly valid to me and simple means "less than 1000" and not an open tag.

Hello,
I think that bug reported by you is already fixed.
thank you for report

Thank you.


Write Tune step

def do(self, previous_states: Dict):
        trainer = Trainer()  # Here we should write other object for this.
        # TODO how to solve this?
        trainer.tune(model=self.model, datamodule=self.datamodule)

TBD in v3

Tune capability:

random over grid search. For simultaneously tuning multiple hyperparameters it may sound tempting to use grid search to ensure coverage of all settings, but keep in mind that it is best to use random search instead. Intuitively, this is because neural nets are often much more sensitive to some parameters than others. In the limit, if a parameter a matters but changing b has no effect then you’d rather sample a more throughly than at a few fixed points multiple times.
hyper-parameter optimization. There is a large number of fancy bayesian hyper-parameter optimization toolboxes around and a few of my friends have also reported success with them, but my personal experience is that the state of the art approach to exploring a nice and wide space of models and hyperparameters is to use an intern :). Just kidding.

I think that first version of Tune should just support the random search. Over parameters/data/model modifiers

I'd then name it a RandomSearch step. I agree

Probably right we shouldn't have one Tune step with options but rather few simpler ones.

Also we need to remember that trainer.tune tunes only learning_rate


[Bug] [API]  The name of the process definition doesn't display on the page of task definition.

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
When I browsed the list page of task definition I found that the name of process definition  didn't display. So I checked the result of the requested api and make sure that this issue is caused by the backend.

What you expected to happen
I expect that the name of process definition  can display correctly.
How to reproduce
You can browse the list page of task definition and then you will see it.
Anything else
No response
Version
dev
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I will fix this issue.


Update KoreBuild version

FYI

I believe it was this change that is causing all the tests to fail. Can we revert?
cc @pakrym

I believe he attempted to fix that with https://github.com/aspnet/Logging/commit/7f4bcd95ba1d0c982ad42cc78426a23fd5065f39, and that commit is just now making its way to the Win2012 configs. We should learn pretty quickly if that fixed it.

I'd rather we revert the test parallelization change in BuildTools (which is seemingly what's causing these failures).

Yeah, now that we're having trouble with EF too I agree with @pranavkm, we can revisit test parallelization once our builds are in a more solid state.

I don't think reverting is the right move. I think we're uncovering legitimate product and test bugs. I ran EF and logging before I merged https://github.com/aspnet/BuildTools/pull/417, and they passed just fine. Before we rush to turn off parallelization, I think we should look at the errors and figure out why the parallelization is bad.
For example, before merging I noticed that Kestrel always failed. The issue was port exhaustion and contention between libuv and managed sockets. We disabled parallelization there because we legitmately don't care if you can run 1000 kestrel servers in parallel at the same time on a machine.
Logging and EF on the other hand - seems like product bugs that analyzers fail if when run in parallel, and if you can't access a SQL database in parallel with other process.

@natemcmaster how long are we going to keep Universe broken for this? Can we make it opt in and do it repo by repo so we don't stall entire workflow?

@pakrym I'm not overly concerned with this. We're down to a handful of EF tests that fail to initialize a shared database in parallel (sometimes), and a few flaky NTLM and WebHostBuilder tests that were flaky before the parallelization change
.


Update licensing-fundamentals.md

Removed duplicate names:
Microsoft Entra ID P1 (becoming Microsoft Entra ID P1)

@billmath
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off

I've resolved a merge conflict, and I'll merge shortly.


fix(version): update package.json fabric8-analytics-lsp-server to 0.1.36

closing for https://github.com/fabric8-analytics/fabric8-analytics-vscode-extension/pull/187


Resources being replaced on every "pulumi up"

A bunch of my resources are replaced every time I run pulumi up even though no changes have been made in their definitions.
I reached out on slack (https://pulumi-community.slack.com/archives/CRH5ENVDX/p1632414069155000) and was asked to file an issue here.
Here is an example:
% pulumi up

Please choose a stack, or create a new one: dev
Previewing update (dev):
     Type                        Name                          Plan        Info
     pulumi:pulumi:Stack         cc-devops-dev                   8 messages
 +-  ├─ aws:ecr:LifecyclePolicy  cc-bidder-policy              replace     [diff: ~policy]
 +-  ├─ aws:ecr:LifecyclePolicy  cc-nginx-log-archiver-policy  replace     [diff: ~policy]
 +-  ├─ aws:ecr:LifecyclePolicy  cc-backend-policy             replace     [diff: ~policy]
 +-  ├─ aws:ecr:LifecyclePolicy  cc-redis-policy               replace     [diff: ~policy]
 +-  ├─ aws:ecr:LifecyclePolicy  cc-bidder-proxy-policy        replace     [diff: ~policy]
 +-  ├─ aws:ecr:LifecyclePolicy  cc-nginx-policy               replace     [diff: ~policy]
 ~   ├─ aws:s3:Bucket            <REDACTED>       update      [diff: ~lifecycleRules]
 +   ├─ cloudflare:index:Record  cc_ingress_cert_validate_0    create
 ~   ├─ cloudflare:index:Record  cc_ingress_cert_validate_1    update      [diff: ~value]
 +   ├─ cloudflare:index:Record  cc_ingress_cert_validate_2    create
 +   ├─ cloudflare:index:Record  cc_ingress_cert_validate_3    create
 +   ├─ cloudflare:index:Record  cc_ingress_cert_validate_4    create
 +   ├─ cloudflare:index:Record  cc_ingress_cert_validate_5    create
 +   ├─ cloudflare:index:Record  cc_ingress_cert_validate_6    create
 ~   ├─ cloudflare:index:Record  cc_ingress_cert_validate_7    update      [diff: ~value]
 -   ├─ cloudflare:index:Record  v6                            delete
 -   ├─ cloudflare:index:Record  v3                            delete
 -   ├─ cloudflare:index:Record  v2                            delete
 -   ├─ cloudflare:index:Record  v0                            delete
 -   ├─ cloudflare:index:Record  v4                            delete
 -   ├─ cloudflare:index:Record  v1                            delete
 -   └─ cloudflare:index:Record  v5                            delete

None of these resources have been edited since the last pulumi up -- and it happens every single time.
Currently on pulumi version v3.13.0 -- though it also occurred on the last several releases as well.
Here is some sample code:
import pulumi
import pulumi_aws as aws

cc_backend = aws.ecr.Repository(
    "cc-backend",
    image_scanning_configuration=aws.ecr.RepositoryImageScanningConfigurationArgs(
        scan_on_push=True,
    ),
    image_tag_mutability="MUTABLE",
    tags={
        "Name": "cc-backend",
    }
)

cc_backend_policy = aws.ecr.LifecyclePolicy(
    "cc-backend-policy",
    repository=cc_backend.name,
    policy="""{
    "rules": [
        {
            "rulePriority": 2,
            "description": "Expire images older than 14 days",
            "selection": {
                "tagStatus": "untagged",
                "countType": "sinceImagePushed",
                "countUnit": "days",
                "countNumber": 14
            },
            "action": {
                "type": "expire"
            }
        },
        {
            "rulePriority": 1,
            "description": "Keep last 30 images",
            "selection": {
                "tagStatus": "tagged",
                "tagPrefixList": ["m"],
                "countType": "imageCountMoreThan",
                "countNumber": 15
            },
            "action": {
                "type": "expire"
            }
        }
    ]
}
""")

Here's an example for the ACM/Cloudflare part:
import pulumi
import pulumi_aws as aws
import pulumi_cloudflare as cloudflare

cc_ingress_cert = aws.acm.Certificate(
    "cc",
    domain_name="a.REDACTED.com",
    subject_alternative_names=[
        "*.REDACTED.com",
        "*.REDACTED.com",
        "*.REDACTED.com",
        "*.REDACTED.com",
        "*.REDACTED.REDACTED.com",
    ],
    tags={
        "Name": "cc_ingress_cert",
    },
    validation_method="DNS"
)

def get_domain_from_hostname(hostname):
    """
    Retruns the SLD for the hostname.
    """
    parts = hostname.split('.')
    return ".".join(parts[-2:])

def get_zone_id(domain):
    zones = cloudflare.get_zones(filter=cloudflare.GetZonesFilterArgs(
        name=domain,
    ))

    for zone in zones.zones:
        return zone.id

def create_dns_records(domain_validation_options):
    zone_ids = {}
    validation_cnames = []
    idx = 0
    for dv in domain_validation_options:
        domain = get_domain_from_hostname(dv.domain_name)
        try:
            zone_id = zone_ids[domain]
        except KeyError:
            zone_id = get_zone_id(domain)
            zone_ids[domain] = zone_id
        name = f"cc_ingress_cert_validate_{idx}"
        print(
            name,
            dv.domain_name,
            dv.resource_record_name,
            dv.resource_record_type,
            dv.resource_record_value,
        )
        record = cloudflare.Record(
            name,
            zone_id=zone_id,
            name=dv.resource_record_name,
            value=dv.resource_record_value,
            type=dv.resource_record_type,
            allow_overwrite=True,
            ttl=60
        )
        idx += 1
        validation_cnames.append(record)
cc_ingress_cert.domain_validation_options.apply(create_dns_records)

cc_ingress_cert_validation = aws.acm.CertificateValidation(
    "ccCertificateValidation",
    certificate_arn=cc_ingress_cert.arn,
    #validation_record_fqdns=[v.fqdn for v in validation_cnames]
)

Hi @erikcw
Please can you tell me the version of pulumi-aws that you are using? And can you have a look at the details of the update and tell me (either here on in our slack via DM) the nature of what is changing in the resource
Paul

Regarding the AWS diff issue, I tried reproducing it today with the latest version of provider, but I don't get the diff anymore. I took your literal repro, deployed once, and then ran pulumi up again to no diff. I'll assume it's been fixed since.
I haven't tried the cloudflare repro - but if it's still a problem - please file a separate issue in https://github.com/pulumi/pulumi-cloudflare


Debugger incorrectly escapes arguments with trailing back slashes

@Rots commented on Sun Apr 28 2019
Environment data

VS Code version: 1.33.1
Extension version (available under the Extensions sidebar): 2019.4.11987
OS and version: Win 10
Python version (& distribution if applicable, e.g. Anaconda): 3.7.2 64bit
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): na
Relevant/affected Python packages and their versions: na

Expected behaviour
All the arguments from the launch.json are passed to the lauched file as specified.
I.e. The output should be list of 3 items: program and two arguments in the example below.
Actual behaviour
The arguments get mungled up, when space and trailing backslash is used.
Only two items are produced in the list: program and 'merged' args
Steps to reproduce:
example.py:
import sys
print (sys.argv)

launch.json:
        {
            "name": "Argument handling issue example",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "args": ["C:\\path to\\arg1\\","arg2"],
            "console": "integratedTerminal"
        },

Run the launch configuration with the example.py.
Logs
Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)
Empty

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)
extensionHost.ts:215 Extension Host
extensionHost.ts:216 Debugger attached.

Output of integrated terminal:
PS C:\Users\XXX> cd 'c:\Users\XXX'; ${env:PYTHONIOENCODING}='UTF-8'; ${env:PYTHONUNBUFFERED}='1'; & 'C:\Python37\python.exe' 'c:\Users\XXX\.vscode\extensions\ms-python.python-2019.4.11987\pythonFiles\ptvsd_launcher.py' '--default' '--client' '--host' 'localhost' '--port' '49818' 'c:\Users\XXX\example.py' 'C:\path to\arg1\' 'arg2'
['c:\\Users\\XXX\\example.py', 'C:\\path to\\arg1" arg2']

Note, this is not a Python Extension issue

No plans to fix this in the next couple of milestones.
Code pointer if you would like to investigate more and potentially provide a PR
https://github.com/Microsoft/vscode/blob/a30ca29b8b4a8a848b27fc55631cf3a4f3f7f85c/src/vs/workbench/contrib/debug/electron-browser/debugService.ts#L254
Checkout where the args array in the configuration does not get escaped.

Thanks, to help the issue forward I did some investigation. I'm pretty sure at least part of the issue is here:
https://github.com/Microsoft/vscode/blob/a30ca29b8b4a8a848b27fc55631cf3a4f3f7f85c/src/vs/workbench/contrib/debug/node/terminals.ts#L348-L352
The trailing backslash in s probably escapes the closing quote.
I'd expect anyone familiar with the tooling could easily create a failing unit test for the prepareCommand function to demonstrate the issue.

Two bugs here:

With Powershell if a quoted argument contains a backslash before the ending quote (e.g. 'foo\') the quote is treated literally and results in foo' being passed. The fix is to detect this case and double (escape) the backslash.
For bash-like shells, backslashes are now escaped with another backslash.


1.0: Rename the client accessors pointing at “collections” to just say the name e.g. client.virtualMachines() as opposed to client.getVirtualMachineOperations()

related to 640

Available in master.


git fetch fails with error 255

I've done the following configuration:

created a deployUser
granted deployUser full control to local repo folder
created customAppPool for gitdeployhub with deployUser as the identity
using TortoisePlink and Putty ssh, not openssh on my git install.
Created a putty session for bitbucket.org using my custom ssh private key as the auth key.

I can log in to the server as deployUser, and successfully run a git fetch/ git pull from the commandline.
I tried setting environmentVariables="PLINK_PROTOCOL=SSH;GIT_SSH=" in my instance, with no success.
With the level of logging going on in gitdeployhub, I can't see what is causing the error 255 on the git fetch.
Do you have any insight on this?

It was the permissions, but it runs now, except that when I hit the "Smoke Test" button I get this message
"This type of page is not served."


For GitHub plugins, use scmAuthApi instead of githubAuthApi

Feature Suggestion

We have some repositories in a GitHub Enterprise Server instance and some on github.com
For GitHub plugins (in our case the Pull Requests and GitHub Insights plugins) we can only use the plugins for one or the other.
This feature suggestion is to alter how tokens are retrieved in order to be able to use these plugins for multiple GitHub instances.
Possible Implementation
https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/frontend/backstage-plugin-github-pull-requests/src/components/useGithubLoggedIn.tsx#L36
Something like this but more tweaking needed to get it to work with what you have here, but kinda the gist of it:
  const scmAuthApi = useApi(scmAuthApiRef);
  const [isLoggedIn, setIsLoggedIn] = useState(false);

  useEffect(() => {
    const token = (
    await auth.getCredentials({
      url: `https://${host}`,
      additionalScope: { customScopes: { github: ['repo'] } },
    })
  ).token;

Context
We need to use multiple GitHub providers. In order to do this, we followed the Backstage maintainer suggestion of using the scmAuthApi to accomplish this - the original issue on the Backstage side is here:
https://github.com/backstage/backstage/issues/18887#issuecomment-1667803331
We followed the custom SCMAuthApi implementation detailed in the docs here https://backstage.io/docs/auth/#custom-scmauthapi-implementation
For our own plugins we were able to switch from the githubAuthApi to scmAuthApi to be able to view GitHub information from both locations using the appropriate user tokens. Now we'd love to still be able to use Roadie plugins for both as well.

unstale, please