New version 0.6.1

Codecov Report
Base: 39.17% // Head: 38.76% // Decreases project coverage by -0.41% :warning:

Coverage data is based on head (49afdd4) compared to base (1f260de).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #282      +/-   ##
==========================================
- Coverage   39.17%   38.76%   -0.42%
==========================================
  Files          92       92
  Lines        6096     6081      -15
==========================================
- Hits         2388     2357      -31
- Misses       3708     3724      +16

Impacted Files
Coverage Δ

algorithms/linfa-linear/src/float.rs
20.00% <0.00%> (-13.34%)
:arrow_down:

algorithms/linfa-nn/src/heap_elem.rs
0.00% <0.00%> (-10.00%)
:arrow_down:

algorithms/linfa-logistic/src/argmin_param.rs
41.17% <0.00%> (-8.83%)
:arrow_down:

...rithms/linfa-clustering/src/k_means/hyperparams.rs
27.08% <0.00%> (-6.25%)
:arrow_down:

...linfa-clustering/src/appx_dbscan/cells_grid/mod.rs
46.42% <0.00%> (-6.21%)
:arrow_down:

...orithms/linfa-clustering/src/optics/hyperparams.rs
20.58% <0.00%> (-5.89%)
:arrow_down:

algorithms/linfa-linear/src/glm/distribution.rs
54.90% <0.00%> (-5.89%)
:arrow_down:

algorithms/linfa-svm/src/classification.rs
42.10% <0.00%> (-5.27%)
:arrow_down:

src/composing/platt_scaling.rs
30.43% <0.00%> (-5.22%)
:arrow_down:

algorithms/linfa-pls/src/utils.rs
53.19% <0.00%> (-4.26%)
:arrow_down:

... and 52 more

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

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

This branch should not be merged


SHINIGAMI ID

Source information
Shinigami 1.4.58
Source language
Indonesia
Source new URL
https://shinigamitoon.xyz/
Other details
Change domain from https://shinigamitoon.app/ to https://shinigamitoon.xyz/
Acknowledgements

[X] I have updated all installed extensions.
[x] I have opened WebView and checked that the source URL has not changed yet.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I will fill out all of the requested information in this form.

Up sir


Automatically Bump Version of Project Using Dependabot

Hello! I have a use case I would like to describe and an initial proposal for addressing. Thank you in advance for reading and considering!
Use Case
I am using Dependabot to manage several projects. One of the problems or limitations that I run into is that Dependabot updates the version of dependencies but not the version of my projects. Some projects we would like to always generate a new version (usually a patch version) whenever we accept a dependency version bump.
Proposal
I think it would be very useful to enable Dependabot to increment the version of the project based on a handful of available strategies.
This could be accomplished via an additional input parameter called something like project-version-increment-strategy. If this value is not set, Dependabot does not attempt to update the version of the project it manages dependencies for.
Some simple strategies to start could be
major - update the major component of a Semver version
minor - updates the minor component of a Semver version
patch - updates the patch component of a Semver version
Other strategies could be created overtime to meet the needs of other projects.
Since I'm interested in this, I would be happy to work on contributing this idea, but would want to make sure this is in keeping with the direction and vision for Dependabot before starting.
Thanks again for reading and considering!

Duplicate of #2048?

Duplicate of #2048?

@buffcode sorry I didn't respond for a while. Got missed in the inbox.
I don't know if it is an exact duplicate - the other ticket seemed to be focused on NodeJs applications. This was a larger conversation about supporting a feature across all dependabot supported eco-systems.

@dangoslen so I implemented a pretty ugly hack around this using github actions, but it does work
jobs:
  setup:
    runs-on: ubuntu-20.04
    name: Setup
    steps:
      - name: git checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Get changed files
        id: changed_files
        if: github.event_name == 'pull_request' && contains(github.event.pull_request.labels.*.name, 'dependabot')
        uses<EMAIL_ADDRESS>        with:
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Check modified files
        id: check_modified
        if: github.event_name == 'pull_request' && contains(github.event.pull_request.labels.*.name, 'dependabot')
        run: |
          echo "::set-output name=version_modified::$(jq '. | contains(["actions-runner/VERSION"])' ${HOME}/files_modified.json)"

      - name: Increment version and changelog
        if: ${{ !steps.check_modified.outputs.version_modified && github.event_name == 'pull_request' && contains(github.event.pull_request.labels.*.name, 'dependabot') }}
        run: |
          SEM_VER=$(cat VERSION | awk -F. -v OFS=. 'NF==1{print ++$NF}; NF>1{if(length($NF+1)>length($NF))$(NF-1)++; $NF=sprintf("%0*d", length($NF), ($NF+1)%(10^length($NF))); print}')
          COMMIT_MSG=$(git log --format=%B -n 1 ${{ github.event.after }})

          # Write files
          echo $SEM_VER > VERSION
          sed -i "12i ## [${SEM_VER}]\n### Changed\n* ${COMMIT_MSG}" CHANGELOG.md

          # Add new git commit
          git add VERSION
          git add CHANGELOG.md
          git config --global user.name "dependabot[bot]"
          git config --global user.email<EMAIL_ADDRESS>          git commit -m "[Automated] Increment Version"
        working-directory: actions-runner

      - name: Push increment version commit
        if: ${{ !steps.check_modified.outputs.version_modified && github.event_name == 'pull_request' && contains(github.event.pull_request.labels.*.name, 'dependabot') }}
        uses<EMAIL_ADDRESS>        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          branch: ${{ github.head_ref }}

Maybe you can consider that previous decision @jurre? 🙏
Yes, we can do an action for it... although it really seems like one of those things that are easy to do in the core framework, but instead you rely on the community to build it - think lodash.

Closing, for the same rationale as explained in https://github.com/dependabot/dependabot-core/issues/2048#issuecomment-785972222.
We actually have this exact thing wired up internally within one of the repos that we use for running Dependabot natively at GitHub. Whenever we merge a PR to that repo, a GitHub action triggers which cuts a new release, and tags it with the date so that Dependabot is able to open a PR in downstream repo's that import from that first repo. We found it pretty straightforward to wire up.


Extension causes high cpu load

Issue Type: Performance
Extension Name: vscodeintellicode
Extension Version: 1.1.3
OS Version: Darwin x64 16.7.0
VSCode version: 1.31.0

@a-eid, can you attach the CPU profile file mentioned in the message? What language were you programming in when this happened?

VisualStudioExptTeam.vscodeintellicode-unresponsive.cpuprofile.txt
@jkeech javascript.

Thanks!
/cc @minestarks @uniqueiniquity

@a-eid, did this happen when you first opened a JS file? Was it the first time you used IntelliCode for JS files? I looked through the trace, and the bulk of the time (5s) is spent in the model downloading/caching component of the IntelliCode extension.
3.9s is spent in the actual model download. This should only happen during initial extension activation, then the cached model is loaded for future use. The whole model loading process only happens during extension activation, so it should not have a continual impact while you are editing. While the download is happening, you should also see a VS Code progress indicator in the bottom saying "Downloading IntelliCode models" with a progress update (you can briefly see it in the gif below):

I don't see any immediate ways to greatly reduce the cost here. Depending on your location, we could possibly reduce the time spent in network calls by having our models service and the model blobs themselves deployed to a region closer to you. I'd be interested to hear if this was a one-time issue or if this happens on every VS Code session. Thanks!

@jkeech yeah that might be it, thanks.


[3.2.x] Fixed #33338 -- Document and test @never_cache

Full title and issue link: Document that @never_cache and add_never_cache_headers() set the Expires header.
I wrote the documentation based on a link I found in staticfiles.txt: https://developer.yahoo.com/performance/rules.html#expires
And the docstring in http_date method
Please let me know any changes needed, thank you.

@mgaligniana  Thanks for this patch :+1: Please submit PR to the main branch, we will backport if needed.


dc-toast shows black border when animated

When using it with an animation to slide-in/slide-out the dc-toast shows an empty box with black border after the for example green box of the success toast is hidden.
This can be fixed applying the border style only to the success, error, etc... types like this:
.dc-toast__content {
border-style: none;
&--success,
&--info,
&--warning,
&--error {
border-style: solid;
}
}
@gabrielhl You can check this broken behaviour on the development and stage environments of the Solution Center when deleting a user for instance.

@dami-gg I've tried but can't see this. What browser are you using

We've already implemented the fix so it was too late now :)


CI testing of post install libraries

We need to ensure that functionality in the post installation libraries (after stripping etc.) is tested, as something could go wrong during that stage.

Installed package integrity is now tested nicely through optional GIT_SELF use in the relocatable src/examples tree.  The feature is there, which addresses the main concern of the original issue.  We could use this at some point in the future for CI testing if we want to spend the CPU cycles.


Transient initialization causes CUDA runtime error

I have an SDFG that computes neighbor reduction. The issue is related to initialization of the transient scalar used for reduction. The SDFG works on CPU device, this issue is only on GPU.
The SDFG is included in a PR, see tests/codegen/neighbor_reduction_test.py
This is the GPU runtime error:
E   cupy_backends.cuda.api.runtime.CUDARuntimeError: cudaErrorLaunchFailure: unspecified launch failure

cupy_backends/cuda/api/runtime.pyx:144: CUDARuntimeError

The issue is related to initialization of a transient scalar. If I remove the initialization with the below diff:
diff --git a/tests/codegen/neighbor_reduction_test.py b/tests/codegen/neighbor_reduction_test.py
index d75e1621a..b07a406e1 100644
--- a/tests/codegen/neighbor_reduction_test.py
+++ b/tests/codegen/neighbor_reduction_test.py
@@ -34,12 +34,7 @@ def build_sdfg_neighbor_reduction(sdfg_name: str):
     nsdfg.add_scalar('_input_weight_idx', dace.int32)
     nsdfg.add_scalar('_acc', dtype, transient=True)
     nsdfg.add_array('_result', (1,), dtype)
-    istate = nsdfg.add_state(is_start_block=True)
     nstate = nsdfg.add_state()
-    nsdfg.add_edge(
-        istate, nstate,
-        dace.sdfg.InterstateEdge(assignments={'_acc': '_result[0]'})
-    )
     me_red, mx_red = nstate.add_map('neighbors', dict(_neighbor_idx=f"0:{N_E2V_NEIGHBORS}"))
     nsdfg.add_scalar('_field_idx', dace.int32, transient=True)
     field_idx_node = nstate.add_access('_field_idx')

the program will run on GPU (however validation of the result will fail, of course).
The SDFG above uses an inter-state edge assignment to initialize the reduction scalar. I have also tried to initialize it with a tasklet within the init state, but I saw the same error.
Can you please check if there is anything wrong in my SDFG, or if this is a bug in CUDA-codegen?

I am not sure that this is a DaCe issue, and it is not blocking any work.


