Add cell type section to QC report

After we have performed cell type classification, we will want to have a way to visualize the cell type assignments. We already have a QC report that is created for each library through the main scpca-nf report. We should add a section to this report that includes plots to show the results of cell type assignment. To start we can show a UMAP with the cell type labels.
Unlike with previous reports, we will want this addition to live in scpca-nf so we will have to think about how to append it to the report that is already getting rendered in the workflow that is stored in scpcaTools.

Unlike with previous reports, we will want this addition to live in scpca-nf so we will have to think about how to append it to the report that is already getting rendered in the workflow that is stored in scpcaTools.

I think the way we will want to do this is to complete https://github.com/AlexsLemonade/scpcaTools/issues/162, then copy the full template report that is currently embedded in scpcaTools into this repo and use that as the input template here (with the addition of cell typing reports.

Some things we discussed that should be in the cell type section of the QC report:

UMAP with cell type labels
Heatmap or some sort of plot showing how confident the assignments are
Summary table of how many of each cell type are assigned
There was also some future discussion of looking at the ontology labels and comparing assignments across references, but we should start with the first three and then go from there

I think we should use this issue to outline some ideas of what we would like to see in the report. Next sprint I will plan to post a diagram of my thoughts for the QC report and then get other people's opinions before we begin development.

Here I'm proposing an initial outline for the added cell type section of the QC report. A few things to note:

In creating this, I considered how we would display both cell type annotation results, clustering results using a single parameter, aneuploid status, and submitter annotations, if present. The focus is definitely on the cell type annotations and less on clustering and aneuploid status. There is another question that we are not yet addressing regarding which clustering method is best. We previously talked about utilizing tools such as MultiK, but for now, we are focusing on a single clustering approach to compare cluster assignments with cell-type annotations. If we want to explore other clustering methods in the future, I think we could easily expand this.
I know there are a lot of UMAPs, but I think it's important to show them with the various annotations. I put them in a 4X4 block plus an extra for the submitter annotations if present, but I think we might want to make them separate plots printed right after the other. I'm worried about the 4x4 being too crowded, depending on how many annotations or clusters there are for a given sample.
We discussed having a single combined visual that shows both cell type annotations, clusters, and CNV status. I think the ideal solution here would be to have both cell type annotations from SingleR and CellAssign represented with ontology IDs, and then it would be easier to combine them in a single plot. Also, having ontology IDs would allow us to calculate the percentage of cells with the same assignment with both methods. However, I don't know if we want to spend time converting all the cell types in PanglaoDB to their ontology terms. So the solution I came up with is a heatmap broken up by cell type method (y-axis) with cluster assignments on the x-axis. The heatmap would be colored by the number of cells that are overlapping. I also included an annotation bar for the cell type annotations and cluster assignments to show how many cells in each cell type/cluster are aneuploid. What do we think of something like this? I am very open to other ideas if people have them!
I also created a similar heatmap for looking at each of the cell type references directly to the submitter annotations. This section would only be present if submitter annotations existed. Additionally, instead of only looking at % aneuploid cells for each cell type, we could add an annotation bar that shows if cell types are tumor/ normal based on the submitter type. We may want something that directly compares the number of cells that are tumor/normal according to submitters vs. aneuploid with CNV. I didn't include that yet because we are still exploring CNV inference, and I think that's a later thing to add.
The last section is looking at the distribution of scores for SingleR and prediction scores for CellAssign. This would be using the delta median method we had used previously, where we subtract the top score from the median score. The scores have different ranges of values, so we will need to separate plots for each method. Another caveat is that we haven't made this plot yet for CellAssign, so it could be useless.
With the plots made here, I plan to develop them with/ without submitter ids and with/without CNV status. Those are both things that can be incorporated once the base of the report has been started.
Sorry about all the colors, the actual colors I picked are mostly meaningless, and I don't plan on using those color schemes. I just had a bit of fun while drawing this.

Please look at the attached outline and provide any feedback you may have by EOD Tuesday, August 22. Tagging @jashapiro @sjspielman @jaclyn-taroni.
Cell type report Aug 16, 2023.pdf

Responding here with some initial thoughts!

I agree with your choice to not spend much time on clusters themselves. As you said, this report is not primarily about clustering, and a clustering-specific report (e.g. in scpca-downstream-analyses) would need a lot more exploration that will really bog down this report and detract from the central message of cell types.

We should add a statement explaining how clusters were created, and perhaps indicate that they can further explore clustering methods & parameter space on their own.

I'm worried about emphasizing CNV status given some of the preliminary results in https://github.com/AlexsLemonade/sc-data-integration/pull/230. It would be ideal to be able to emphasize it, but I'm skeptical that we will find a way to have confidence in it! Following more discussion & exploration of how to get reliable estimates here, we'll have to wait and see how this pans out. So, good call to mock this up with and without CNV status!
UMAPs - Yeah...we do need four (plus option for 5th if we have submitter info), but I do agree it might get very busy especially since we can't really have a shared legend (we could for the SingleR + CellAssign panels with some ontology IDs, but as you said that's a real time investment!).

In a 2x2 grid, we'd probably want to have SingleR and CellAssign on the same line, so clockwise from top left I'd order: clusters, CNV, SingleR, CellAssign
That said, I imagine we'll want to play around with layout here to make it less busy - we may even want to not have a grid and just four "stacked" UMAPs, if the legends take up a lot of space.

Heatmaps - no notes, I think what you've sketched is a good place to start, and we'll see how it looks!
Score plots - If a delta median approach does not work well for CellAssign, we probably want these plots on different lines, separated by explanations of what each score is. We should only put these plots on the same line if the score calculation is the same for both.

I do tend to think we should place this closer to UMAPs, as you asked in the sketch. I think it would be good to emphasize some measures of confidence before showing the heatmaps - otherwise we're almost "hiding" the confidence, which IMO needs to be more front-and-center. We don't want to convey meaningful comparisons if the results themselves aren't reliable.

UMAPs - Yeah...we do need four (plus option for 5th if we have submitter info), but I do agree it might get very busy especially since we can't really have a shared legend (we could for the SingleR + CellAssign panels with some ontology IDs, but as you said that's a real time investment!).

In a 2x2 grid, we'd probably want to have SingleR and CellAssign on the same line, so clockwise from top left I'd order: clusters, CNV, SingleR, CellAssign
That said, I imagine we'll want to play around with layout here to make it less busy - we may even want to not have a grid and just four "stacked" UMAPs, if the legends take up a lot of space.

Just responding to this one point with what is probably a bad idea: maybe we want to use tabs for these?
https://bookdown.org/yihui/rmarkdown-cookbook/html-tabs.html

Thanks so much for your notes! All great points!
I think in terms of layout, I definitely resonate with this point:

I do tend to think we should place this closer to UMAPs, as you asked in the sketch. I think it would be good to emphasize some measures of confidence before showing the heatmaps - otherwise we're almost "hiding" the confidence, which IMO needs to be more front-and-center. We don't want to convey meaningful comparisons if the results themselves aren't reliable.

Just responding to this one point with what is probably a bad idea: maybe we want to use tabs for these?
https://bookdown.org/yihui/rmarkdown-cookbook/html-tabs.html

I kind of like this idea actually... I'd want to see it actually implemented but I think it may be a good way to show the UMAPs without over crowding things. But otherwise, yes I was thinking 4 stacked UMAPs if the grid looks bad.

I'm worried about emphasizing CNV status given some of the preliminary results in https://github.com/AlexsLemonade/sc-data-integration/pull/230. It would be ideal to be able to emphasize it, but I'm skeptical that we will find a way to have confidence in it! Following more discussion & exploration of how to get reliable estimates here, we'll have to wait and see how this pans out. So, good call to mock this up with and without CNV status!

I definitely agree that CNV status is iffy at this point. I think if there's a way we can display confidence in the CNV calls as we are in the cell type annotations than that might be a good compromise. To be honest, the cell types won't always be accurate either. My take is that the goal of this report is to show what happens when we use these automated methods and then also show some statistic to help users decide how much they trust this information.

I think if there's a way we can display confidence in the CNV calls as we are in the cell type annotations than that might be a good compromise.

Was just going to start to look into this now!

I have little to add over and above the points raised so far. My "spidey senses" were tingling when I arrived at the delta median plot for CellAssign, but I think that's pretty well-covered by @sjspielman's points here:

Score plots - If a delta median approach does not work well for CellAssign, we probably want these plots on different lines, separated by explanations of what each score is. We should only put these plots on the same line if the score calculation is the same for both.

I do tend to think we should place this closer to UMAPs, as you asked in the sketch. I think it would be good to emphasize some measures of confidence before showing the heatmaps - otherwise we're almost "hiding" the confidence, which IMO needs to be more front-and-center. We don't want to convey meaningful comparisons if the results themselves aren't reliable.

The contents of the report have all been filed into separate issues. I'm going to go ahead and close this, but if you have additional comments about any of the plots, feel free to reference the new issues.


Animepahe error 404

I'm getting either 'HTTP Error 404' or 'error getting link' in animepahe extention on any anime I choose. Please look into it.

It might be a problem with the extensions at the moment /:

Atleast gogoanime works

Didn't knew that I only used animephae but thx for telling
On Tue, Feb 1, 2022, 09:41 raeespulikkal @.***> wrote:

Atleast gogoanime works
—
Reply to this email directly, view it on GitHub
https://github.com/jmir1/aniyomi/issues/375#issuecomment-1026553080, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AXRZVKAPBNW63UNB33WU2ILUY6FBFANCNFSM5NIJAT7Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>

duplicate issue. see #366


chore: remove elsewhere block resulted from clicks

Also remove outputOnly for split and tab new commands
Fixes #6057

Description of what you did:

My PR is a:

[ ] 💥 Breaking change
[ ] 🐛 Bug fix
[x] 💅 Enhancement
[ ] 🚀 New feature

Please confirm that your PR fulfills these requirements

