Removed use of deprecated String.characters property

Breaks Swift 3 compatibility; should not be merged until Vapor is bumped to 3.0.0.
See also: https://github.com/vapor/console/pull/47

Vapor 3.0 is a full rewrite so unfortunately this will just cause a merge conflict. However I would be happy to accept a PR that is compatible with Swift 3!


Unruly: FPD and Protected Audience Support

Describes the Unruly adapter's support for Protected Audiences and First Party Data.
🏷 Type of documentation

[X] new feature

📋 Checklist

[X] Related pull requests in prebid.js or server are linked -> Paste link in this list or reference it on the PR itself

Adapter PR: https://github.com/prebid/Prebid.js/pull/10709

We submitted this PR in anticipation of our backend becoming available within a week. Upon further consideration, we'll re-submit after the entire pipeline's available.

URLs are live now.


Firebase analytics error

Xamarin forms 4.5 latest
Xamarin.Firebase.iOS.Analytics: 6.2.1
I am getting this error while building iOS app.
error : There was an error unzipping the file bin\iPhone\Release\Dev\iPhone\GTMSessionFetcher.framework.dSYM.zip: Could not find a part of the path '\bin\iPhone\Release\Dev\iPhone\GTMSessionFetcher.framework.dSYM'.
When I checked bin\iPhone\Release\Dev\iPhone\GTMSessionFetcher.framework.dSYM.zip file it exists but its empty.

Any update on this?

@kunaldhande Can you provide a test case of this, please? Thanks in advance!


Allow admins to export helper details in CSV format

Similar to #235 we should allow admins to export all helper data in CSV format for them to further massage in Excel.

Hi @dottorer , I should have a working prototype up in a PR by tonight (your morning)

Pushed to PROD - thanks @NolanChan


UI update

As a user, I want UI to be simplified and expanded:

Remove the "Upload" button and automatically upload on every file choice
Reformat the "Options" menu to add there additional checkboxes

Closed by #44


Design System > Enhancement in checkbox as per new project flow

Design System > Enhancement in checkbox as per new project flow

Verified on stage


Rectify formatting issues in Table of Contents in UG

Codecov Report
Base: 74.75% // Head: 74.75% // No change to project coverage :thumbsup:

Coverage data is based on head (ea6a2a7) compared to base (72821a5).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #232   +/-   ##
=========================================
  Coverage     74.75%   74.75%
  Complexity      556      556
=========================================
  Files            86       86
  Lines          1632     1632
  Branches        163      163
=========================================
  Hits           1220     1220
  Misses          352      352
  Partials         60       60

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Bumping base image in Dockerfile.test to ubi9

Signed-off-by: Priyanshu Raj<EMAIL_ADDRESS>py-mtcli
Description
Short description of the change:
Bumping base image in Dockerfile.test to ubi9 to avoid dependency issues.
eg. https://ci.ext.devshift.net/job/mt-sre-managed-tenants-cli-gh-pr-check/388/console

/ok-to-test


Middleware Manager - Middleware Messagings Monitoring->Utilization view shows - Unexpected error encountered

When navigated to Middleware->Messagings->JMS Queue or JMS Topic summary page, clicking on Monitoring->Utilization shows 'Unexpected error encountered' in UI and shows error text as below:
Error text:
No such file or directory @ rb_sysopen - /var/www/miq/vmdb/product/charts/layouts/hourly_perf_charts/ManageIQ_Providers_Hawkular_MiddlewareManager_MiddlewareMessaging_jms_queue.yaml [middleware_messaging/perf_chart_chooser]
Please refer the attachd screenshot and MIQ production.log

MIQ-productionLog.txt
MIQ version: Version master.20170808074803_
Steps:
-Login to MIQ
-Add a middleware provider
-Navigate to Middleware->Messagings
-Click on any JMS Queue or JMS Topic
-On the summary page, click on Monitoring->Utilization
-It shows the error page as attached

@miq-bot add_label providers/hawkular

this too belongs in the ui repo. cc @karelhala @mtho11

@miq-bot add_label bug

@miq-bot move_issue manageiq-ui-classic


Delta indexer for categories

I was wondering how to best syncronize changes to categories using a delta indexer. The productdelta command only syncronizes products. For instance, if I add a new category and an new product under this category and then run node --harmony cli.js productsdelta --partitions=1 no new category/product will be displayed when reloading the frontend.
Could this be done by running a normal full indexing for just categories e.g node --harmony cli.js categories --partitions=1 or similar?

Yes, for now I believe its' a only way (to run the full reindex on categories); however, it would be nice to add categoriesdelta mode :-) The problematic thing is that if the category is on deeper level like 3, 4 - the parent categories should also be refreshed as the SidebarMenu.vue component is using category.children_data to display subcategories.


Only DDL shows correct column size with MAX_STRING_SIZE  = EXTENDED (Oracle 19c)

Description
Under table T, under columns dropdown, The Database Navigator shows the column as 4000.
Also right-click table, view table, Properties tab, columns vertical tab, shows 4000.
Only viewing the DDL shows the correct size.

DBeaver Version
DBeaver Enterprise Version <IP_ADDRESS>309120446
Operating System
Windows 11
Database and driver
Oracle Database 19c Enterprise Edition Release <IP_ADDRESS>.0 - Production
Version <IP_ADDRESS>.0
with MAX_STRING_SIZE  = EXTENDED
Steps to reproduce
CREATE TABLE T(
column1 VARCHAR2(8000 CHAR)
)
Under table T, under columns dropdown, The Database Navigator shows the column as 4000.
Also right-click table, view table, Properties tab, columns vertical tab, shows 4000.
Only viewing the DDL shows the correct size.
Additional context
No response

Hello @rockyfjord
Thanks for the report.
This is for future testing: https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/MAX_STRING_SIZE.html#GUID-D424D23B-0933-425F-BC69-9C0E6724693C

Closed as a duplicate of https://github.com/dbeaver/dbeaver/issues/20231


project.py fail II

with PR #2179 the result of
project.py -m NUCLEO_F401RE -i GCC_ARM -n RTOS_1

is a folder .temp not a zip as before.

cc @sarahmarshy

Ah, sorry, pushed that before I saw  your fix. Equally good.


Discard master and slave language

For diversity reasons, it would be nice to try to avoid 'master' and 'slave' terminology in this repository which can be associated to slavery. The master-slave terminology could be problematic for people in several countries which has the history of slavery like Romania, USA and many others. Thank you for considering the proposal. Let me know if any changes in the PR are needed, I would be happy to implement them.

I agree and approve. Thank you for taking the time to draw attention to this!

I also changed the default branch name


wcow: support graceful termination of servercore containers

Graceful termination was already supported for nanoserver containers,
but those based on servercore still use a 5 second timeout which is
controlled by Windows. The reason behind this behavior is due to the
different implementation of SrvEndTask() in Servercore image which is
as follows:
(1) Deliver CTRL_SHUTDOWN_EVENT to the appropriate process
(2) Wait for 'WaitToKillServiceTimeout' amount of time (5 seconds by default) and kill the process before returning back to the caller.
This causes the containers with servercore base images to be killed in 5 seconds immaterial of the timeout specified with the container stop command.
We fix this by instead sending the termination signal for WCOW on a
background goroutine, and then returning immediately without waiting
for 'WaitToKillServiceTimeout' to expire.
In the future, if the underlying issue in Windows is fixed, this change could be reverted.

Tried to capture the time elapsed since the container exited using container stats but this is not supported for a container that has already existed.