[KYUUBI #1634][FEATURE] Redact secret information from SparkSQLEngine UI

Why are the changes needed?

SparkSQLEngine's Kyuubi UI tab shows SQL statements. In some cases, these informations are secret information like S3 access/secret key. Spark SQL UI tab already redact with spark.redaction.string.regex configuration. Kyuubi also should redact secret informations with this property.
How was this patch tested?

[X] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[X] Add screenshots for manual tests if appropriate
with below property and query:
spark-defaults.conf:

spark.redaction.string.regex (?i)url|access.*|secret.*|password

query:
SET fs.s3a.access.key=testkey

[X] Run test locally before make a pull request

Codecov Report

Merging #1640 (cb8721f) into master (2af105a) will increase coverage by 1.27%.
The diff coverage is 58.13%.

:exclamation: Current head cb8721f differs from pull request most recent head c84778e. Consider uploading reports for the commit c84778e to get more accurate results

@@             Coverage Diff              @@
##             master    #1640      +/-   ##
============================================
+ Coverage     58.32%   59.60%   +1.27%
- Complexity      164      193      +29
============================================
  Files           260      264       +4
  Lines         12930    13081     +151
  Branches       1633     1650      +17
============================================
+ Hits           7542     7797     +255
+ Misses         4756     4625     -131
- Partials        632      659      +27

Impacted Files
Coverage Δ

...g/apache/kyuubi/engine/flink/result/Constants.java
0.00% <0.00%> (ø)

...org/apache/kyuubi/engine/flink/schema/RowSet.scala
50.00% <24.24%> (+36.13%)
:arrow_up:

.../apache/kyuubi/engine/flink/FlinkEngineUtils.scala
29.41% <29.41%> (ø)

...rg/apache/kyuubi/engine/flink/FlinkSQLEngine.scala
42.10% <42.10%> (ø)

...apache/kyuubi/server/api/v1/SessionsResource.scala
77.17% <66.66%> (+0.50%)
:arrow_up:

...yuubi/engine/flink/FlinkEngineProcessBuilder.scala
75.90% <75.90%> (ø)

...ain/scala/org/apache/kyuubi/engine/EngineRef.scala
86.00% <87.50%> (+1.05%)
:arrow_up:

.../apache/kyuubi/engine/flink/result/ResultKind.java
100.00% <100.00%> (ø)

...e/kyuubi/engine/flink/FlinkSQLBackendService.scala
100.00% <100.00%> (ø)

...uubi/engine/flink/operation/ExecuteStatement.scala
80.64% <100.00%> (+12.90%)
:arrow_up:

... and 28 more

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 2af105a...c84778e. Read the comment docs.

Thanks, merging to master


Upgrade RxJava version to 2.x

As RxJava went to EOF, is there any plan this package will upgrade to RxJava 2.x ? Below is from RxJava README.
As of March 31, 2018, The RxJava 1.x branch and version is end-of-life (EOL). No further development, bugfixes, documentation changes, PRs, releases or maintenance will be performed by the project on the 1.x line.

Hi @Incarnation-p-lee we are planning an upgrade to RxJava2. That is planned for early 2019.
this is a duplicate of https://github.com/Azure/azure-cosmosdb-java/issues/28

@moderakh
Sorry for missing the existed one. So I will close this issue and track the status from #28


Disentangling

Disentangling neighbors_convert.so from libtorch by this https://github.com/spozdn/pet/commit/e4fca34330a418c7587e504ee3983c2745da3302
as discussed earlier.

📚 Documentation preview 📚: https://metatrain--298.org.readthedocs.build/en/298/

This seems to contain a duplicate version of https://github.com/lab-cosmo/metatrain/pull/295. Could you rebase your branch on top of main to only include new changes?

upd. It looks like I started from the wrong state. It should have been only last commit, instead of the current 4. So I am closing this pr.


DotNetCoreCLI@2 with command=publish ignores "projects" argument and selects arbitrary wrong csproj instead

Required Information
Question, Bug, or Feature?
Bug
Enter Task Name:
DotNetCoreCLI@2
Environment

Server - Azure Pipelines or TFS on-premises? Azure Pipelines
If using Azure Pipelines, provide the account name, team project name, build definition name/build number: https://skype.visualstudio.com/DefaultCollection/SCC/_build?definitionId=9928&_a=summary
Agent - Hosted or Private: Private, Windows 10, 2.169.1

Issue Description
My YAML says this:
      - task: DotNetCoreCLI@2
        displayName: .NET Core publish
        inputs:
          command: publish
          projects: xxx.sln
          arguments: --configuration Release
          workingDirectory: $(projectRoot)

When I run the build, the task runs the command D:\a_work\_tool\dotnet\dotnet.exe publish D:\a_work\321\s\xxx\DevPlayer\DevPlayer.csproj --configuration Release
My expectation was something along the lines of: D:\a_work\_tool\dotnet\dotnet.exe publish D:\a_work\321\s\xxx\xxx.sln --configuration Release
Notably, the project file is completely wrong. The task seems to entirely ignore the value I enter in the projects parameter and always pick this "DevPlayer" project for whatever reason (which is part of my solution, but not the only project in there). My goal is to publish all .NET Core projects in the solution.
Also tried various alternatives for projects value, with no difference.
Is the task just overwriting my projects variable without a care in the world? See https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/DotNetCoreCLIV2/dotnetcore.ts#L351
Yes, that seems to be.  Even if technically by design, this is a big UX defect.
Task logs
Logs with debug output accessible here for MSFT users: https://skype.visualstudio.com/DefaultCollection/SCC/_build/results?buildId=38531869&view=logs&j=518a43f1-9e9c-5e03-8567-3796dcbb14f5&t=bcc15253-5413-56d2-ed86-472e79afb69b&l=33568
I see the correct (?) inputs in the log at the start:
2021-01-09T15:46:33.5151370Z ##[debug]command=publish
2021-01-09T15:46:33.5153840Z ##[debug]projects=middle-lane.sln
2021-01-09T15:46:33.5156064Z ##[debug]arguments=--configuration Release
2021-01-09T15:46:33.5157945Z ##[debug]publishWebProjects=true
2021-01-09T15:46:33.5159347Z ##[debug]zipAfterPublish=true
2021-01-09T15:46:33.5161395Z ##[debug]workingDirectory=D:\a_work\321\s\xxx

But immediately after that the task seems to start some search for csproj files starting from my repo root:
2021-01-09T15:46:33.5472384Z ##[debug]pattern: '**/*.csproj'
2021-01-09T15:46:33.5492855Z ##[debug]findPath: 'D:\a_work\321\s'
2021-01-09T15:46:33.5493710Z ##[debug]statOnly: 'false'
2021-01-09T15:46:33.5494191Z ##[debug]findPath: 'D:\a_work\321\s'
2021-01-09T15:46:33.5494743Z ##[debug]findOptions.allowBrokenSymbolicLinks: 'false'
2021-01-09T15:46:33.5495325Z ##[debug]findOptions.followSpecifiedSymbolicLink: 'true'
2021-01-09T15:46:33.5495886Z ##[debug]findOptions.followSymbolicLinks: 'true'

Hi @sandersaares, this is expected behavior.
the projects input is valid only when publishWebProjects  is false. See this. The help text of publishWebProjects  input is also helpful in understanding its behavior.
Not all task inputs are relevant in every case. When building a YAML pipeline, the valid inputs and their help texts can be seen through the show assistant  button.

Below are the various options for publish once you enable show assistant

Hi @sandersaares, this is expected behavior.
the projects input is valid only when publishWebProjects  is false. See this. The help text of publishWebProjects  input is also helpful in understanding its behavior.
Not all task inputs are relevant in every case. When building a YAML pipeline, the valid inputs and their help texts can be seen through the show assistant  button.

Below are the various options for publish once you enable show assistant

Let me know if you have any questions.

Let me know if you have any questions.

I do not have any questions. I understand how the task operates. This feedback is intended to emphasize that the way the task operates is problematic and difficult to understand. I recommend the task be redesigned without this "modality".

I do not have any questions. I understand how the task operates. This feedback is intended to emphasize that the way the task operates is problematic and difficult to understand. I recommend the task be redesigned without this "modality".

@sandersaares makes sense. I'll escalate this to the PM and see what can be done. Thanks for the feedback :)

@sandersaares makes sense. I'll escalate this to the PM and see what can be done. Thanks for the feedback :)

We wasted couple of hours on this. The way this works is just absurd. If we provide projects property, why would it go and try to find web projects on it's own? We literally specify what to publish.
publishWebProjects and projects are mutually exclusive properties, but because publishWebProjects is true by default, this whole thing just breaks down.
publishWebProjects should be false by default, and should be ignored if projects is specified.

@biiiipy Agreed. I am increasingly concerned about how the DotNetCoreCLI@2 processes commands. Me and my team just wasted hours trying to get dotnet restore to work with arguments. The restoreArguments property didn't work and neither did arguments. Beyond this, it's crazy to me that restoreArguments was created to begin with. Every other command accepts arguments.
The code behind this feels like spaghetti.

I just spent several aggravating hours investigating the same issue. Very glad to find this issue and understand how to resolve it. Very unhappy that this was an issue from the get go.
Very poor design. If anything the projects property should take precedence over the publishWebProjects property.
In fact, I dont understand the need for the publishWebProjects property at all. In my mind a publishStartupProject would make more sense for a more generic design.

Tasks should be able to infer intent by what is being directly invoked. If any setting default is made invalid by a direct CLI command, the command should take precedence without you needing to know the setting exists at all.
Otherwise, you have read the documentation on the task and check every setting default to see if it conflicts with your args every time you add or update a command.

how we can pass project(s) names dynamically ?
I tried passing xx.csproj  with spaces it is not accepting


fix bench and add example script

Summary of changes
Changes introduced in this pull request:

add sample benchmarking script,
remove caching that was behaving funny and producing lots of errors. Probably will need to find an alternative or a proper fix if it becomes a kind of bottleneck.

Reference issue to close (if applicable)

Other information and links

remove caching that was behaving funny and producing lots of errors. Probably will need to find an alternative or a proper fix if it becomes a kind of bottleneck.

Can you share CI runs exhibiting this please? I'd like to take a look.

Hi @fenollp. I didn't notice this happening in the CI but on a fresh VPS when building all of the images. Interestingly, when trying to build a single image, it would succeed. My wild guess is that there is some kind of a race condition, though it's just speculation.
Here's the error log from my machine (Fedora 36, though I had the same issue on a Ubuntu 22.04 VPS).
cache_error.txt

Indeed the unexpected EOF issues seem to be related to BuildKit's BUILDKIT_INLINE_CACHE=1.
I've found a couple issues on their bugtracker around these symptoms with merged PRs as the outcome.
Can it be that you're running an older docker engine? Latest is: https://docs.docker.com/engine/release-notes/#201018
Note: removing these cache directives should make build jobs run longer (in theory. I see the actions in this PR seem to run pretty fast anyway).
Yeah, no idea what's going on here really. It'd be nice to have a reproducer to send to BuildKit. In any case it seems harmless to drop these directives. Doing so though I'd suggest removing the code that pushes the docker images as well, as these are of no use anymore.

@fenollp Thanks for looking into it! I believe I am using a quite recent docker release, 20.10.18. I can't say I fully get what is happening. Issuing a bug for buildkit seems like a good idea, I may do that later!

@fenollp By the way, would you like to be added to the repo collaborators? No pressure of course! I believe it's only fair after your outstanding contributions. :)

Yes, sure :)