[x] Multiple commits are squashed into one commit.
[x] The commit message follows Conventional Commits, which allows us to autogenerate release notes; e.g. fix(plugins/plugin-k8s): fixed annoying bugs
[x] All npm dependencies are pinned.

re: the old travis-ci.org red: this PR was opened in the middle of the .org to .com transition


Set instance hostnames to match their private DNS entries

I'd be nice if the hostnames matched the private DNS.   This will probably involve some cloud-init fu as it seems to be setting the hostname at boot using its own AWS sauce.
Here's a little ditty that works on the Debian boxes:
sudo hostnamectl set-hostname `host \`hostname -I | head -n1\` | awk '{print $5}'`

Backticks are pretty old school.  The preferred syntax these days would be:
sudo hostnamectl set-hostname $(host $(hostname -I | head -n1) | awk '{print $5}')

The Amazon Linux boxes don't use systemd and hence don't have hostnamectl.  You have to set the hostname a little differently, but this should work:
sudo hostname $(host $(hostname -I | head -n1) | awk '{print $5}')


hotfix: fix tags readthedocs build

Coverage report

This PR does not seem to contain any modification to coverable code.


The 'NoBuild' property was set to true but the 'Build' target was invoked.

I am trying to use your package to include ref projects dlls to my nuget package. To build the package, the following command is executed :
dotnet pack  .\$(ProjectName).csproj  --include-symbols --no-build -o C:\dev\Packages
I am getting the error message :
The 'NoBuild' property was set to true but the 'Build' target was invoked.
If I remove the --no-build parameters then I don't get the error message but I'd like to keep it, otherwise the solution is rebuilt a second time as it is already built as a first step in my build pipeline.
Is this possible ?

I think this happens because I am not generating package on build (GeneratePackageOnBuild project property set to false).
Instead I generate package in post build

 <Target Name="NugetPack">

		<Message Importance="High" Text="dotnet pack" />
		<Exec Command="dotnet pack  .\$(ProjectName).csproj  --include-symbols --no-build -o C:\dev\UPP\" />
    </Target>

Error is triggered by following code in Microsof.NET.sdk.targets :

  <!-- TODO: this target should not check GeneratePackageOnBuild.
             remove when https://github.com/NuGet/Home/issues/7801 is fixed.
    -->
  <Target Name="_CheckForBuildWithNoBuild"
          Condition="'$(NoBuild)' == 'true' and '$(GeneratePackageOnBuild)' != 'true'">
    <NETSdkError ResourceName="NoBuildRequested" />
  </Target>

If I don't use your package, I don't get the error. Obviously my csproj ref dll are no longer included in the generated package, but at least there is no error, so I'm wondering why your package leads to this error ?

I tried to track down the problem. I cannot find the problem. What the program is actually doing is just injecting custom target in the the process of packing (compare https://github.com/teroneko/Teronis.DotNet/blob/9b206bb711670bc352d4dbf73249bc43fbed037e/src/MSBuild/Packaging/ProjectBuildInPackage/src/build/Teronis.MSBuild.Packaging.ProjectBuildInPackage.targets#L11 and https://github.com/NuGet/NuGet.Client/blob/ea0bf4a379b6306fd88ff1529dc57e9b16af326a/src/NuGet.Core/NuGet.Build.Tasks.Pack/NuGet.Build.Tasks.Pack.targets#L434). I do not build. the custom target CopyProjectBuildInPackage (see https://github.com/teroneko/Teronis.DotNet/blob/9b206bb711670bc352d4dbf73249bc43fbed037e/src/MSBuild/Packaging/ProjectBuildInPackage/src/build/Teronis.MSBuild.Packaging.ProjectBuildInPackage.targets#L16) just depends on the targets BuildOnlySettings and ResolveReferences (see https://github.com/dotnet/msbuild/blob/master/src/Tasks/Microsoft.Common.CurrentVersion.targets) but they normally are sub targets of the build itself.
This means, that dotnet pack is going to build your project but that's in conflict with your parameter --no-build.
I can remember that the program dotnet pack is more user friendly and builds your project before it actually packs it. It only builds your project only once unless you have made changes. If you really just want to "pack", then you have to call the pack target manually with dotnet msbuild -t:pack (see https://github.com/NuGet/NuGet.Client/blob/ea0bf4a379b6306fd88ff1529dc57e9b16af326a/src/NuGet.Core/NuGet.Build.Tasks.Pack/NuGet.Build.Tasks.Pack.targets#L202).


Credit card number length validation

@rikterbeek's latest merge added validation as a form of forcing mobile browsers to use numeric keyboards. As long as we're adding validation (numbers only), we may as well use it properly and validate against 14+ character for CC numbers and 3+ for CVV numbers. I would have gone with 14-19 characters for the credit card, but with the space adding javascript it was a bit more complicated.
We could reasonably change this to 14,22 to accommodate for 14,19 characters + 3 spaces.
Further improvements to: #710.

Hi @shanelja,
Thanks for this adding a minimum length is a nice to have. I would rather go for safe if it concerns the  card number field. There are many cards that varies in length. Could you remove it for card number field then I will accept the PR for CVC we can just use it.
Regards,
Rik
Adyen

Thanks @rikterbeek, this is done now.

Hi @shanelja,
Thanks for the PR! I merged it now.
Regards,
Rik
Adyen


explain locking mechanisms that we use

https://github.com/iterative/dvc.org/pull/867#discussion_r358671217 E.g. repo lock .dvc/lock, rwlock, etc.

Nice. And link from "file locks" in https://github.com/iterative/dvc.org/blob/master/static/docs/command-reference/config.md#core as well as other places where they may be mentioned in docs 🙂

From https://github.com/iterative/dvc.org/issues/880#issue-541863812

#868 introduces a note about parallel execution (involving repo locks) which feels like it comes out of the blue, as no basic explanations about locking mechanisms can be found.
To further complicate things, the dvc lock command reference talks about locking but this is a completely different topic. Not sure how to eliminate that ambiguity but at least explaining repo locking in a new doc (linked to existing docs where appropriate) and clearly noting these things are separate in both docs would be great.


breakpoints when debugging docker linux target from windows not set

Issue Type: Bug
launch.json:
{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "attach",
      "name": "docker",
      "address": "localhost",
      "port": 9229,
      "localRoot": "${workspaceFolder}",
      "remoteRoot": "/app",
      "trace": "verbose",
    }
  ]
}

debug console messages when removing/adding breakpoint:
To client: {"seq":0,"type":"event","event":"output","body":{"category":"telemetry","output":"setBreakpointsRequest","data":{"Versions.DebugAdapterCore":"6.3.1","Versions.DebugAdapter":"1.25.5","Versions.Target.Version":"v8.11.3","fileExt":".js"}}}
Mapped localToRemote: d:\Work\anais\bee-forms-extension\middleware\src\rest\requests\pdf.js -> /app/src/rest/requests/pdf.js
SourceMaps.setBP: SourceMaps are enabled but d:\Work\anais\bee-forms-extension\middleware\src\rest\requests\pdf.js is a runtime script
Mapped localToRemote: d:\Work\anais\bee-forms-extension\middleware\src\rest\requests\pdf.js -> /app/src/rest/requests/pdf.js
Paths.setBP: Resolved d:\Work\anais\bee-forms-extension\middleware\src\rest\requests\pdf.js to /app/src/rest/requests/pdf.js
Mapped localToRemote: /app/src/rest/requests/pdf.js -> /app/C:/app/src/rest/requests/pdf.js
→ To target: "{\"id\":15,\"method\":\"Debugger.setBreakpointByUrl\",\"params\":{\"urlRegex\":\"\\\\/app\\\\/C:\\\\/app\\\\/src\\\\/rest\\\\/requests\\\\/pdf\\\\.js\",\"lineNumber\":29,\"columnNumber\":0}}"
← From target: {"id":15,"result":{"breakpointId":"/\\/app\\/C:\\/app\\/src\\/rest\\/requests\\/pdf\\.js/:29:0","locations":[]}}
To client: {"seq":0,"type":"response","request_seq":11,"command":"setBreakpoints","success":true,"body":{"breakpoints":[{"id":1000,"verified":false,"message":"Breakpoint set but not yet bound"}]}}
To client: {"seq":0,"type":"event","event":"output","body":{"category":"telemetry","output":"ClientRequest/setBreakpoints","data":{"Versions.DebugAdapterCore":"6.3.1","Versions.DebugAdapter":"1.25.5","Versions.Target.Version":"v8.11.3","successful":"true","timeTakenInMilliseconds":"37.400099","requestType":"request"}}}