Could you clarify what the problem with this is? I would think getting stats on an exited container (so long as it's not cleaned up) would be supported.

Tried to capture the elapsed time before and after container was stopped with a timeout but even without this fix, I see that containerStopWithTimeout() in test/cri-containerd waits for the entire timeout period even if the container exits before the specified timeout has elapsed.

I wonder if this is a bug in our cri? Do you know if that's the case?

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

Tried to capture the time elapsed since the container exited using container stats but this is not supported for a container that has already existed.

Could you clarify what the problem with this is? I would think getting stats on an exited container (so long as it's not cleaned up) would be supported.

I am using the StopContainerWithTimeout() function to stop the container with timeout in the cri test. This function currently kills the container after the timeout has passed and trying to get status after that results in the following error :
=== RUN   Test_Gracefultermination_WCOW_Hypervisor_Servercore
error getting container container stats after stop: rpc error: code = Unknown desc = unexpected metrics response: []
stopcontainer_test.go:68: error getting container container stats after stop: rpc error: code = Unknown desc = unexpected metrics response: []

Tried to capture the elapsed time before and after container was stopped with a timeout but even without this fix, I see that containerStopWithTimeout() in test/cri-containerd waits for the entire timeout period even if the container exits before the specified timeout has elapsed.

I wonder if this is a bug in our cri? Do you know if that's the case?

I am not sure of this but it probably is something with the implementation as capturing the time right before and after the StopContainerWithTimeout() function with a timeout of 't' always returns a diff of 't' seconds even without my fix (but when I run it manually crictl.exe stop -t of any value kills the container in 5 seconds on servercore base images).

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

There are a lot of complaints saying we are not supporting timeout >5 seconds so am not sure if too many folks rely on the 5 second timer. I can double check with Brandon about this. The idea was to make behavior similar to nanoserver and linux which honor graceful timeout. Maybe adding release notes about this fix would help any customer upgrading to the latest package whenever its released?

A few notes on Git commit style:

The commit title should be fairly short (a lot of places recommend 50 characters max, but I think going a bit over this is still fine).
The commit title should be written using imperative mood.
If it is helpful, the title can be prefixed with a brief descriptor indicating the scope of the change (e.g. internal/foo: fix bug bar).
The commit title should be followed by a blank line, and then a mutli-line commit body with more details on the change. It's good to describe here what changed and why the change is important, follow-up work that may be needed, link to more info on the change, etc. The commit body should also not use super long lines when it can be avoided. Personally I try to keep my lines to 72 characters max.

Taken together, you might consider a commit description like the following:
wcow: Support graceful termination of servercore containers

Graceful termination was already supported for nanoserver containers,
but those based on servercore still use a 5 second timeout which is
controlled by Windows. The reason behind this behavior is <reason>.

We fix this by instead sending the termination signal for WCOW on a
background goroutine, and then returning. <more details on fix>.

In the future, if the underlying issue is fixed in Windows, this change
could be reverted.

There's a lot of guidance on the internet for how to write a good Git commit. One guide I like is here. Note that here we are not super prescriptive on the exact line length to use. :)

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

This is probably worth explicitly calling out in the PR/commit description. If a customer (for whatever reason) explicitly depended on this WaitToKillServiceTimeout value, this would be a breaking change for them. For instance, if a customer sent a termination signal between apps in their container, they would observe a difference in behavior now.

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

This is probably worth explicitly calling out in the PR/commit description. If a customer (for whatever reason) explicitly depended on this WaitToKillServiceTimeout value, this would be a breaking change for them. For instance, if a customer sent a termination signal between apps in their container, they would observe a difference in behavior now.

Actually, @jsturtevant or @marosset interested in your opinions on if this will be a problem for customers. This change will fix graceful termination for servercore containers, but could have negative impact if a customer is relying on the default termination timeout in servercore.

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

This is probably worth explicitly calling out in the PR/commit description. If a customer (for whatever reason) explicitly depended on this WaitToKillServiceTimeout value, this would be a breaking change for them. For instance, if a customer sent a termination signal between apps in their container, they would observe a difference in behavior now.

Actually, @jsturtevant or @marosset interested in your opinions on if this will be a problem for customers. This change will fix graceful termination for servercore containers, but could have negative impact if a customer is relying on the default termination timeout in servercore.

IMO there are a lot of downsides w/ relying on the default termination timeout in servercore (especially for K8s scenarios) and users are unhappy with current solution.
I agree we should call this out as a breaking change but think it might be more important to label this as a breaking change in containerd when we update decencies there.

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

This is probably worth explicitly calling out in the PR/commit description. If a customer (for whatever reason) explicitly depended on this WaitToKillServiceTimeout value, this would be a breaking change for them. For instance, if a customer sent a termination signal between apps in their container, they would observe a difference in behavior now.

Actually, @jsturtevant or @marosset interested in your opinions on if this will be a problem for customers. This change will fix graceful termination for servercore containers, but could have negative impact if a customer is relying on the default termination timeout in servercore.

IMO there are a lot of downsides w/ relying on the default termination timeout in servercore (especially for K8s scenarios) and users are unhappy with current solution. I agree we should call this out as a breaking change but think it might be more important to label this as a breaking change in containerd when we update decencies there.

I am not sure I understand why this is a breaking change.  The WaitToKillServiceTimeout reg key is used only when crictl.exe stop -t   is specified. Currently no matter what value of 't' is specified, it is always killed in 5 seconds. This fix is only going to help honor the time specified. Am I missing something here?

wcow: Support graceful termination of servercore containers

A few notes on Git commit style:

The commit title should be fairly short (a lot of places recommend 50 characters max, but I think going a bit over this is still fine).
The commit title should be written using imperative mood.
If it is helpful, the title can be prefixed with a brief descriptor indicating the scope of the change (e.g. internal/foo: fix bug bar).
The commit title should be followed by a blank line, and then a mutli-line commit body with more details on the change. It's good to describe here what changed and why the change is important, follow-up work that may be needed, link to more info on the change, etc. The commit body should also not use super long lines when it can be avoided. Personally I try to keep my lines to 72 characters max.

Taken together, you might consider a commit description like the following:
wcow: Support graceful termination of servercore containers

Graceful termination was already supported for nanoserver containers,
but those based on servercore still use a 5 second timeout which is
controlled by Windows. The reason behind this behavior is <reason>.

We fix this by instead sending the termination signal for WCOW on a
background goroutine, and then returning. <more details on fix>.

In the future, if the underlying issue is fixed in Windows, this change
could be reverted.

There's a lot of guidance on the internet for how to write a good Git commit. One guide I like is here. Note that here we are not super prescriptive on the exact line length to use. :)

Sure I'll keep this in mind, thanks Kevin :) I was following the template we had on my previous team for the commit body on ADO.

A few notes on Git commit style:

The commit title should be fairly short (a lot of places recommend 50 characters max, but I think going a bit over this is still fine).
The commit title should be written using imperative mood.
If it is helpful, the title can be prefixed with a brief descriptor indicating the scope of the change (e.g. internal/foo: fix bug bar).
The commit title should be followed by a blank line, and then a mutli-line commit body with more details on the change. It's good to describe here what changed and why the change is important, follow-up work that may be needed, link to more info on the change, etc. The commit body should also not use super long lines when it can be avoided. Personally I try to keep my lines to 72 characters max.

Taken together, you might consider a commit description like the following:
wcow: Support graceful termination of servercore containers

Graceful termination was already supported for nanoserver containers,
but those based on servercore still use a 5 second timeout which is
controlled by Windows. The reason behind this behavior is <reason>.

We fix this by instead sending the termination signal for WCOW on a
background goroutine, and then returning. <more details on fix>.

In the future, if the underlying issue is fixed in Windows, this change
could be reverted.

There's a lot of guidance on the internet for how to write a good Git commit. One guide I like is here. Note that here we are not super prescriptive on the exact line length to use. :)

Sure I'll keep this in mind, thanks Kevin :) Also, do we follow a template for the PR description section? Does that section look ok?

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

This is probably worth explicitly calling out in the PR/commit description. If a customer (for whatever reason) explicitly depended on this WaitToKillServiceTimeout value, this would be a breaking change for them. For instance, if a customer sent a termination signal between apps in their container, they would observe a difference in behavior now.

Actually, @jsturtevant or @marosset interested in your opinions on if this will be a problem for customers. This change will fix graceful termination for servercore containers, but could have negative impact if a customer is relying on the default termination timeout in servercore.

IMO there are a lot of downsides w/ relying on the default termination timeout in servercore (especially for K8s scenarios) and users are unhappy with current solution. I agree we should call this out as a breaking change but think it might be more important to label this as a breaking change in containerd when we update decencies there.

In Kubernetes it is a very common p

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

This is probably worth explicitly calling out in the PR/commit description. If a customer (for whatever reason) explicitly depended on this WaitToKillServiceTimeout value, this would be a breaking change for them. For instance, if a customer sent a termination signal between apps in their container, they would observe a difference in behavior now.

Actually, @jsturtevant or @marosset interested in your opinions on if this will be a problem for customers. This change will fix graceful termination for servercore containers, but could have negative impact if a customer is relying on the default termination timeout in servercore.

IMO there are a lot of downsides w/ relying on the default termination timeout in servercore (especially for K8s scenarios) and users are unhappy with current solution. I agree we should call this out as a breaking change but think it might be more important to label this as a breaking change in containerd when we update decencies there.

I am not sure I understand why this is a breaking change.  The WaitToKillServiceTimeout reg key is used only when crictl.exe stop **-t ** is specified. Currently no matter what value of 't' is specified, it is always killed in 5 seconds. This fix is only going to help honor the time specified. Am I missing something here?

In Kubernetes it is common for pods to be stopped with a termination grace period.
When this happens a shutdown signal is sent to the containers and that after a configurable timeout a kill signal is sent.
This is commonly used during scale-down operations, and it gives and containers that are selected for scale-down a chance to complete any in-progress operations and the configurable timeouts are controlled are set by Kubernetes and can be changed at any time.
My understanding is that the currently shutdown behavior for servercore based containers is that it must be set at container build time. This does not provide the flexibility cluster operators expect.
I think it would be a breaking change because shutdown logic would no longer be honoring registry keys which previously affected shutdown duration/behaviour.

In Hcsshim, we override value of reg key 'WaitToKillServiceTimeout' from 5 seconds to 30 minutes

Did you mean 30 seconds? Do we know if this will impact container users if they rely on this 5 second timeout?

This is probably worth explicitly calling out in the PR/commit description. If a customer (for whatever reason) explicitly depended on this WaitToKillServiceTimeout value, this would be a breaking change for them. For instance, if a customer sent a termination signal between apps in their container, they would observe a difference in behavior now.

Actually, @jsturtevant or @marosset interested in your opinions on if this will be a problem for customers. This change will fix graceful termination for servercore containers, but could have negative impact if a customer is relying on the default termination timeout in servercore.

IMO there are a lot of downsides w/ relying on the default termination timeout in servercore (especially for K8s scenarios) and users are unhappy with current solution. I agree we should call this out as a breaking change but think it might be more important to label this as a breaking change in containerd when we update decencies there.

I am not sure I understand why this is a breaking change.  The WaitToKillServiceTimeout reg key is used only when crictl.exe stop **-t ** is specified. Currently no matter what value of 't' is specified, it is always killed in 5 seconds. This fix is only going to help honor the time specified. Am I missing something here?

Discussed this with Kevin today and I understand how this could be a breaking change. I will make sure to call this out specifically.

I've signed off on this PR. If there's any additional testing we can do before merging that would be idea, though. Maybe you can run the upstream containerd integration tests with an updated shim binary?


vite 5 support

Hi,
Is there plan to support vite 5?
Thanks.

There is! I don't believe the plugin is incompatible with Vite v5. We're just waiting on Meteor v3, as Vite v5 dropped support for Node.js 14 - which is the version Meteor v2 uses internally.
If there is a need for Vite v5 for users on Meteor v2, there are certainly ways to get around this, as I assume most people will have a newer version of Node.js already installed that we can use instead when firing up Vite from Meteor. But I've opted not to put much time into that as I don't think the complexity of managing two Node.js installs for your environment makes the upgrade worthwhile.
But again, I'm open to add support if there is a real need. I'd love to hear some use cases. 🙌

In fact, I use the package vite-plugin-vuetify and it has as peer dependencies vite  >=5:
"peerDependencies": {
        "vite": ">=5",
        "vue": "^3.0.0",
        "vuetify": "^3.0.0"
      }

So I have some error running npm.
But at least everything to work.

Yeah, most plugins have recently upped their major version to match the new Vite release. Usually there aren't any major changes apart from the Vite v5 version bump.
https://github.com/vuetifyjs/vuetify-loader/blob/master/packages/vite-plugin/CHANGELOG.md#-breaking-changes
The following should fix those warnings for you. I'll be sure to add Vite v4 as a peer dependency for our plugin so npm won't try to install incompatible plugin versions.
npm i vite-plugin-vuetify@1


libunwind: 1.6.2 -> 1.7.2

Description of changes

The original upstream no longer publishs new tarballs, switch to GitHub.
Remove upstreamed patch.
Add new platforms supported by latest libunwind.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2766

LGTM, built 5 reverse dependencies locally and they seem to work.


Add tooltip for tabs in TabBar and TabContainer

Ah, sorry. Just noticed that #89247 already exists.

Would be great if you could review that PR and see if some of the changes you made are needed there / would be better.


Position 2 is 1 pixel north!

Hello! I enjoy your plugin and the idea is creative, but the position 2 slot is misaligned. It will shift whenever the plugin is active. Hopefully, this is an easy number tweak, as I enjoy customizing my client, but it's hard to ignore once you notice it haha. Thank you!

Didn't see others have already posted this issue. Closing this.


ExceptT constructor

Any reason why the ExceptT constructor is not exported? As far as I can see, it’s the only way to conveniently go from Either to ExceptT.

I believe it is: https://github.com/sdiehl/protolude/blob/c9a2d176d144c4e9ac3a11668706e5f0c11ec0bf/src/Protolude.hs#L293

Ah, then I probably looked at the wrong package or commit. What about withExcept(T) and mapExcept(T)? They shouldn’t clash with anything else and since it’s a monad transformer they are the only way to modify the exception value.

Don't see any issue with adding them. We already export withState. :+1:


Updated Dutch translations.

I ran into a few fields that were not translated to Dutch, so I updated the translation file with the Dutch translations for the lines that were empty before.

🤖 Generated by Copilot at 238a0f3
This pull request updates and improves the Dutch translations for ghost.json and portal.json in the ghost/i18n/locales/nl folder, making them more accurate, consistent, and user-friendly.

Hoi @sanne-san! Thanks for the review, I updated all the suggestions.
I do disagree about the use of hey, which is not a dutch word. The informal alternative would be hoi, but that feels too informal to me. That's why my suggestion was 'hallo'. But as this is the consensus within the dutch speaking team, I updated it anyway!

@martijnburger thanks for the updates! You made a good point so I brought it up again with the team – let's go with Hallo instead. Are you ok to change that still?

@sanne-san Updated to Hallo


[Bug] Custom ring is not showing up on the player's client

Describe the bug
Custom ring is not showing up on the player's client but is showing correctly on the GM's client.
To Reproduce
Steps to reproduce the behavior:

Create am custom ring.
Check that an actor has the correct ring on the GM's client.
Check the same actor on the player's client.

Expected behavior
Custom ring should be showing on all clients.

Oh i think i know the issue, i'll look into it!

It should be fixed!

Confirmed. Thank you!


Re-design GetAttributeAtVertex

Is your feature request related to a problem? Please describe.
The current implementation of GetAttributeAtVertex has bugs which are products of the design rather than just the implementation:

https://github.com/microsoft/DirectXShaderCompiler/issues/6220
https://github.com/microsoft/DirectXShaderCompiler/issues/5417
https://github.com/microsoft/DirectXShaderCompiler/pull/6453

Describe the solution you'd like
We need to design a different approach to this feature that doesn't rely on compiler optimization to guarantee correctness.
Describe alternatives you've considered

Use a proper type qualification for data that may have attributes
Use a boxed type for parameters that may have attributes

(cc @Keenuts, @sudonatalie, @tex3d)
I filed this to track our need to spend some time designing an alternate solution at the language level to handle GetAttributeAtVertex.

Do you happen to know how the DXIL side is usually implemented? And why we haven't required the input of GetAttributeAtVertex() to be an array of 3?
On the SPIR-V Side, the shader ends up with a array as input. nointerpolate float a : A would give us roughly:
%array_type = OpTypeArray %float 3
%a = OpVariable %array_type Input

So if the HLSL type was an actual array, it would be quite easy to support this feature correctly.

The DXIL side of this is totally magic (and buggy). We don't actually represent the parameter as anything but the specified source type. The presence of the attributes is implied in DXIL not represented.


MirrorVertexGroups keeps return DictGroup error custom pattern

MirrorVertexGroups 0.0.1
OSX 10.11.6
bl 2.83
Im using trying to use the mirror action using a custom pattern to limit the number of groups it will mirror. Im using this pattern "LeftLegUp" + "RightLegUp", im not sure the enum pattern then will also be used, its not being grayed out as you choose custom.
Each time i tried it, it loops over all existing groups, then when it reaches that group return a dictgroup error.
Here's short past of the console, it has a long list of each group, but thats not needed for this error
ixamorig:LeftFoot
318
mixamorig:LeftToeBase
318
mixamorig:LeftFoot
320
mixamorig:RightFoot
320
mixamorig:LeftLeg
320
mixamorig:LeftToeBase
320
mixamorig:LeftFoot
319
mixamorig:LeftLeg
319
mixamorig:LeftToeBase
319
mixamorig:LeftLeg
317
mixamorig:RightFoot
317
mixamorig:LeftToeBase
317
mixamorig:LeftLeg
318
mixamorig:Spine2
318
mixamorig:LeftToeBase
318
mixamorig:LeftLeg
317
Traceback (most recent call last):
  File "/Users/macpro1/Library/Application Support/Blender/2.80/scripts/addons/MirrorAllVertexGroups.py", line 206, in execute
    copy_mirror_weight(self.enum_Axis,self.enum_Way,self.enum_Pattern,self.special_pattern,self.left_side,self.right_side,self.tolerance)
  File "/Users/macpro1/Library/Application Support/Blender/2.80/scripts/addons/MirrorAllVertexGroups.py", line 162, in copy_mirror_weight
    print(DictGroup[group.group])
KeyError: 60

location: <unknown location>:-1

location: <unknown location>:-1
Error: Traceback (most recent call last):
  File "/Users/macpro1/Library/Application Support/Blender/2.80/scripts/addons/MirrorAllVertexGroups.py", line 206, in execute
    copy_mirror_weight(self.enum_Axis,self.enum_Way,self.enum_Pattern,self.special_pattern,self.left_side,self.right_side,self.tolerance)
  File "/Users/macpro1/Library/Application Support/Blender/2.80/scripts/addons/MirrorAllVertexGroups.py", line 162, in copy_mirror_weight
    print(DictGroup[group.group])
KeyError: 60

location: <unknown location>:-1

That KeyError seems to be different each time i run it.

PS in the top it says "Actions", that is some leftover code i guess, i see in the code its just a string and has not functionality

Does the custom pattern only look at trailing pattern. so everything after the dot?
Im testing this on a Mixamo rig and it doesnt have the regular pattern like .l or .r or any of these it has Left and Right in the middle of the name.
If i understand the error correct, it looks like it cant find the pattern. Im not sure also why it states the same group multiple times. For instance the group "mixamo:head" is shown 146 times in the output, seems like its running over code again and again adding to a dictgroup but that cause it to get added multiple times.
Ive added the complete output here in a log file
error-custom-pattern.log
The error is there because is no error catch as well.
After trying a simpler pattern with just the word 'Left' and 'Right', i did run, yet im not sure if the outcome is correct. It basically made left and right the same. I thought it would mirror from L to R and use propernaming.
I do notice when i add say :LeftLegUp as a custom pattern, then it seems to go wack. It then basically mirrors from left to right in the left group and the right group is basically empty.

PS i altered the operator, so now when it has an error it will show that in the bottom info panel, it will also show when its done. At the end i tried showing the issue i pasted earlier, when i use a pattern which also adds something else other then Left or Right

I believe the issue here is how it is applying vertex groups when using a custom pattern. I think it will always try to delete and add no matter the pattern. I see a couple for loops and in one i do see the pattern is being search for. But in the loop below that it is not, i think thats causing the issue here.
When i use a pattern of only "left" en "right" it does work, when i expand it to say "LeftUp" to narrow the results down it causes an error. I think thats to those second for loops deleting and adding no matter if the pattern is in there.

hey sorry I just saw this.  yeah the code is using a trailing pattern.   the _L and _R are best as other tools don't like "." in object names.    you can use the batch rename tool in the menu to conform badly named skeletons btw.

I found this code and ported it since I use it a lot.  I am draconian about skeleton naming so if you are trying to use it on a messy skeleton naming it's going to be easy to break.  I suggest renaming your skeletons to follow a clean standard and use "_L" and "_R" for chirality.


Second bar on cooldowns

I have configured my XML file to only have 3 skills in the cooldown window and set the mode to fixed but I still get all the default cooldowns showing up on a second bar and don't know how to get rid of them. (Berserker)

Use UI instead of xml file if you're on v1.0.X.

I have already done that but still get this second bar that I can't interact with

Normally it looks like this

That's how it's supposed to work. You get all other skills on 2nd row. You have to manually Hide them using the button if you don't want to see them.


fix jax deps

Issue
Encountered by @erialc-cal
Importing cpa fails after following the installation tutorial due to the call to jax.random.KeyArray in ... which was already depracated in 0.4.16 and recently (Feb. 6th) removed in 0.4.24, see here for more details.
>>> import cpa
[rank: 0] Global seed set to 0
...[trace]...
AttributeError: module 'jax.random' has no attribute 'KeyArray'
How to  Reproduce

conda create -n cpa python=3.9
conda activate cpa
pip install git+https://github.com/theislab/cpa
python
>>> import cpa

Fix/Changes
Added jax version upper bound in pyproject.toml, also added same for jaxlib to avoid consistency errors for jax.

Thank you for noticing the issue, I am merging your PR to the main branch.


fix: #7030 use temp-dir instead of data-dir for lock files

Fixes Issue
#7030
Description of Change
Use temp directory for lockfile instead of data directory
Have test cases been added to cover the new functionality?
no

https://github.com/jeremylong/DependencyCheck/blob/585016a461edd96b2e0a06055266c75a927d5389/utils/src/main/java/org/owasp/dependencycheck/utils/Settings.java#L1269
Your 'fix' is breaking the exclusive locking meant to ensure that 'during update' the files will not be used by another parallel execution of ODC that uses the same datadirectory.
Tempdirectory will be a unique folder per ODC process.

@aikebah thanks for the response, i've converted the PR to draft, since it was kind of low effort, end-of-day and couldn't get the tests running properly locally
But, i see, would it be acceptable to use system temp directory for lock files?

OK, the tests do look better now.
The once that are failing are also failing for me locally on a clean checkout of this repo, so i'm not sure what to do with that

@guidoschreuder system temp folder for the locks would, for the same reasons, typically only work for single system CI environments. Containerized with volume-mounted datafolder and multiserver with network-mounted datafolder would also need the lock folder to be shared with the same granularity so that all instances that share the same datafolder also share the same locks folder.
The only change I can imagine to support your setup while retaining the intended locking semantics is to add a configuration possibility for a separate data-locks folder (that would need to be shared between builds in the exact same granularity as the datafolder itself and that would typically default, if not configured explicitly, to the datafolder itself)

@aikebah thanks for the clarification, i totally get your point
that solution would work for me, so, i could continue on that if that would be accepted
(just for background) we really would never experience any problems without locking, what we do is, roughly:

we have a single, exclusive, task that runs periodically
we maintain multiple versions of the data directory e.g. /owasp_cache/d1, /owasp_cache/d2, etc.
before updating we copy the latest directory to a new directory and then run update over that
when successful we ln -snf /owasp_cache/cache /owasp_cache/d3
and then rotate old directories away

When I spotted your issue in the tracker an approach along those lines would be what I had in mind to resolve it, so if you code a PR along those lines I would be happy to accept it.
Be aware though that there are also the various dynamic caches (unless you disable their caching): for centralAnalyzer, NodeAudit and the OSSIndexAnalyzer.
Depending on the frequency of your builds and the amount of overlap in dependencies across projects you might have a benefit by hosting those on a shared, writeable volume/mount to have the builds profit from a lower number of dependencies to lookup at the remote APIs for those.
These dynamic caches are currently stored (if writeable, otherwise caching is automatically disabled) inside two subfolders (oss_cache and cache) underneath the data folder; I think these locations are also not configurable at the moment so if the caching would be valuable to you  you might want to extend configurability to also allow these two cache folders  to point to (shared across your builds) writeable locations outside of your read-only mounted data folder.

Closing the PR as a better approach would be figuring out why a lock is generated when auto-update is disabled.

@jeremylong lock is taken by the engine to guard that the copy-to-a-temp-folder of the H2 database file for readOnly access copies from a stable and consistent state - https://github.com/jeremylong/DependencyCheck/blob/116a63fdba7706cec2cf6a33d8002c9d53a16f8f/core/src/main/java/org/owasp/dependencycheck/Engine.java#L1002


MQTT camera

Which addon?

ICantBelieveItsNotValetudo
Describe the bug
According to the documentation, this plugin should generate PNG and publish it to HA as MQTT camera.

So the floor plan can be accessed via the build-in side panel or the auto-configured mqtt camera.

But for me, the auto-configured MQTT camera doesnt exist.
Here's my config:
identifier: rockrobo_downstairs
topicPrefix: valetudo
autoconfPrefix: homeassistant
broker_url: 'mqtt://xxxx:xxxx@<IP_ADDRESS>:1884'
caPath: ''
mapSettings:
  drawPath: true
  drawCharger: true
  drawRobot: true
  border: 2
  scale: 4
  crop_x1: 90
  crop_x2: 200
  crop_y1: 80
  crop_y2: 280
mapDataTopic: valetudo/rockrobo_downstairs/map_data
minMillisecondsBetweenMapUpdates: 10000
publishMapImage: true

Log:
[18:04:10] INFO: Setup config
[18:04:10] INFO: Start ICantVelieveItsNotValetudo

><EMAIL_ADDRESS>start /app
> node app.js

Loading configuration file: /app/config.json
Connecting to MQTT Broker
Webserver running on port 3000
Connected to MQTT Broker

And here's what is published to homeassistant autodiscovery topic when restarting Icantbelieveitsnotvaletudo:
Feb 27 18:04:11 homeassistant/camera/valetudo_rockrobo_downstairs_map/config {"name":"rockrobo_downstairs_map","unique_id":"rockrobo_downstairs_map","topic":"valetudo/rockrobo_downstairs/map"}
The rockrobo_downstairs_map text sensor is visible and fine in HA. The Ingress functionality is working fine and shows the correct PNG.
Expected behavior
I should have a camera.rockrobo_downstairs_map device in HA which would show same map as Ingress feature.

I will look it up, when at home. But I guess it's an issue on the ICantBeliveItsNotValetudo software and not the addon package.

Can you tell me what the text sensor is showing?
Does the valetudo/rockrobo_downstairs/map contains the png?
Do you have Mqtt Discovery enabled?
I'm having the same situation except that the text sensor is the image.

Im not sure if text sensor is from this addon or just vacuum cleaner integration, but its huge.
header_length: 20
data_length: 62059
version:
major: 1
minor: 0

map_index: 107
map_sequence: 3954
image:
position:
  top: 249
  left: 390
dimensions:
  height: 383
  width: 313
pixels:
  floor:
    - - 137
      - 273
    - - 138
      - 273
    - - 139
      - 273
    - - 140
      - 273
    - - 141
      - 273
    - - 142
      - 273
    - - 143
      - 273
    - - 144
      - 273
    - - 145
      - 273
    - - 146
      - 273
    - - 147
      - 273
    - - 148
...
...
...

dinth@ubuntu-server1:~$ mosquitto_sub -h <IP_ADDRESS> -p 1884 -u wickhay-mqtt -P wickhay-mqtt -t '#' -v | grep valetudo
valetudo/rockrobo_downstairs/state {"state":"docked","battery_level":100,"fan_speed":"max"}
valetudo/rockrobo_downstairs/attributes {"cleanTime":"35.1","cleanArea":"1940.9","cleanCount":102,"last_run_stats":{"startTime":1583060401000,"endTime":1583062246000,"duration":1845,"area":"25.6","errorCode":0,"errorDescription":"No error","finishedFlag":true},"mainBrush":"264.9","sideBrush":"164.9","filter":"114.9","sensor":"0.0","state":"docked","valetudo_state":{"id":8,"name":"Charging"}}
valetudo/rockrobo_downstairs/map_data {"header_length":20,"data_length":62059,"version":{"major":1,"minor":0},"map_index":107,"map_sequence":3954,"image":{"position":{"top":249,"left":390},"dimensions":{"height":383,"width":313},"pixels":{"floor":[[137,273],[138,273],[139,273],[140,273],[141,273],[142,273],[143,273],[144,273],[145,273],[146,273],[147,273],[148,273],[149,273],[150,273],[151,273],[152,273],[153,273],[154,273],[155,273],[156,273],[157,273],[158,273],[159,273],[160,273],[161,273],[162,273],[163,273],[164,273],[165,273],[166,273],[167,273],[168,273],[169,273],[170,273],[171,273],[172,273],[173,273],[174,273],[175,273],[176,273],[113,272],[114,272],[115,272],[116,272],[117,272],[118,272],[119,272],[120,272],[121,272],[122,272],[123,272],[124,272],[125,272],[126,272],[127,272],[128,272],[129,272],[130,272],[131,272],[132,272],[133,272],[134,272],[135,272],[136,272],[137,272],[138,272],[139,272],[140,272],[141,272],[142,272],[143,272],[144,272],[145,272],[146,272],[147,272],

[cut a lot of text]

Binary file (standard input) matches

Ok, it seems that the text sensor contains the raw data FOR the Addon.
So the addon don't push the png on the valetudo/rockrobo_downstairs/map topic.
Did your vacuum move? The image generation happens only when new data arrives at the broker.

Hmm, tested it yesterday with my vacuum and your settings (except the cropping) and it worked out 😅
Maybe they can help you out better in the repro of  ICantBeliveItsNotValetudo itself.


How can we freeze the layer?

Hi, I want to know how can we freeze the layer and let them not update parameters? I have a such question after I read your paper.

Hi @VoyageWang , you can set param.requires_grad=False. Please refer to https://github.com/taoyang1122/adapt-image-models/blob/main/tools/train.py#L187

你好，你的邮件已经被我接受。hello，your email has been recieved. Thank you.


Concerns about the evaluation metric.

Description
According to "Anomaly scoring is based on overlapping segments: a true positive (TP) if a known anomalous window overlaps any detected windows, a false negative (FN) if a known anomalous window does not overlap any detected windows, and a false positive (FP) if a detected window does not overlap any known anomalous region" in the "AER: Auto-Encoder with Regression for Time Series Anomaly Detection" paper.
We find that this library uses an evaluation method resembling point-adjustment (PA), which can overestimate the model's performance. Details please refer to https://github.com/thuml/Anomaly-Transformer/issues/65 and paper "Towards a Rigorous Evaluation of Time-Series Anomaly Detection".
Please use the recent proposed F1(PA%K) [1] and VUS-PR [2] metric for a rigorous evaluation.
[1]  Siwon Kim, Kukjin Choi, Hyun-Soo Choi, Byunghan Lee, and Sungroh Yoon. 2022. Towards a Rigorous Evaluation of Time-Series Anomaly Detection. Proceedings of the AAAI Conference on Artificial Intelligence 36, 7 (June 2022), 7194– 7201. https://doi.org/10.1609/aaai.v36i7.20680
[2] John Paparrizos, Paul Boniol, Themis Palpanas, Ruey S. Tsay, Aaron Elmore, and Michael J. Franklin. 2022. Volume under the Surface: A New Accuracy Evaluation Measure for Time-Series Anomaly Detection. Proceedings of the VLDB Endowment 15, 11 (July 2022), 2774–2787. https://doi.org/10.14778/3551793.3551830

Hi @richard-tang199 – thank you for raising this issue.
The AER paper adopts the overlapping evaluation method proposed in the NASA paper. This evaluation strategy has been used in many papers and all the models in the benchmark use the same evaluation strategy. Therefore, the comparison is unified.
I would like to note that there are differences between the mentioned overlap strategy and point-adjustment (PA). In PA, the model is rewarded for predicting a single point as anomaly if it overlaps with the ground truth anomaly. Therefore, the model is incentivized to predict one point as anomaly at various locations hoping that one of it overlaps with the true one. The false positives in this situation is not severe because the number of normal instances substantially overweights anomalies.
In our evaluation method, we do not concern ourselves with the normal sequences. We evaluate the ability of finding the anomaly without looking at the normal class. Moreover, all the anomalies are predicted as an interval with (start, end) timestamps of various lengths, this reduces the chances of exploiting the point anomalies as I have mentioned earlier.
Nevertheless, we appreciate the suggestion of including more metrics in our evaluation criteria as we are always interesting in having a wholesome evaluation to all models. We also welcome their implementation in our evaluation sub-package if you would like to take the opportunity and contribute.
Please let me know if you have any further questions


Readme: Add PyPI version badge

Add a PyPI version badge to the Readme to quickly see the latest stable version uploaded to PyPI.

It would also be convenient to keep the git tags and GitHub releases in sync with the PyPI version.


Feature/prepare manage boxes for shipments part 1

@pylipp @aerinsol
@vahidbazzaz and I agreed that we will merge this so we can both base our additional PR on master. Since we will touch all files again (and it is not yet used by our users), it has not been as thoroughly reviewed as we normally do.

 2.0 Manage Boxes Improvements for Shipments #extra-large

Noted, thanks @HaGuesto @vahidbazzaz


Add item button UX

On the form-fill page there are some Add Item buttons (when creating a relation and there is no such leader/project)
This button should provide better UX:

[ ] It should be hidden if the object is found in the DB
[ ] It should notify about successful saving the item to the DB (maybe just with that fact that it disappears)
[ ] It should ask user before send API request for adding the item like "Are you sure?"
[ ] It should be more visible and it's action should be more obvious
Item 3.7 from tasks table

Also the same button should be near Location input. If there is no such location is the DB user should be able to add the location using similar mechanism (3.17)

4 story points


Critical vulnerability idenfitied suggestion of a Private reporting

Hi,
I have identified a critical vulnerability in the latest codebase of django-oscar.
I think reporting it publicly as an issue, is not correct. I suggest please that you enable the GitHub's private vulnerability reporting for this repository. It would permit CVE assigning, private discussion, etc.
Otherwise, if you have a bug bounty program, I am wiling to share my report in there.
Thank you in advance.

Hi @Sim4n6 , excuse the somewhat late reply. Could you please send me an email regarding the vulnerability (contact on my github profile) or alternatively upload it to something like https://huntr.dev/?
The person who has admin rights on this repo is unavailable at the moment to enable the private vulnerability option, but we'll do so once he's back.

No problem, I will write the details using the huntr platform.

Report submitted https://huntr.dev/bounties/f0e67c54-e881-45ca-942a-aa7e4e6cee5e

In case you have a bug bounty program or you consider I am eligible for a bounty please let me know.
And please keep me posted regarding the activation of the GitHub Private Bounty reporting feature ...


[RayService][HA] Fix flaky tests

Why are these changes needed?
Fix flaky tests introduced by #1808. Note that the RayService was already flaky before #1808, but it became much more unstable after #1808 (failing about 5 times in 6 runs). Although the tests remain as flaky as they were before #1808 even after this PR is merged, it does alleviate the additional flakiness introduced by #1808.
Related issue number

Checks

[ ] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[ ] This PR is not tested :(

cc @Yicheng-Lu-llll

lgtm


Updated the validation for cloud service after deployment to wait for…

… teh isnatnes to come online with ReadyRole state

@jagany
Changes look fine to me.  I have left few comments please fix them, After that, I can test and merge PR.


Add support for multiple license keys

The current model has the following
('license_name', StringField(capture=True)),
...
('dje_license_key', SingleLineField(capture=True)),

which shows no multi-license can be generated at this moment.

We are having problem to create a dictionary list which have license short name as a key and license context as a value to pass to the template for generation.
For instance,
about_resource: jsch-0.1.52.jar
name: Jsch
version: v 0.1.52
license_name: |
    BSD-Modified
    Apache License 2.0
    MIT License
    Public Domain
license_file: |
    apache-2.0.LICENSE
    bsd-new.LICENSE
    public-domain.LICENSE
    mit.LICENSE
license_url: |
    https://enterprise.dejacode.com/urn/?urn=urn:dje:license:bsd-new
    https://enterprise.dejacode.com/urn/?urn=urn:dje:license:apache-2.0
    https://enterprise.dejacode.com/urn/?urn=urn:dje:license:mit
    https://enterprise.dejacode.com/urn/?urn=urn:dje:license:public-domain
copyright: Copyright (c) Atsuhiko Yamanaka
dje_license_key: |
    bsd-new
    apache-2.0
    mit
    public-domain
confirmed_license: BSD-Modified

When the tool look at the above ABOUT file, it cannot associate the 'BSD Modified' with 'bsd-new.LICENSE' or 'Apache 2.0' with 'apache-2.0.LICENSE'
The reason we need the short name is because  it looks better and the short name is used to identify COMMON_LICENSES listed in the licenses.py

We are not supporting to show license short name by default.
Fixed in
https://github.com/dejacode/about-code-tool/commit/1e5c2b2c501d4b52c3d6576d7764237fc90a90e2

@chinyeungli Is this is really closed? We should IMHO add support for SPDX license expressions and not multiple keys. And the multiple text fields that are like parallel lists without being lists nor dicts is not a the best way. Are we sure this is really closed?

For the multiple license texts, I ran some actual tests and it's working, but I should have added test code for it.
For the support of SPDX license, perhaps another ticket?

It can stay this same ticket I guess: SPDX-like expressions is really about multiple license keys, but I am fine either way

The current code use yaml newline for multiple lines/multiple licenses support.
For instance,
about_resource: .
name: test
license: |
    x11
    mit
    public-domain
    bsd-simplified

I've entered #275 for support of license expression.
We will not support license expression in version 3.
Closing this.


Added Connection name fields

Dear Emiel, I tried to complete your task, written in the e-mail.

Can you add a test-program to show that it works?


SAK-50164 Experimental patch do not merge

This is an experimental patch do not merge.

Just a test patch. Closed.


L58 touch controller cannot start.

When we set touch controller to L58, the error will accour and then will crash:
I (12428) L58: 158 init0) Touch initialized
I (12428) gpio: GPI0[16]1 InputEn: 11 OutputEn: 0l OpenDrain: 0l Pullup: 11 Pulldown: 0l Intr:1
Guru Meditation Error: Core 1 panic'ed (LoadProhibited).
Exception was unhandled.
Core 1 register dump:
PC
: 0x40092263 PS
0x00060733 A0
: 0x80092d4c A1
0x3fffda40
0x40092263: block_size at /Users/Shared/SDK/esp/esp-idf/components/heap/heap_tlsf_block_functions.h:75
(inlined by) block_locate_free at /Users/Shared/SDK/esp/esp-idf/components/heap/heap_tlsf.c:447
(inlined by) tlsf_malloc at /Users/Shared/SDK/esp/esp-idf/components/heap/heap_tlsf.c: 757
Az
0x3f800014 A3
A6
0x00060720 A7
A10
: Oxffff0000
A11
A14
: 0x007af028 A15
EXCVADDR: 0x02000004
LBEG
0×000bd800 A4
ex00000001
A8
0x0000000d
A12
ox003fffff SAR
0x4000c2e0
LEND
0x3§fb3d74
A5
0x00060723
0x02000000
Ag
Ox00000010
0x0000002c A13
0×3f£49010
0x0000001O EXCCAUSE: 0x0000001C
0x4000c2f6
LCOUNT
Oxffffffff
Backtrace:0x40092260:0x3fffda400x40092d49:0x3fffda600x40082451:0x3fffda800x40082479:0x3fffdaa00x400dalez:0x3fffda
c0 0x400907b1:0x3fffdb30
0x40092260: block_locate_free at /Users/Shared/SDK/esp/esp-idf/components/heap/heap_tlsf.c:445
(inlined by) tlsf_malloc at /Users/Shared/SDK/esp/esp-idf/components/heap/heap_tlsf.c:757
0x40092d49: multi_heap_malloc_implat/Users/Shared/SDK/esp/esp-idf/components/heap/multi_heap.c:189
0x40082451: heap_caps_malloc_base at /Users/Shared/SDK/esp/esp-idf/components/heap/heap_caps.c: 139
0x40082479: heap_caps_malloc at /Users/Shared/SDK/esp/esp-idf/components/heap/heap_caps.c: 159
0x400dalez: gui_task(void*) at /Users/lanistor/C/flicker/Hardware-EInk_Desktop_Display/main/main.cpp:83
0x400907b1: vPortTaskWrapper at /Users/Shared/SDK/esp/esp-idf/components/freertos/FreeRTOS-Kernel/portable/xtensa/po
rt.c:132

No matter if the touch screen device is attach to the PCB board or not.
So, had L58 touch driver been tested fine? Or It's my problem?
Set to GT911 will not cause crash.

No idea what is going on there but it seems like some heap memory corruption.
I tested it time ago with my old Lilygo and runs fine

No idea what is going on there but it seems like some heap memory corruption. I tested it time ago with my old Lilygo and runs fine

Yeah, this had be resolved.


[wip] support multi-query-attention

for multi_query_kv_attention, we can use torch.expand to expand single key/value to the same number of heads without incurring memory overhead
for single_query_kv_attention, we detect if the key_cache/value_cache is mqa, and reuse the same key/value for different head.

Thanks @scv119 for the inital exploration! Fixed in #452.


Workaround to clean up old reviews on creating a new one (#28554)

close  #28542
backport #28554

Sponsored by Kithara Software GmbH

looks like i have to adjust it to the old codebase :/


Update Ember Power Select Dependency

Update ember-power-select dependency to latest version.

Why was this closed?

I decided to try to add on the code to prevent duplicates after the fact, and included these changes in that branch.


SSL handshake

Using remote server https://gcc.godbolt.org/ i've got
ERROR: SSL handshake failed
I was using QSslSocket::AutoVerifyPeer but it doesn't help

I found that article
https://meetingcpp.com/index.php/br/items/http-and-https-in-qt.html
but libeay32.dll and ssleay32.dll are in qtcreator/bin folder...


Update find-unattached-disks.md

we cannot get the billing details of unattached managed disks from the Azure Portal. This can be acheived by adding tags to the unattached disks and filterring with the tag in the subscriptions,cost analysis tab.

Trying a close/reopen to clear the validation warnings

emailed author

Thanks for your contribution. We won't be accepting this at this time.
Accordingly, I'm closing this out.
#please-close


Esbuild and Images plugin

Hey, I know that the esbuild run option isn't out of beta, but I wanted to let you know that for some reason, the image plugin currently gets the reload-on-file-change stuck somewhere.  I'm not quite sure where it's breaking, so I'll do some more exploration.

(Gets stuck after it prints 'minifying css and adding sourcemaps took 19ms)
Thanks for the great tool :).

I've determined a few things.

If you modify the .js files, it reloads just fine.
If you modify the .svelte files in components, it reloads just fine.
If you modify the .svelte files in layouts, it fails to reload.
If you modify the .svelte files in routes, it fails to reload.
npm run start has the same issues.


Fixes bug where an Ethereum node giving bad answers could break things.

This changes the way we announce block/log additions/removals so that we wait until we are sure we can fully synch with the node before doing any announcements.  This allows us to rollback when the Ethereum node gives us something weird in response such as a claim that a parent block doesn't exist, or logs that don't line up with the expected block.
No longer does console.log when an error occurs, instead calls the optional user provided errorCallback.  This cleans up the tests, and also allows the user to do something more useful with errors like track them.
Removes deprecated ES5 callback stuff.

Fixes #10.
Fixes #17.

Pinging @epheph @mohoff @LogvinovLeon to see if anyone wants to review this PR.  I currently have the flu so I don't really trust my abilities at the moment and there may be some glaringly obvious problem.  If I don't hear from anyone by the time I am feeling better I'll review it myself in a few days (after having forgotten what I have done here today).


npm run build:prod dont calls enableProdMode()

I'm submitting a ...
[X ] bug report
[ ] feature request
[ ] question about the decisions made in the repository

Do you want to request a  bug?

What is the current behavior?

npm run build:prod creates dist files, dist files still call in the console:
"Angular is running in the development mode. Call enableProdMode() to enable the production mode."

What is the expected behavior?
npm run build:prod should call enableProdMode()

having the same issue here, too

@ChadElias I think it will be fixed with the next major.

is this fix?


update flect to fix #12827

Please follow the commit message guidelines.
For example:
deps: Upgrade github.com/gobuffalo/flect v1.0.2 => v1.0.3

Closes #12827

🙏🏾 ty, sorry about that


Added module guid

Docs Build status updates of commit efcfc24:
:clock10: Full build: the average full build time is 28 min(s) 31 sec(s), this is based on the last 450 build(s) for this repository.

Docs Build status updates of commit efcfc24:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azurermps-4.4.1/AzureRM.MachineLearningCompute/AzureRM.MachineLearningCompute.md
:white_check_mark:Succeeded
View (azurermps-4.4.1)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Heathcare : Hl7 messages to HL7v2 Store (HCAPI) example

https://colab.research.google.com/drive/1k0s8E_4cGt6FCHdqAK2lBxsqyHo_bjwo?resourcekey=0-uwoUnBzJLYyBilHaFEnYcQ

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

R: @svetakvsundhar

Thanks, this is looking good! Left a few comments, ptal.

R: @damccorm


Support a way to show what tls version is supported by the starrocks server

mysql> SHOW GLOBAL VARIABLES LIKE 'tls_version';
+---------------+-----------------------+
| Variable_name | Value                 |
+---------------+-----------------------+
| tls_version   | TLSv1.2,TLSv1.3       |

TLS support will be a commercial feature from CelerData


core[patch]: Move async generator consumption code into local storage context

@nfcampos can you have a look please?

CC @hinthornw as well

Updated and added test


bugfix: adjusts to use retry_on_conflict on bulk

Description
Bug fix.
Adjust to set retry_on_conflict when using bulk indexer.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thank you! Can you please add a unit test for this, since we've visibly introduced a bug?

hello @dblock,
I added a unit test for this case, can you review again please?

@dblock done =D

@dblock done =D

Thank you @nicolascb! Unblocking the tests.


Screen Locking doesn't work

Lumina 0.9.0-Release
PC-BSD 10.3-RELEASE-p5 amd64 GENERIC on an Optiplex-9010
Neither clicking the lock button in the pop up menu, nor Ctrl-Alt-l, locks the screen.

This is most likely caused by running the wrong binary to start your desktop.
You should be using the "start-lumina-desktop" binary, not the "Lumina-DE" binary, since the xscreensaver process is launched/managed via the "start-lumina-desktop" routine.

So I should then file this bug with PC-BSD?
I didn't choose the binary. This is what got used/configured after I installed the Lumina package via AppCafe, and I select Lumina from the login window desktop environment option.

Same answer as issue #242 - this has the same root cause.


Update readme.md

To resolve Russell's paradox Awesome list should contain link to itself

It already does. Look for Awesome in the Misc section ;)


Formatting fails with tidy_html

tidy is installed and works in the shell but is not working from vim. I am using zsh in MSYS2, unsure if this is related.
Here is the error from verbose output:
Selected formatter: tidy_html
Trying definition from g:formatdef_tidy_html
Evaluated formatprg: tidy -q --show-errors 0 --show-warnings 0 --force-output --indent auto --indent-spaces 8 --vertical-space yes --tidy-mark no -wrap 0
Using python 3 code...
Formatter tidy_html gives nonzero returncode: 1
Definition in 'g:formatdef_tidy_html' was unsuccessful.

Any input is appreciated!

I think this is due to having no .tidyrc config file, so I will close this issue.


Cmd+A closes the window instead of normal behaviour

Pretty cool project man :)
I tried doing a quick and instinctive Cmd+A and backspace on MacOS to quickly clean the scratch and it closed the app. Unexpected behavior !
You think that could be corrected ?
Greetings from Paris ^^

You're using an Azerty keyboard[1]. There are problems with alternative keyboard layouts in Electron, the system FromScratch uses, please see https://github.com/Kilian/fromscratch/issues/9 I assume you're using electron 1.2.0 (latest version)?
I'm closing this in favor of keeping #9.
[1] my awesome deduction powers combined "greetings from Paris" and "ctrl+A closes FromScratch"


Draft of smarter dev analysis for review

Purpose
Improves "completeness" for finding development aka non-production systems. We care about non-production systems because identifying them is a precondition for automatic remediation.
Impact
The revision triples the true positives (from 4k to 13k in test data) by picking up on examples like:

{"environment": "stg"}
{"ENV": "nonprod"}
test.example.com:8443

It also eliminates the previous 20% false positive rate (1k of 5k) by not flagging examples like:

devops
devanshi.lastname
{"team": "named-dev", "env": "prod"}

Technical overview

Introduces script "InferWhetherServiceIsDev", including tests & docs, which:

checks public indicators as well as internal tags
checks internal tags for many more terms
checks more precisely only the tags that are related to the deployment "environment".

Alters playbooks to use "InferWhetherServiceIsDev"

Enrichment - Adds a final stage that executes script
ASM Alert - Alters the "Meets automated remediation requirements?" task to use result

Testing plan

Unit tests (see file)
Verified script can execute on its own within alert warroom: !InferWhetherServiceIsDev active_classifications=${ASM.ExternalService.active_classifications} asm_tags=${alert.asmtags}
Verified revised playbooks successfully execute against two examples:

inferred "dev": see callu alert 743
inferred "can't tell": see callu alert 1566

General question: Is to goal to have some certainty that the service is non-dev or non-prd?  They are somewhat different

!InferWhetherIsDev_jw active_classifications=${subplaybook-97.ASM.ExternalService.active_classifications} asm_tags=${alert.asmtags}
^^Example command to test in war room for newest run of "Cortex ASM - ASM Alert" playbook

from linting:
############################
 unit-tests coverage report
############################
Name                                                                                Stmts   Miss  Cover
----------------------------------------------------------------------------------------------------------------------
Packs/CortexAttackSurfaceManagement/Scripts/InferWhetherServiceIsDev/InferWhetherServiceIsDev.py      48     15    69%
----------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                48     15    69%

Flake8       - [FAIL]
XSOAR linter - [PASS]
Bandit       - [PASS]
Mypy         - [FAIL]
Vulture      - [PASS]
Pytest       - [PASS]
Pylint       - [PASS]
Pwsh analyze - [SKIPPED]
Pwsh test    - [SKIPPED]

Passed Unit-tests:
  - Package: InferWhetherServiceIsDev
      - Image: demisto/python3:<IP_ADDRESS>476
         - InferWhetherServiceIsDev_test.py::test_canonicalize
         - InferWhetherServiceIsDev_test.py::test_is_dev_according_to_key_value_pairs
         - InferWhetherServiceIsDev_test.py::test_is_dev_according_to_classifications

###############
 Flake8 errors
###############

InferWhetherServiceIsDev
InferWhetherServiceIsDev.py:1:1: F401 'json' imported but unused
InferWhetherServiceIsDev.py:3:1: F401 'base64.b64decode' imported but unused
InferWhetherServiceIsDev.py:40:131: E501 line too long (133 > 130 characters)
InferWhetherServiceIsDev.py:41:131: E501 line too long (153 > 130 characters)
InferWhetherServiceIsDev_test.py:3:1: E302 expected 2 blank lines, found 1
InferWhetherServiceIsDev_test.py:9:1: E302 expected 2 blank lines, found 1
InferWhetherServiceIsDev_test.py:19:1: E302 expected 2 blank lines, found 1
InferWhetherServiceIsDev_test.py:23:91: W292 no newline at end of file

#############
 Mypy errors
#############

InferWhetherServiceIsDev
/Users/jwilkes/Code/pamela-content/content/Packs/CortexAttackSurfaceManagement/Scripts/InferWhetherServiceIsDev/InferWhetherServiceIsDev.py:48:36: error:
Argument 1 to "_canonicalize_string" has incompatible type "Optional[Any]";
expected "str"  [arg-type]
            key = _canonicalize_string(kv_pair.get("Key"))
                                       ^~~~~~~~~~~~~~~~~~
/Users/jwilkes/Code/pamela-content/content/Packs/CortexAttackSurfaceManagement/Scripts/InferWhetherServiceIsDev/InferWhetherServiceIsDev.py:49:38: error:
Argument 1 to "_canonicalize_string" has incompatible type "Optional[Any]";
expected "str"  [arg-type]
            value = _canonicalize_string(kv_pair.get("Value"))
                                         ^~~~~~~~~~~~~~~~~~~~
Found 2 errors in 1 file (checked 1 source file)

General question: Is to goal to have some certainty that the service is dev or just non-prd? They are somewhat different

Pamela to add more information to script description and pack README

Revised.
@johnnywilkes I'd appreciate your eyes one more time, since it's more complex now. additionally, would you want to paste final linting/etc. on this, or should I close it and we open against the full repo and have it run automatically? (I'd like to wait for a second PR to invest in setting up VSCode locally since PyCharm is my pre-existing daily driver)

Adding here so I don't forget.  We need to create the new field and add to PR also

@ptoman-pa here it the most up to date lint report:
############################
 unit-tests coverage report
############################
Name                                                                                Stmts   Miss  Cover
----------------------------------------------------------------------------------------------------------------------
Packs/CortexAttackSurfaceManagement/Scripts/InferWhetherServiceIsDev/InferWhetherServiceIsDev.py      49     16    67%
----------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                49     16    67%

Flake8       - [FAIL]
XSOAR linter - [FAIL]
Bandit       - [PASS]
Mypy         - [PASS]
Vulture      - [PASS]
Pytest       - [FAIL]
Pylint       - [PASS]
Pwsh analyze - [SKIPPED]
Pwsh test    - [SKIPPED]

############
 Unit Tests
############

Passed Unit-tests:
  - Package: InferWhetherServiceIsDev
      - Image: demisto/python3:<IP_ADDRESS>476
         - InferWhetherServiceIsDev_test.py::test_canonicalize

Failed Unit-tests:
  - Package: InferWhetherServiceIsDev
         - InferWhetherServiceIsDev_test.py::test_is_dev_according_to_key_value_pairs
      - Image: demisto/python3:<IP_ADDRESS>476
           Error: def test_is_dev_according_to_key_value_pairs():
                          from InferWhetherServiceIsDev import is_dev_according_to_key_value_pairs

                          assert is_dev_according_to_key_value_pairs([{"Key": "env", "Source":
                  "AWS", "Value": "dev"},
                                                                      {"Key": "Name", "Source":
                  "AWS", "Value": "rdp_server"},
                                                                      {"Key": "test", "Source":
                  "AWS", "Value": ""}])
                          assert is_dev_according_to_key_value_pairs([{"Key": "ENVIRONMENT",
                  "Source": "AWS", "Value": "TEST"}])
                          assert is_dev_according_to_key_value_pairs([{"Key": "Stage", "Source":
                  "AWS", "Value": "status - preprod"}])
                  >       assert not is_dev_according_to_key_value_pairs([{"Key": "env", "Source":
                  "AWS", "Value": "prod"}])
                  E       AssertionError: assert not (False, [])
                  E        +  where (False, []) = <function is_dev_according_to_key_value_pairs at
                  0x400c743b50>([{'Key': 'env', 'Source': 'AWS', 'Value': 'prod'}])

                  InferWhetherServiceIsDev_test.py:19: AssertionError

         - InferWhetherServiceIsDev_test.py::test_is_dev_according_to_classifications
      - Image: demisto/python3:<IP_ADDRESS>476
           Error: def test_is_dev_according_to_classifications():
                          from InferWhetherServiceIsDev import is_dev_according_to_classifications

                          assert is_dev_according_to_classifications(["SshServer",
                  "DevelopmentEnvironment"])
                  >       assert not is_dev_according_to_classifications(["RdpServer",
                  "SelfSignedCertificate"])
                  E       AssertionError: assert not (False, [])
                  E        +  where (False, []) = <function is_dev_according_to_classifications at
                  0x400c743be0>(['RdpServer', 'SelfSignedCertificate'])

                  InferWhetherServiceIsDev_test.py:27: AssertionError

###############
 Flake8 errors
###############

InferWhetherServiceIsDev
InferWhetherServiceIsDev.py:59:26: E127 continuation line over-indented for visual indent
InferWhetherServiceIsDev.py:59:69: E261 at least two spaces before inline comment
InferWhetherServiceIsDev.py:60:26: E127 continuation line over-indented for visual indent
InferWhetherServiceIsDev.py:61:26: E127 continuation line over-indented for visual indent
InferWhetherServiceIsDev.py:145:131: E501 line too long (164 > 130 characters)

#####################
 Xsoar_linter errors
#####################

InferWhetherServiceIsDev
/Users/jwilkes/Code/pamela-content/content/Packs/CortexAttackSurfaceManagement/Scripts/InferWhetherServiceIsDev/InferWhetherServiceIsDev.py:145:12: E9002 main: Print is found, Please remove all prints from the code.
/Users/jwilkes/Code/pamela-content/content/Packs/CortexAttackSurfaceManagement/Scripts/InferWhetherServiceIsDev/InferWhetherServiceIsDev.py:147:12: E9002 main: Print is found, Please remove all prints from the code.

#########
 Summary
#########
Packages: 1
Packages PASS: 0
Packages FAIL: 1
Packages WARNING (can either PASS or FAIL): 0

Failed packages:
   - InferWhetherServiceIsDev

@ptoman-pa , i am really sorry about this but I think you used an older version of the repo/playbook because of your instructions in https://gitlab.xdr.pan.local/xdr/xpanse/machine-learning-projects/data-science-experiments/-/tree/master/2022-08-afr/afr-is-dev/productionization and I should have correctly you earlier.
You want to set git remote add upstream https://github.com/demisto/content.git and update your local repo with
git fetch upstream
git rebase upstream/master

at least before creating branch.  Let me know if you want me to clean this up for you

Updates to branch:

included the "ASM - Dev Check" IncidentField
rebased against upstream master
flattened everything into a single commit for easy cherry-picking
installed & configured VSCode & ran all the linting (ok), coverage (72% because it's not clear to me how to test for a context side effect as output with the mocking library), and tests (ok)
slightly updated the logic to (a) remove the explanations which were only being used in a print statement that is disallowed, and (b) detect conflicting dev PLUS prod environments and avoid setting them to "is dev".

I'm closing this PR (the diff is massive because now this branch is ahead of the target), but the diff is visible at: https://github.com/demisto/content/compare/master...ptoman-pa:content:plt-dev-script?expand=1


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_12v7k9hu4l/clone/recipe/meta.yaml:22: missing_wheel: For pypi packages, wheel should be present in the host section
WARNING: /tmp/abs_12v7k9hu4l/clone/recipe/meta.yaml:52: missing_description: The recipe is missing a description
ERROR: /tmp/abs_12v7k9hu4l/clone/recipe/meta.yaml:52: http_url: http://github.com/nteract/papermill is not https
ERROR: /tmp/abs_12v7k9hu4l/clone/recipe/meta.yaml:52: http_url: http://papermill.readthedocs.io/ is not https
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_ec_5vjohbx/clone/recipe/meta.yaml:22: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_ec_5vjohbx/clone/recipe/meta.yaml:52: http_url: http://papermill.readthedocs.io/ is not https
ERROR: /tmp/abs_ec_5vjohbx/clone/recipe/meta.yaml:52: http_url: http://github.com/nteract/papermill is not https
WARNING: /tmp/abs_ec_5vjohbx/clone/recipe/meta.yaml:52: missing_description: The recipe is missing a description
Errors were found


BookStore : Connect To API

In this PR I have implemented following Features :

Made use of the Bookstore API as my backend.
Used axios with createAsyncThunk to make HTTP requests to the backend.
Fetched books from the Bookstore API after the components has rendered.
Refactored add book and remove book features to persist your changes in the server.
Made sure that application should behave the same way after the refactoring.

Thank You ,
Bhushan .

Hello sir , I hope my submission passes your review but if there are any small changes required it would be of great help to me if you contact me on slack or whatsapp (+91<PHONE_NUMBER>) about it . as There is time constraints
Thank You ,
Bhushan .

@bhushan354, I try to reach you on slack but you were not responding.


GWAS manhattan plot not displaying colours when kmer/unitig positions (e.g. 140..160) used

When I provide a plink file with unitig positions in the 3rd column, the colours in the 5th column are not displayed (all points are grey and sized corresponding to the length). If I use the same file but with just the start position the colours work so the general formatting of my file seems to be correct.

files here https://drive.google.com/drive/folders/1itDvjenQhG6kTRoPWwPwZor7dU0XgY2j?usp=sharing

Hey Becca!
We did allow x..y coordinate formatting for seer output (from memory), so this should be working. I'll try to figure out why the colours are not displayed correctly in this case sometime in the next ~week.
For x..y coordinates it looks like the circle radius is variable. I don't remember why this is, but presumably this represents the kmer/unitig length? Is this what you expect / how you interpret it?

Hi James!
Yeah, when I played around with a mock plink file the radius of the circle changed with the x..y coordinates to represent the length. With longer unitigs the bigger circles will start to mask unitigs with higher or lower p-values (I accidentally made the x..y coordinates 100,000bp long and it covered the whole plot haha). I was actually kind of expecting ellipses stretched horizontally before it plotted) but it functions alright for short kmers/unitigs. In this subset the max unitig is only 83bp but the entire dataset has unitigs up to 4540bp long.
Thanks for your help 😊
From: james hadfield @.>
Reply to: jameshadfield/phandango @.>
Date: Wednesday, 21 February 2024 at 21:41
To: jameshadfield/phandango @.>
Cc: Rebecca Gladstone @.>, Author @.***>
Subject: Re: [jameshadfield/phandango] GWAS manhattan plot not displaying colours when kmer/unitig positions (e.g. 140..160) used (Issue #151) [EXT]
Hey Becca!
We did allow x..y coordinate formatting for seer output (from memory), so this should be working. I'll try to figure out why the colours are not displayed correctly in this case sometime in the next ~week.
For x..y coordinates it looks like the circle radius is variable. I don't remember why this is, but presumably this represents the kmer/unitig length? Is this what you expect / how you interpret it?
—
Reply to this email directly, view it on GitHub [github.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jameshadfield_phandango_issues_151-23issuecomment-2D1957874833&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v6s6pvOcw9r40RHMkRZgykz0Wy3sTie-S9KIaOVCOlY&m=WhWu4kZCTbytUh3i4zW5yF9Nl07nZCHJ7wjuPLSKiiDNbwBWJowUy7c-0EbtLVxt&s=zcR1Ic59wSx16oItHCzPJAo3rJMlA0vzK5zHa_BjTH4&e=, or unsubscribe [github.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AGYKG5GWVL22V2JQJW2ASPDYUZLYXAVCNFSM6AAAAABDSYIGRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJXHA3TIOBTGM&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v6s6pvOcw9r40RHMkRZgykz0Wy3sTie-S9KIaOVCOlY&m=WhWu4kZCTbytUh3i4zW5yF9Nl07nZCHJ7wjuPLSKiiDNbwBWJowUy7c-0EbtLVxt&s=pwV7mCzj6Q1fjNiophHaaQcmdTksgGr6kcTXXuZ3r9w&e=.
You are receiving this because you authored the thread.Message ID: @.***>
--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is Wellcome Sanger Institute, Wellcome Genome Campus,
Hinxton, CB10 1SA

I think it would be great to have ellipses, I have a couple more sets of analysis to look at this week and I’m sure there would be less overlapping with ellipses.
Thanks for looking into these!
From: james hadfield @.>
Reply to: jameshadfield/phandango @.>
Date: Monday, 26 February 2024 at 02:11
To: jameshadfield/phandango @.>
Cc: Rebecca Gladstone @.>, Author @.***>
Subject: Re: [jameshadfield/phandango] GWAS manhattan plot not displaying colours when kmer/unitig positions (e.g. 140..160) used (Issue #151) [EXT]
I was actually kind of expecting ellipses stretched horizontally before it plotted
This'd be better -- in the code it's actually called an Ellipse but it's just a circle. Let me know if you need this, it should be possible to improve this.
When I provide a plink file with unitig positions in the 3rd column, the colours in the 5th column are not displayed (all points are grey and sized corresponding to the length).
This is now working as of version 1.3.1 - you may need to shift-refresh the page if you're still getting the old version (1.3.0)
—
Reply to this email directly, view it on GitHub [github.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jameshadfield_phandango_issues_151-23issuecomment-2D1963151202&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v6s6pvOcw9r40RHMkRZgykz0Wy3sTie-S9KIaOVCOlY&m=iNewVEbzYKSa0cPN70eyGhikLRxcsKpG3g8CmV1IxiGTV34AnvN3VKnhWMMPMoIM&s=v_lSJazowRsazd3Z5-Pg2U8WysaU2nIuhUjNuO61rI8&e=, or unsubscribe [github.com]https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AGYKG5AYHI6RIJSL2T7CAQLYVPONBAVCNFSM6AAAAABDSYIGRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRTGE2TCMRQGI&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=v6s6pvOcw9r40RHMkRZgykz0Wy3sTie-S9KIaOVCOlY&m=iNewVEbzYKSa0cPN70eyGhikLRxcsKpG3g8CmV1IxiGTV34AnvN3VKnhWMMPMoIM&s=aBEMYTgfp2qluMoR_W73hOTUBvArNaf0-Uk13KN5wg4&e=.
You are receiving this because you authored the thread.Message ID: @.***>
--
The Wellcome Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is Wellcome Sanger Institute, Wellcome Genome Campus,
Hinxton, CB10 1SA


M3-4662 Managed Summary tab

Description
Since we're removing the Dashboard in CMR, we need a place for the ManagedDashboardCard. There's now a new tab called "Summary" on the Managed Landing page which houses this component. I also refactored ManagedLandingContent to use NavTabs. Once we fully move to CMR we'll move the files to the Managed directory.
Note to Reviewers
Please check both CMR and non-CMR.

I think the union of beta testers | managed customers is small, but even so I think we should remove the "Linode Managed" and "details" link (since you're already on Managed now and the details link takes you to where you are). seems like removing the dashboardcard wrapper will do both things, but maybe annoying to do it conditionally.

Good call. I didn't end up having to do it conditionally since it's in a CMR file. I kept the card around (removed title and headerAction props) in order to keep the styling.


Talk taxonomies with BC211

Get in touch with BC211 and explore the use of their taxomomy in our recommendation.

handling feedback received- about accuracy, missing/incorrect data?
new requests to add data to AA and BC211
should we create our own forms for intake and feedback? what fields should we include? how do we track progress?
BC211 used to have a form for updating service data, now they just have an email address. Why?

moved to doc with list of questions for Oct 2019 meeting with BC211


fix: bug with multiple subjects. Add ModifyWith funcs.

Codecov Report
Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (567d61c) 84.89% compared to head (61ee6c5) 84.99%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   84.89%   84.99%   +0.09%
==========================================
  Files          72       72
  Lines        8488     8576      +88
==========================================
+ Hits         7206     7289      +83
- Misses       1018     1022       +4
- Partials      264      265       +1

Files
Coverage Δ

verifiable/credential.go
89.00% <94.17%> (+0.47%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Mutable iteration with look-back

Current approach is to create a Pointer by calling first(), that is advanced with advance. It's not ergonomic, and neither it is peformant, since we need to lock the pending array to get each next epoch.
See also - #19

I think I've got an idea, will try today

I believe a streaming iterator is still the answer, and I'm nearly done implementing it. I don't think relying on an external library for streaming operations would be useful though.


Copy as CURL in report html

See printscreen

Idea to convert http.Request into curl: https://github.com/moul/http2curl/blob/master/http2curl.go

No need for fancy javascript to copy the command into the clipboard but a simple pre-formatted text field would be enough.

http2curl.go is incomplete and buggy, a bad combination...

That's why I've written "Idea" 😜

Thanks! 👏


Remove gratuitous Unicode in resources and test for it

Include not much used Sourcer to open files with UTF8 encoding

With this, it should not be necessary, as least as far as the rules are concerned, to do
export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8
The program will run even with ASCII encoding.  There is code in Sourcer to enforce UTF8 in case it is found in some text file that we process.  I have not checked in changes to code that makes use of Sourcer because I have not found a good way to test it yet.

@bsharpataz, do you know why EidosActions tries first fromFile and then fromURL?  Are we allowing people to override the URL location with a file and falling back if it isn't there?  I'd like to make it the same as the others with just fromURL.
val source:BufferedSource = if (url == null) scala.io.Source.fromFile(new File(path)) else scala.io.Source.fromURL(url)

I think it may have been so it could be run both in the IDE and with
sbt...?  to help with finding the file in the jar...? I'm not 100% sure but
I recall that one way of running things had trouble finding files in the
resources?
but FWIW people should be able to provide their own grammar/resource files
as easily as possible
On Wed, Mar 7, 2018 at 11:20 PM, Keith Alcock<EMAIL_ADDRESS>wrote:

@bsharpataz https://github.com/bsharpataz, do you know why EidosActions
tries first fromFile and then fromURL? Are we allowing people to override
the URL location with a file and falling back if it isn't there? I'd like
to make it the same as the others with just fromURL.
val source:BufferedSource = if (url == null) scala.io.Source.fromFile(new
File(path)) else scala.io.Source.fromURL(url)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/clulab/eidos/pull/168#issuecomment-371391714, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFInifCPgs29WLk7eMcARNiN7awa--W3ks5tcM22gaJpZM4SiKfa
.

Fwiw, both the IDE and sbt should work with fromURL...

I've gone ahead and rerouted Eidos file access through this Sourcer thing where our standard of encoding any necessary Unicode characters as UTF-8 is codified.  It shouldn't break anything, but I haven't found a case where it is actually necessary except second-hand in the docker container.  This might allow inclusion of the special characters I just got rid of in the yaml files without requiring the environment setting.  Everything is read as a resource via URL.  We may well have to make an exception for the file of vectors, however.  That's coming up yet.


Recompilation fails without indicating location of invalid IR

When attempting to recompile a large IR file generated by mcsema, LLVM fails with:
warning: overriding the module target triple with x86_64-unknown-linux-gnu [-Woverride-module]
fatal error: error in backend: expected relocatable expression

As the location of the error in the ~100MB IR file is not specified, I am unable to determine why compilation has stopped.  LLVM should print a line number to assist in debugging.

I'm not sure what we can do here. What is your compiler invocation? Perhaps you are not using -fPIC -pic when you should be.

Good point.  I'm using the same flags, etc as the example documentation, with the libraries adjusted:
remill-clang-4.0 -rdynamic -O3 -o xz.new xz.bc /usr/local/lib/libmcsema_rt64-4.0.a -llzma

@pgoodman Still getting fatal error: error in backend: expected relocatable expression out of remill-clang-4.0 with no other information.  Ideas are welcome.

Try with -fPIC -pie? See if adding a -v prints out any other errors? Also try compiling to a .S file (using -S I think), then assemble that, and see if any better info is dumped out?

Here's a hint from trying to compile the .S file.  It's choking on the contents of an exception table (lines truncated for practical reasons; this is still a 650MB source file or so)
seg_10ed988__gcc_except_table:
        .ascii  "\377\000\264\007\001\243\007\032t\000\000\336\001\230;\233\324\001\001\266=\005\307\306\001\003\362=B\343\303\001\003\310>\005\257\306\001\003\326>\005\245\306\001\003\355>\003\307\306\001\003\214?\005\357\306\001\003\$
        .long   seg_529400__text+1274207
        .asciz  "o\005\000\000\377\377\001\b:\005J\000S\005\000\000\377\000\274\001\001\253\001\263\001\236\b\000\000\202\n\227\001\204\022\000\313\013\005\236\017\000\212\f\005\353\021\000\231\f\005\341\021\000\343\f\024\204\022\000\2$
        .long   seg_529400__text+814517
        .ascii  "\000\245\002\005\353\002\000\262\002\005\205\003\000\327\002\005\000\000\366\002\005\375\002\000\222\003\005\231\003\000\377\377\001S\216\001B\353\006\000\244\002J\363\006\000\204\003b\353\006\000\202\004\005\231\006\0$
        .long   callback_sub_60a005&-1
        .ascii  "\215\004\004\315c\000\320\b\005\266c\000\244\t\005\251c\000\261\t+\266c\000\245\n\310\003\224c\000\360\r\005\266c\000\217\017\206"
        .long   seg_529400__text+1125377
        .ascii  "\316\021\342\002\361`\000\257\027\005\244c\000\205\030\005\204c\000\215\030+\244c\000\371\030\316"

Assembler errors are as follows:
as -mtune=generic64 binary.S
binary.S: Assembler messages:
binary.S:3: Error: junk at end of line, first unrecognized character is `"'
binary.S:4: Error: junk at end of line, first unrecognized character is `"'
binary.S:5: Error: junk at end of line, first unrecognized character is `"'
binary.S:6: Error: junk at end of line, first unrecognized character is `"'
binary.S:7: Error: junk at end of line, first unrecognized character is `"'
binary.S:8: Error: junk at end of line, first unrecognized character is `"'
binary.S:9: Error: junk at end of line, first unrecognized character is `"'
binary.S:10: Error: junk at end of line, first unrecognized character is `"'
binary.S:11: Error: junk at end of line, first unrecognized character is `"'
binary.S:12: Error: junk at end of line, first unrecognized character is `"'
binary.S:13: Error: junk at end of line, first unrecognized character is `"'
binary.S:14: Error: junk at end of line, first unrecognized character is `"'
binary.S:15: Error: junk at end of line, first unrecognized character is `"'
binary.S:16: Error: junk at end of line, first unrecognized character is `"'
binary.S:17: Error: junk at end of line, first unrecognized character is `"'
binary.S:18: Error: junk at end of line, first unrecognized character is `"'
binary.S:19: Error: junk at end of line, first unrecognized character is `"'
binary.S:20: Error: junk at end of line, first unrecognized character is `"'
binary.S:21: Error: junk at end of line, first unrecognized character is `"'
binary.S:20871772: Error: invalid operands (.text and *ABS* sections) for `&'
binary.S:20871776: Error: invalid operands (.text and *ABS* sections) for `&'
binary.S:20871780: Error: invalid operands (.text and *ABS* sections) for `&'
binary.S:20871782: Error: invalid operands (.text and *ABS* sections) for `&'
binary.S:20871784: Error: invalid operands (.text and *ABS* sections) for `&'
<repeats with increasing line number>

I know McSema doesn't support exception handling, but I would have expected that to be "exception causes program to crash", not "exception handler prevents recompilation".  Am I misunderstanding?

Try with llvm-as?

@pgoodman
remill/remill-build/libraries/llvm/bin/llvm-as: binary.S:1:2: error: expected top-level entity
        .text`
        ^

I'm trying one last idea; using llvm-dis then trying llvm-as on the .ll file.  No idea if that will get a more verbose error or not.

@kumarak Can you add a command-line flag that disables lifting of exception tables?
@madscientist159 Hrm okay. What about going the route of .o file, and then trying to see if either of clang or gcc will produce a more helpful error message (especially when provided with a -v) when trying to link the .o into a binary?
Some future steps to try:

Running with a debug build of ld or or whatever is producing this error, and seeing what causes the bug.
Representing the cross-references in the exception tables (if these are in fact problematic) in terms of lazily-initialized xrefs.

Another thing perhaps worth trying is to make a small program that uses exceptions, compile that to assembly, then modify the assembly to add in a really big section of otherwise useless data, compile that, then lift it and see if we can find a simpler program that reproduces the problem.

@pgoodman Unfortunately even llc fails:
llc -filetype=obj binary.bc
LLVM ERROR: expected relocatable expression

Can you try a debug build of llc? If you don't have one available then you can build a debug build of cxx-common using the --debug flag to pkgman.py.

It's running a compile in debug mode still; it's been doing so for many hours and has not failed yet.  Hopefully when it does finally fail we'll get information on what went wrong.

Was still running after 2 days.  Is there a better way to do this?

I'm closing this because I think the problem is that LLVM's errors just aren't helpful here, and we probably have other problems for big files that are tracked by other issues you've filed.