sep: differentiate the age and ledger gap components of the observation period O

right now O is describing the observation period in the SEP, but that value can be set by two fields that have different values/types:
	ObservationPeriodTime      time.Duration
	ObservationPeriodLedgerGap int64

differentiate the variable so that it isn't referring to different values

this paragraph explains the O period well now. So closing this.
The observation period is defined both as a duration in time, and a count of
ledgers. The observation period has passed if both the duration and ledger count
have been exceeded. These two properties together are referred to as O
throughout the protocol.


feat: Support all OP Stack components

Is your feature request related to a problem? Please describe.
Currently, the alternative implementations of OP Stack components, apart from op-erigon and asterisc, cannot take advantage of the superchain registry. This creates a sharded collection of chain configurations, where components like op-reth, magi, hildr, op-besu, op-nethermind, cannon-rs, the Rust FPP, and whatever comes in the future that isn't written in Golang, cannot take advantage of this package.
Describe the solution you'd like
Modularize the superchain registry such that it can be used by all OP Stack components, preparing for a future where our critical infrastructure is implemented in many more languages than just Go.
Ideally, this means defining a core implementation, preferably in a language such as C, C++, or Rust that is more friendly for interop, and then creating FFI bindings that enable several front-end APIs to be built for the library.
We currently need support for:

Java
Rust
C#

Describe alternatives you've considered

Implement separate versions of the superchain-registry repository for each language that the OP Stack's core components are built upon. This would require a decent bit of duplicated code, increasing the possibility of divergent configuration between the implementations.
Create FFI bindings from the Go implementation. Go does not lend itself well towards being called via FFI, and Cgo is a bit horrendous to work with when the direction is <language> -> Go rather than Go -> <language>. It requires cbindgen to embed Go types and semantics into the C header, etc. Rather than doing this, we should choose a more FFI friendly language that is closer to C (or, even C/C++ itself) for the base implementation.

Additional context
Modularizing the superchain registry will pay dividends in the future, offering a central, interoperable library for every OP Stack component to share the same configuration utilities.

Before diving into building sharable code, we should review how we approach configuration.  It's usually better to have a well defined config file format so that each client can then parse it using its own code rather than needing to embed a shared library.  I'm not sure of the details of why we've got specific go code in this repo and it may be the right option  but we should evaluate the options for making config available to alternate clients and not just dive into building reusable code.

I'm not sure of the details of why we've got specific go code in this repo

To have have a form that we can read and validate the configuration consistency of. E.g. address-format (checksums), completeness (missing references), and bytecode hashing are all tested with Go. And then it's better to expose the struct types publicly, so we do not have to duplicate them in the optimism monorepo or op-geth software.

This doesn't have to be repeated for every language. As long as the raw config files can be embedded into the destination program of choice, then we don't need complete bindings.
And these configs are not particularly performance-sensitive, we just need to keep the total data reasonably small (hence the bytecode deduplication and compression), to not blow up the binary size of op-stack applications.
One approach to configs for all languages might be to expose just minimal bindings that expose the config as embedded filesystem (i.e. just a simple read-function by filepath). That way we can do releases/versioning of native package, but don't have to opinionate bindings or create types for every language. This might be as simple as defining a package definition file, that then exposes the config files as importable data (like in JS).
Or alternatively, if the programming language of choice already can import a git repo efficiently and elegantly as dependency by git release tag, then we don't need any bindings for it at all.

Which approaches will we choose?

Can we add Solidity support here as well?  It may be worth integrating the registry on the contract level.


🐞 @media and @supports doesn't transform | to

Description
Incorrect and valid: hidden@supports(transform-origin:5%_5%)
Correct and invalid: hidden@supports(transform-origin:5%|5%)
Reproduction
No response
System Informations
macOS

Released at v2.0.0-beta.151

🎉 Released in https://github.com/master-co/css/releases/tag/v2.0.0-beta.160


Feedback for Oppo page

https://github.com/urbandroid-team/dont-kill-my-app/issues/570#issue-1591622470


compiler warnings (GCC 12 binutils 2.39) on Linux

Building dhcpcd 9.4.1 wih GCC 12.2.0 and binutils 2.39.90 on Debian/Linux produces the attached compiler warnings.
dhcpcd5_9.4.1-12_i386_build.txt

Can you post the content of config.log pertinent to finding arc4random please?
Looks like it's been added to glibc but configure is not finding it.

config.log

config_log.txt

Can you test the commit on the above branch to see if it fixes your issue please?

This is what I get after applying the above.
config_log_2.txt
build_log_2.txt

I've added some more commits to the branch. It should now compile without any warnings.
Can you test it please?

What I get after applying the 3 other patches:
build_log_3.txt
config_log_3.txt

Great, all looks good now, thanks for testing.

When compiling 9.4.1 on an earlier Debian release (GCC 10.2.1 and binutils 2.35.2), with the above 4 patches applied, I also get this warning:
ipv6nd.c: In function ‘ipv6nd_open’:
ipv6nd.c:230:3: warning: unsigned conversion from ‘int’ to ‘uint32_t’ {aka ‘unsigned int’} changes value from ‘-65’ to ‘4294967231’ [-Wsign-conversion]
230 |   ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &filt);

So that means the earlier Debian release shipped with a buggy header as  ICMP6_FILTER_SETPASS and ND_ROUTER_ADVERT are defined by the system.
I went out of my way to clear if-linux.c of warnings from other system headers such as NLMSG and RTA macros when using clang, but I do have to draw the line somewhere.


Previous Scholars tips helps Aspirants.

For the scholarship section, connect to the previous scholars and ask them to give tips. It would be helpful for the viewers/aspirants.
I think my article for WTM Scholarship helps.
(https://medium.com/@sudeepa.kolli/google-wtm-apac-scholarship-2020-9dabe5ddf052).
wtmdoc.docx

@SudeepaNoble That's a great idea. Would you like to take up this issue?
You could create a separate page for the scholar's medium articles and link it to the original README.md

@SudeepaNoble That's a great idea. Would you like to take up this issue?
You could create a separate page for the scholar's medium articles and link it to the original README.md

Sure, I'll do that!


Updates language for both design indexes under Engineering.

This PR updates the language for both design freezing index and design thawing index under Engineering.
Closes #180

I missed adding the size class to the design thawing index, thanks for catching that!


Revert "Warn about singleton being a Reference"

Reverts godotengine/godot#43682
Closes #43783.
P.S. This is my first "Revert" PR. 😃 😕

Superseded by #43788 and #43789.


fix: move all the rfds into an specific rfd folder.

Description
Move all the RFDs folders into an specific rfd so the links from the main page can work and for better organization.
Motivation and Context
Fix and Organize.
How Has This Been Tested?
N/A
Screenshots (if appropriate):
N/A
Types of changes
N/A
Checklist:
N/A

Could you describe what kind of links from the main page we're talking about? I don't see anything mentioning RFD at the top level readme at the moment, and I'm confused to as why adding an additional level makes a difference.

@fargozhu the new paths have double rfd, why do you need that?

ping @fargozhu

yes so we can "tool" around like: updating the RFD landing page when a new RFD is pushed and some other automation processes.

Wouldn't that already be possible, since all RFDs were in a subdirectory already? It's unclear to me why we needed the extra directory (and in fact, we currently appear to have extra directories inside extra directories).


Critical error: Assertion failed: Index >= 0 (from LatentPromise.cpp:138) v1.10.3

Application crashes in a cooked build (sometimes). Crash rate is ~80%.  I might have done something wrong, though...
UE5Coro version: tag v1.10.3
UE:
Version: 5.4.4-35576357+++UE5+Release-5.4
Platform: Windows 10 (22H2) [10.0.19045.5011] (x86_64)
[2024.10.11-17.48.19:877][430]LogWindows: Error: === Critical error: ===
[2024.10.11-17.48.19:877][430]LogWindows: Error:
[2024.10.11-17.48.19:877][430]LogWindows: Error: Assertion failed: Index >= 0 [File:D:\build\++UE5\Sync\Engine\Source\Runtime\CoreUObject\Public\UObject\UObjectArray.h] [Line: 868]
[2024.10.11-17.48.19:877][430]LogWindows: Error:
[2024.10.11-17.48.19:877][430]LogWindows: Error:
[2024.10.11-17.48.19:877][430]LogWindows: Error:
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff663b8a4f8 game.exe!FUObjectArray::AllocateSerialNumber() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff663bcffaf game.exe!FWeakObjectPtr::operator=() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66b69721f game.exe!`anonymous namespace'::FPendingLatentCoroutine::FinishNow() [E:\Unreal Projects\CatGame2\Plugins\UE5Coro\Plugins\UE5Coro\Source\UE5Coro\Private\LatentPromise.cpp:138]
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66b6978ba game.exe!`anonymous namespace'::FPendingLatentCoroutine::UpdateOperation() [E:\Unreal Projects\CatGame2\Plugins\UE5Coro\Plugins\UE5Coro\Source\UE5Coro\Private\LatentPromise.cpp:111]
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff669486088 CatGame2.exe!FLatentActionManager::TickLatentActionForObject() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff6694641ff CatGame2.exe!FLatentActionManager::ProcessLatentActions() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff669482f1d game.exe!UWorld::Tick() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff6691d57b9 game.exe!UGameEngine::Tick() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66a8363da game.exe!FEngineLoop::Tick() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66a84e72c game.exe!GuardedMain() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66a84e7fa game.exe!GuardedMainWrapper() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66a8513c5 game.exe!LaunchWindowsStartup() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66a8616a4 game.exe!WinMain() []
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007ff66f87bbd6 game.exe!__scrt_common_main_seh() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
[2024.10.11-17.48.19:877][430]LogWindows: Error: [Callstack] 0x00007fffeafc7374 KERNEL32.DLL!UnknownFunction []

The reason is probably in code like this:
FAsyncCoroutine UMyGameInstance::ServerTravel_C(FString Map, bool bListen,
                                                FForceLatentCoroutine Latent) {
	if (UGameplayStatics::GetCurrentLevelName(GetWorld()) != Map) {
		co_await Async::MoveToGameThread();
		auto WorldLoaded = LaunchDelegateCoroutine(this, FCoreUObjectDelegates::PostLoadMapWithWorld);
		GetWorld()->ServerTravel(Map + (bListen ? "?listen" : ""), true);
		co_await WorldLoaded;
	}
	co_return;
}

This coroutine changes world and CallbackTarget becomes deleted. Though, there is no reason to register this coroutine with world context since game instance outlives the world.

This seems to be addressed in v2.0, but I have to use 1.10.3 due to compatibility with clang.

Thank you for the bug report.

This coroutine changes world

Ouch. Yes, that's not handled well by UE5Coro 1 (see #22, #23), and fixing it required substantial changes that went far beyond the scope of a theoretical v1.11. Because of that, I'm inclined to treat this as a wontfix for v1 specifically, but I'd like your input before doing so. Maybe there's a low-hanging fruit somewhere, or this could be a separate, independent bug that I'm too hasty to consider a duplicate.

This seems to be addressed in v2.0

Thank you for testing this.

due to compatibility with clang.

There are a few things that you can try to work around your current situation. Your coroutine doesn't look particularly latent to me, so I'd first suggest not forcing it to latent mode. There's a good chance you'll be able to fix it right away. Since you'll be losing "latent this protection", the coroutine should look more like the left example here and work with a TWeakObjectPtr<UMyGameInstance> instead of this. This removes pretty much all world access by UE5Coro itself, and your code can get it right. Make sure to avoid latent awaiters in this case, too!
Alternatively, you can remove the LlvmTrap() from v2.0 at your own peril, if you're absolutely sure that none of your lambdas are affected by bug that it refers to. Other than this, things are relatively stable with Clang; v2.0 was mainly developed on it before MSVC was fixed!
The trap is mainly there for user safety, because behavior will silently change between compilers. Ironically, the Clang bug provides a better user experience in this case than what C++20 mandates :)