If the debugger stops on exception and I click the file in the stack panel then it opens the right line in the file. But setting breakpoints does not work (breakpoints are "unverified")
EDIT: just tested version 1.24.1 and breakpoints work, so this may be a regression
VS Code version: Code 1.25.0 (0f080e5267e829de46638128001aeb7ca2d6d50e, 2018-07-05T13:11:58.697Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (4 x 2592)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwarevideo_decode: enabledvideo_encode: enabledvpx_decode: unavailable_softwarewebgl: enabledwebgl2: enabled

Memory (System)
11.91GB (3.33GB free)

Process Argv
C:\Program Files\Microsoft VS Code\Code.exe

Screen Reader
no

VM
0%

Extensions (4)

Extension
Author (truncated)
Version

xml
Dot
2.3.1

rightclick-git
Eve
1.0.0

rest-client
hum
0.19.0

debugger-for-chrome
msj
4.7.0

Probably dupe of #53785


fix node tokenRequest object example

The tokenRequest object is missing a comma after verifier as object key:value needs to be comma seperated this is an error

@ashu8912 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

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

The following users don't have valid GitHub IDs, or are not collaborators on this repo: microsoftdocs/public-repo-pr-review-team

#assign-reviewer @Dickson-Mwendia

#sign-off

@Dickson-Mwendia: I'm sorry - only the author of this article, @CelesteDG, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Enable partition projection on Glue tables

This tells Athena to manage partitions itself via
Projected Partitions rather than requiring us to define every
partition up front in the Glue data catalog.
We also rename the table to be underscored rather than dashed for better
Athena compatibility.
The TBLPROPERTIES parameters aren't natively exposed by CDK, so we use
CloudFormation overrides instead for these.
This will give a whole-date partition, so would be queried by:
WHERE date >= '2023/10/01' AND hour > 10 AND hour < 18

We can change this easily to be split by year, month and day if needed.
Deploying this will remove the old table definition and replace it with the newly partitioned one with the new name.

Thanks! Can you fixup the ruff commit before merging?


Set dib elements executable

These are defined as executable in the git repo but when ansible does
the copy it copies them as regular files. Set them as executable until
we have a better strategy for copying these over.

Still good.


"transientsolo" should be renamed "transient-solo"

See https://mediasession.spec.whatwg.org/#idl-index
The current name is a bit odd. Usually content attributes will use "foo-bar" while IDL properties use "fooBar". Should we use the same convention here? Are there some precedent? On top of my head, I don't know of any composed enumerated attribute.

I agree, some hyphenated values in https://fetch.spec.whatwg.org/#request-class
On the topic of style, I think the names of the states should match the strings more closely, something like https://html.spec.whatwg.org/#input-modalities:-the-inputmode-attribute
In other words "Transient" and "Transient Solo" with no underscores.

Good idea.
Fixed in https://github.com/whatwg/mediasession/commit/dcbd626929ead00f75246f75b80cf1871747c505.
(Media category state name changes fixed in https://github.com/whatwg/mediasession/commit/8cff29ee0847fdc711b2b848ea2fe7ac6b4b4b1d).


[PE-D][Tester A] DocumentationBug: AddTransaction small typo

Screenshot 2023-11-03 at 16.35.33
Error typo:
-Instead of w=1, =w1

Labels: type.DocumentationBug severity.VeryLow
original: LinWanLeii/ped#2

correct timestamp and weight typo


port object range splitter

Description

.auto porting
input / output

autoware_perception_msgs::msg::DynamicObjectWithFeatureArray -> autoware_auto_perception_msgs::msg::DetectedObjects

Review Procedure

Remarks

Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.

[ ] Read pull request guidelines
[ ] Code follows coding guidelines
[ ] Assign PR to reviewer

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code follows coding guidelines
[ ] (Optional) Unit tests have been written for new behavior
[ ] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets
[ ] Write release notes

CI Checks

Build and test for PR / build-and-test-pr: Required to pass before the merge.
Build and test for PR / clang-tidy-pr: NOT required to pass before the merge. It is up to the reviewer(s). Found false positives? See the guidelines.
Check spelling: NOT required to pass before the merge. It is up to the reviewer(s). See here if you want to add some words to the spell check dictionary.

@kenji-miyake changed commits :bow:


GHA workflow(s) for Linux

After #9 is merged (which will fix #8), let's get a Github Actions workflow to test the bindings on Linux. That will also include setting up a manylinux docker image.  The problem on Linux is that we'll need to build the bindings in an environment with a fairly low version of glibc so the binary package will be compatible with as many linux distros as possible (Mac & Win are much easier in that regard).
I personally use manylinux_2_28 these days, others have had success with manylinux2014. To preserve processing time, I prefer to publish my own manylinux image which have all OSRM dependencies installed. But to get quickly off the ground, we can also use the officially distributed image for now.
It's easiest to use cibuildwheel and configure it in pyproject.toml.

To drop an update on where I'm at with this, I'm currently trying to figure out how to handle setting up dependencies properly.
I got it working without cibuildwheel, but I'm getting issues related to missing dependencies when using cibuildwheel and manylinux.

My findings so far:

osrm-backend can't be "built out of the box" in manylinux_2_28, even with even with -DENABLE_CONAN=ON, due to some thrown warnings (and all warnings are treated as errors).
Some CMakeLists changes for py-osrm need to be made in order to pass the "ignore warnings of x type" flag into the osrm-backend build.
Python 3.8+ also needs to be built and installed from source, due to the older default version, and no newer version accessible from directly yum.
For Conan usage, Conan needs to be installed, but the default version of Conan installed will install a version incompatible with certain flags in osrm-backend, so an older version needs to be specified (ie. 1.60.1):ERROR: Error while initializing options. The usage of package names `boost:filesystem_version` in options is deprecated, use a pattern like `boost/*:filesystem_version` instead
    CMake Error at build/cp311-cp311-manylinux_2_28_x86_64/_deps/libosrm-src/cmake/conan.cmake:540 (message):
      Conan install failed='1'
    Call Stack (most recent call first):
      build/cp311-cp311-manylinux_2_28_x86_64/_deps/libosrm-src/cmake/conan.cmake:882 (old_conan_cmake_install)
      build/cp311-cp311-manylinux_2_28_x86_64/_deps/libosrm-src/CMakeLists.txt:371 (conan_cmake_run)

Some other py-osrm CMakeLists changes might be necessary to get proper linkage to LibOSRM and its dependencies as well.

and all warnings are treated as errors

I believe it should be possible to turn it off

For Conan usage, Conan needs to be installed, but the default version of Conan installed will install a version incompatible with certain flags in osrm-backend, so an older version needs to be specified

in OSRM we just specify that we don’t want 2.x version via pip install <2.0

and all warnings are treated as errors

I believe it should be possible to turn it off

Ah there is no existing CMake flag for that in OSRM, but it is trivial to add…

Oh yeah, I was able to get most of the aforementioned issues resolved, and get the tests running on a local manylinux image. I just set the appropriate CMAKE_CXX_FLAGS in the CMakeLists, and the other "findings" I listed were the parts I managed to resolve.
The main issue I'm facing is that while I can make it work on a local manylinux docker image, I can't seem to port it over to GitHub Actions smoothly.
The working local version was with a separate install of osrm-backend, and not using FetchContent - with FetchContent, I have this odd issue where I can find the Lua package on the py-osrm CMakeLists run, but not on the FetchContent's run.
Some of the things that worked on the local image also don't seem to transfer that well, resulting in failed setups and other weird issues that didn't happen on the local runs (ie. building wheel for Cython (when Python installs the required packages) results in status 'error').

done in #12


gitAndTools.delta: init at 0.0.12

Motivation for this change
Add https://github.com/dandavison/delta
Things done

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

[X] NixOS
[X] macOS
[ ] other Linux distributions

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

Notify maintainers
cc @

@GrahamcOfBorg build gitAndTools.delta


Support .markdownlintignore

So I can use same ignore patterns when using https://github.com/marketplace/actions/markdownlint-cli2-action and  https://github.com/DavidAnson/vscode-markdownlint without having to write the same rules twice.

.markdownlintignore is kind of a legacy file. What you want is possible today with .markdownlint-cli2.jsonc. Would you be able to convert to that instead?


Add outputs.<output_id>.description, which is updated as required

Fix #10
Signed-off-by: Sophia Guo<EMAIL_ADDRESS>

Tests: https://github.com/sophia-guo/runaqaTest/runs/1113128194

Will also need to backport to v1 version.


Add 3D circular Button with Click Effect

Fixes Issue
Closes #761

Screenshots

https://github.com/Spyware007/Animating-Buttons/assets/103810119/ce553295-e0ef-4ecf-bef3-c204bce3ab61
Checklist

[x] You've linked this PR to the correct issue.
[x] You have checked that the code is working correctly.
[x] You ⭐ the repository!

Note to reviewers

@Prajwal0225 The button is not alligned at center

Please check #1346


The scroll position of the test runner page jumps around while running acceptance tests

As you can see in the attached GIF, the scrollbar jumps to the top and then back down towards the test container element as the tests run. It only seems to happen on some of the tests, which may implicate a specific kind of interaction (like a click). This also happens in "dock container" mode.

This issue makes it difficult to observe the test progress or watch what is rendered in the test container div. It's also just plain annoying.
I'm not sure if this also happens during integration tests.

Was wondering if anyone has looked into this. It's extremely annoying to have to wait till all your tests are done to go back and look at the results because of scroll jumping.

@ikirkpat and @evanhl the "Dock container" checkbox at the top of the screen (also a query param) helps a lot ;)

@ikirkpat and @evanhl the "Dock container" checkbox at the top of the screen (also a query param) helps a lot ;)

This has improved my life so much!

I think this is resolved now (dock container is the default mode now)


Is this repo active?

Hello @kmees ,
Really like the start here, but nervous to take a dependency with no work in 5 months. If I start using this repo I would be PRing back to it. Are you still actively interested in this project? Would you be interested in adding owners or handing over the project if you are no longer actively interested?
Just curious where this stands before I consider taking this repo as a dependency.

No its not. There were some gamebreaking issues in the first office ui fabric relase which made me switch to something else. I think they fixed most of them by now but i currently don't have the time to continue working on this


[PDI-8928]  KettleDatabaseRepositoryConnectionDelegate - multiple un-…

[PDI-8928]  KettleDatabaseRepositoryConnectionDelegate - multiple unsynchronized methods that mutate objects.
extracted code for modifying sqlMap in separated synchronized method

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dpentaho.resolve.repo=http://ivy-nexus.pentaho.org/content/groups/approved -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dpentaho.resolve.repo=http://ivy-nexus.pentaho.org/content/groups/approved -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/repository/kdr/delegates/KettleDatabaseRepositoryConnectionDelegate.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change:  + 7.14%
Complexity Change:  + 7.69%

org.pentaho.di.job.entries.evalfilesmetrics.JobEntryEvalFilesMetrics

Branch Change: -.78%:small_red_triangle_down:
Complexity Change: -1.03%:small_red_triangle_down:
Instruction Change: -.16%:small_red_triangle_down:

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.28%:small_red_triangle_down:
Line Change: -3.87%:small_red_triangle_down:

org.pentaho.di.repository.kdr.delegates.KettleDatabaseRepositoryConnectionDelegate

Branch Change:  + .06%
Complexity Change:  + .04%
Instruction Change:  + .05%
Line Change:  + .05%
Method Change: -.03%:small_red_triangle_down:

org.pentaho.di.repository.kdr.KettleDatabaseRepositoryCreationHelper

Branch Change: -1.64%:small_red_triangle_down:
Complexity Change: -.69%:small_red_triangle_down:
Instruction Change: -2.43%:small_red_triangle_down:
Line Change: -3.70%:small_red_triangle_down:

org.pentaho.di.trans.step.StepMeta

Instruction Change:  + .19%
Line Change:  + .27%

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Branch Change:  + 1.32%
Complexity Change:  + 1.43%
Instruction Change:  + .54%
Line Change:  + .54%

org.pentaho.di.trans.steps.combinationlookup.CombinationLookupMeta

Instruction Change: -.04%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -2.08%:small_red_triangle_down:
Complexity Change: -2.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change:  + 2.35%
Complexity Change:  + 2.70%

org.pentaho.di.trans.steps.rowgenerator.RowGeneratorMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.setvalueconstant.SetValueConstantMeta

Instruction Change: -.14%:small_red_triangle_down:

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change:  + .08%

org.pentaho.di.trans.steps.systemdata.SystemDataMeta

Branch Change:  + 2.04%
Complexity Change:  + 2.04%
Instruction Change:  + .32%
Line Change:  + .81%

org.pentaho.di.trans.steps.webservices.WebServiceMeta

Branch Change:  + 1.79%
Complexity Change:  + 1.19%
Instruction Change:  + .07%

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Branch Change: -.29%:small_red_triangle_down:
Complexity Change: -.18%:small_red_triangle_down:
Instruction Change: -.05%:small_red_triangle_down:
Line Change: -.08%:small_red_triangle_down:

@mbatchelor Could you please review it?

@lucboudreau Could you please review it?
Fails of wingman  don't applies to my changes.

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dpentaho.resolve.repo=http://ivy-nexus.pentaho.org/content/groups/approved -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dpentaho.resolve.repo=http://ivy-nexus.pentaho.org/content/groups/approved -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/repository/kdr/delegates/KettleDatabaseRepositoryConnectionDelegate.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change:  + 7.14%
Complexity Change:  + 7.69%

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -3.28%:small_red_triangle_down:
Line Change: -3.87%:small_red_triangle_down:

org.pentaho.di.job.entries.waitforsql.JobEntryWaitForSQL

Branch Change: -.66%:small_red_triangle_down:
Complexity Change: -.93%:small_red_triangle_down:
Instruction Change: -.13%:small_red_triangle_down:

org.pentaho.di.repository.kdr.delegates.KettleDatabaseRepositoryConnectionDelegate

Branch Change:  + .06%
Complexity Change:  + .04%
Instruction Change:  + .05%
Line Change:  + .05%
Method Change: -.03%:small_red_triangle_down:

org.pentaho.di.trans.steps.checksum.CheckSumMeta

Branch Change:  + 1.32%
Complexity Change:  + 1.43%
Instruction Change:  + .33%
Line Change:  + .54%

org.pentaho.di.trans.steps.constant.ConstantMeta

Instruction Change: -.10%:small_red_triangle_down:

org.pentaho.di.trans.steps.csvinput.CsvInputMeta

Instruction Change: -.05%:small_red_triangle_down:

org.pentaho.di.trans.steps.dbproc.DBProcMeta

Instruction Change: -.11%:small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change: -.66%:small_red_triangle_down:
Complexity Change: -.41%:small_red_triangle_down:
Instruction Change: -.50%:small_red_triangle_down:
Line Change: -.24%:small_red_triangle_down:

org.pentaho.di.trans.steps.groupby.GroupByMeta

Branch Change: -3.12%:small_red_triangle_down:
Complexity Change: -3.16%:small_red_triangle_down:

org.pentaho.di.trans.steps.ifnull.IfNullMeta

Branch Change:  + 2.00%
Complexity Change:  + 1.89%
Instruction Change:  + .17%

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -2.35%:small_red_triangle_down:
Complexity Change: -2.70%:small_red_triangle_down:

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change:  + .08%

org.pentaho.di.trans.steps.sort.SortRowsMeta

Instruction Change: -.08%:small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change:  + .18%

org.pentaho.di.trans.steps.synchronizeaftermerge.SynchronizeAfterMergeMeta

Instruction Change: -.04%:small_red_triangle_down:

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change:  + .53%

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -.18%:small_red_triangle_down:

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Branch Change: -.29%:small_red_triangle_down:
Complexity Change: -.18%:small_red_triangle_down:
Instruction Change: -.05%:small_red_triangle_down:
Line Change: -.08%:small_red_triangle_down:

Code issue is fixed.
@mbatchelor Could you please review it?


Move token and ref to option object

As they are both not required
Format:
{
  token: string, // default to '': disabled
  ref: string // default to 'master'
}

Based on my feature/add-ref branch.
This is a breaking change, I suggest you release #9 as minor and push this one as v2.0.0

Sorry for making this wait so long! I forgot about it.
How about adding it to the repo as user/repo#ref? So no object is needed


Enable migrations - failing

Same as this issue  but more details.
Create a .NET Standard class library. Change to use .NET Standard 2.1.
(Or create a .NET Core 3 class library, same problem).
Add EF 6.3 preview 7.
Try to use entityframework\enable-migrations
This is the result: enable migrations error.txt
EF version: 6.3 preview 7
Database Provider: EntityFramework.SqlServer
Operating system: Windows 10)
IDE: Visual Studio 16.3 Preview 1.0
It works fine with a .NET framework class library as expected.

Closing because with Preview 8 we now get a sensible error message:

Project 'ClassLibraryNetStandard' targets framework '.NETStandard'. The Entity Framework Package Manager Console Tools don't support this framework.


Mouse/touch events near bottom of screen

If you touch near the bottom of the screen on an iPhone 5 Safari, the display reverts to the full view. Is that Safari's built-in behavior? Or is that a brim setting?
If it's the former, I'm guessing there's no way to intervene. I have some buttons near the bottom edge because I'm trying to use most of the viewing area for an image that can be panned and zoomed.
Thanks to anyone who knows or has experienced the same thing.
-Dave

I'm realizing that this is a duplicate of #4.


change to a single row causes render of whole table (external data store)

Describe the bug
I have a table with 100 rows, the data is fed from an external store (redux), when a single row is modified the whole table is re-rendered, which is extremely slow.
To Reproduce
The suggested codesandbox for redux already displays this behaviour, just run it locally, enable react profiler with highlight updates enabled, then click on Update Last Record.
The whole table is highlighted
Expected behavior
I would expect only the modified row to be re-rendered
Desktop (please complete the following information):

OS: Linux
Browser Chrome
Version 70

react-table 6.8.6

Good morning, this issue has been fixed in version 7?
I have the same issue with Redux as external source...
Thank you


Remove fixed port for health tests

Fixes #18
Removed live HTTP server unit tests for health.go from dispatcher and channel (unnecessary duplication of testing between those and common).  Changed common health.go test to use a system-assigned port for the local HTTP server to avoid random port conflicts during testing.

/ok-to-test

/test all
Note - I will be re-testing a few times to ensure prow-only failures are not occurring ; )

/test all

/check-cla

I've requested that Eric get added to the sap corporate cla, should be resolved shortly

/test pull-knative-sandbox-eventing-kafka-go-coverage

/test pull-knative-sandbox-eventing-kafka-go-coverage

/test pull-knative-sandbox-eventing-kafka-go-coverage

/test pull-knative-sandbox-eventing-kafka-go-coverage

/check-cla

@googlebot rescan

/lgtm

/approve


Replace NMEPreloader template for backwards compatibility.

@jgranick how does https://github.com/openfl/openfl/commit/c3237c9b5eb69ec9ab3e7d8ac211df75e43f724e mix with this?
This file can't be removed just like this, people are extending it.

I have made a workaround for now
https://github.com/openfl/openfl/commit/ee5f10dbcb8c3d2f59e5051b8089c0f2e16307ff
I am still concerned, though, that we will have the same problem in the future, if we ever remove this code. I'm a little concerned about the "magic" nature of this, but I think it has been long enough that we should not have this file included by default

A typedef with a @:deprecated metadata left for a version would have been a lot simpler.
It hasn't been long enough, you just removed its usage and added something else, instead of getting a deprecation message people would get a build error if they use this class, that's not good.


Add models and schema for backend objects and Results

Summary
Follow-up to #1249, adding models and schemas for:

BackendConfiguration
BackendProperties
BackendStatus
JobStatus
Results

along with the utilities needed for supporting their functionality (Fields, Validators, and tweaks and fixes for the base models).The models however have been tested against the existing qiskit/schemas/examples files by modifying the test_schema.py file.
By having these files in place, the rest of the work (updating the components needed for each schema, adjusting the simulators for conforming to it, working with results, etc) can hopefully be split more easily.
Details and comments
Please note that the objects are not in use yet - will be tackled in subsequent PRS. Also, the location of some files and classes is still not set in stone (in particular, qiskit.validation.result will be removed, Jay!). No changes have been made to the schemas themselves, and the .json files have been used as a reference.
The schema files

Thanks for the review, @delapuente !
Regarding the counts field, the motivation was mostly to explicitly avoid using Dict (the field), as previous exploratory efforts yielded some errors (that might be no longer a concern, but part of using it is ... testing it as well). Consistency also played a role - it would be the only item in the current schemas that would be a Dict, and it felt safer to stick to the overall approach and model it in a similar way (with the extra validator) - but indeed is a blurry line.
Combined with the nature of the PR (setting the basis for future PRs, and allow for adjustments of different kinds once the rest of the work is completed), I went with the "conservative" approach - I think your suggestion is bound to be explored, although perhaps it fits better to make it as a follow-up for optimizing efforts.


ci: delete success build notice

delete email notice for travis success build

I'm +/-0, I don't mind them.


better way of doing non-ghost noting

title explains, just a cleaner and better way of doing non-ghost noting

basics education


MOOC for Eli

This repository's issues are reserved for feature requests, and bug reports, and questions.
I'm submitting a ...

[ ] bug report
[x] feature request
[ ] question

Expected Behavior
MOOC for reviewing dissertations / thesis / papers / ...
Actual Behavior
Steps to Reproduce the Problem