Thank you, yes, I ended up changing coroutine to be not latent and it works, but I'll consider removing llvmTrap.

I'm glad that you managed to get it to work. Since this is already fixed in 2.0, I'll close this one.


Add support for pydantic v2

Thanks for your next contribution @fdroessler ! 🏅

@fdroessler I had to revert this change and Kedro-Viz is not compatible with pydantic v1 yet, due to the transitive dependency via FastAPI <0.96.0 https://github.com/kedro-org/kedro-viz/blob/240ff6e2f25e1e90f73e799564d417f54c34f1c6/package/requirements.txt#L4


fixed osm logo

Signed-off-by: Aditya Chatterjee<EMAIL_ADDRESS>Description
osm icon was incorrectly named which was causing it to have a broken icon on the extension.
This PR fixes #
Notes for Reviewers
Signed commits

[ ] Yes, I signed my commits.

Thank you.


fix: building in release mode for simulator

Summary
Fixes #29984
Right now, running a React Native application with Xcode 12 in Release mode on an iPhone Simulator will fail with something like below:

[some file path], building for iOS Simulator, but linking in object file built for iOS, file '[some file path]' for architecture arm64

The best explanation of this issue has been provided by @alloy in #29984:

This issue has started coming up with Xcode 12 and support for the new ARM based Macs, as arm64 now no longer can be assumed to only be for iOS devices. This means Xcode 12 will now also build for arm64 simulator SDKs and it has become ambiguous if an arch slice in a prebuilt binary is meant for a simulator or device.
In any case, for now this means that you can configure your Xcode project to exclude arm64 when building for any iOS simulator SDK.

This PR implements aforementioned workaround.
Changelog
[FIX] [IOS] - Fix running React Native project with Xcode 12 in Release on iPhone Simulator
Test Plan
Switch your scheme to Release and run the app on simulator. Will complete w/o issues.

I'm on an M1 MacBook Mini and if I add arm64 to excluded architectures I'm getting this error right at the beginning of the build:
Module map file '/Users/.../Library/Developer/Xcode/DerivedData/MyApp-bmibskzjfhlxbsblspkqkqtndyjb/Build/Products/Debug-iphonesimulator/YogaKit/YogaKit.modulemap' not found

It seems that running the build through Rosetta via arch -x86_64 react-native run-ios does work though, but there's a glitch with momentum scrolling, which seems like a bug when arm64 slices are missing according to this report:
https://developer.apple.com/forums/thread/668488
It also feels relatively slow, as if it runs on the simulator via rosetta x86 simulation rather than being native ARM.
So, how do we build for the simulator and keep the arm64 arch?