Open the link below, and complete the free version of the course
https://www.coursera.org/learn/sciwrite

Specifications

Version:
Platform:
Subsystem:

How can this issue be closed?

Completed a while ago, confirmed with @ElijahCapps on 9/2.


tags for the metadata yaml files is accepting only lowercase

What we don't understand at the moment is why the tags needs to be in the lowercase? Is there any rationale behind this?
It actually doesn't accept the upper case as well as any special characters

ok I get this. Thanks I will close this ticket now.


Update import for django.template.context_processors.

Old import was deprecated in Django 1.8.

Also took care of deprecation warning in Django 1.9.

I highly suggest to merge this pull-request, since the django-jfu will be unusable with the next major django version.

Indeed. We just updated to Django 1.10 and jfu was one of many packages we had to patch because of the problem addressed here. If I had seen this pull request beforehand I could have saved a few minutes.

Is anybody still maintaining this library? It breaks on my django 1.10 install too.

can someone merge these updates ???


DBZ-3960 Provide list of DBZ UI configurations

@rk3rn3r Thanks for the changes. Updated accordingly.

LGTM now! Ready for @gunnarmorling to review now

@uidoyen Could you please either squas the commits into a single one or prefix all of them with  DBZ-3960? Thanks

@uidoyen Could you please either squas the commits into a single one or prefix all of them with  DBZ-3960? Thanks

@jpechane Done!

Thanks, @uidoyen! Some minor comments inline. Also, this should go into a new README file in the directory of the UI Dockerfile instead of this root README here; that other README file will be shown on Docker Hub for this image.

@gunnarmorling Should it go inside each versions https://github.com/debezium/docker-images/tree/master/ui

Should it go inside each versions
https://github.com/debezium/docker-images/tree/master/ui

Yes, exactly. That way, it will be shown next to the image on Docker Hub.

Should it go inside each versions
https://github.com/debezium/docker-images/tree/master/ui Yes, exactly. That way, it will be shown next to the image on Docker Hub.

Updated the PR accordingly. I'll fix those two items on the other PR


luci-app-unbound: add rate_limit and dns_assist option support

maintainer: me
tested: Linksys WRT3200ACM
description:
resolves #4174 and picks up options from https://github.com/openwrt/packages/pull/12798

Merged, thanks!


Loading MF Remote as ESM

It seems like MF is currently always loaded as a script file. Is there a way to load it as an ESM to prevent this issue:

Angular is just using ESM, meanwhile.

How can we know if it should be ESM or not from the outside?
Webpack itself is just loading these as scripts. I think you might use another remote target (the default is var, but there are others which may indicate an ESM - but var is historically the default and therefore right now supported out of the box). Other targets may require the JSON (manifest) instead of the plain JS (or we introduce another specifier / attribute when using it single handed).

We could add a parameter to specify its esm. In our Angular API we also had such an option (type: 'module' | 'script').

This should be solved in the 0.0.6 that is already available on npm.

container (in attributes) is now called remote-name
the remote type (in attributes) is called remote-type

Specifying the remote type is optional. The two available types are var (default) and esm (equivalent to library type being set to module).
Let me know if this works for you (works in my testing - see example 10; dependency sharing).


Question: Writing my own plugin like docs, vs like actual plugins are written.

My plugins that are written per the docs work fine, using this basic format
module.exports = {   plugin: (schema, documents, config) => { ...
If I'd prefer to write in the post-common.js style - such as virtually everything in packages/graphql-codegen-cli/src/init/plugins.ts - but I don't know how to reference this style of code into my development workflow without inserting into the plugin.ts etc.
Is this possible? Documented? Or do I have to stick with the documented common.js style until I am ready to make it a part of the graphql-codegen-cli?,

Hi @petecarapetyan !
Can you please explain what do you mean by post-common.js?
You wish to use ES6 or TypeScript for writing your plugins? You can easily do that with tsc, just make sure to compile it and point the correct files in your package.json's main field.

Yes, by post-common-js I meant ES6 or ES2017 or any of the other later versions, none of which use common.js requires or module.exports
I would like to use the same kind of ES6 code that I see in the plugins written in graphql-code-generator
I am attempting to write a generator for web components and lit-apollo

@petecarapetyan We are using TypeScript, compiled with tsc. You can copy the following and it will work for you:

https://github.com/dotansimha/graphql-code-generator/blob/master/packages/plugins/typescript/typescript/tsconfig.json
https://github.com/dotansimha/graphql-code-generator/blob/master/packages/plugins/typescript/typescript/package.json#L27-L33


NFTs in Prague 2023 Kodachain - Collection won't load items

What happened?
check:
https://canary.kodadot.xyz/ahp/gallery/0-18
is it related to the media type?

👋🏻

It looks like it can be loaded, just takes time. Until the image of this item is displayed, the position of the image is shown as blank.


[Update] Master to develop

[Update] Master to develop

Codecov Report

Merging #716 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #716   +/-   ##
========================================
  Coverage    28.48%   28.48%
========================================
  Files          253      253
  Lines        18349    18349
  Branches      1563     1563
========================================
  Hits          5227     5227
  Misses       12559    12559
  Partials       563      563

Continue to review full report at Codecov.

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


Processing empty pdr shots

RI-580

Does this repo have a test suite?

Does this repo have a test suite?

We don't currently run tests like we do on processing. When we get around to refactor this and bring this into processing repo, we should add tests for all top level commands.

Does this repo have a test suite?

We don't currently run tests like we do on processing. When we get around to refactor this and bring this into processing repo, we should add tests for all top level commands.

:sad-ok-emoji:


Vector Control General Functionality

Class for Vector Control, header and main file. This is the initial overview of how vector control will work. We just need it now to merge with CAN messages. All steps are added until the space vector modulation

Probably don't even need to review. We are apparently changing to scalar control now.


Include Java api rest client link

Adds link to Java based REST API Client library Buildkite-Api-Client

@Crim, sorry this has taken so long to get to but thanks for adding the information. Can you please resolve the conflict and then I can help you get this live. 😊

@mbelton-buildkite I've updated my branch with the latest from the main repository.  Let me know if that resolves it, or other changes are required.
As far as I can tell the rest-api page looks correct to me, and don't see any conflicts.
Thanks!


Components or Macro Elements as method

Hey guys,
It would be great if the components or some kind of macro elements returning content would be defined as a method, so any parameter attribute should not enter in conflict with others.

Hey Daniel, Can you give me an example or use case of the kind of things you'd like to use? Not sure I understand exactly what you're looking for here.


Macro: Attachment points on monomer do not disappear after moving cursor away

Steps to Reproduce

Switch to Macro mode
Place monomers on canvas and connect them with bonds
Select bond tool and hover over monomer and move cursor between attachment points

Actual behavior
Attachment points on monomer do not disappear after moving cursor away
Expected behavior
Attachment points on monomer disappear after moving cursor away
Screenshots
https://github.com/epam/ketcher/assets/62464241/fcac4608-1813-48f0-884f-d76a8ef28ab1
Desktop (please complete the following information):

OS: Windows 10
Browser Chrome
Version 112.0.5615.138 (Official Build) (64-bit)

Ketcher version
Version 2.17.0-rc.2

The bug is a duplicate of https://github.com/epam/ketcher/issues/3899 that is already being worked on

The bug is a duplicate of https://github.com/epam/ketcher/issues/3899 that is already being worked on


Linux Download

What do i do to run the program on linux with the zip from the releases tab

The program was compiled as a 64-bit elf (GNU Binutils for Ubuntu 2.38).
You may need to mark the program as executable.
chmod +x Dolphin-memory-engine

and then run it (some DEs allow double click)
./Dolphin-memory-engine


Add GHC 7.10.1 support - RC3 and later adds (<$>) to the Prelude.

It may be worth it to add a prefix 'above' combinator and deprecate
'(<$>)' given that this will eventually become a real pain point for
users.

main difference to #11 is that #12 uses CPP whereas #11 gets away without CPP-use

I rather prefer your patch.


rely on webhooks and websocket messages to avoid receiving stale data

Summary
We added extra calls to get updated information when requesting trial as a stopgap to some webhooks issues we were seeing. The issue was, cloud instances run two mattermost-server nodes in a cluster, and it isn't guaranteed that the node that handled the trial request and gets the updated data is the same node through which subscription and limits info was subsequently requested.
We have improved the webhook's reliability, so we should rely on it to send correct information now. This will also improve the perceived performance of the trial request because we don't need to make and wait for 4 extra re-requests of data. And for the updated license, it is returned from the trial request, so we can use that for updated subscription immediately.
Ticket Link
https://mattermost.atlassian.net/browse/MM-45056
Related Pull Requests
https://github.com/mattermost/enterprise/pull/1244
Screenshots
Release Note
Decrease flakiness of requesting cloud trial.

E2E tests not automatically triggered, because PR has no approval yet. Please ask a developer to review and then try again to attach the QA label.

I don't think this is worth adding tests at the moment. To my knowledge, cloud e2e tests are only run locally on an ad-hoc basis, if at all, because they are skipped in CI https://git.internal.mattermost.com/qa/cypress-ui-automation/-/blob/master/scripts/prepare-test-cycle.sh#L15 . If we want to run cloud e2e tests in an automated fashion, we'd need to orchestrate a way to talk to a CWS instance and set up a new account, and then set up the mattermost-server instance with that CWS account.
Looking more closely, at least some of the @cloud_only e2e tests are no longer valid, and because we don't run the tests we don't have a good way to keep them up to date or take any action if they break.


Build System Rework #4

@mattnite sees reason to rework the build system once again.
I think we're not in a perfect place yet, so that's reasonable.
What are features we need and what are features we want to have?

I’m newish. But it took me a bit to figure out what data/files are relevant for the project. For most c projects all the relevant files are placed along side the src for the project. I think I’d rather have a folder init script for my particular micro family. But then again, the current method allows switching between things

Idea:
We can ship MicroZig as a monolith, but not as a mono-package.
We did the split originally to reduce package size, and this is still a concern. But with the introduction of lazy dependencies, we can now make a single package the user can pull in, and we can then have an inner resolution logic pulling in all the BSPs lazily.
This will decrease download and cache size, and gives the user a monolithic frontend, which might improve UX a good bunch
Only question is how to distribute the information about BSPs... This might require some "build logic" that glues together the BSPs into a singular data structure...
const BSPs = struct {
  avr: ?type = null,
  rp2: ?type = null,
  stm32: ?type = null,
  …
};

which would be populated lazily with the @import() of the BSPs

Really only three pain points with MicroZig's build system in order of most to least painful:

Including MicroZig is your project is pretty un-intuitive at the moment (although I understand some of the hackier things we have to do are due to limitations of Zig's build system). Having to include things like:

 .dependencies = .{
        .@"microzig/build" = .{ .path = "../../../build" },
        .@"microzig/bsp/raspberrypi/rp2040" = .{ .path = "../../../bsp/raspberrypi/rp2040" },
    },

In your build.zig.zon isn't very self-explanatory, and in the ideal world I would love to have:
 .dependencies = .{
        .microzig= .{ path, url, whatever},
    },

be the only requirement for including MicroZig in your project, build utilities and all! I think I already have a loose understanding of what prevents us from doing this in Zig's current build system, but I'll spend some time brainstorming.

It takes a lot of code searching and head scratching to figure out how everything is stitched together at build time in regards to the chip, hal, board modules as well as startup code + vector table. Lots of tracking down modules importing other modules. It took me a very long time to figure out how const microzig = @import("microzig"); gets you what it does. I think a lot of this can be solved with documentation, but if there's any low hanging fruit to make this more intuitive that would be a welcome change. Note that this one is mostly due to my "firmware engineer" brain not allowing me to trust anything until I know what it's doing under the hood. I'll also think about this one in terms of what could maybe change.

Nit, but I can't not read "Board Support Package" when I see bsp/, and none of these are really "BSPs". They're HALs! I think we should rename the bsp/ directory to vendor/, and  keep the rest of the organization the same. Both HALs and BSPs can live within this directory (although currently only HALs do).

@ikskuh would your idea basically be accomplishing number 1 in my list? I like the idea of leaning on lazy dependencies to only use what the user wants especially if it allows us to only import a single package to use MicroZig!

Oh! Sorry, one more thing that's pretty important to me. MicroZig should support a "native" target (Linux, Windows, etc.). Obviously HAL/device code isn't included in this, it just gives you the bones to make it easy to run certain parts (think testing) or all of your "business logic" code natively. I have a complicated build setup on my current projects in C/C++ that lets me do this and it's a dream once you get it working. You basically always have a dummy, simulation version of your firmware that runs on your computer.
I'll take on brainstorming how to do this, since I currently haven't even done this vanilla in Zig's build system. I think Zig's build system and language is very well suited for this purpose though. Lazy evaluation + easy comptime switching based on architecture should make this much more ergonomic than C/C++ + CMake.

@ikskuh would your idea basically be accomplishing number 1 in my list? I like the idea of leaning on lazy dependencies to only use what the user wants especially if it allows us to only import a single package to use MicroZig!

Yes, that would be addresses by the "entrypoint/mono-package" style package. No idea how we could make that yet, but it should be doable for sure. We just need to keep the vendor packages in sync with the root build script, but that's totally fine i guess

Nit, but I can't not read "Board Support Package" when I see bsp/, and none of these are really "BSPs". They're HALs! I think we should rename the bsp/ directory to vendor/, and keep the rest of the organization the same. Both HALs and BSPs can live within this directory (although currently only HALs do).

I'm in for that, i don't like "bsp" either. We could also use port or arch or something like that

MicroZig should support a "native" target (Linux, Windows, etc.).

I agree, it's super useful for testing and simulation, which makes it easier to run improved tests

I'm in for that, i don't like "bsp" either. We could also use port or arch or something like that

Yep port seems perfect.
I think once I get RP2350 in a somewhat working order I may take a break from that to noodle on the build system. It makes my head hurt every time but there should be a way to get what we're after and ditch the need to patch all of the relative imports into URLs... Well, hopefully :)

I was thinking that using git submodules might help with the zig zon archives, and allow keeping somewhat the same monorepo. Sadly they are a pain.

I was thinking that using git submodules might help with the zig zon archives, and allow keeping somewhat the same monorepo. Sadly they are a pain.

Nah, not really, as you then have to double-maintain all dependencies, while .path is a maximum in MicroZig Development Experience for now

I was thinking about the people who are working off of main. They have an additional steps downloading extracting the repo and placing somewhere convenient. But basically it’s because “.url” doesn’t support a relative path on zon. I feel that this could be potentially fixed by using CI to build the individual root packages. It would help with release consistency, cause individual revs could be used.

I'm liking what I'm seeing, to summarize some action items:

Rename bsp to port
Single entry point into microzig
Add a native target

For the single entry point, I think that's what we need, we just need to figure out a way to make it work with lazy dependencies, so we need some sort of runtime registration. Now another question for y'all, up until now I've been big on users being able to set up their own hardware support if they didn't want to deal with upstreaming it. But I'm starting to question that, why put work into that part of the design for people who aren't going to give back to the project? Like maybe we still expose that ability, only if it's trivial to do so. What do you think?
For the native target, I know @vesim987 wants it so that he can leverage the GPIO interface on a raspberry pi. Is what you're referring to @haydenridd more about software simulation where I imagine you provide some fake hardware? (I suppose vesim could wire the gpio interface to his OS).

For the native target, I know @vesim987 wants it so that he can leverage the GPIO interface on a raspberry pi. Is what you're referring to @haydenridd more about software simulation where I imagine you provide some fake hardware? (I suppose vesim could wire the gpio interface to his OS).

Yup exactly, for the dev phase where you're still waiting for boards to come back but just want to test your business logic. Essentially just give you an easy way to compile a native executable. Obviously it's up to the user to correctly swap out their hal for a dummy simulation maybe using a cfg.is_native compile time constant MicroZig provides. There is also maybe an argument to be made that this is up to the user to do, as there's nothing that keeps you from swapping out add_firmware() for the standard Zig build commands based on an input target (native vs. an MCU) in your build.zig.  I can noodle around with some stuff...

I would use cfg.is_simulation instead of cfg.is_native, because native might still be a suitable target (see: raspberry pi)

For the single entry point, I think that's what we need, we just need to figure out a way to make it work with lazy dependencies, so we need some sort of runtime registration.

For the GitHub record, I started drafting a new build interface here:
https://github.com/ZigEmbeddedGroup/microzig-build-api-draft
My current focus is on composing via b.dependency() and a custom MicroZig instance

The build system is centered almost completely around the build/build.zig file. This I think cuts off a lot of flexibility in terms of what it is capable of.
This, for instance, is very hard to achieve.

... in the ideal world I would love to have:
 .dependencies = .{
        .microzig= .{ path, url, whatever},
    },

I suppose a better way to write the build system would be to have each part (chip, board, hal, even cpu although including it in core is fine I guess) have their build.zig file do the actual build of the module. Then we could have a master module (it can be the root module of the repo) that would create the hierarchy made currently by the core module including all the necessary parts, including the user's app (it's build.zig should contain the current add_firmware etc. functions from build.zig). In the root module's build.zig.zon we could have all the chips, boards, cpus (maybe) as lazy deps so as to be able to add them as imports. What do you think? Another benefit of this is that modules can depend upon each other (the hal can depend on chip, chip on cpu, board on hal).

I also think this would improve a little the readability of the repo. It took me quite some time to learn how things are glued together.

What do you think? I'll be glad to implement this, but I thought it would be better to ask before, so as to not work in vane.

If you figure out a way how that would work, sure!
Problem is that you want to access a microzig package from all modules (chip, cpu, hal, board, core), so you have to create the packages per application and not once in the build.zig file of it's "owning" project.

Problem is that you want to access a microzig package from all modules (chip, cpu, hal, board, core), so you have to create the packages per application and not once in the build.zig file of it's "owning" project.

This is something that puzzles me because I don't really see why those have to access the whole microzig package. Like the hal package can have a dependency on the specific chip and cpu instead. We could join everything (hal, chip, cpu, util etc.) after the fact, only in the api that we expose to the user.
Also, I think the way that stuff currently works allows for ports that live outside the microzig monorepo to be used. Is this a kind behaviour that should be kept? I think it's a nice feature.

This is something that puzzles me because I don't really see why those have to access the whole microzig package, but maybe I miss something. Like the hal package can have a dependency on the specific chip and cpu instead. We could join everything (hal, chip, cpu, util etc.) after the fact, only in the api that we expose to the user.

The reason is that a HAL can be used for many chip packages, and a chip package can be used for many CPU packages.
Or considering the RP2350, you can use the same HAL and chip package for two distinct CPUs and it will still work.

I'll get to work then :)) I have a couple of ideas for it. I'll post updates in this issue.

Should this be closed, with #259 being merged?


Straight Driving

We need straight driving PID. It can be implemented the same way it was attempted to be implemented last year.

@KIllin-A13, do you think that #44 (straight driving ready for testing) completed the issue?

We have reached a consensus that this issue has been completed.


Re-name of DNF/out of time for  QT Test

Th Why
We need to re-name the terminology  used for candidates that have their test auto submitted after their time in the time  has expired. The Administrators find the current terminology used which DNF/out of time a bit  confusing.
The Action
We need to re-name  DNF/out of time to Auto-submitted to ensure that the Administrators understand the terminology used at different stages of the test. This will also allow Administrators to better support the candidates who might be worried about their test has not been submitted. We need to make this changes on the dashboard and on candidates log. See pictures attached

This is pretty straight-forward just a few places to reflect the change - admin, apply, downloads - so have estimated at 2 SPs

@warrensearle Thanks for updates


List all the ROCm packages and its version installed in system.

rcqt: list all the ROCm packages and its version installed in the system.

@manoj-freyr Review comments fixed. Please have a look.


Add CI/CD

The application must, at least build to gh-pages on master push, it also should deploy to an azure static website.

[ ] Should deploy to Github pages
[ ] Should deploy to Azure

Did some tries in order to publish to gh-pages but seems to be kinda hard, take a look at the Actions log to see more.

Did some tries in order to publish to gh-pages but seems to be kinda hard, take a look at the Actions log to see more.


cannot map  as delete at vim binding

I tried mapping <C-d> to 'delete' in insert mode, instead of 'indentRight'.
In online Vim bindings demo,
:imap <C-d> <Del>

doesn't work.

:unmap <C-d>

unmapped at normal mode (never 'moveByScroll')
not unmapped at insert mode (still 'indentRight')

As a workaround, I use
:imap <C-d> <Esc>lxi

almost OK
not good at Beginning / End of line.

I was using Safari version 14.0.1 on MacBook Pro.
Online demo at https://codemirror.net/demo/vim.
(Also testing on Obsidian v0.10.1, along with Obsidian Vimrc Support Plugin v0.2.1)

The problem with :imap <C-d> <Del> is that <Del> doesn't have an insert mode binding in the default keymap.
@hnsol Can you use the API instead?
CodeMirror.Vim.mapCommand('<C-d>', 'motion', 'moveByCharacters', { forward: true }, { type: 'operatorMotion', operator: 'delete', context: 'insert' })

Unfortunately, this mapping won't work in the search / cmdline dialog.
I see there is some special handling of Delete / Backspace in insert mode, so I'm not certain what other effects this mapping might have (e.g. in macros). But if this mapping works correctly, adding <Del> and <BS> to the default keymap might eliminate the need for that code... (along with <C-d>, <C-h>, <C-k> on mac).

BTW, you specify the context after the key. E.g. :unmap <C-d> insert

The problem with :imap <C-d> <Del> is that <Del> doesn't have an insert mode binding in the default keymap.
@hnsol Can you use the API instead?
CodeMirror.Vim.mapCommand('<C-d>', 'motion', 'moveByCharacters', { forward: true }, { type: 'operatorMotion', operator: 'delete', context: 'insert' })

Unfortunately, this mapping won't work in the search / cmdline dialog.
I see there is some special handling of Delete / Backspace in insert mode, so I'm not certain what other effects this mapping might have (e.g. in macros). But if this mapping works correctly, adding <Del> and <BS> to the default keymap might eliminate the need for that code... (along with <C-d>, <C-h>, <C-k> on mac).

BTW, you specify the context after the key. E.g. :unmap <C-d> insert

@benhormann Thank you for your kindly support. I will try CodeMirror.Vim.mapCommand() !
Especially in my case of Obsidian, I use CodeMirror.Vim.defineEx() as a part of vimrc-support plugin.
Again, thank you so much!
P.S.
It's a pity that :unmap <C-d> insert doesn't seems to work, at least Vim bindings demo.

@benhormann Thank you for your kindly support. I will try CodeMirror.Vim.mapCommand() !
Especially in my case of Obsidian, I use CodeMirror.Vim.defineEx() as a part of vimrc-support plugin.
Again, thank you so much!
P.S.
It's a pity that :unmap <C-d> insert doesn't seems to work, at least Vim bindings demo.

🤦 You're right, it doesn't delete the correct mapping.
We ought to add the missing :iunmap, :nunmap and :vunmap commands. You wouldn't need them with the mapping I suggested, since new mappings get higher precedence than defaults. However... my suggested mapping won't delete through line-endings, unlike the standard Backspace / Delete / C-d. It is ignored during macro recording and C-d is the same :(
The only real solution would be to fix 'keyToKey' insert mapping, so that you can use :imap <C-d> <Del>. Only maps that resolve to a non-keyToKey map, or to <Esc>, seem to work.

🤦 You're right, it doesn't delete the correct mapping.
We ought to add the missing :iunmap, :nunmap and :vunmap commands. You wouldn't need them with the mapping I suggested, since new mappings get higher precedence than defaults. However... my suggested mapping won't delete through line-endings, unlike the standard Backspace / Delete / C-d. It is ignored during macro recording and C-d is the same :(
The only real solution would be to fix 'keyToKey' insert mapping, so that you can use :imap <C-d> <Del>. Only maps that resolve to a non-keyToKey map, or to <Esc>, seem to work.


chore: update spring-boot in templates

The Spring Framework version in 2.6.6 includes a fix for CVE-2022-22965, check the dedicated blog post for more details.

/cherry-pick release-0.23


prow: move to use WI for auth_header in private (#45606)

Fixes https://github.com/istio/istio/issues/45607

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all


scipy.io.savemat is not thread-safe

Empirically, I've found that scipy.io.savemat using SciPy v0.15.1 is not thread-safe (https://github.com/blink1073/oct2py/issues/120). Attempting to save two objects at once can result in writing a silently corrupted file.
Is this expected behavior?

Are you attempting to write to the same file from two different threads?   I wouldn't expect that to work.  If you're writing to different files, then that is surprising, I guess we have some global state in there.

Definitely writing to different files.
On Wed, Apr 5, 2017 at 12:03 AM Matthew Brett<EMAIL_ADDRESS>wrote:

Are you attempting to write to the same file from two different threads? I
wouldn't expect that to work. If you're writing to different files, then
that is surprising, I guess we have some global state in there.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/issues/7260#issuecomment-291772680, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABKS1rUOcGlXgPKn6n7IbIO8eRYElT0yks5rszykgaJpZM4Mzrxy
.

Can you come up with a minimal repeatable example we / I could have a look at?


[Bug Report] table [fixed column] and [show-summary] lead to layout disorder

Element UI version
1.4.3
OS/Browsers version
windows10 Chrome60
Vue version
2.4.2
Reproduction Link
https://jsfiddle.net/khmnLtsu/
Steps to reproduce
set table attributes[show-summary] and table-column attributes[fixed column]  exist at the same time
lead to layout disorder
What is Expected?
fix table layout disorder
What is actually happening?
...

Duplicate of #5415


RSpec/EmptyExampleGroup warning when using rswag's run_test!

rubocop does not recognize rswag's run_test! as a test block and results in an unexpected behavior. If this really is a bug, I would love to explore it and try to fix it.

Expected behavior
I expect this to give no offenses
Actual behavior
spec/integration/menu_spec.rb:3:1: C: RSpec/EmptyExampleGroup: Empty example group detected.
RSpec.describe MenusController do
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Steps to reproduce the problem
A simple spec like this should suffice.
require 'swagger_helper'

RSpec.describe MenusController do
  path '/menus' do
    get 'menus' do
      tags 'Menus'
      produces 'application/json'
      response '200', 'success' do
        run_test! do
        end
      end
    end
  end
end

RuboCop version
$ bundle exec rubocop -V
0.93.1 (using Parser <IP_ADDRESS>, rubocop-ast 1.7.0, running on ruby 2.6.3 x86_64-darwin20)

We've discussed pretty extensively how it would be possible to smoothen the rough edges between Rswag and rubocop-rspec in https://github.com/rubocop/rubocop-rspec/issues/1165. To make use of the described technique, you'll need to use RuboCop version that includes this fix. And it's not yet included in the latest 1.18.4.
Thanks for reporting. Please don't hesitate to ask further questions. This area is interesting and important to make rubocop-rspec compatible with many tools that add custom RSpec DSL.
If you want to kick-off rswag-rubocop-rspec to include the default configuration, that would be great, too.

Hey @pirj, thanks for the reply. Could you expand a bit more about this?

If you want to kick-off rswag-rubocop-rspec to include the default configuration, that would be great, too.

@Krupskis sure: https://github.com/rubocop/rubocop-rspec/issues/1165#issuecomment-884773009 https://github.com/rubocop/rubocop-rspec/issues/1165#issuecomment-888664525

https://github.com/rubocop/rubocop/releases/tag/v1.19.0 released with the fix to DSL configuration loading.

https://github.com/rubocop/rubocop/releases/tag/v1.19.0 released with the fix to DSL configuration loading.

@pirj Thanks for the news! does that fix the RSpec/EmptyExampleGroup when only response and run_test! are present??

does that fix the RSpec/EmptyExampleGroup when only response and run_test! are present?

Provided you configure its DSL properly https://github.com/rubocop/rubocop-rspec/issues/1165, supposedly yes.
I encourage you to test it out.


Error installing remix-auth v2.1.1

I am trying to install remix-auth into a remix app and am receiving the following error:
➜  my-remix-app npm i remix-auth
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: remix-app-template@undefined
npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/remix
npm ERR<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm ERR! node_modules/remix-auth
npm ERR!   remix-auth@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

You need to upgrade to use Remix v0.20.1, the main breaking change is that you need to update some command to runyour app, check https://github.com/remix-run/remix/releases/tag/v0.20.0


Change retention policy to support incremental annotation processing

Aggregating annotation processors require annotations to have either
CLASS or RUNTIME as retention policy.

This appear to work, but incremental builds generate an incorrect output.
Let's consider assisted-inject-sample-android and:

add a copy of Greeter.java named GreeterCopy.java
build the project
change something in Greeter.java
build the project incrementally

At step 4, we will see the following:
warning: Assisted injection without at least one non-@Assisted parameter doesn't need a factory

If we look at the generated GreeterCopy_AssistedFactory.java, we will see that the parameters have lost their name.
I'm not sure what's causing this, GreeterCopy.class contains the name of the parameters and adding manually -parameters to JavaCompile has no effect.
All I know is that incremental builds do not work as long as the retention policy is SOURCE.

Also note that using CLASS allows third party annotation processors to generate code that use @Assisted to be incremental (see https://github.com/hansenji/ViewModelInject/pull/4#issuecomment-546611683)

Thanks!


secret in the repo

This blocks git commits
elharo@elharo1:~/java-docs-samples/automl/cloud-client$ commit "merge master"
iap/src/test/java/com/example/iap/BuildAndVerifyIapRequestIT.java:45:      "320431926067-ldm6839p8l2sei41nlsfc632l4d0v2u1.apps.googleusercontent.com";
[ERROR] Matched one or more prohibited patterns

@elharo Your saying that Github now has something that notices a service account being explicitly checked in?
(or was it our linter?)
I don't think that's a secret of any kind as it's not checked in with a SA key.
What's giving you the message?
What are you asking us to fix / change?

This happened in the CLI on my gLinux laptop when I tried to git commit my changes (which did not include this file). Never seen this message before.
As you say, it's probably not a problem but in that case we should figure out where this check comes from and turn it off.

see https://github.com/awslabs/git-secrets
I'm pretty sure I didn't install this myself but perhaps the gLinux maintainers did?

It's not installed on my Mac, nor are there any commit hooks in my version of J-D-S -- I looked. .git/hooks - just lots of samples.
I'm going to close this as it only applies to gLinux users.  Feel free to reopen if you disagree.

I am going to reopen this since it's not resolved.
I have established that yes, gLinux does install git secrets by default even though gMac doesn't so it's an issue for many developers here.
Two possibilities:

This should be a secret and it shouldn't be in the repo. I know in CT4E we went through some gyrations to avoid checking these things into our repo.

It's not a secret and we need to somehow configure this repo so it isn't recognized as such.

See "man git-secrets", section IGNORING FALSE POSITIVES:
   You can add regular expressions patterns to filter false positives
   to a .gitallowed file located in the repository's root directory.


Rename to carts

renaming all cart occurrences to carts.

Coverage remained the same at 64.639% when pulling 829aa66f4e1b7c9964ed0c89f69a2a7f2484219a on rename-to-carts into 39963b861c78f972b9d9a918c250fde90449f4c7 on master.


feat(icons): add clear parternship icon #199

Changes to be committed:
modified:   src/data/icons.json
new file:   src/icons/clear.svg
Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes: #199
Summary:
Please summarize the scope of the changes you have submitted, what the intent of the work is and anything that describes the before/after state of the project.
Added the clear icon in the icons database.
Type of change:

[x] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Delete .travis.yml

Pretty straight forward. /shrug
Closes #204

We might want to keep it for #201

heck

@erickzhao, is this so that we can run CI tests on the #201 stuff? We can do that with Netlify too.

@krubenok yep. If we can do it with Netlify sounds good to me.

https://www.netlify.com/docs/netlify-toml-reference/
Reference docs on the file here!  @loreina @erickzhao


Added consistency in build context

fixes #445

now it is broken other way around ;-)
▶ kompose --provider openshift convert --stdout -f compose-build-test/build.yaml | grep context
INFO Buildconfig using https://github.com/kadel/compose-build-test.git::master as source.
      contextDir: ./build

▶ kompose --provider openshift convert --stdout -f compose-build-test/context.yaml | grep context
INFO Buildconfig using https://github.com/kadel/compose-build-test.git::master as source.
      contextDir: compose-build-test/build

(same files as in #445)

This might be great case where you can try test driven development. ;-)
Try to write unit tests for this first. Than you can easily check if both things work.

@kadel , sure. it seems that its failing for first example

@kadel , it works for me :)
$ kompose convert --provider=openshift --stdout -f ex1/context.yml | grep context
INFO Buildconfig using git@github.com:surajnarwade/buildconfig_example.git::master as source.
      contextDir: ex1/build

$ kompose convert --provider=openshift --stdout -f ex1/build.yml | grep context
INFO Buildconfig using git@github.com:surajnarwade/buildconfig_example.git::master as source.
      contextDir: ex1/build

That is strange. I'm still getting the same error as in #445.
Maybe something is wrong on my side. I'll check it.
Anyways, can you please add unit tests for this? We should have unit tests that covers both scenarios  (build and context).

I agree that we should really add unit tests to this as Travis passed on this and should probably fail judging from @kadel and @surajnarwade 's errors

I haven't look at the code yet, but i tested it and it is still not working as it should.
for

this PR works for me:
✔ ~/tmp/buildcontextimproper [master L|✔]
12:19 $ kompose --provider openshift convert --stdout -f compose-build-test/build.yaml | grep -i context
INFO Buildconfig using https://mycode.com.git::master as source.
      contextDir: compose-build-test/build

and
✔ ~/tmp/buildcontextimproper [master L|✔]
12:25 $ kompose --provider openshift convert --stdout -f compose-build-test/context.yaml | grep -i context
INFO Buildconfig using https://mycode.com.git::master as source.
      contextDir: compose-build-test/build

my dir structure
✔ ~/tmp/buildcontextimproper [master L|✔]
12:25 $ tree
.
├── build
└── compose-build-test
    ├── build.yaml
    └── context.yaml

2 directories, 2 files

oops my bad I had docker-compose file with wrong build info so updated it and gave a correct relative path now
$ cat compose-build-test/build.yaml  | grep build
        build: "../build"

$ kompose --provider openshift convert --stdout -f compose-build-test/build.yaml | grep -i context
INFO Buildconfig using https://mycode.com.git::master as source.
      contextDir: build

and
$ cat compose-build-test/context.yaml  | grep build
        build:
            context: "../build"
$ kompose --provider openshift convert --stdout -f compose-build-test/context.yaml | grep -i context
INFO Buildconfig using https://mycode.com.git::master as source.
      contextDir: compose-build-test/build

@surajnarwade I'm getting this :(
$ kompose  convert --provider=openshift --stdout -f test/build.yaml
FATA [foo] Buildconfig cannot be created due to error in creating build context.

$ kompose  convert --provider=openshift --stdout -f test/context.yaml
FATA [foo] Buildconfig cannot be created due to error in creating build context.

@surajnarwade for me it fails like this:
I am here
✘-1 ~/tmp/buildcontextimproper/compose-build-test [master L|✚ 1]
18:23 $ pwd
/home/hummer/tmp/buildcontextimproper/compose-build-test

my dir looks like this
✔ ~/tmp/buildcontextimproper/compose-build-test [master L|✚ 1]
18:23 $ tree ..
..
├── build
└── compose-build-test
    ├── build.yaml
    └── context.yaml

2 directories, 2 files

I run this
✔ ~/tmp/buildcontextimproper/compose-build-test [master L|✚ 1]
18:23 $ kompose --provider openshift convert --stdout -f ../compose-build-test/build.yaml | grep -i context
FATA [foo] Buildconfig cannot be created due to error in creating build context.

docker-compose file looks like this:
✘-1 ~/tmp/buildcontextimproper/compose-build-test [master L|✚ 1]
18:23 $ cat ../compose-build-test/build.yaml
version: "2"
services:
    foo:
        build: "./build"
        command: "sleep 3600"

oh my bad again the build path was wrong in above example, it should be ../build not ./build, but the error was not very helpful!

@surajnarwade would recommend improving the error message if possible!

@surajssd @containscafeine , you are getting error because build directory you mentioned is not present there.

@surajssd , added error message

@surajnarwade
Still think your commit message could be improved:
fixes #445
Modified unit test cases
Added comments

Please elaborate on what's being changed / added and all :)

@surajnarwade Hi, in order for this to be more consistent with the comments in here, I'd advise to close this PR and create a new PR for just the vendor update as well as update your commit message.

cc @cdrage @surajssd @containscafeine

Files to review:

(openshift.go)[https://github.com/kubernetes-incubator/kompose/pull/454/files#diff-91f3ad308c13930dc408cd92991debea]

(openshift_test.go)[https://github.com/kubernetes-incubator/kompose/pull/454/files#diff-d138004ee5d369cc4ce608ebbee34753]

@surajnarwade You've mixed up the vendor update and the code being changed in the same PR. Please make this PR code-only and update the vendoring in a seperate PR or wait until https://github.com/kubernetes-incubator/kompose/pull/566 is merged.

@cdrage, vendoring and this code are interdependent, if we are going to put both things in separate PR, both are going to fail.

@surajnarwade They won't fail. We've got multiple PR's out there relying on the same vendoring being updated, thus why #566 was created.

@cdrage , I have split the PR into two separate commits for code and vendoring

@surajnarwade
You need to update your Git messages as well. They are blank for both.
git commit --amend

@cdrage done

cc @cdrage @kadel @surajssd @containscafeine

@surajnarwade as we talked you gonna add some functional tests to this before we merge this right?

@surajssd , yeah I am going to add few more unit test

@surajssd have a look

@surajssd @kadel done with changes


LoadGen should use Python 3

I think we have said it multiple times that only Python 3 is officially supported (e.g. here). Yet inference/loadgen/BUILD.gn has this on top:
# These can be overriden in the .gn file or via the "gn gen" command line.
declare_args() {
  py_include_dirs = [ "/usr/include/x86_64-linux-gnu/python2.7",
                      "/usr/include/python2.7" ]
  py_ld_flags = [ "-lpython2.7" ]
}

Moreover, build/config/linux/pkg-config.py is not Python 3 compatible, as can be seen in multiple prints without parentheses e.g.
    print "You must specify an architecture via -a if using a sysroot."

@briandersn please clean up.
Actually I always use python3 and there is no issue with the quick start steps at https://github.com/mlperf/inference/blob/master/loadgen/README.md

The setup.py approach to building the loadgen as a python module is compatible with python3.
The gn/ninja approach for building as a C++ library uses build files that assume python2. It'll require a bit of work to remove python2 as a dependency for the gn/ninja approach since I don't own the code in build/config. I'd really like to avoid fixing or re-implementing build/config.
As a compromise, I'll see if I can make it easy to provide a python2 path to gn/ninja if python3 is the system default. @psyhtest : would that be acceptable?
I will also update the REAMDE file so folks aren't surprised.

Alternatively, if we could add CMake bulid files - but I'm not familiar with CMake and would appreciate if someone else might be able to pick that up.
I imagine some folks already have CMake files of their own set up for internal use.

@briandersn Will have a look at providing CMakeLists.txt.

@briandersn Please check https://github.com/mlperf/inference/pull/239. I believe this should be sufficient to build LoadGen using tools that most people already have (e.g. CMake and make), without extra dependencies.

This work is completed.