The error in the previous comment seems to go away if I change the deployment target to 11.0 from 10.0 (as per: https://github.com/facebook/react-native/issues/29605#issuecomment-701920944) but then I got this which is related to Flipper:
In /Users/andreialecu/Work/.../ios/Pods/OpenSSL-Universal/ios/lib/libcrypto.a(cryptlib.o), building for iOS Simulator, but linking in object file built for iOS, file '/Users/andreialecu/Work/.../ios/Pods/OpenSSL-Universal/ios/lib/libcrypto.a' for architecture arm64

Seems like I needed to manually edit the Pods project to add arm64 to its excluded architectures as well and then it works.
However, the glitch with momentum scrolling remains because of the missing arm64 slice. And the app in the simulator is pretty janky because of it.

Also note that I'm not even attempting to run in Release mode, just Debug -> but I felt the PR was relevant.

I was able to get an arm64 build working on the M1 Mac that works in the iOS simulator by adding this in the Podfile.
Also needed to disable Flipper.
  # Enables Flipper.
  #
  # Note that if you have use_frameworks! enabled, Flipper will not work and
  # you should disable these next few lines.

  #use_flipper!
  post_install do |installer|
    #flipper_post_install(installer)

    installer.pods_project.targets.each do |target|
      target.build_configurations.each do |config|
        config.build_settings.delete 'ARCHS'
        config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
        config.build_settings['ONLY_ACTIVE_ARCH'] = 'YES'
      end
    end
  end

I'm not sure if this also works on non-M1 Macs, but it would be something to try.

Upon further experimentation it seems the Podfile changes above may not be necessary except for disabling Flipper. I was not able to get Flipper to work.
One other change I needed to do was to remove LIBRARY_SEARCH_PATHS from my project.pbxproj:
@@ -1007,11 +1017,6 @@
                                GCC_WARN_UNUSED_VARIABLE = YES;
                                IPHONEOS_DEPLOYMENT_TARGET = 10.0;
                                LD_RUNPATH_SEARCH_PATHS = "/usr/lib/swift $(inherited)";
-                               LIBRARY_SEARCH_PATHS = (
-                                       "\"$(TOOLCHAIN_DIR)/usr/lib/swift/$(PLATFORM_NAME)\"",
-                                       "\"$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)\"",
-                                       "\"$(inherited)\"",
-                               );
                                MTL_ENABLE_DEBUG_INFO = YES;
                                ONLY_ACTIVE_ARCH = YES;
                                SDKROOT = iphoneos;
@@ -1060,11 +1065,6 @@
                                GCC_WARN_UNUSED_VARIABLE = YES;
                                IPHONEOS_DEPLOYMENT_TARGET = 10.0;
                                LD_RUNPATH_SEARCH_PATHS = "/usr/lib/swift $(inherited)";
-                               LIBRARY_SEARCH_PATHS = (
-                                       "\"$(TOOLCHAIN_DIR)/usr/lib/swift/$(PLATFORM_NAME)\"",
-                                       "\"$(TOOLCHAIN_DIR)/usr/lib/swift-5.0/$(PLATFORM_NAME)\"",
-                                       "\"$(inherited)\"",
-                               );
                                MTL_ENABLE_DEBUG_INFO = NO;
                                SDKROOT = iphoneos;
                                VALIDATE_PRODUCT = YES;

I'm not sure if the above was part of the RN default template or not, but with it I was running into weird problems with Swift Pods.
Also needed to manually add a Swift Bridging Header to the main project.
Now the app properly runs on the M1 simulator in ARM mode and it's responsive and fast.
The main takeaway is that I think you should really consider whether disabling arm64 is the proper solution to this problem, because it may have unintended consequences on the M1 macs.

@andreialecu Thanks for all the feedback! To be clear, this is absolutely it meant as the long term solution, but as a workaround to still being able to release 0.64 without further delay and serve the common case out of the box (those without ARM based macs). Longer term the solution is to switch to producing xcframeworks artefacts instead.

@alloy I noticed this was recently merged: https://github.com/facebook/flipper/pull/1735 and it seems like a fix for the same problem. Unfortunately I don't have an Intel Mac any more to test it.

Yup, just saw that too. I’ll see how I can best test/verify that.

I was able to update Flipper to the one containing the fix via:
use_flipper!('Flipper-Folly' => { :podspec => 'https://raw.githubusercontent.com/facebook/flipper/master/iOS/Podspecs/Flipper-Folly.podspec' } )

Analyzing dependencies
Fetching podspec for `Flipper-Folly` from `https://raw.githubusercontent.com/facebook/flipper/master/iOS/Podspecs/Flipper-Folly.podspec`
Downloading dependencies
Installing Flipper-Folly 2.3.0
Installing OpenSSL-Universal 1.1.171 (was <IP_ADDRESS>)
Generating Pods project
Integrating client project

However, linking on the M1 still fails, but now with a different dependency:
in .../ios/Pods/CocoaLibEvent/lib/libevent.a(buffer.o), building for iOS Simulator, but linking in object file built for iOS, file '.../ios/Pods/CocoaLibEvent/lib/libevent.a' for architecture arm64

CocoaLibEvent seems to also be a dependency of Flipper:
https://github.com/facebook/flipper/blob/031cec299b527975cd1e252177372bb33cb0ae18/iOS/Podspecs/Flipper-Folly.podspec#L20
https://github.com/e314521/CocoaLibEvent
I'm not very familiar with pods or xcode in general so I'm not sure why the lib is incompatible or how it can be fixed.
The Flipper PR thus seems incomplete.

Basically, Flipper fix was to exclude arm64 as we are doing in this PR. As a result, the error started happening in the next library after it.
I am going to double check the if statement and let's ship this PR for broader testing.


Search box within select2 not working in Firefox

I've noticed that the select2 inputs are not working correctly in Firefox (OS: Linux). The select2 search box is not writable despite it's not specified as disabled nor readonly.
No problem with Chrome though.
You can check it out here in the code where we have this problem:
https://jsfiddle.net/luis_apuyen/9f3t5b5g/
In order to see it, open any of these tabs:
1- "pedidos" / "presupuestos" / "albaranes" / "facturas",
2- next click on "agregar", and a modal pops up,
3- check the select input below "Transportistas", and the second to last. Both work in Chrome, but you won't be able to type anything in FF.

This sounds like an issue with Bootstrap's modal stealing focus away.
Check out https://github.com/select2/select2/issues/600#issuecomment-102857595 for an easy fix.

I am having the same issue; however, I don't see an explanation related with the Bootstrap's modal stealing the focus away or how to solve it. Not sure why this issue was closed.

only remove tabindex="" from model

remove tabindex=""

You should just be able to set dropdownParent: https://select2.org/troubleshooting/common-problems

Check if your Jquery is the lastest and do the same for your select2.
i change my jquery to the 3.4.1 and it worked.

only remove tabindex="" from model div id="stack1" class="modal fade" tabindex="" role="dialog" aria-hidden="true" data-focus-on="input:first"
remove tabindex="" div id="stack1" class="modal fade" role="dialog" aria-hidden="true" data-focus-on="input:first"

Not worked in Firefox.


[BEAM-732] Only remove Elements that were pending from Pending Elements

Be sure to do all of the following to help us incorporate your contribution
quickly and easily:

[ ] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[ ] Make sure tests pass via mvn clean verify. (Even better, enable
Travis-CI on your fork and ensure the whole test matrix passes).
[ ] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

Update the comparator so elements will only be removed from the
collection of pending elements if they were formerly added. This ensures
that elements cannot be removed if a timer delivery has an identical
timestamp to them.

R: @kennknowles
CC: @dhalperi
This should fix the flakyness in jenkins. 2500 runs on my desktop don't reproduce the flake with this change.

LGTM pending green


PublishSymbols Task and Functional Breakpoints

I'm pretty sure this is nothing to do with the PublishSymbols task but I though I'd ask anyway. We have the following:
VSTS Private Build Agent
Shared Drive Using Azure File Storage to hold symbols
PublishSymbols step to publish to Shared Drive
Visual Studio 2017 Enterprise configured to use the same Shared Drive as Symbol Server
If I set a breakpoint and step into some code which we have symbols for it correctly finds them and then uses the symbol file to download the source.; this work fine (it's pretty cool as I'm newish to this).
However if I set a functional breakpoint to code that's been indexed at the sametime of the previous one the breakpoint is but I get the No Source Page in Visual Studio.
Does anyone know the expected behaviour here ? Should hitting the functional Breakpoint download the source like stepping into the debugger ?

I am not sure what you mean by functional breakpoint.  Can you provide some additional details?

Thanks for responding @chrisrpatterson , I got this mostly working in the end by sharing the symbols with our machines via Azure Storages (Files), although for some reason the class I wanted to see the source for just isn't there. Pretty much everything else is from the same assembly. It's really odd but I'll close this I think.


Middle-ground for wrapping function/macro arguments

A lot of the assert! calls in my code are just too long to fit on a single line, but that "tiny first and last argument, big middle one" structure produces a lot of wasted space for tall layouts.
assert!(1 == 1,
        "12345678901234567890123456789012345678901234567890123456789012345678{}",
        901);

In my Python programs, I resolve this sort of issue by using a word-wrap-esque style like this:
assert!(1 == 1,
        "12345678901234567890123456789012345678901234567890123456789012345678{}", 901);

...or, in rare situations when the above isn't any better, like this...
assert!(1 == 1, "1234567890123456789012345678901234567890123456789012\
<PHONE_NUMBER>345678{}", 901);

For asserts of the form "Failed to foo. Got {}", it also has the benefit that the variable name is right next to the substitution placeholder, rather than requiring a full-width visual CRLF.
In Rust, it's annoying to have to throw out rustfmt's attempts to change these every time I run it and it'd be nice if there were some kind of layout option which left them intact.

cc https://github.com/rust-lang-nursery/fmt-rfcs/issues/86


[general] Support for VS 2017

Currently embeddinator does not support the usage of VS 2017 which is included in the newest CppSharp version. There are some bugs I'll list here which have to be fixed.

[ ] fix compilation option for VS 2017
[x] fix build script for generating VS 2017 solutions (I'll make a PR as soon as possible)
Further bugs can appear. Stand by.

The compilation for VS2017 fails due to that the path of cl.exe is wrong.
For getting the correct one a additional dependency (which is already included in the newest CppSharp version) is needed. Whether we should use it must be discussed. What do you think @tritao ?

Compilation also can fail earlier when you choose VS2017 in parameter, it fails in Embeddinator-4000\binder\Compilation.cs on line 721 when you have multiple instances of Visual Studio 2017 (e.g. I have Enterprise and Enterprise Preview but you can have even different editions on the same computer)

We actually had great progress towards VS 2017 compatibility.

But solving VS 2017 compatibility is my keyword, I already handled this for CppSharp @michalkovy 😄

Think this one is solved now


Feature: liveServer option should be reactive

Hi, I'm having one more issue:
Updating liveServer via dataLiveServer option has no effect even when re-instantiating the object. For context, I'm using this when the component is mounted and/or dataLiveServer prop changes:
init() {
      if (!this.id) {
        console.error("AucompleteInput requires an id attribute.");
        return;
      }

      const opts = {
        onSelectItem: this.onSelectItem,
        fullWidth: true,
        suggestionsThreshold: 2,
        liveServer: this.dataLiveServer
      };

      const element = document.getElementById(this.id);

      const obj = new Autocomplete(element, opts);

      if (this.dataLiveServer) {
        console.log('should suggest!');
      }
      else {
        console.log('should not suggest!');
      }
      console.log('element: ', element);
      console.log('object: ', obj);
      console.log('options: ', opts)
    },

Component will remain completing or not completing results based on the initial state of liveServer option. I guess all options should be reactive.

@guifsdev if you create a new instance, it should work well. i'm not sure what you mean by "re instantiating" ?
data attributes are only read when creating the instance. if you change them, simply dispose/create it and you should be fine.

or use setConfig
in the current way it's built, data attributes are not meant to be reactive. Maybe something nice for a future version or a custom element or something ;-)


Cannot close the window if open the url in electron

Cannot close the window while opening the code server url in electron
Steps to Reproduce

start a code server
open the code server url from  as a new window in electron
the window close button is useless

The problem is onbeforeunload(return or returnValue) hook not work as usual in eletron


How to wait on read or write with Async?

Back before this crate was split from smol, there used to be a with method which would wait for either a readable or writable event.
This method was deprecated even then, and nowadays there is only read_with and write_with.
Is there any alternative way to do the equivalent?
My use case is that I am trying to update the async-ssh2 crate, which tries to provide an async wrapper around the libssh2 C library. My fork can be found here.
This C library provides a non-blocking interface. When using this interface, when you make calls to async functions, they may return LIBSSH2_ERROR_EAGAIN indicating that you should call back again later when the underlying socket is ready. The problem is you don't know if it is waiting for a read or a write - it could be either depending on the state of the protocol.
The original code, which was written against smol 0.1, used the above mentioned 'with' method, and appeared to work. It was doing something like this:
    let res = stream
        .read(|_s| match cb() {
            Ok(v) => Ok(Ok(v)),
            Err(e)
                if io::Error::from(ssh2::Error::from_errno(e.code())).kind()
                    == io::ErrorKind::WouldBlock =>
            {
                Err(io::Error::new(io::ErrorKind::WouldBlock, e))
            }
            Err(e) => Ok(Err(e)),
        })
        .await??;

where cb is a callback that is calling a libssh2 function that may return LIBSSH2_ERROR_EAGAIN (which is converted to an io::Error of kind WouldBlock).
I am trying to update it to depend on async-io directly. I've replaced the calls to read with calls to read_with or read_write, but it ends up hanging at various points. I suspect the reason is that the C function wants to write from within read_with or vice versa.
Sorry for the convoluted explanation ... hopefully it makes sense.

In the end I have replicated more or less the same logic as was in the original with method for this.
                        let readable = stream.readable();
                        let writable = stream.writable();
                        futures_util::pin_mut!(readable);
                        futures_util::pin_mut!(writable);
                        let (ready,_) = future::select(readable, writable).await.factor_first();

Initially I was having problems with I/O operations hanging, which I (incorrectly) attributed to this issue, however I since discovered that there were other issues causing that.
I imagine this is not a common use case, so probably no need to add anything to the API.

In the end I have replicated more or less the same logic as was in the original with method for this.
                        let readable = stream.readable();
                        let writable = stream.writable();
                        futures_util::pin_mut!(readable);
                        futures_util::pin_mut!(writable);
                        let (ready,_) = future::select(readable, writable).await.factor_first();

Initially I was having problems with I/O operations hanging, which I (incorrectly) attributed to this issue, however I since discovered that there were other issues causing that.
I imagine this is not a common use case, so probably no need to add anything to the API.


Revert "[Exposing ALTS Context 2/2] Provide a Utility Function to Get Context"

Reverts grpc/grpc#21196
This breaks the import process.
cc_proto_library doesn't exist internally, and that's why we have wrappers for these functions.

Hi @nicolasnoble @AspirinSJL
I've created a patch PR: https://github.com/grpc/grpc/pull/21302 to fix this issue and am working on manually testing it. That being said, feel free to merge this revert PR if you think it is needed and I will resubmit a new one after confirming everything works fine.

Looks like there are still some errors after the patch. Feel free to proceed with this reverting. Thanks!


Activity log is not captured if modifications are done to enroll or unroll of projects done on a CLA Group

Activity log is not captured if modifications are done to enroll or unroll of projects done on a CLA Group
Breadcrum of the group: HOME / THE LINUX FOUNDATION / A-FEB-10 MULTI LEVEL PROJECTS / TOOLS / CLA / OVERVIEW
url: https://admin.staging.platform.linuxfoundation.org/apps/cla/overview#id=a097c000007oIh7AAE
Please find attached video for more information as follows:
https://images.zenhubusercontent.com/194341141/cfc70f44-2d6b-4d73-8fb9-f3873296200e/recording__119.mp4

@manishv09  based on the videos you shared .. upon a manual refresh activity log is showcased. so this happens to be a UI issue that should auto refresh upon enroll/unenroll events
cc @vinod-kadam @dealako

PR link https://github.com/LF-Engineering/admin-console/pull/678
cc: @dealako @vinod-kadam

Created PR: https://github.com/communitybridge/easycla/pull/2725

Verified on DEV and Staging both but still the activity log is not appearing for enroll and unenroll. Even after manual refresh log is not updated. Please refer attached video for reference.
https://images.zenhubusercontent.com/194341141/c1361667-7b9f-4d85-9a8e-f1114cb712b4/2716_02032021.mp4

@manishv09 I have now migrated the activity log data. Can you please re-test?

Actually, still testing - new indexes are deploying...

Deployed to PROD through https://github.com/communitybridge/easycla/releases/tag/v2.0.5.


please close this issue

1026142198
f98db.md
retain above haste : relax and kill yourself Winning nothing
Eight-ton-off-to no pay learn-Be grateful to yah cheese madden hastes

md make it cue

[f98db] md this one
A star pink fabulous doing aft See yah


Don't mark crossing paths of different layers as a problem

Title says it all, I think. I added a path on top of an underground path, and it was marked as a problem and I was asked if I wanted to connect them. They obviously can not connect since one is underground and the other is not :) The underground path was labeled as layer=-1, and the top one as layer=1.
Link to the place: https://ideditor.netlify.app/#background=geovekst-nib&disable_features=boundaries,rail&id=w-6&map=19.28/59.91377/10.78802
Thanks!

What the system is implying is that one or other path should be a bridge or tunnel.
For buildings, tunnel=building_passage is an option. highway=corridor and indoor=yes is another option.
PS. At that location, is it correct that a cycleway is connected directly to steps?


Removing broken page alias.

@fermujica Removing page alias temporarily to get build working again.

Thanks @sleslie23.
This was caused by my PR: https://github.com/mulesoft/docs-connectors/pull/394
Trying to fix https://github.com/mulesoft/docs-connectors/commit/f3d0b6d56c1f33e974d6b0150f18139e10bbf187
and not testing against the docs-release-notes module.
I assumed the original author removed this page from release-notes and declared the page-aliases incorrectly.


UI x-axis as days since first assessment instead of count of assessments

Consider changing the x-axis so that it is the time since the first assessment for the student. This is a more consistent scale, but the "average" will need to become a best-fit function.

see data_prep.py line 53 ?

looking to instead use age


typo fixed and js min updated

also added the missing color parameter in on change event

Thx!
I'll push up a version number.


DEV: Stop using FoundUserWithStatusSerializer

⚠ Do not merge, Core changes with new API hasn't merged yet

We probably need a discourse compatibility entry too no?

We probably need a discourse compatibility entry too no?

Yeah, that's right. I was going to add it after we merge the Core PR.


Migrate Metadata Service Auth Tests to auth_permutation_test.go Framework

Changes
This PR migrates tests covering the metadata service to auth_permutations_test.go. This ensures that the test configuration is dumped for these tests and can be used to autogenerate test cases for auth in other SDKs.
One noteworthy point: this PR adds a Client field to config.Config. This is exposed for testing and allows us to mock the responses to HTTP requests made during authentication.
This PR adds the following fields to configFixture:

AssertHeaders: A set of headers expected to be set on the http.Request. This allows us to verify that the correct Authorization header (and potentially other headers, depending on auth type) are set.
HTTPFixtures: when set, the test framework will start a local webserver and pass the client into the Config struct. The client will respond using the provided API mocks.
MetadataServiceURL: sets the corresponding field on Config. If HTTPFixtures is supplied, the URL authority is replaced by that of the local server.

Tests

[x] make test passing
[x] make fmt applied
[ ] relevant integration tests applied

Closing this out as won't do.


feat(css): Implement css helper with callback

What kind of implementation is this?
The callback mechanism used in Suspense and ErrorBoundary is used to insert the class name.
It is primarily targeted to be used in JSX components, but can also be used in html tag functions.
It does not depend on jsxRenderer.
Pros

It does not depend on jsxRenderer, so you can use any pattern you like.
In environments where initialization does not occur with every request, It works very fast because CSS is not recalculated when class names are predefined globally.

Cons

The mechanism is complicated because the string is always a Promise<string> and callback must be properly called to obtain the final result. (However, if you use c.html(), you do not need to be aware of this complexity.)
Allowing Promise in the class attribute may confuse some linters (e.g. https://github.com/honojs/hono/issues/1812 ).

https://github.com/honojs/hono/compare/feat/css-helper...usualoma:hono:feat/css-helper?expand=1#diff-eea0d4f8a89b330f26eea854ef087c7d92cfca29268164f8ee315f770e4be7e8L26-R26

Demo
import { Hono } from './src'
import { jsx, Fragment } from './src/jsx'
import { Suspense } from './src/jsx/streaming'
import { jsxRenderer } from './src/middleware/jsx-renderer'
import { css, Style } from './src/helper/css'

const app = new Hono()

app.get(
  '*',
  jsxRenderer(
    ({ children }) => {
      return (

Hello!

Hello!

Hello!
<template id="H:1"></template>
Loading...
<template>
Hello!
</template>

https://github.com/honojs/hono/assets/30598/bf08ddb6-9dd3-40a2-9c22-2bba255001ff
Author should do the followings, if applicable

[x] Add tests
[x] Run tests
[x] yarn denoify to generate files for Deno

Hey @usualoma !
This is cool! This implementation can cover all use cases!

The mechanism is complicated because the string is always a Promise<string> and callback must be properly called to obtain the final result.
Allowing Promise in the class attribute may confuse some linters.

I think these are acceptable. Using Promise and callback is the only way I can think of to do it, so that's fine. My one concern is the complexity of the implementation, but I think the css feature is worth it.
As you mentioned this commend: https://github.com/honojs/hono/pull/1850#issuecomment-1869259251, I think we have to implement pseudo-elements, pseudo-selectors, and @keyframes.
I tried it and found one problem: with stream turned off, the style tag is empty when accessed a second time.
https://github.com/honojs/hono/assets/10682/902b9aa4-65f8-49fd-a214-748d25d3b358

@yusukebe Thank you for your comment!

I tried it and found one problem: with stream turned off, the style tag is empty when accessed a second time.

Ah, there was one parameter missing. Fixed in dd92903
https://github.com/usualoma/hono/pull/4 has been merged with this PR.
So, can we proceed to work on this PR, writing tests and tidying up the code so that we can merge it into #1850?

@usualoma

So, can we proceed to work on this PR, writing tests and tidying up the code so that we can merge it into #1850?

Yes, please!

@yusukebe Improved CSS helper by fd2ea73 and 5f0ba8b
How about this?
Changes
Pseudo selectors
There's both good news and bad news.

Bad News: The selector for pseudo-elements using '&' has been removed due to its overly complex implementation.
Good News: Pseudo-elements using '&' are now almost universally supported by browsers.

caniuse.com/css-nesting

I believe that we should start with a small release as an MVP (Minimum Viable Product) to evaluate its value. Therefore, if it works in the latest browsers, it would be a wise choice to consider it not supported here.
createCssContext()
Default css and Style are also provided, but you can create your own using createCssContext() if you want to use them in a context separate from this one.
The test code will show you how to use it.
https://github.com/honojs/hono/pull/1858/files#diff-b13e9a99ad47b9364486431c602062116158762edc7a647fa557b8c80a76774cR181-R203
escape variable
Variables embedded in ${} are now escaped. This is the same as html
${'(><;) crying...
 being escaped, which is a satisfactory specification in the hono. However, I feel a little uneasy about the difference from there, since it seems that styled-components does not escape.
css`
    animation: 1s ${animation} ease-in-out;
    background-color: green;
    color: white;
    padding: 1rem;
    transition: opacity 0.1s ease-in-out;

    &::after {
      margin-left: 1rem;
      content: "${`I'm a hono!`}"; // will be escaped
    }

    &:hover {
      opacity: 0.5;
    }
  `

Embed sub css
This was added in the last e4ceb1e. This feature allows a very large possibility to generate CSS programmatically.
Nevertheless, it may be overkill. I think we can revert this commit if it is not needed.
const FizzBuzz = () => {
  const list = [...Array(20)].map((_, i) => i + 1)
  const className = css`
    ${list.map((n) => {
      const fizz = n % 3 === 0
      const buzz = n % 5 === 0
      return css`
        :nth-child(${n}):after {
          margin-left: 1rem;
          content: '${fizz && buzz ? 'FizzBuzz' : fizz ? 'Fizz' : buzz ? 'Buzz' : ''}';
        }
      `
    })}
  `

  return (

      {list.map((n) => (

{n}

      ))}

  )
}

app.get('/', (c) => {
  return c.render(<FizzBuzz />)
})

@usualoma
I'm trying to use it now. Please wait a moment!

An immediate, responsive LIKE button without JavaScript (delayed, maybe debouncing and then sending the pressed count via JS) I think it's interesting stuff, but I think there are only a limited number of situations where it has value.
https://github.com/honojs/hono/assets/30598/3594d4e1-6dc3-49ee-be7b-b6ec812dada2
const LikeButton = () => {
  const list = [...Array(100)].map((_, i) => i + 1)
  const animations: Promise<String>[] = [
    keyframes`
    // even
    0% {
      transform: scale(1);
    }
    50% {
      transform: scale(1.2);
    }
    100% {
      transform: scale(1);
    }
  `,
    keyframes`
      // odd
      0% {
        transform: scale(1);
      }
      50% {
        transform: scale(1.21);
      }
      100% {
        transform: scale(1);
      }
    `,
  ]

  const className = css`
    font-size: 30px;
    position: relative;
    display: inline-block;
    label {
      position: absolute;
      width: 100%;
      height: 100%;
    }
    input {
      display: none;
    }
    span {
      pointer-events: none;
      position: relative;
    }
    ${list.map(
      (n) => css`
        input#id-${n}:checked ~ label[for='id-${n}'] {
          pointer-events: none;
        }
        ${[...Array(n)].map(() => 'input:checked ~').join(' ')} span {
          &:after {
            animation: 0.3s ${animations[n % 2]} ease-in-out;
            border-radius: 50%;
            background: red;
            color: white;
            position: absolute;
            font-size: 10px;
            display: inline-block;
            min-width: 13px;
            text-align: center;
            top: -10px;
            right: -10px;
            padding: 3px;
            content: '${n}';
          }
        }
      `
    )}
  `

  return (

      {list.map((n) => (
        <input id={`id-${n}`} type='checkbox' />
      ))}
      {list.map((n) => (
        <label for={`id-${n}`} />
      ))}
      👍

  )
}

app.get('/', (c) => {
  return c.render(<LikeButton />)
})

The following patch is required to execute the above code.
commit 33d158734c8e0ea412703e2e7bb9bf0067c9e5fd
Author: Taku Amano<EMAIL_ADDRESS>Date:   Wed Dec 27 18:00:39 2023 +0900

    fix(css): propagate selector to parent class

diff --git a/src/helper/css/index.ts b/src/helper/css/index.ts
index 00ede444..c0cdcf17 100644
--- a/src/helper/css/index.ts
+++ b/src/helper/css/index.ts
@@ -4,6 +4,8 @@ import type { HtmlEscapedCallback, HtmlEscapedString } from '../../utils/html'
 type CssClassName = HtmlEscapedString & {
   isCssClassName: true
   styleString: string
+  // eslint-disable-next-line @typescript-eslint/ban-types
+  selectors: String[]
 }

 type CssEscaped = {
@@ -108,6 +110,7 @@ const buildStyleString = async (
         styleString += ` ${value.substring(11)} `
       } else {
         if ((value as CssClassName).isCssClassName) {
+          selectors.push(...(value as CssClassName).selectors)
           value = (value as CssClassName).styleString
         } else if (!(value as CssEscapedString).isCssEscaped && /([\\"'\/])/.test(value)) {
           value = value.replace(/([\\"'\/])/g, '\\$1')
@@ -138,7 +141,6 @@ export const createCssContext = ({ id }: { id: Readonly<string> }) => {
     const selectors: String[] = []
     const styleString = await buildStyleString(strings, values, selectors)
     const selector = new String(toHash(styleString))
-    selectors.push(selector)

     const appendStyle: HtmlEscapedCallback = ({ buffer, context }): Promise<string> | undefined => {
       const [toAdd, added] = contextMap.get(context) as usedClassNameData
@@ -179,7 +181,7 @@ export const createCssContext = ({ id }: { id: Readonly<string> }) => {
       }
       const [toAdd, added] = contextMap.get(context) as usedClassNameData
       let allAdded = true
-      selectors.forEach((className) => {
+      ;[selector, ...selectors].forEach((className) => {
         if (!added.has(className)) {
           allAdded = false
           toAdd.set(className, true)
@@ -196,6 +198,7 @@ export const createCssContext = ({ id }: { id: Readonly<string> }) => {
       isEscaped: true,
       isCssClassName: true,
       styleString,
+      selectors,
       callbacks: [addClassNameToContext],
     })

@@ -213,6 +216,7 @@ export const createCssContext = ({ id }: { id: Readonly<string> }) => {
       isEscaped: true,
       isCssClassName: true,
       styleString,
+      selectors: [],
     })
     return className
   }

Oh, I just remembered that I need to write one thing.
I'll leave Embed sub css for once and talk about the rest of the implementation.
The current implementation could be better, so I'm sure there are more efficient ways to use memory and minify. However, these improvements can only be made after we decide this feature is worthwhile. We believe the current implementation is of sufficient quality to be tested as an MVP.

For whom is this a feature?
I think this is a feature not only for CSS guru but also for design tool guru who are not familiar with CSS. This feature can be used when exporting components from design tools.
https://github.com/honojs/hono/assets/30598/8fc459ca-ac24-48f3-a4d0-cb01dea19871

Nevertheless, I am not sure if this is the scope of the issue that hono should cover. I think some would argue that we should concentrate on smaller areas only.

Hi @usualoma
Super cool ramen example! I love it!
Please give me some time to continue to try it out.
I have tried to rewrite pages created with Tailwind CSS using hono/css. It is very user-friendly. Greate. For example, I wrote the following code:
import dayjs from 'dayjs/esm'
import relativeTime from 'dayjs/esm/plugin/relativeTime'
import { css } from 'hono/css'
import { createRoute } from 'honox/factory'
import Time from '../../components/time'
import { findArticleById } from '../../db'
import { parseMarkdown } from '../../utils'

dayjs.extend(relativeTime)

const articleClass = css`
  background-color: #fff;
  padding: 1.5rem;
  margin-bottom: 1rem;
  border-radius: 0.5rem;
  box-shadow: 0px 4px 8px rgba(0, 0, 0, 0.1);
`

const titleClass = css`
  color: rgb(31 41 55);
  font-weight: 800;
  font-size: 2rem;
`

export default createRoute(async (c) => {
  const { id } = c.req.param()
  const article = await findArticleById(c.env.DB, id)

  if (!article) {
    return c.notFound()
  }

  const parsedContent = parseMarkdown(article.content)

  return c.render(

{article.title}

          <Time created_at={article.created_at}>{dayjs(article.created_at).format('YYYY-MM-DD HH:mm:ss')}</Time>

  )
})

The interesting thing is we can make it a variable and make it a component, or we can make it a utility class like Tailwind CSS. We can also write css directly in the class attribute. This would be very useful when creating web pages in Hono.

Please give me some time to continue to try it out.
👍

Several bug fixes have been pushed.

@usualoma
How can we mixin class names, like this in HTML?

Hello!

For example, allow an attribute to have Promise<string>[] as its value?
const classH1 = css`
  font-size: 2rem;
`

const classTitle = css`
  color: blue;
`

app.get('/', (c) => {
  return c.html(


QueryBuilder count with subquery and having

Example:
We have 2 tables: bills, payments
Bills table:

id

1
2
3

Payments table:

id
bill_id
sum

11100
21200
3250

We want to count bills with payments.sum > 100.
I decided to do it like so:
```php
\DB::table('bills')
    ->selectSub(
        \DB::table('payments')
            ->whereColumn('bill_id', 'bills.id')
            ->selectRaw('sum(sum)'),
        'current_sum')
    ->having('current_sum', '>', 100)
    ->count()
```
As a result I had an Exception:
```
Column not found: 1054 Unknown column 'current_sum' in 'having clause' (SQL: select count(*) as aggregate from `bills` having `current_sum` > 0)
```
`count` method in `Query\Builder` just removed my subquery, which is obviously incorrect.
Am I doing smth wrong?

Found PR for this: #9307

Thanks for getting in touch. Closing this in order to move further discussion to the PR.


Number format integer translated to double

Hi,
I'm using NSwagStudio to translate YAML to C# Client, and found that the number format integer is still translated to double:
Here is the YAML Spec:
TotalRecords:
type: number
format: Integer
I have downloaded the latest version of NSwagStudio. Can you please advise if this is a bug or it needs to be configured somewhere?
Thanks
Julius

This is essentially a wrong spec, ie the type must be "integer"
https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema/JsonObjectType.cs#L32
Not sure whether we should handle this "wrong" spec in your expected way:
https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema.CodeGeneration.CSharp/CSharpTypeResolver.cs#L97
and here
https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema.CodeGeneration.TypeScript/TypeScriptTypeResolver.cs#L106

Hi Rico
Thanks for the clarification. I will ask the provider to change their YAML spec. If they don’t want to change the spec, is there any recommended workarounds?
Thanks
Julius
From: Rico Suter<EMAIL_ADDRESS>Sent: Wednesday, 10 June 2020 7:30 AM
To: RicoSuter/NSwag<EMAIL_ADDRESS>Cc: julznygit<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [RicoSuter/NSwag] Number format integer translated to double (#2880)
This is essentially a wrong spec, ie the type must be "integer"
https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema/JsonObjectType.cs#L32
Not sure whether we should handle this "wrong" spec in your expected way:
https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema.CodeGeneration.CSharp/CSharpTypeResolver.cs#L97
and here
https://github.com/RicoSuter/NJsonSchema/blob/master/src/NJsonSchema.CodeGeneration.TypeScript/TypeScriptTypeResolver.cs#L106
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/RicoSuter/NSwag/issues/2880#issuecomment-641592463 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AP4TJR74GYMXTDWLTWKAZGLRV2SV3ANCNFSM4NZC2DKQ .  https://github.com/notifications/beacon/AP4TJR2HNMBL4RFBVI3DOFDRV2SV3A5CNFSM4NZC2DK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEY66ZDY.gif

If they don’t want to change the spec, is there any recommended workarounds?

Preprocess the spec so that it fits the generator expectations...


Update Docs

Fills the guild id fields in example payloads with a valid snowflake (lavalink server id) so that it's possible to more easily copy/paste them when writing unit tests.
Also added the user data field to tracks

Actually, leave this open. When I get around to implementing the REST API, I may need to change those docs too.


QUESTION Theme customization

Is there a place to post an offer for a web developer who would be willing to create a TastyIgniter theme based on a HTML template?

Yes, the forums or slack:
https://forum.tastyigniter.com
https://app.slack.com/client/T115HEDFS
Again, please close of this issue as it does not relate to a bug


Need to add a setup.py install script

It's better now with simplified default.conf.template and a requirements.txt


Ensure publicPath is always absolute

Fixes #1141.
Implements the changes discussed here to ensure that publicPath/process.env.REACT_STATIC_PUBLIC_PATH is always absolute.
This also address the issue with the getRoutePath utility, ensuring it strips basePath when it's present.

mmh. I also get these failing specs locally, on master - so I had believed they would pass here.. Apparently not. The latest commit to master is green so that's puzzling.

The tests that are failing might be failing because the configuration that is received is bigger. It doesn't look too bad. Travis was down for a while, so that might explains the green check.
@jviotti can you checkout this PR and see if YOUR configuration works with it?
@nddery I will do the same for our projects. If the three of us (we all have different configurations) have working projects in both DEV and PROD, we can fix the tests and merge this and do a release.

Had another look - and the tests that we're failing here were different than the ones I was seeing locally on master 🤦♂. Updated one of the per my changes and pushed - tests now passes!
To be clear, this PR only fixes the publicPath issue - I still had to update my static.config.js to use path.resolve() for all my route.template - would you see the next release as 8.0.0 (breaking change) ?

To be clear, this PR only fixes the publicPath issue - I still had to update my static.config.js to use path.resolve() for all my route.template - would you see the next release as 8.0.0 (breaking change) ?

Yes, unless we can fix that, so it's not longer a breaking change.

@nddery do you think we can make this non-breaking? If not I will test this this weekend and merge it if possible and do a release.

@SleeplessByte do you mean this PR introduce another breaking change or are you referring to the one from https://github.com/react-static/react-static/pull/1253#issuecomment-513891203 ? If you're referring to this PR could you please clarify as I'm not aware of any breaking change here.

@nddery  https://github.com/react-static/react-static/pull/1253#issuecomment-513891203 indeed!

Sorry for the delay @SleeplessByte; I took time-off since the last PRs I sent. Has this been released to NPM already? I'll give it a shot and see if it works for me.

@SleeplessByte It seems to work fine for me!

@jviotti not on npm yet !

@SleeplessByte I ended up testing it from the tip of master directly, and it seemed fine to me

How close are we to releasing to NPM?

@alexjfno1 hours

@SleeplessByte Am I correct in thinking that it's not yet on npm? The changelog still lists this issue under #master, and npm refers to a last publish two months ago - or am I looking at the wrong thing?

You're correct. It's super close. See the release pr! 7.2.0
There are two issues left to fix:
Some weird load error with chokidar which I can not figure out why it
happens and builds hanging without running with the --debug flag.
On 2019-08-17 16:56, Vincent wrote:

@SleeplessByte [1] Am I correct in thinking that it's not yet on
npm? The changelog [2] still lists this issue under #master, and npm
refers [3] to a last publish two months ago - or am I looking at the
wrong thing?
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [4], or mute the
thread [5].
Links:
[1] https://github.com/SleeplessByte
[2]
https://github.com/react-static/react-static/blob/master/CHANGELOG.md
[3] https://www.npmjs.com/package/react-static
[4]
https://github.com/react-static/react-static/pull/1272?email_source=notifications&email_token=AAO7SWEX3EOFWPZXTRHN64TQFAGTXA5CNFSM4IIBUUN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QNE5Q#issuecomment-522244726
[5]
https://github.com/notifications/unsubscribe-auth/AAO7SWFJOGH6ZHCYUQB7NKTQFAGTXANCNFSM4IIBUUNQ


How to add a endpoint on Bot

I want to add a callback endpoint on Bot. How can i achieve this ?

There's no generic support for callbacks yet, and currently none planned, but you could write a Go plugin for this. When gopherbot starts the connector or does a reload, it calls each plugin with the command "init". In the processing for init, you'd check to see if your http listener is already running (in the case of a reload), and then fire off a goroutine with the bot object that would create a listener.

i created listener on main.go like this:
go func() {
		http.Handle("/metrics", handler)
                http.ListenAndServe(":8080", nil)
	}()

İs this a bad practice ? Should i really need a plugin for this?

I don't have any problem with this, if it works for you. The main reason to do it in a plugin would be getting the robot object from init, and storing it so you could later use one of the "Send*Message" methods, and also to store stuff in the brain, etc. If you're just adding the listener in main, how is your handler interacting with the robot?

I understand what you mean but i don't interact with bot directly. So it works for me this way. Thanks for reply.


isRecyclable decremented below 0

I'm testing the Checkbox Sample you have through my own app (we have essentially the same code). It works fine without animators, but as soon as I add one (ie FadeIn), I start receiving the following error:
isRecyclable decremented below 0: unmatched pair of setIsRecyable() calls for ViewHolder{1534c69 position=2 id=102, oldPos=-1, pLpos:-1}
The checkbox toggle still works, but it also seems to call the animation used for adding an object rather than simply setting the checkbox to checked or unchecked. Do you have any insight on this?
Here is the fragment used to implement this; it's essentially the same as your sample activity, apart from the itemanimator

@AllanWang the isRecycleable error comes from the RecyclerView the FastAdapter itself nor the IItem interface do not makr the items as recycleable or not. That's all handled by the RV itself

I think that's an issue caused by the animation you use. Please head over there. (you can also try the ItemAnimators library from me, perhaps it is different)

I found the solution and am linking it here in case someone stumbles across it while using FastAdapter
The solution was to add
if (oldHolder == newHolder) {
    // Don't know how to run change animations when the same view holder is re-used.
    // run a move animation to handle position changes.
    return animateMove(oldHolder, fromX, fromY, toX, toY);
}

in animateChangeImpl

Thanks for adding this info :)


DXCDT-218: Allow empty fields through pointers

Description
There are some fields that are unable to be explicitly set to empty when making requests. This occurs with fields that are tagged with omitempty in their struct definitions; the system has no way to differentiate between explicitly empty and omitted. This shortcoming has been frequently logged as an issue in the Terraform provider repo, cataloged here. This PR attempts to completely rectify this inability by setting the field types to pointers. By doing so, we introduce a tertiary state that we can use to distinguish between omitted and explicitly empty values.
⚠ Note: These changes introduce breaking changes! However, the intention is for this to be one of the last breaking changes before v1.
References

Related issue in auth0/terraform-provider-auth0

Testing

[ ] This change adds test coverage for new/changed/fixed functionality

Checklist

[x] I have read and agreed to the terms within the Auth0 Code of Conduct.
[x] I have read the Auth0 General Contribution Guidelines.
[ ] I have reviewed my own code beforehand.
[ ] I have added documentation for new/changed functionality in this PR.
[ ] All active GitHub checks for tests, formatting, and security are passing.
[ ] The correct base branch is being used, if not main.

Codecov Report
Base: 95.16% // Head: 95.29% // Increases project coverage by +0.13% :tada:

Coverage data is based on head (c589491) compared to base (7765c8b).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #113      +/-   ##
==========================================
+ Coverage   95.16%   95.29%   +0.13%
==========================================
  Files          37       37
  Lines        5792     5954     +162
==========================================
+ Hits         5512     5674     +162
  Misses        226      226
  Partials       54       54

Impacted Files
Coverage Δ

management/client.go
85.96% <ø> (ø)

management/client_grant.go
86.66% <ø> (ø)

management/connection.go
68.02% <ø> (ø)

management/hook.go
91.42% <ø> (ø)

management/log_stream.go
80.59% <ø> (ø)

management/organization.go
100.00% <ø> (ø)

management/resource_server.go
50.00% <ø> (ø)

management/tenant.go
83.90% <ø> (ø)

management/actions.go
100.00% <100.00%> (ø)

management/management.gen.go
100.00% <100.00%> (ø)

... and 1 more

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

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


semi DETR code with deformable transformer

Hi,
Thank you so much for your amazing work. Could you please share semi DETR code wirh deformable transformer.
Thank you in advance!

Apologies for the delay in getting back to you. Lately, I've been quite occupied with various commitments and haven't had the time to continue organizing the code related to Deformable DETR. However, I'd like to highlight that the code for these modifications is relatively straightforward. You can take cues from our existing DINO codebase to implement it on your own.

Is this existing DINO codebase a standard implementation for paper “DINO: DETR with Improved DeNoising Anchor Boxes for End-to-End Object Detection”? If not, what is the difference?

@becauseofAI You can find the official implementation for DINO at https://github.com/IDEA-Research/DINO. Our code borrows some codes from their official repo and reimplements DINO with mmdetection.


rbd: add e2e with pykimp for kmip encryption

Add a note somewhere about how it was tested?

This was tested with pykimp server instance deployed in kubernetes cluster,
I'll open an issue to track this, so we can add e2e for kmip encryption in a follow-up pr.
Originally posted by @Rakshith-R in https://github.com/ceph/ceph-csi/issues/3306#issuecomment-1219029880

@Rakshith-R any plan to add e2e for pykmip?


Support Route Metadata

Description:
In Envoy, static metadata can be configured on virtual hosts, routes, clusters, etc.
Static metadata can be used for various purposes:

Enrichment of access logs with metadata-based formatters
Enrichment of traces with metadata-based tags
Providing configuration context for filters
Rate-limiting requests based on metadata actions
Loadbalancing to a subset of endpoints that match some metadata
Transport socket matching

In the context of Envoy Gateway, route metadata can be beneficial for observability and configuration of custom data-plane extensions, as described above.
Envoy gateway can support route metadata using:

A vendor-specific Gateway API HTTP Route Filter. This is possibly a misuse of the filter mechanism, since there is no additional processing of traffic.
A new or existing Envoy Gateway Policy
An extended Gateway API HTTPRoute resources that supports route metadata, e.g. using annotations.

:100: This type of stuff is super useful to get metadata per route or per ext_authz filter, etc. Makes it a lot easier to provide context about things like:

Team that owns/maintains some routes/services/APIs
Pass info over to an ext_authz filter

During the community meeting, the following proposal was raised:

Use K8s resource annotations to store metadata
Support per-route-rule metadata, leveraging httprouterule.name introduced in GEP-995 as a rule id, allowing rules to be referenced.

For example:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-app-1
  annotations:
    route.metadata.gateway.envoyproxy.io/rules: |
      rules:
      - rule1:
         team: ops
         app: commerce
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "foo.com"
  rules:
  - matches:
    name: rule1
    - path:
        type: PathPrefix
        value: /bar
    backendRefs:
    - name: my-service1
      port: 8080

Will lead to the generated xds route corresponding to rule1 to have the following static metadata : {gateway.envoyproxy.io: {ruleName: rule1, team: ops, app: commerce}}. Note that the GEP-995 route ruleName is also propagated as route metadata.
This approach has several limitations:

Annotation size is limited to 262144 bytes.
Confidential configuration should not be stored in annotations.
Using annotations to implement features is somewhat of an anti-pattern in the Gateway-API ecosystem.

+1 for mapping Gateway API fields ( like Kind, Name, Namespace and Annotations) into Xds resources, which can be then used for enriching telemetry such as access logs.
3 open questions here are

which Gateway API fields to use as input
Mapping Gateway API to IR to xDS config
Is Telemetry and other enrichment default or opt in

which Gateway API fields to use as input

K8s meta: Name, Namespace, Kind, Annotations. Only annotations from a specific namespace will be copied (e.g. gateway.envoyproxy.io/key : value).
Meaningful Gateway API fields like "section names": Listener name, Route rule name, port name
Open to future extension, e.g. supporting GW-API annotations (like gateway annotations).

Mapping Gateway API to IR to xDS config

In high level, I think that the following makes sense:

GWC/GW => Listener Metadata
Listener => VHost Metadata
xRoute => Route(s) Metadata
Service/Backend => Cluster Metadata

Of course, we don't have to implement everything immediately.

Is Telemetry and other enrichment default or opt in

Since annotations are filtered and the other metadata is constrained in size, I think that adding the relevant Listener/Route/Cluster metadata will not inflate XDS too much. Users can decide if they want to add this metadata to their access logs and/or other telemetry.
WDYT?

+1 to this @guydc

note: VHost metadata, which is a reasonable target for GW/Listener metadata, is currently not accessible for access logger/attribute consuming extensions: https://github.com/envoyproxy/envoy/issues/34900. However, it can still be beneficial to annotate Vhosts for blame tooling like #3684.

closed with: https://github.com/envoyproxy/gateway/pull/3602


Book label test

Added test for book and label classes:

2 test cases added for label
2 test cases added for the book class

@SnakyMz ,
@BenMKT
The branch is ready for the tests. you can review and merge it.


make switcher value update when change value

HI bro,
I made a change in repo to make switcher value updated when pass new value. Can you please check it and if seem good please merge it.
Thanks

Thanks man! tested and working
Merged 😉


operator-sdk olm status is unable to install olm

Bug Report
$ /home/pmorie/go/src/github.com/open-cluster-management/nucleus/_output/tools/bin/operator-sdk olm status --olm-namespace openshift-operator-lifecycle-manager
INFO[0002] Fetching CRDs for version "0.14.2"
FATA[0002] Failed to get OLM status: failed to get resources: failed to fetch CRDs: request failed: failed GET 'https://github.com/operator-framework/operator-lifecycle-manager/releases/download/0.14.2/crds.yaml': unexpected status code 404, expected 200: Not Found

Possible Solution

add flag --version to allow users to choose the version
we package a set of OLM manifests with the SDK to use as the default set, and only reach out to github releases if the user specifies another version

Additional context

discussion in slack https://coreos.slack.com/archives/C3VS0LV41/p1590174772452300
place in the code is: https://github.com/operator-framework/operator-sdk/blob/master/internal/olm/manager.go#L120
Currently, we get the version from ClusterServiceVersion for then looking for the assets in the GH to install it.

Clarification: olm status does not install OLM, it looks up the installed version of OLM then queries OLM's Github release manifests for that version. If those manifests don't exist, status (and uninstall) will error.
These error messages need to be better and the SDK should both permit --version to override the detected version and package its own version of released manifests that gets updated like other dependencies.


Approval system for story posting

When some organization will post some story it must be approved by the admin. Make the routes and controller function. For reference look at the approval system of organization registration

I'd like to work on this!


Download Device CSV data

As a User I would like to download CSV data from a device.

This is completed


Bump lscolors to 0.9.0

Fixes https://github.com/Peltoche/lsd/issues/248
Just a note for future: I am not bumping crossterm as they have changed the deserialize code to not deserialize 0 into 256 color 0, but now you have to write ansi_0. We might have to create custom deserialize for that. We can maybe change back to ansi-term while we are at it as that has 16 color support which could be useful for https://github.com/Peltoche/lsd/issues/609.
ref: https://github.com/crossterm-rs/crossterm/pull/604

TODO

[ ] Use cargo fmt
[ ] Add necessary tests
[ ] Add changelog entry

Codecov Report

Merging #623 (0e2fab8) into master (4120f68) will decrease coverage by 0.17%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #623      +/-   ##
==========================================
- Coverage   86.12%   85.95%   -0.18%
==========================================
  Files          37       37
  Lines        3907     3915       +8
==========================================
  Hits         3365     3365
- Misses        542      550       +8

Impacted Files
Coverage Δ

src/color.rs
49.14% <0.00%> (-2.36%)
:arrow_down:

Continue to review full report at Codecov.

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