Fix neighbourhood calculation

This PR:

[x] Closes #387.
[ ] Adds and passes relevant tests.
[x] Has well-formatted code and documentation.

Benchmarks on VRPTW
This PR (3748b5f7cc116cb52c3efbed7a5db4262b47da04; job ID 4321818):
               MEAN      MIN      MAX   COV
      inst
obj   R2    27758.9  27731.9  27793.7   0.1
      RC2   23247.3  23235.6  23267.1   0.0
iters R2    65899.8  54272.0  81913.0  13.7
      RC2   67226.8  55315.4  85177.8  14.5

Current main (b5449f4e7d5dcb0d75d05232a5fee1ca89915ac8; job ID 4323122):
               MEAN      MIN      MAX   COV
      inst
obj   R2    27793.5  27762.9  27834.1   0.1
      RC2   23301.0  23272.0  23322.9   0.1
iters R2    63402.3  43486.3  76481.2  16.3
      RC2   62689.9  43425.9  72048.3  15.7

Target to hopefully match (28f8aedd2d805d35c739b5f045445aa1d27df006 with old neighbourhoods; job ID 4319800):
               MEAN      MIN      MAX   COV
      inst
obj   R2    27709.0  27698.2  27746.9   0.1
      RC2   23221.1  23207.2  23236.4   0.0
iters R2    54235.3  43754.2  64960.2  13.8
      RC2   60875.1  47926.0  69932.9  14.1

Notes:

It is essential that you add a test when making code changes.
This keeps the code coverage level up, and helps ensure the changes work as intended.
When fixing a bug, you must add a test that would produce the bug in the master branch, and then show that it is fixed with the new code.
New code additions must be well formatted. Changes should pass the pre-commit workflow, which you can set up locally using pre-commit.
Docstring additions must render correctly, including escapes and LaTeX.

Are there any differences here in the computation? I really don't see it. 😅

Might well be largely in how ties are handled, I'm not sure. But the benchmarks are quite clear? I'm not going to investigate this much further: these changes revert what happened in #338, and that seems to help.
But it could be this is way overfitted on the instances. Who knows.


Test issues after latest commit

Describe the bug
The tests are having issues after the latest update and the PRs are failing due to it. Although the app builds but the tests are failing with errors.
To Reproduce
Steps to reproduce the behavior:

Go to 'Any test file'
Click on 'Run'
Scroll down to 'Debug Console'
See error

Expected behavior
Tests should not be failing
Screenshots

Device Information [optional]:

OS: Android

Additional context
This was tested on the master branch of mobile-app repository after latest commit.

Please check your development environment as the CI successfully passes tests + analyzer. Refer: https://github.com/CircuitVerse/mobile-app/runs/4817887656?check_suite_focus=true

Hey @manjotsidhu. Just wanted to know if tests are working fine in your local environment? I tried some ways, but my flutter environment and packages seem fine; however, I'm still facing the errors mentioned above.

@ItsAdityaKSingh Run this command flutter packages pub run build_runner build to generate those files.


⚠ Bofrost.de has degraded performance

In 23433f2, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1518 ms

Resolved: Bofrost.de performance has improved in d61733b.


Setup Calico polices while creating cluster

Hi
I want to setup calico polices while creating cluster automatically..is there any way?
like using cli ,we can create a cluster, but how can we setup calico polices?
can you help me on this..?
Thanks!!

You can create Kubernetes NetworkPolicies using kubectl (see the Kubernetes documentation).
You can also create Calico policies using calicoctl (see the Calico docs: https://docs.projectcalico.org)


(WIP) Add support for RDM passthrough for Honda, static 0xe5 on Bosch, switch to LDW cereal visual alert for all cars

Note: Do not run this untested branch!
This PR has several additions:

Passthrough RDM hud values from the stock ADAS camera.
Block 0xe5 (Bosch only) and send only static values. Wheel wobble functionality is disabled on vehicles that support it. This important safety change is crucial for Bosch cars because the wobble overrides any torque command on 0xe4 sent by OP (or stock LKAS).
Move the ldw alert to use the ldw visual alert that is in cereal. This minor change affects all car makes.
Use the "Lane Departure" stock hud warning on Honda for OP's lane departure alert instead of the usual Steering Required.

Todo:

[x] Does static 0xe5 disable AEB? Don't see any bits that correlate to AEB.
[ ] Final test on Nidec and Bosch
[ ]  PRs on the opendbc and panda changes. Reset .gitmodules to comma.
 Maybe some signals are feedback bits from other frames/modules?
[x]  Gate RDM hud passthrough to be based solely on the dashboard button. If stock LKAS is active behind the scenes (OP in control and the driver accidentally presses the LKAS button) RDM is available regardless of the state of the dash button's indicator. This can be confusing to the driver as there is no way to visually see the state of the stock LKAS system and thus needs to be tuned out at all times.
[x]  Explore the RDM bit on Honda Bosch (bit 35 of 0xe4) Had no obvious effect.
[x]  Panda safety on 0xe5 because this frame can control some minor aspects of stock long control.

Splitting e5 and RDM stuff. Closing this for now.


1.0 install error: Git repository not found at 'IJulia'

I get the following strange error on 1.0:
(v1.0) pkg> add IJulia
   Cloning git-repo `IJulia`
ERROR: Git repository not found at 'IJulia'

Other packages work fine.

I can't reproduce.

Me neither anymore, it just works now.


Got compiler exception in Tutorial: "map2: Different_list_size"

The tutorial asked me to report an issue: https://www.fstar-lang.org/tutorial/
Input:
exception Bouh
val f: int -> Exn int
let f x =
    if x > 0
    then 2 + x
    else raise Bouh

Output:
Welcome(21,18-21,21): Expected type "Effect";
got type "(pre:Prims.ex_pre -> post:(Prims.ex_post Prims.int) -> Tot Effect)"
Error: Unexpected error; please file a bug report, ideally with a minimized version of the source program that triggered the error.
Invalid_argument("map2: Different_list_size")
Error: 1 errors were reported (see above)

I suspect I may have caused this. Investigating now.

Upon investigating, the problem is that the Exn effect expects a pre and post-condition as argument; the error message you get is particularly unhelpful. Ex is the exception effect with trivial pre and post condition, the following code does what you expect:
exception Bouh
val f: int -> Ex int
let f x =
    if x > 0
    then 2 + x
    else raise Bouh

I'll see if I can improve the error message for insufficient effect arguments.

This keeps confusing users. Simpler example:
module M

val f: unit -> ST unit
let f x = ()

Sorry, this is a crash. Will fix asap


Specify ruby version

Specify the exact Ruby version for this gem. Trying to align all Ruby versions with the main one (2.7.2) so that it's easier to handle repos and do some bulk processing when preparing for migration to Ruby 3.0
@vinted/platform-backend

After some discussions it seems that setting the platform as ruby is the preferred solution, but it requires a bundler config setting so that other devs bundling a project would not get their platform added
bundle config set force_ruby_platform 1
This will be added to dev-tools.


Bug fix: issue 664 - pfe-cta link clickability in Edge & IE

Goal of this pull request

Fix issue 664

What has changed and why
Summarize files edited as part of this MR along with a brief description of what was changed/why.

Add z-index to link inside pfe-cta

Testing instructions

Test the default, primary & secondary CTA buttons in all browsers; the link should be clickable
https://web-dev-drupal-carobert.dev.a1.vary.redhat.com/en/web-components-demo#

(note that the padding issue is being worked on here )

[x] Latest 2 versions of Edge
[x] Internet Explorer 11 (should be useable, not pixel perfect)
[x] Latest 2 versions of Firefox (one on Mac OS, one of Windows OS)
[x] Firefox 60.7.2 (or latest version for Red Hat Enterprise Linux distribution)
[x] Latest 2 versions of Chrome (one on Mac OS, one of Windows OS)
[x] Latest 2 versions of Safari
[x] Galaxy S9 Firefox
[x] iPhone X Safari
[x] iPad Pro Safari
[x] Pixel 3 Chrome

Ready-for-merge Checklist

[x] Expected files: all files in this pull request are related to one feature request or issue (no stragglers)?
[ ] Did browser testing pass?
[x] Did you update the CHANGELOG.md file with a summary of this update?

Be sure to share your updates with the<EMAIL_ADDRESS>mailing list!

+1 to Code


[Feature Request] Auto-reveal annotations for fully pre-filled lights.

I was updating an ongoing competition puzzle and I wanted to see if the new entry's author had a previous entry, but the only way to tell from the UI was to select each clue one-at-a time and click 'Reveal'. It got me wondering what is the point of hiding annotations when the solutions are on display?
I think this would also be a good feature for anyone who'd like to provide separate pages with  pre-filled solutions for their puzzles.

Sure, will add the functionality soon.

Excellent, thank you!
Another thought I've just had: in a fully pre-filled grid there's no point displaying any of the buttons as there won't be anything to reveal or clear.

This is done, with v0.46.
Please note though:

When a puzzle is loaded, any entry that is fully pre-filled will get its anno displayed.
Clear this/clear all will clear the anno, if clicked. I think keeping this behaviour consistent with the non-pre-filled case is better (I for one would like the option to be able to look at clues "cleanly," without the presence of distracting annos).
Reveal all/clear all do have additional responsibility of revealing/clearing ninas and notes if any. So, for the above reason and for this reason (and for consistency), even if there is  puzzle with all entries pre-filled, the buttons will get rendered.

Installed and working great!
I take your point about the buttons. It hadn't occurred to me that someone might want to hide the annotation with the answer being shown, but I guess it could be a good way to test their parsing skills.
Thanks again.


"Old style" display applications are no longer accessible - possibly related to  #14341

Describe the bug
Beta history is not rendering HTML/CSS for a class called display-applications -  these can be seen by switching to Legacy History
Galaxy Version and/or server at which you observed the bug
Galaxy Version: {"version_major":"22.05","version_minor":"1"}
https://usegalaxy.eu/training-material/topics/transcriptomics/tutorials/ref-based/tutorial.html - no IGV links
Additional context
This may have already been corrected in the galaxyproject/galaxy#14341 report and not yet propagated to the GTN server, if so - my apologies.

I've moved it to the GTN because the description and sceenshot need to be updated, let's keep this open until that's done.

I believe you fixed this in https://github.com/galaxyproject/training-material/pull/3585 @hrukkudyr, thanks! So am closing this. Feel free to re-open this issue if there is something more that needs to be done here that I may have overlooked.


Fixes #133

Coverage remained the same at 94.498% when pulling 9e22489f6207c20712dccef33dbea8bb4bbe31a1 on atomicpages:patch-1 into dfaaf7402d56a3eaf1034fbebfc86770d41f3700 on diogofcunha:master.

Maintaining a fork until then 😞  https://github.com/atomicpages/react-virtualized-tree

Hi @atomicpages, thanks for this, sorry for the delay, I was a father recently and I'm only getting now the time to catchup 🙂

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

@diogofcunha no worries and congrats 🎉


Provide scroll bar Smoothness

.css must be changed
add some smoothness code

Could you please elaborate what changes it required.

Could you please elaborate what changes it required. @kalashvasaniya

I put some scrollbar smoothness code in .css file!

@kalashvasaniya
But the project is in Tailwind CSS

@kalashvasaniya But the project is in Tailwind CSS

we can add it in global.css


rtgdk_python3 - Conflicting Dependencies

@rtgdk
Trying to use rtgdk_python3 branch, which seems to be the one most recently updated python3 migration , it has conflicting dependencies

The conflict is caused by:
    The user requested jpype1==1.2.0
    spdx-license-matcher 0.0.1 depends on jpype1==1.0.1

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies

Should I create a PR updating requirements.txt setting jpype1==1.0.1 if that's okay?

@nishantc7 The jpype versions 1.0 and 1.1 has memory leak problem in strings that's why the dependency was updated to version 1.2. The conflict you got will be fixed once https://github.com/spdx/spdx-license-matcher/pull/13 this PR is merged.

@nishantc7 The jpype versions 1.0 and 1.1 has memory leak problem in strings that's why the dependency was updated to version 1.2. The conflict you got will be fixed once https://github.com/spdx/spdx-license-matcher/pull/13 this PR is merged.

Oh, alright thanks for letting me know. Closing this now.

@nishantc7 I merged that PR spdx/spdx-license-matcher#13 and release a new version https://github.com/spdx/spdx-license-matcher/releases/tag/v2.1 and updated requirements.txt in rtgdk_python3 branch with this release build. Now you should not face this issue while running pip install.


Repaired luigi build

Description
Changed URI.js route
Motivation and Context
Luigi does not build properly, referencing issue #2028
Have you tested this? If so, how?
The project has passed the travis tests, luigid is running properly.

It's been requested and (somewhat) supported by @nmb10 and @kwilcox to leave the version number within the path. So just change luigi/static/visualiser/lib/URI.js/1.18.2./URI.js to luigi/static/visualiser/lib/URI/1.18.2/URI.js.

@Tarrasch @nmb10 Are you good with this?

Hi, @dlstadther . Yes.

Can anyone else verify this works?

I believe this PR would fix the installation problem, that I encountered:
$ pip install luigi
....
error: can't copy 'luigi/static/visualiser/lib/URI.js': doesn't exist or not a regular file

In setup.py, get_static_files will return (among other globs) 'static/visualiser/lib/*.js',, which will match URI.js, which is not a regular file, as setup seems to expect.

Thanks!

I have the same error when pip installing luigi 2.6.0. I cannot use this version in its current state.
Could you please include this fix in a 2.6.1 release ?

@Lucas-C I don't have the ability to push luigi releases. That'll have to wait until @Tarrasch returns.

I had issue
/opt/cloudera/parcels/Anaconda-4.0.0/bin/pip install luigi
....
reating build/lib/luigi/static/visualiser/lib
copying luigi/static/visualiser/lib/mustache.js -> build/lib/luigi/static/visualiser/lib
copying luigi/static/visualiser/lib/jquery-1.10.0.min.js -> build/lib/luigi/static/visualiser/lib
error: can't copy 'luigi/static/visualiser/lib/URI.js': doesn't exist or not a regular file
then I download and then pip it.
wget https://github.com/spotify/luigi/archive/master.zip
unzip master.zip
cd luigi-master/
sudo /opt/cloudera/parcels/Anaconda/bin/pip install .
it works for me


Remove JWKManager, JWKSetManager and associated interfaces

These manager are not needed anymore and should be removed.
JWK or JWKSet objects can be created directly by developpers.
Some additional static methods could be created.

Done


fix(costmodels): delete i18n keys for metrics/measurements

closes COST 756
remove unnecessary i18n keys and removing them from toolbars and tables in cost models.

Thanks Dan!


Gamma Remote Sensing Feature Requests

Following a conversation with Charles Werner and Christophe Magnard of Gamma Remote Sensing, several feature requests have been identified:

[x] Correct polarization code in SAFE name
[x] The ability to specify an output directory
[x] Pass search extent as either bounding box or geospatial file.
[ ] The ability to create stacks of SAFE files
[x] The ability to specify a minimum number of bursts (or raise an error if a minimum is not met)
[x] The ability to specify desired swaths
[ ] Adding a confirmation step that show the selected bursts in Vertex

All of these would be useful to the broader user community, and are worth implementing.

Correct polarization code fixed by PR #40.

Output directory specification fixed by PR #41.

Ability to specify minimum number of bursts and swaths added by PR #44

Passing search extent as either bounding box or geospatial file added by PR #45.

Stack based interface added by PR #46

Adding a confirmation step that shows the selected bursts in Vertex will require changes to the upstream asf_search library. Once those change have been made, I will create a new issue for implementing this feature.


[improve][broker] Optimise msgOutCounter and bytesOutCounter (#16214)

Motivation
AbstractTopic#getBytesOutCounter and AbstractTopic#getMsgOutCounter
both generate full stats only to pick the single required counter for
the getters. These can be optimised to perform only the necessary work
to calculate the counters.
Modification
Provided a scoped implementation of the above methods for the single
counter required for each getter.

Fixes #16214
Verifying this change

[ ] Make sure that the change passes the CI checks.

(Please pick either of the following options)
This change added tests and can be verified as follows:
mvn clean install -Pcore-modules,-main -DskipTests
mvn test -pl pulsar-broker -Dtest="AbstractTopicTest,AbstractSubscriptionTest,ConsumerTest"

Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: ( no)
Anything that affects deployment: (no)

Documentation
Check the box below or label this PR directly.
Need to update docs?

[ ] doc-required
(Your PR needs to update docs and you will update later)

[x] doc-not-needed
(Please explain why)
Implementation optimisation only

[ ] doc
(Your PR contains doc changes)

[ ] doc-complete
(Docs have been already added)

Hi, @nahguam
It looks like this pull request has many conflicts at branch-2.9 could you please help push a new PR to branch 2.9?

#16771 cherry-pick this improvement. So, I remove the release 2.9.4 label.


Support for generics

Since v3 is going to require Xcode 7, adding generics support would be nice. Who knows, it might even catch some lingering bugs. 😝

Added a PR here to this issue @0xced


Improve Trusty integration

Summary
This PR surfaces the Trusty maliciousness data on the comment added by minder when analyzing dependencies. It also adds the required piping to add the data to the rest of the required low scored dependencies.
I've broken the Trusty evaluator to more scoped utility functions to make them more testable and added a few initial unit tests. It needs a little bit more mocking to write an integration test and the rest of the unit tests
I've simplified the comment template, we now have a single template instead of 3 and it is now pure markdown which is smaller. Here' is a screenshot of the output with malicious dependencies:

Demo PRs showing

A malicious dependency
A low score dependency
Both malicious and low score

Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[x] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[x] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Added initial tests (up to 22% from 0 :) )
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[x] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[x] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 50.558% (+0.2%) from 50.319%
when pulling df92e3ebe4a2be13256cb663ee16e847f5b76fef on puerco:malicious-deps
into 6c471020bbbe65d297e423cb8c8999299e7c7619 on stacklok:main.

There is more payload from trusty we could leverage here.
Provenance: sigstore or historical provenance. It might make sense to surface a threshold here for folks to set within the policy. This could be an float (I think?) between 1-10, or a simply bool cc: @therealnb , @yrobla
We also have deprecated or achieved available as fields to report in the same way as malicious

OK, I've surfaced the rest of the malicious data and the score components on the PR comment. The rule evaluator will now honor minimal scores for provenance and activity in the rule configuration.

I really like the new format, but it seems like a high-scoring package is getting flagged now as well, see e.g. https://github.com/jakubtestorg/bad-python/pull/193

This is how its looking now. I will investigate Jakubs bugfind next but we can merge as it is and iterate on smaller PRs.

This is how its looking now. I will investigate Jakubs bugfind next but we can merge as it is and iterate on smaller PRs.

Let me try to reproduce again so I don't send you down the wrong path

I think there are two issues: The evaluator has hardcoded default configuration which should include also the two new attributes and additionally it seems like the condition when evaluating the scores are reversed - shouldn't we check that the score of the package is higher than the config? Check out the diff below:
diff --git a/internal/engine/eval/trusty/config.go b/internal/engine/eval/trusty/config.go
index 8b673b494..534427641 100644
--- a/internal/engine/eval/trusty/config.go
+++ b/internal/engine/eval/trusty/config.go
@@ -60,16 +60,22 @@ func defaultConfig() *config {
 		Action: pr_actions.ActionSummary,
 		EcosystemConfig: []ecosystemConfig{
 			{
-				Name:  "npm",
-				Score: 5.0,
+				Name:       "npm",
+				Score:      5.0,
+				Provenance: 5.0,
+				Activity:   5.0,
 			},
 			{
-				Name:  "pypi",
-				Score: 5.0,
+				Name:       "pypi",
+				Score:      5.0,
+				Provenance: 5.0,
+				Activity:   5.0,
 			},
 			{
-				Name:  "go",
-				Score: 5.0,
+				Name:       "go",
+				Score:      5.0,
+				Provenance: 5.0,
+				Activity:   5.0,
 			},
 		},
 	}
diff --git a/internal/engine/eval/trusty/trusty.go b/internal/engine/eval/trusty/trusty.go
index 634fdb915..53b4dcf6c 100644
--- a/internal/engine/eval/trusty/trusty.go
+++ b/internal/engine/eval/trusty/trusty.go
@@ -253,14 +253,14 @@ func classifyDependency(
 		}
 	}

-	if ecoConfig.Score <= packageScore {
+	if ecoConfig.Score > packageScore {
 		reasons = append(reasons, TRUSTY_LOW_SCORE)
 	}
-	if ecoConfig.Provenance <= descr["provenance"].(float64) {
+	if ecoConfig.Provenance > descr["provenance"].(float64) {
 		reasons = append(reasons, TRUSTY_LOW_PROVENANCE)
 	}

-	if ecoConfig.Activity <= descr["activity"].(float64) {
+	if ecoConfig.Activity > descr["activity"].(float64) {
 		reasons = append(reasons, TRUSTY_LOW_ACTIVITY)
 	}
 	if len(reasons) > 0 {

it seems like the condition when evaluating the scores are reversed - shouldn't we check that the score of the package is higher than the config?

Should we have a test for this?  It feels like the sort of bug that we could easily accidentally introduce again.

it seems like the condition when evaluating the scores are reversed - shouldn't we check that the score of the package is higher than the config?

Should we have a test for this? It feels like the sort of bug that we could easily accidentally introduce again.

We do have a smoke test, but alas, no way of running it locally yet. You are right that we should do better on the unit testing front - not having proper tests is mostly my fault, we do have reasonable tests for the OSV evaluator and the current Trusty evaluator code was meant to be a "quick hack" until we can generalize the PR dependency evaluators into common code and built both OSV and trusty evaluators atop them. We just haven't prioritized that work.

I think we can merge this now. Let's start adding tests in further PRs

Should we have a test for this? It feels like the sort of bug that we could easily accidentally introduce again.
@evankanderson as part of this improvement I've been splitting the logic into more atomic functions to make them testable and to be able to mock the whole trusty evaluator. I'll strat sending incremental PRs to add more tests


Remove version: VGN.VHUB version 2.3.18

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

For moderators or/and anyone else

[!Caution]
As a result of several personal problems I've had over the last few months + my final exams coming up very soon, I'm currently unable to look at my GitHub notifications every day and maintain my executions correctly.
If you detect a certain problem on a certain pul request:

Either you can close the pull request directly without mentioning me.
Or you can send me a message on X (Twitter): @Exorcism0666

Thank you for your understanding, and I'm sorry if some pull requests can't be approved due to the situation I'm in.

This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping Exorcism0666.

[!warning]
With the new version of Komac, numerous Pull Requests may contain bugs or unwanted elements. If such issues arise, please tag russellbanks so that these bugs can be addressed in future updates.

[!important]
Please carefully review these Pull Request before merging. If it is a Pull Request for removing incorrect content and the URLs are issue, free upon manual checking, please close this Pull Request directly. (It is best to inform Exorcism0666 of the closure.)

良い一日をお過ごしください！

URL: https://cdn.vgnclub.com/device/download/win32/2.3.18/v-device-1-2.3.18.exe
Response Error: The remote server returned an error: (404) Not Found.
(Automated message - build 910)


Adding testing feature to bonfire

I have created an addition to the bonfire IDE that allows users to test any function within the main coding window.  Here are some pieces of its functionality:

Identifies arguments and creates input boxes for each
Side by side mode with editor
Test suite execution displays percentage of tests correct, highlights passing tests green, failing tests red
For failing tests, displays what the actual output was
Users can delete tests once they are created

Here are some todos that still remain:

Don't use the eval method to evaluate the test. Nate has the plugin, but it is currently only configured with the console output.  I need to make the test framework work as a callback from the plugin completing its execution.  This requires changing a large portion of Nate's code, so I held off on it.
Allow other types of comparisons besides equality.  We can test behavior, type, length, features of a JSON object, almost anything with chai.

Merged in bonfire-improvements


Plugin fails to connect

Incredibly stoked for this plugin, however it fails to connect. I don't see anything in the console that seems useful for debugging.

Hey @readywater, big thanks for trying to help! I don't have a mac device so it's extremely difficult for me to debug and reproduce this issue. I saw you have some JavaScript experience so I wonder if you can help me collect some information to debug:

Make sure your SpaceMouse connected and active
Go to a chrome browser (no need to be in Figma) and dump the connected gamepad devices ids to the console using this script.

console.log([...navigator.getGamepads()].map(gamepad => (gamepad.id)))

If the output is blank or error, try it a few more times while jittering the knob. Sometimes the device must "wake up" the browser first.

The expected output should look like this:

Once do you this, we can figure out next steps.
Thank you again.

@chuanqisun I'm here for help. After update on BigSure this, awesome,  plugin didn't work anymore :( I'm crying. Tears can't help grief.
So, this is what got:

Thank you @bimawa for the update! A bit of background:
This plugin uses the browser's "gamepad" api to detect 3Dconnexion device. Even though SpaceMouse is not technically a "gamepad", it should still show up in the browser's gamepad device list, at least in the past versions of macOS and all versions of Windows. So we are exploiting the browser as the driver.
Based on your console log, it appears that the device is not detected by the browser. Could you help try 2 more things?

There is a similar project that uses the same technique. Just to rule out any bug in my implementation, could you try these demos and see if you SpaceMouse works? (make sure to jiggle the device a few times to activate it)
1 .THREE.js
2. A-Frame Component
3. A-Frame Inspector
With the device connected and active, could you copy, paste, and enter this javascript in the browser console and see what the results are? If possible, try it in a few different browsers.navigator.getGamepads()

I found another listed for reference:
Chrome browser support on OS X Big Sur
Re: Use 3DConnexion mouse as 2D
These made me think the beta driver caused the device to disappear from the gamepad list. I also replied in the forum to see if the device vendor is willing to provide a driver fix on their side.
Attaching the support forum thread for reference:
https://forum.3dconnexion.com/viewtopic.php?f=23&t=39825&p=82487&hilit=gamepad#p82487

@chuanqisun

gamepads still not found:

chrome:

vivaldi:

I think problem not in browsers. This is drivers or plugins from 3dConnexion.
I can't use stable driver on Big Sur. It doesn't exist yet. Older drivers didn't work on big sur.

I think we should request from 3dconnexion supports to developers.

Thanks for further testing. 3DConnexion also replied in the support forum. Looks like it's a macOS 11 quirk that forced them to change the driver behavior to have an "exclusive grab" of the device, hence making it invisible to the browser.
I'll keep this issue open. We can track the status in the support forum thread: https://forum.3dconnexion.com/viewtopic.php?f=23&t=39825&p=82487&hilit=gamepad#p82522
I've requested more details in that thread. If anyone is impacted by this issue, please reply in the 3DConnexion forum so we can get this prioritized.

Hello, I am facing the same issue and found this issue.
I tested the 3 similar projects and none of them detects any gamepad.
I testing using Brave (so close to Chromium) while having all shields down.

FYI I tried again, but in Chrome this time. Still now success:

However, after trzing the following:

https://archilogic-com.github.io/aframe-space-navigator-controls/examples/three.html
https://archilogic-com.github.io/aframe-space-navigator-controls/examples/aframe.html
both worked.

Then revisiting the same browsers (tested with Chrome and Brave):
Chrome:

Brave:

🎉
So I suspect there is soemthing that triggers loading the gampads that including in one or both the demos I linked and that should be called to ensure the browser does grab the 3dmouse as gamepad.

I then tried figma in a browser, it did not work.
I then opened the plugins settings and while the plugin settings popup is open, the 3dmouse does respond.
As soon as I close the popup, it stops working again.


Support | and other special characters in domain join password

Overview/Summary
Wrap domain join password in ' in the PowerShell command.
This PR fixes/adds/changes/removes

Fixes #515

As part of this Pull Request I have

[x] Read the Contribution Guide and ensured this PR is compliant with the guide
[ ] Ensured the resource API versions in .bicep file/s I am adding/editing are using the latest API version possible
[x] Checked for duplicate Pull Requests
[x] Associated it with relevant GitHub Issues
[ ] (AVD LZA Team Only) Associated it with relevant ADO Items
[x] Ensured my code/branch is up-to-date with the latest changes in the main branch
[ ] Performed testing and provided evidence.
[ ] Updated relevant and associated documentation (e.g. Contribution Guide, Module READMEs, Docs etc.)

@SvenAelterman thanks for your contribution, merging on feature branch for testing.


Investigate options for CI

Our much loved Travis has been turned into a paid service and we are out of free credits there. What should be done to keep our CI running?
Some options:

pay Travis ($69/month for one concurrent build job, other pricing options too)
move to another CI system (Aalto GitLab? Other?)
something else

Investigate!

@superseacat is to ask Travis

@superseacat is to ask Travis

GitHub actions seems to be completely free for open source projects, so I suggest we switch to that, especially since our release already happens through GH actions.

GitHub actions seems to be completely free for open source projects, so I suggest we switch to that, especially since our release already happens through GH actions.

But GH actions cannot run tests or SonarScanner, can they?

But GH actions cannot run tests or SonarScanner, can they?

Why could they not run tests?

Why could they not run tests?

SonarScanner is a good question though

SonarScanner is a good question though

I at least found a SonarScanner GH action, so that should be possible as well

I at least found a SonarScanner GH action, so that should be possible as well

Why could they not run tests?

I don't know. I just didn't expect them to give away computing resources that generously (more than making some simple https queries to external services). But I might have been wrong. Worth investigating, I guess.

Why could they not run tests?

I don't know. I just didn't expect them to give away computing resources that generously (more than making some simple https queries to external services). But I might have been wrong. Worth investigating, I guess.

As far as I know tests is completely fine and a common use of GH actions. The only thing I haven't been able to figure out whether free for open source means unlimited minutes or if it has the 2000 free minute limit that private repos have.

As far as I know tests is completely fine and a common use of GH actions. The only thing I haven't been able to figure out whether free for open source means unlimited minutes or if it has the 2000 free minute limit that private repos have.

Should this be closed now or only later? What is there still to do?

Should this be closed now or only later? What is there still to do?

Should this be closed now or only later? What is there still to do?

I've agreed I write an email to Travis and @jsorva wanted to take a look as well

Should this be closed now or only later? What is there still to do?

I've agreed I write an email to Travis and @jsorva wanted to take a look as well

migrated to GH actions, but some things still need to be handled: #506, #507


FEAT: Refactor device related code and add initial Intel GPU support

Refactors most device related code into device_utils (only pytorch backend, vllm and ctransformers are unsupported, 8bit and 4bit are also unsupported), and adds initial Intel GPU support.
You will need intel-extension-for-pytorch to run it: https://intel.github.io/intel-extension-for-pytorch/xpu/latest/tutorials/installation.html
Tested on Llama2-chat and ChatGlm3.
(for device_map, requires https://github.com/huggingface/accelerate/pull/2383)

Lint failed, we use pre-commit(https://pre-commit.com/) to lint before commit, you can install it on local and commit again.

@aresnow1 All lint errors fixed, and tested again on chatglm3.

I solved the lint for you, other than flake8, we use black to format code and isort to sort the imports.

Hi, could you rebase main branch and push again?

Hi, could you rebase main branch and push again?

Rebased and pushed.

Looks good to me, thanks for your contribution.


Add an option in order to not create hooks

In my project I don't use the ionic hooks.
Is it possible to add an option in order to not create hooks when running ionic commands ?

This is something I've added to my list to look at. I just hadn't gotten to it yet.
Due to the latest release of cordova, some of these functions happen now without these hooks. Thus, it's time to remove the hooks and let cordova do its thing.
I'll be addressing this fairly soon. I'd love any help in the meantime!

@rpignolet - thanks again for the submission. I'll be merging this to master soon. Also, some of the plugin hooks have been removed since cordova provides this. :)

No problem, glad to help you :wink:


[Calls / TURN] Add note about RTCPeerConnection structure

Summary
Maybe this doc change could be clearer, but here's the issue I was having:
I was stuck for quite a while trying to pass on turn credentials to an RTCPeerConnection via y-webrtc & simple-peer, it seems that I was passing along the ice credentials incorrectly.
Here's how I ended up modifying the credentials:
const TURN_ID = 'secret_id';
const TOKEN = 'secret_token';

// Fetch TURN credentials from the API (don't worry, I'm using a worker in the real thing!)
const response = await fetch(`https://rtc.live.cloudflare.com/v1/turn/keys/${TURN_ID}/credentials/generate`, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${TOKEN}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ ttl: 86400 }),
});

// Parse the response
const config = await response.json();

try {
  // Attempt to create a new RTCPeerConnection using the returned config
  const pc = new RTCPeerConnection(config);
} catch (e) {
  // Error occurs here because config.iceServers is not iterable
  console.error('Error constructing RTCPeerConnection:', e);
  // Error message: TypeError: Failed to construct 'RTCPeerConnection':
  // Failed to read the 'iceServers' property from 'RTCConfiguration':
  // The object must have a callable @@iterator property.
}

// Fix the issue by wrapping iceServers in an array
config.iceServers = [config.iceServers]; // Ensure iceServers is an array

try {
  // Attempt to create the RTCPeerConnection again with the fixed config
  const pc = new RTCPeerConnection(config);
  console.log('RTCPeerConnection successfully created.');
} catch (e) {
  // This block won't be called as the iceServers issue has been resolved
  console.error('Unexpected error constructing RTCPeerConnection:', e);
}

Screenshots (optional)

Documentation checklist

[x] The documentation style guide has been adhered to.
[x] If a larger change - such as adding a new page- an issue has been opened in relation to any incorrect or out of date information that this PR fixes.
[x] Files which have changed name or location have been allocated redirects.

I think the pseudo code already shows an array. And as far as I can remember the change for iceServers (not the plural here) to be an array is quite old, see https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/RTCPeerConnection#browser_compatibility
The word 'now' suggests to me that this is something new, which I don't think is the case. If we remove the word 'now' from the PR I have no problem with the extra hint about it being an array.
@renandincer what do you think?

let's ship it! thanks for the contribution @benfoxall

the word 'now'

I meant this as in "it was an object in the credential response, but now it's an array", tbh the wording isn't that great, but thanks for merging 😅


Cannot find index.js in built MacOS app

Describe the bug
Error at application startup
To Reproduce
Steps to reproduce the behavior:

Build and run the Electron app on MacOS, shows alert with:

`Uncaught Exception:
Error: Cannot find module ```
/Users/mhicks/projects/clients/courio/courio/capacitor/electron/out/make/zip/darwin/x64/Courio.app/Contents/Resources/app/build/index.js'
at Module._resolveFilename (internal/modules/cjs/loader.js:972:15)
at Function.n._resolveFilename (electron/js2c/browser_init.js:249:921)
at Object. (electron/js2c/browser_init.js:185:3470)
at Object../lib/browser/init.ts (electron/js2c/browser_init.js:185:3714)
at webpack_require (electron/js2c/browser_init.js:1:128)
at electron/js2c/browser_init.js:1:1200
at electron/js2c/browser_init.js:1:1267
at NativeModule.compileForInternalLoader (internal/bootstrap/loaders.js:277:7)
at NativeModule.compileForPublicLoader (internal/bootstrap/loaders.js:219:10)
at loadNativeModule (internal/modules/cjs/helpers.js:24:9)

**Expected behavior**
A clear and concise description of what you expected to happen.

**Desktop (please complete the following information):**

- OS: MacOS

What version of MacOS is this happening on?

10.15.7

I have tested this a few times, and had a few other people I know try this without being able to reproduce. I may be an issue with your local system/project setup, give it a shot with a very generic starter app and see if you still have issues


Setup retrieval based on string

As done in masknn.norms, setting up retrieval based on strings could be pretty useful for optimizers, activation functions and filterbanks in a first stage.

Solved by #7


Added text to README file

Used boilerplate README file template to describe this project

everything works going to merge


Table overflows without scrollbars

TableBody contains overflow-y: auto;, but it seems it doesn't actually work.

Can I help to fix this issue? please let me know, I would love to work on this


Update document of nnictl

Check if there are bugs in the requirements, especially required and optional
Add some example for a better user guide

Fixed in #961


Explicitly addding StyleCop.Analyzers to all project.json files

This solve #114.

Looks great. Thanks.


Copilot causes vscode scaling to change

Issue Type: Bug
Just click the code prompt of copilot, and the zoom of vscode will change
VS Code version: Code 1.62.2 (3a6960b964327f0e3882ce18fcebd07ed191b316, 2021-11-11T20:56:38.428Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No

https://user-images.githubusercontent.com/22639324/141621884-9cfa3693-63ca-4169-9a39-582ae2b03cec.mp4

@isidorn looks like VS Code issues. Do you want to move this to the VS Code repo?


Add groovy library for JBang Groovy Script automatically

Now if you create JBang groovy script, and IDEA will ask you to create Groovy library to Groovy Script.
Adjusting:

check groovy library available during JBang groovy script creation
if no groovy library found, create default groovy library for Groovy script

Issues:

How to change Groovy library version if Groovy script uses new version with //GROOVY 4.0.0
Different Groovy scripts use different groovy version, how to deal with global groovy library?  -- Ask developer to use same Groovy version in same project?

this is not something a ide plugin shoould do. how do I repdocue this issue of intellji complaining about creating groovy library?

This feature is not necessary because dependencies synced between JBang and Gradle  ready now.

How does it solve that?

After developer clicks Sync Dependencies for Groovy script, and the action will add org.codehaus.groovy:groovy:version to build.gradle,  then reload Gradle and groovy library will be available.

Why are those dependencies not in the build.gradle to begin with ? Is jbang edit not putting it there or ?

Yes,   if  jbang edit --open=idea hello.groovy  adds org.codehaus.groovy:groovy:version  in build.gradle, and it will be good.

No. Jbang exit Wont add it. Did You mean jbang init ?

Now the developers just right click the groovy script and choose Sync DEPS to Gradle and plugin will sync groovy artifact to Gradle then Groovy library will be created from Gradle.

Eh? Sync deps will add dependencies that does not exist ? I assume you mean it will sync it if they are present in the file ?

The plugin can detect that no DEPS related with Groovy script and no groovy related dependencies for module, we have some ways to help developers:

warning:  you should add org.codehaus.groovy:groovy:3.0.9  by hand
add //DEPS org.codehaus.groovy:groovy:3.0.9 to code automatically

In IDEA Inspection almost with a quick fix, and what's your suggestion?

I think its fine to provide quick fixes/warnings that are helpful.
Adding dependencies automagically into the dependencies when run inside IntelliJ differently from how jbang would run it would be a big no-no. We should ensure things runs in a consistent same way.
If the sync adds dependencies which then at least are in the script file the behaviors will at least be the same when running - but if its something actually missing in the dependencies it feels more like a quick fix.
I'll try the latest main version to see how it works but by default I'll assume any "magic" dependency add/remote in the plugin signals of a problem that should be fixed properly somewhere else. I.e. if jbang idea just use jbang tools classpath to setup the module info in IDEA then there should be be no need for the plugin to do anything here, right?


Update stages.md

This was discussed in DTS: 1665435

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

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

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

#sign-off

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


[21.05] rtw89: init at 2021-07-03

Motivation for this change
Backport of rtw89 driver (https://github.com/NixOS/nixpkgs/pull/129325)
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

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

[ ] Fits CONTRIBUTING.md.

@SuperSandro2000 Hi, can you help me review this? Considering you reviewed #129325 before.


Flushing error prepend.bin

Hi,
I'm having issues with:
FLUSHING: ERROR: boost::filesystem::remove:
The process can not access the file because it is used by another proces: C:/Apps/PotreeConverter/temp_data/export_3/temp/prepend.bin"
Using:
PotreeConverter.exe "D:/DemoData/x3.las" -o C:/Apps/PotreeConverter/temp_data/export_3 --overwrite
Sometimes it quits halfway, sometimes at 90% and sometimes i have no issues at all.
With larger las files (5Gb) it fails often.
System: i7 3Ghz, 48Gb, 1Tb SSD Windows 10 Pro x64
What can i do to prevent this?
Greetings,
Erwin

Hi,
I'm having the same issues.
I want to use large las files and it fails every time, my system is also Windows 10 Pro x64.
Is there any solution?
Thanks
Victor

Hello,
i'm having the same problem with Windows 7 Enterprise x64
Best Greetings,
Cesar


1 test fails on 05-31 snapshot on Linux OS only

1 test failing on Linux OS

Looked further into these test failures:
First:
TestResponse.swift line: 319
error: TestResponse.testAcceptTypes : XCTAssertEqual failed: ("Optional("text/html")") is not equal to ("Optional("html")") - Accepts did not return expected value
Could be that the acceptable type for Linux is different rather than anything's broken.

I'm not sure what this issue is but I can confirm that using the current 06/06 snapshot, all tests are passing on Linux.


Add notes-ref action input

This PR adds notes-ref optional input to the action.
It allows using this action in a monorepo with multiple independent Go modules (each module can set a different notes-ref and avoid overriding each other's coverage reports while allowing them to run in parallel via the matrix strategy).

Any chance this PR is merged anytime soon? That's a useful addition for monorepos.

Thanks for this; merged after a rebase via 904b079


e2e_test: create e2e test for cleanup keys

TL;DR

Add new e2e test for testing cleaning up keys
Design
Proposal

Add keys
Export keys, check that all keys are there
Add more keys
Export keys, check that only new keys are there
Clean up old keys
Verifies that they were actually deleted and not included in any export

Alternatives considered

/assign


Adding support for markdown in checks description

They say image is worth a thousand words, so let me say, provides this:

Codecov Report

Merging #17980 (615028b) into main (0981ec3) will increase coverage by 0.01%.
The diff coverage is 0.00%.

:exclamation: Current head 615028b differs from pull request most recent head 415175d. Consider uploading reports for the commit 415175d to get more accurate results

@@            Coverage Diff             @@
##             main   #17980      +/-   ##
==========================================
+ Coverage   45.27%   45.28%   +0.01%
==========================================
  Files         820      820
  Lines       90933    90939       +6
==========================================
+ Hits        41172    41184      +12
+ Misses      43204    43198       -6
  Partials     6557     6557

Impacted Files
Coverage Δ

modules/templates/helper.go
49.83% <0.00%> (-0.52%)
:arrow_down:

models/asymkey/gpg_key_commit_verification.go
44.16% <0.00%> (-2.13%)
:arrow_down:

services/pull/pull.go
41.78% <0.00%> (-0.41%)
:arrow_down:

modules/queue/queue_bytefifo.go
59.88% <0.00%> (+0.59%)
:arrow_up:

modules/queue/queue_disk_channel.go
62.72% <0.00%> (+1.77%)
:arrow_up:

modules/log/event.go
62.50% <0.00%> (+1.85%)
:arrow_up:

modules/queue/workerpool.go
49.23% <0.00%> (+3.43%)
:arrow_up:

modules/queue/queue_channel.go
96.66% <0.00%> (+5.00%)
:arrow_up:

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 0981ec3...415175d. Read the comment docs.

Looks like a good idea but even Github just stored text and most of them are short.

I agree it might be a specific use case but I use jenkins with checks plugin and it seems warnings-ng publishes analysis results as markdown tables.

I agree it might be a specific use case but I use jenkins with checks plugin and it seems warnings-ng publishes analysis results as markdown tables.

Yeah, so the UI should consider both long markdown content and short plain content

Do we really need another markdown-rendering template helper function? Why can't it be covered by existing helpers?

Do we really need another markdown-rendering template helper function? Why can't it be covered by existing helpers?

If there's a helper that takes raw markdown and spits out HTML, I'd gladly take it, but with my limited knowledge of Go and Gitea internals I couldn't find anything that did what I needed.

Do we really need another markdown-rendering template helper function? Why can't it be covered by existing helpers?

Although I have the same feeling, after reading through the code, I didn't find an existing markup/markdown helper .....

I think we need to add something to the rendercontext here - for example I think it's likely that SHAs will be in these reports and you'll want to link to them.
To that end we need to pass the repo and urlmetas

I think we need to add something to the rendercontext here - for example I think it's likely that SHAs will be in these reports and you'll want to link to them.
To that end we need to pass the repo and urlmetas

Actually from what I have seen any links that might happen to be in the reports lead to the CI that generated them (for example to the build) rather than to somewhere in repo.

I'm not sure if "status" is the appropriate place for this as it could seriously increase page load size, perhaps another field such as how github does it (see "checks" page on PRs)
(I'm for collecting this information, just in a different field to keep the status lightweight)

FYI: another merged PR has introduced another RenderMarkdownToHtml

misuse
https://github.com/go-gitea/gitea/pull/16510/files#diff-df6792f0bd4f2d349508731c08110a47e5cf0c9559f863f9bb5d7c37cd4f1240

Or we can have two columns, one is for status, another is for description which allow markdown renderering.

So this PR gets stale and I guess most people prefer to keep the "status description" as simple as possible, so the "markdown rendering" is not accepted, right?

So this PR gets stale and I guess most people prefer to keep the "status description" as simple as possible, so the "markdown rendering" is not accepted, right?

I myself couldn't find enough reason to support markdown there.

If I understand correctly, GitHub only shows simple text for the status. Maybe it's good to keep that field simple.
And this PR has been stale for a long time and I can't think of a way to handling it other than closing it. Feel free to reopen if there's any new progress and I could also help.


No compilation error when a HexIntLiteral is used to specify a decimal value

Description:
Resulted in an error up to SL Beta3, but doesn't log an error SL Beta4 onward.
Most probably related to https://github.com/ballerina-platform/ballerina-lang/pull/33643.
Steps to reproduce:
public function main() {
    decimal _ = 0xABC; // no error now
}

Similarly, something like
decimal b = <decimal> 0xABC;

should be an int to decimal cast like
int a = 0xABC;
decimal b = <decimal> a;

But it isn't at the moment, the value is considered a decimal value as if it said decimal b = 0xABC;.
Affected Versions:
2201.0.0

Similarly, something like
decimal b = <decimal> 0xABC;

should be an int to decimal cast like
int a = 0xABC;
decimal b = <decimal> a;

Need to verify this. Also related to https://github.com/ballerina-platform/ballerina-lang/issues/32938.


Testing component functions for clicks

So I'm using Karma/Jasmine for the testing.
Basically I have a component:
export default class NavBar extends Component {
  handleClick() {
    console.log("Clicked!");
  }

  render() {
    return (

          Click this

    );
  }
}

And then inside my testing file:
describe("COMPONENTS: <NavBar />", function() {
  it("simulates click event for acceptingChats false", function() {
    const rendered = shallow(<NavBar {...props} />);
    const handleClick = spyOn(rendered.instance(), 'handleClick');
    rendered.find('a').simulate('click');
    expect(handleClick).toHaveBeenCalled();
  });
});

The log that I see for when I try console.log(rendered.find('a').debug()) is:

  Click this
'

Gives me the error: Expected spy handleClick to have been called. This seems to say that it is never called. I'm unsure why.
I've looked at this issue: https://github.com/airbnb/enzyme/issues/208, and various other pages for information, but I can't find how to get this to work.
Seem to be having a lot of problems with the spyOn stuff from Jasmine. Wondering if I should transfer to sinon or something of the sort.
I'm also using ReduxMockStore, and I'm wondering if I can simulate these click events with changes to the store or should I just be not worrying about Redux changes for these enzyme tests?

Spies are on object properties, not on functions - as such, once the  is rendered, it keeps an immutable reference to the original function. You need to spyOn(NavBar.prototype, 'handleClick') before you call shallow.

So when I do that I get this error: Error: <spyOn> : handleClick is not declared writable or has no setter.

What's the implementation of NavBar look like?

It's above, but this is the most complete version (with using babel, ES6, and some ES7 stuff:
import React, { Component } from 'react';
import autobind from 'autobind-decorator';

@autobind
export default class NavBar extends Component {
  handleClick() {
    console.log("Clicked!");
  }

  render() {
    return (

          Click this

    );
  }
}

And @autobind auto-binds every method? (which, btw, is super slow; you should only autobind methods explicitly one at a time)

It does, and it may be, but at the moment it is fitting for us instead of having to explicitly bind them.

So, specifically the implementation of that decorator is the problem. It only autobinds the first time it's referenced on the instance, so you can't spy on it.
If instead, you explicitly bind in the constructor, everything will work (with spying on the prototype).
With the current implementation of your decorator, you're SOL.

Oh I see... well, that may sway us into removing it...
And yeah, removing it and adding the binding to the constructor fixed the issue. Thanks!
Sidenote: Doesn't binding each function directly in the constructor get messy with how the code looks? I never liked it which is why I sided with the @autobind.

It's explicit, correct, and faster; which is much less messy than "having less code".

Glad you got it working!

Hi @ljharb,
I've a similiar issue, and would appreciate your opinion.
That's my class definition; it uses stage-2 class property transform feature.
class MyComponent extends React.Component {
    go = () => {
        // ...
    }
    render() {
        return (
            <button onClick={ this.go }>Click here</button>
        );
    }
}

And I want to spy go.
it('should call go when it is clicked', function() {
    const component = shallow(<MyComponent />);
    const goSpy = sinon.spy(component.instance(), 'go');

    component.simulate('click');

    // myMethod is executed, but ...
    sinon.assert.calledOnce(goSpy); // throws!
});

You need to spyOn(NavBar.prototype, 'handleClick') before you call shallow.

Since I'm using class property transform,  go is not defined on the prototype of MyComponent; so I can't apply your advice here.
In #586 as workround is suggested to use forceUpdate; something like:
it('should call go when it is clicked', function() {
    const component = shallow(<MyComponent />);
    const instance = component.instance();
    const goSpy = sinon.spy(instance, 'go');

    // this make the trick
    instance.forceUpdate()

    component.simulate('click');

    sinon.assert.calledOnce(goSpy); // it works now!
});

I would like to ask you, what do you think about this approach?

Right - that should be a prototype method, and explicitly not a class property arrow function.
In other words, go() { … }, and in the constructor, this.go = this.go.bind(this);. Then you can spy on it just fine, without needing forceUpdate.
Class properties are for data - methods are for functions. If you're installing a function as a property that's anything more than a bound method, you're doing something subpar.

do we really need to make component more complicated/verbose just to be able to make the test working? I'd actually prefer the forceUpdate() approach. Yet as there is side effect of update being called twice I wonder if there may be a way to spy on the arrow after component instance has been called yet before the render i.e. kind of sinon.stub(SomeComponent.prototype, "componentWllUpdate") yet this seems more verbose unless done as some common util.

It's not just for that; it's more performant, because the optimized instance method is shared across all instances.
Arrow function class properties are an antipattern.

Actually I can see exactly same behavior with
class SomeComponent extends Component {
    constructor(props) {
        super(props);
        this.handleClick = this.handleClick.bind(this);
    }

    handleClick() {
        console.log('foo');
    }

    render() {
        return foo
    }
}

and
import React from 'react';
import {mount, shallow} from 'enzyme';
import sinon from 'sinon';
import {expect} from 'chai';
import SomeComonent from '../../src/some-component';

describe('some component', () => {
    it('should call handleClick', () => {
        let component = shallow(<SomeComonent/>); // tried with both shallow and mount
        const instance = component.instance();
        const handleClickSpy = sinon.spy(instance, 'handleClick');
        // instance.forceUpdate(); // this is required for test to pass
        component.find('a').simulate('click');

        expect(handleClickSpy.called).to.equal(true);
    });
});

and I can imagine the reason is also the same as for arrow function - onClick={this.handleClick} is bound before the spy updates this.handleClick.
As for performance of the arrow functions - while they are assigned to instance property I don't thing there is an issue.  For sure using arrow functions as instance properties is not optimal yet it seems to me as comparable solution and it is at least the least verbose one.

Yes - because you should sinon.spy(SomeComponent.prototype, 'handleClick') prior to calling shallow.
It's definitely an issue, because if you create 1000 instances, you have 1000 arrow functions, whereas in the constructor-bound example, you have 1000 tiny bind-proxy-functions to 1 shared and optimized prototype function.

I'm somehow confused now as according to this jsperf test arrow functions performs significantly better then pre-bound functions on recent versions FF/Chrome/Safari. Also according to this pretty old artice arrows perform better in terms of memory as well. Was not able to find anything more details yet would be happy to read any recent detailed analysis or benchmark...

jsperfs are fun toys, but micro benchmarks aren't reliable for drawing useful conclusions.
It's possible that browsers have done well optimizing the use case, but that old article predates any shipping spec-compliant arrow functions, so any performance claims it makes are invalid.
At any rate, I'm saying that constructor-bound functions are both more testable and more conceptually performant, so that's what you should use if you're having trouble with per-instance functions.

I'd really love to learn more about this, could you point me to some resources? I still guess it would be great to have it just measured in some way.

@jamby no need to bind anything:
class MyComponent extends Component {
    handleClick = () => {
        // ...
    };
}

@streamich please read the rest of the thread: https://github.com/airbnb/enzyme/issues/697#issuecomment-265674332

@ljharb Why should I create an extra function at runtime just to be able to spy on it in my tests?

@streamich I don't think you're understanding. Using functions in class properties is incorrect, first and foremost - that it's also slower (because that is what creates unnecessary functions) and harder to test is secondary.

@ljharb I don't think you're understanding. You are suggesting to create two functions to handle an event. Let's say I want to handle a click event. What you are saying is I should first create a function on my component's prototype:
class MyComponent extends Component {
    onClick() {
        // ....
    }
}

And then you say I should create another function, by binding my function I just created on the prototype:
this.onClick = this.onClick.bind(this);

Effectively setting a class property :smile: as a function, which you then go and say is the incorrect way to do.

Using functions in class properties is incorrect

Why? When you bind that function, you are setting a class property as a function.
My approach is much more succinct and creates only one function:
class MyComponent extends Component {
    onClick = () => {
        // ....
    }
}

@streamich I think you're missing the nuance of the issue, see https://github.com/airbnb/enzyme/issues/697#issuecomment-286643955

It's definitely an issue, because if you create 1000 instances, you have 1000 arrow functions, whereas in the constructor-bound example, you have 1000 tiny bind-proxy-functions to 1 shared and optimized prototype function.

@ljharb is stating that when you bind a method you're creating a more "lightweight" proxy to the original method, while defining the function as a class property will result in a full function instance for each component instance.

Effectively setting a class property 😄 as a function, which you then go and say is the incorrect way to do.

He explicitly said (emphasis mine):

If you're installing a function as a property that's anything more than a bound method, you're doing something subpar.

@aweary Re: 1000 arrow functions: some components are used only once in an app, but this implies that a component is used 1000 times.
OK, let's say component is used 100 times, this is an interesting topic, which is faster? An arrow function or Function.prototype.bind?

... when you bind a method you're creating a more "lightweight" proxy ...

Is there something I can read about this? Googling I find this:

However yes, when it matters - .bind is slower

And the Google's style guide:

Prefer using arrow functions over f.bind(this).

This jsperf shows that arrows functions and .bind are approximately equally fast (on my computer arrow function is actually 10% faster).
I mean, honestly, I don't know which one is faster, if you show me a link to a benchmark that shows that for React bound functions are just "lightweight proxies" and are like 2x faster than arrow functions, I would happily use the bind method instead.

He explicitly said (emphasis mine):

If you're installing a function as a property that's anything more than a bound method, you're doing something subpar.

So how is it subpar? Especially, given that arrow function is basically a bound method in this case.

I'll defer to @ljharb for resources on the topic. Though I consider him to be a direct resource in cases like this since he is an active member of TC39. I imagine you can find some information in the ECMAScript spec about how bound functions are defined.

This jsperf shows that arrows functions and .bind are approximately equally fast (on my computer arrow function is actually 10% faster).

Putting aside the fact that micro-benchmarks are rarely representative of real-world performance, this benchmark isn't even testing what we're talking about. We're discussing defining methods on a class that may have a high number of instances at once (a ListItem component, for example).
Here's a benchmark that actually tests this case:
https://esbench.com/bench/59b9b35299634800a03490f7
It defines two classes, one with a bound method and the other with a class property, and then creates and tracks 1000 instances and calls the method. Testing in Chrome, I'm seeing that the bound method is >2.5 times faster.

@aweary In this micro-benchmark I see the bound method to be around 2x faster. However, I think it is such because (1) it is specifically constructed to favor bind; (2) I don't think it test what we are talking about.
(1): if you increase the number of iterations from 1K to 1M, for example, I see that arrow function is actually slightly faster.
(2): a more like a real-world scenario would be to execute results.push(instance.method(i)) many times, say 100 or 1000, in that case, I also see arrow function being faster, sometimes 25%.

The performance seems to depend significantly on the way we're benchmarking. Also there is significant difference between using just an arrow function and the requirement to bind it in a constructor especially when there is no other need for a constructor at all. I.e.
// ...
constructor(props) {
        super(props);
        this.handleClick = this.handleClick.bind(this);
    }
// ...

seems to be unnecessary syntax bloat.
Why not expect from the JS engine and/or transpiler to provide desired performance - like i.e. recent node version improved enough on delete foo.bar which allow to avoid unnecessary gimmick (it's just an example, I know here is not a right place to mention mutating an object at all ;)

I see that bind is faster even with 1M iterations, though that's even less representative of real-world scenarios. The benchmark is not crafted to favor bind, it's the simplest case for both scenarios. It's also testing exactly what we're talking about, which is binding methods to instances in the constructor vs defining them as class properties.
Ultimately, it's up to you which approach you want to use. You should make decisions based on the actual performance of your application (which you should be measuring) not on the results of non-representative micro-benchmarks.
There may also be a difference between what's practically performant and conceptually performant, depending on the current JS engine optimizations. What's fast now might not be fast in a few months.
Ultimately, in the context of Enzyme, there are issues with spying on functions defined as class properties. If that's an acceptable trade off for a more succinct syntax, that's your call.

I see that bind is faster even with 1M iterations

Are you sure? I see arrow function being 5% faster with 1M iterations, also on Chrome.

...though that's even less representative of real-world scenarios.

The point (2) in my post dealt with being re-presentable of real-world scenarios.

Just because something (functions as class properties) is attractive, doesn't mean it's the right path, or that it has a good DX.
Using functions in class properties "because of the dev xp" is optimizing for short-term DX at the expense of long-term DX.

@ljharb, I'd really love to learn more about the right DX related to this case as I can see a lot of contradicting comments and articles without any clear directions and I've already asked this question and haven't seen here any deep arguments agains the arrow function solution.
One thing I'm personally pretty sure is that it's good to avoid excessive syntax and I'm not convinced so far there is anything fundamentally wrong with using arrow functions for this particular case which means for me it's worth to join support to make developers life easier not harder and not to prefer just one approach over another (like i.e. React vs AngularJS) but just to aim less verbose code which in general should be doable one way or another.
Using arrow functions is kind of ready solution with some drawback which should be possible to be eliminated - why not focus on this part instead of trying to cut off the discussion claiming this is just a bad design (while it does not have to be necessarily true).

In no particular order, using arrow functions in class properties:

makes things much harder to stub out, since you can't stub the prototype prior to instantiating the element, before things have grabbed an immutable reference to the function
is slower, since the engine can't optimize the N function bodies (as opposed to the prototype approach where it can optimize the 1 shared body)
is less correct, since it's abusing class properties (meant for instance data) for the sake of binding what should conceptually be an instance method
is less clean than a closed-over function in the module that takes the component as an argument anyways, since it (just like a prototype method) expands the public API, since everything reachable is public, full stop
involves a stage 3 feature, which thus isn't yet part of the language, whereas instance methods and constructor-bindings are part of ES6 for years now

Regardless, you obviously can continue to use them - but then you're just going to be SOL for testing the functions directly, or stubbing them out. Not sure what else to tell you.

I agree with your points @ljharb. Because the facts you state are correct. But I would challenge your approach to the issue at hand - Whether you like it or not a whole bunch of people seem to like their class property/arrow function combo quite a lot. The trade off between more succinct code and (potentially premature) optimisation should be in the hands of the engineer. My advise to you is to consider supporting engineers in either of the two paths that they decide to settle for. Rather than pushing the path that you've opted for on everyone else. Just my two cents.

@hally9k enzyme has zero ability to obstruct users from doing that; however, there have been a large quantity of issues filed on this repo where the solution is "if you want to test it properly, you can't use arrow functions in class properties". In other words, engineers already do, and will continue to, have the decision in their own hands - but this being a testing tool, if one is interested in proper testing, arrow functions in class properties simply aren't a viable option.

I suppose the difficulty here is that you know exactly how this thing ticks so it seems like a simple decision when you have the visibility. Is there a piece in the documentation that outlines the order of operations and differences between testing methods on the prototype and on the instance? This does seem to be something that trips a few people up. If not I'll see if I can get to the bottom of it and contribute. @ljharb Thanks for all the awesome work by the way, it is appreciated.

There's nothing that can be done; the typical usage in user code is that they pass it into enzyme, the component installs the arrow function as a class property on the instance during the constructor, then the component is rendered, and the arrow function is passed (and thus held, by reference/identity) as a prop. Then, whether the user has spied on the method before construction, or after rendering, the spy has no effect. The proper method is to spy on the prototype method prior to creating the wrapper, bypassing the problem.

I don't think you wired your spy up correctly try moving your spy above your shallow function like this:
describe("COMPONENTS: <NavBar />", function() {
  it("simulates click event for acceptingChats false", function() {
    let handleClick = jest.spyOn(FavoriteProduct.prototype, 'handleClick');
    const rendered = shallow(<FavoriteProduct {...props} />);
    rendered.find('a').simulate('click');
    expect(handleClick).toHaveBeenCalled();
  });
});

@ljharb Besides possibly sub-classing the component with arrow bound method, is there another way to stub/spy on such methods before component mount/shallow ?

@pgilad the only way is to fix the implementation to avoid arrow functions in class fields.

I use such approach for arrow functions (instead of jest.spyOn when I need to keep original functionality):
const wrapper = shallow(<MyComponent />);
const instance = wrapper.instance();
instance.someMethod = jest.fn(instance.someMethod);

Using this approach I can simulate clicks and they are tracked via mock(doesn't work with jest.spyOn + simulate) and original functionality of this method works as well

Spies are on object properties, not on functions - as such, once the  is rendered, it keeps an immutable reference to the original function. You need to spyOn(NavBar.prototype, 'handleClick') before you call shallow.

I wish this was written somewhere in docs!

@deep-kiran a PR adding it would be welcome


possible indeterminism in wasm via memcmp

we farm out memcmp to the system's memcmp, however the c specification states that memcmp only needs to return less than 0, 0, or greater than 0. It's implementation specific how much less than or greater than 0 it is.

Resolved by #3707.


Prepare release v0.2.0

Please let me know what you think

resources/PhoneNumberMetadata.xml appears to be out of date compared to Google's repository. Is this intentional?

@brolaugh yes, the included file corresponds to the release 8.10.2 of the original lib

@brolaugh yes, the included file corresponds to the release 8.10.2 of the original lib

Could you add information in the release about and maybe in the README about which metadata version is being used? That would make it easier to see how updated the repo is since it doesn't follow the same version numbers as the original lib.


critical vulnerabilities affect this package?

See here: https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/
Is that an issue here?

This package uses PyJWT which addressed those vulnerabilities.


Support for binary images

I need a way to represent an image mask, i.e. an overlay on an image that indicates which pixels are included and which are not. This implies a binary image type backed by bool primitives. To my knowledge this is unsupported in the image crate because Pixel has no corresponding implementation, nor is there an appropriate member of color::ColorType.
I'm filing this issue as a feature request that a new Binary color type and corresponding pixel type be implemented, allowing representation of binary images. I understand this could be a challenge as Primitive used by Pixel implies traits like Num and NumCast that might be hard to reconcile with bool. So I'm not getting my hopes up, but I want to put the request out here in case it can be resolved at some time in the future.

Alternate request: make modules buffer and color public so I can attempt my own implementation of a binary image.

Attempting my own implementation using a copied version of the define_colors! macro and Blend and Invert, I can get very close to a binary image implementation very quickly. However, the need for bool to implement Primitive and thus Num/NumCast/Bounded is not something I can address on my own since I don't own any of those traits.


The deleted snapshot doesn't auto disappear for one ADLS Gen2 blob

Storage Explorer Version: 1.14.1
Build: 20200710.5
Branch: hotfix/1.14.1
Platform/OS: Windows 10/ Linux Ubuntu 18.04/ macOS Catalina
Architecture: ia32/x64
Regression From: Not a regression
Steps to reproduce:

Go to 'Settings' -> 'Services' -> 'Storage Accounts' -> Enable the setting 'Enable ADLS Gen2 snapshots (preview)' -> Restart Storage Explorer.
Expand one ADLS Gen2 storage account -> Blob Containers.
Create one blob container -> Upload one blob to it -> Right click the blob then select 'Create Snapshots'.
Switch to snapshots view -> Try to delete the snapshot.
Check the result.

Expect Experience:
The snapshot auto disappears.
Actual Experience:
The snapshot doesn't auto disappear.
More Info:

The snapshot disappears after manually refreshing.
The behaviors are same whenever the setting 'Auto-refresh on change' is enabled or not.

For craig to investigate when he gets back. Make sure that things are consistent, or that at least gen2 is respecting the auto refresh setting if possible.

The problem is the promote job handler passes an IBlobContainerRef argument with the refresh event, but the handler in the explorer view model is expecting an IBlobContainerConnection. So, the isMatchingContext function doesn't return true, and the editor refresh doesn't occur.

Hi @craxal Verified this issue on build master/20200812.2. Still reproduce. So we are going to re-open it.

@v-xianya The Cloud Explorer reference was not up to date for 20200812.2. Please verify again with a newer build.

Hi @craxal Thanks for the updates. Verified this issue on build master/20200813.4. Fixed.


Testing, please ignore. (lzzchw)

Please ignore.. Please DO NOT APPROVE THIS! (lzzchw)

Hi @helumanxa,
Thank you for contributing this pull request!
Please sign the Kaltura CLA so we can review and merge your contribution.
Learn more at http://bit.ly/KalturaContrib


Support pointer of the same struct type in struct definition

Currently, there's no way to define a type that would translate to the following C struct definition:
typedef struct  {
int32_t x01;
struct t* x10;
}
t;
I have tried to use
type t =
| T: Int32.t -> Buffer.buffer t -> t
But what this translates to is
typedef struct {
int32_t x01;
t* x10;
}
t;
which does not work for C.

0b2f9a9d7f5ffb4287b319bd1d520e3243f6cc18
Thanks for the bug report!
PS: this change introduced another bug which shall be fixed shortly, so this is a little bit broken right now


Fact refresh deploying resource that no longer exist

Problem
1.if a resource has an UNKNOWN parameter
2. we keep refreshing that on the latest version of the resource

i.e. not the latest released version
and we keep refreshing if the resource doesn't exist in the latest version

which causes code reloading issues

and we never remove the UNKNOWN (as long as its assoicated version exists)

Affects iso7 for sure, probably also iso8


TypeError: Cannot use 'in' operator to search for 'data' in null

I got the following error.
TypeError: Cannot use 'in' operator to search for 'data' in null     at Object.compile (/node_modules/handlebars/dist/cjs/handlebars/compiler/compiler.js:467:19)     at HandlebarsEnvironment.hb.compile (/node_modules/handlebars/dist/cjs/handlebars.js:34:41)     at ExpressHandlebars._compileTemplate (/lib/express-handlebars.js:239:28)     at ExpressHandlebars.<anonymous> (/lib/express-handlebars.js:124:25)     at /promise/lib/core.js:33:15     at flush (//node_modules/promise/node_modules/asap/asap.js:27:13)     at process._tickCallback (node.js:419:13)
After a bit of searching I found out that the file in the dist folder (compiler.js) missed the options = options || {} thus giving the null error. Adding that line solves the error. (The same code worked with 3.0.1 and stopped working with 3.0.2).
Further inspection shows handlebars/lib/handlebars/compiler/compiler.js:448 the compile functions parameter options = {}, is the problem. I'm using express and express-handlebars, and they don't support es6? Not sure.

express-handlebars is defaulting the handlebars configuration to null vs. undefined. The reason that the prior code worked was that it was attempting to save a few bytes vs. the more correct parameter handling the the new es6 code compiles to.
https://github.com/ericf/express-handlebars/blob/d5e664b99c75747a5251343b5a98f8da32ca0ae5/lib/express-handlebars.js#L31
I'm not certain the best path here as it feels like passing null for defaults if fundamentally wrong and the behavior seen previously was an artifact of the implementation vs. an intentional API. While sorting out wether this is something that handlebars or express-handlebars should fix, I'd recommend passing in compilerOptions: undefined to express-handlebars. That appears like it will fix the issue in the near term without having to pin any libraries.
/cc @ericf

@kpdecker +1 for compilerOptions: undefined as a temporary workaround.

@kpdecker thanks, that's a good workaround.

+1 for the workaround... but this is only a temporary. I'll look into a fix for this as well.

@kpdecker so what have you decided on this issue? Are you planning to make a change to Handlebars to add back the falsy check that was removed in the ES6 conversion?
Given that the ES6 conversion was released as a patch release it seems that your intention was purely for authoring style and cosmetics and not to semantically change the APIs. So my vote would be to add back the falsy check that was removed. If you don't plan to go that route, then close this as wontfix, and I'll update Express Handlebars to deal with the API change.

Closing this as while it's a bit unfortunate that it caused issues, I can argue that it's semantically equivalent in my mind, simply following the languages newly codified spec for what defined is, and rolling a major update for a small change seems like unnecessary overhead for the ecosystem as a whole.

It clearly wouldn't be a major update. This could have been a simple: unpublish of 3.0.2, add back the removed falsy check, and publish 3.0.3. Maybe if more issues arise with this refactor you'll be up for reconsidering…

He issue is we can not move forward with es6 defaults if we handle null.
I'm leaving the behavior as is. Please use undefined for your defaults or
better yet, omit the field.
On Wed, Apr 22, 2015 at 10:00 AM Eric Ferraiuolo<EMAIL_ADDRESS>wrote:

It clearly wouldn't be a major update. This could have been a simple:
unpublish of 3.0.2, add back the removed falsy check, and publish 3.0.3.
Maybe if more issues arise with this refactor you'll be up for
reconsidering…
—
Reply to this email directly or view it on GitHub
https://github.com/wycats/handlebars.js/issues/1003#issuecomment-95222335
.

He issue is we can not move forward with es6 defaults if we handle null.

This is not true, these are not mutually exclusive. The function can still do type checking for null.

Official stance is that null is not supported.
On Thu, Apr 23, 2015 at 10:42 AM Eric Ferraiuolo<EMAIL_ADDRESS>wrote:

He issue is we can not move forward with es6 defaults if we handle null.
This is not true, these are not mutually exclusive. The function can still
do type checking for null.
—
Reply to this email directly or view it on GitHub
https://github.com/wycats/handlebars.js/issues/1003#issuecomment-95628783
.


Re-scanning complete Tumblr

I have been current with the download of several hidden Tumblrs. After a new login (not sure whether this is the cause) it is COMPLETELY re-scanning all hidden Tumblrs. Not sure how to reproduce, but it happened in the past and was gone some day.
Expected behavior
Scanning only for updates since the last successful download, not the complete Tumblr.
Desktop (please complete the following information):

TumblThree version: <IP_ADDRESS>
OS: Windows 10 Professional
Browser Edge
Version 97.0.1072.55

Is 'force rescan' checkbox is checked? In app settings or blog settings.

Portable shouldn't trigger anything. But Force rescan should do thing that you talk about. Don't know any other reasons for app to rescan blogs.

Screenshots

@stuwm
Login is only a precondition, but not affecting the way or result of scanning. Do you have the problem with all your hidden blogs or only some? Is there a recent (last few weeks) post in the affected blogs or are they older?
When you experienced it in the past, did it disappear after you updated to a new version or within the same version?
What's the LastId value in the blog files, 0 or some big number?
When you start the app and download one of your affected blogs, can you see an error in TumblThree.log (should be in the local folder for portable mode)?

The problem is that the blog's post list isn't in chronological order when the blog owner uses a pinned post. The id from the pinned post was saved as last id, always crawling until that id again. The id of the first non-pinned post is saved now.
It's fixed in the next version.

The issue has been fixed and closed. You can still comment. Feel free to ask for reopening the issue if needed.


beam_PostCommit_XVR_GoUsingJava_Dataflow fails on some test transforms

Example failure: https://ci-beam.apache.org/job/beam_PostCommit_XVR_GoUsingJava_Dataflow/7/
I couldn't find accurate details about why the tests are failing, but TestXLang_Prefix, TestXLang_Multi, and TestXLang_Partition are failing while running for some reason. Investigating the Dataflow logs, we can see SDK harnesses are failing to connect for some reason. For example:

"getPodContainerStatuses for pod "df-go-testxlang-multi-03300551-62xv-harness-3msv_default(a7f1d8dfb2c3d2b4e80f5d92c1728787)"
failed: rpc error: code = Unknown desc = Error: No such container: bea0d9bde42bf890f6fe1d4f589932471037a5948fb9588d01a06425cd14c177"

However I haven't been able to find any further details showing why the harness fails, and the tests keep running beyond that for a while with other errors that are also pretty inscrutable.
Imported from Jira BEAM-14214. Original Jira may contain additional context.
Reported by: danoliveira.

The previous error message appears to be a red herring, as it occurs in test logs that have successful runs. These seem to continue to execute until the container is started up. This message, on the other hand, appears to be the common denominator in failing runs:
"Container not found in pod's containers" containerID="5fa844e1dea9ec63b43e5e42422c6370dd0f746a3b00f496f6397a7db955fd98"

With the containerID being indicated as started in the log message before.

@jrmccluskey so is this still an issue? are you working on it or should we unassign?

This went on the back burner for other work, hoping to dedicate some time to it next week

Is this fixed? Or perhaps so back-burner that it should be unassigned for someone else to grab? Is there a mitigation so that it would not impact test signal and not be a stale P1?

This suite is perma-red. Should we disable a test? I don't think we should just burn jenkins CPU and person time triaging this repeatedly, considering how long it has been going on.

Yeah we're probably at that point

There are currently 3 failing tests:
--- FAIL: TestXLang_Prefix
--- FAIL: TestXLang_Multi
--- FAIL: TestXLang_Partition

In particular, the worker log for TestXLang_Partition has
Harness ID sdk-1-0
...
2023-06-27 11:23:08.154 EDT Connecting via grpc @ localhost:12371 for data ...
2023-06-27 11:23:11.692 EDT Worker failed: control.Recv failed
caused by:
rpc error: code = Unavailable desc = error reading from server: EOF
2023/06/27 15:23:11 boot.go: error logging message over FnAPI. endpoint localhost:12370 error: EOF message follows
2023/06/27 15:23:11 CRITICAL User program exited: exit status 1

java.util.logging.LogManager$RootLogger log
SEVERE: *~*~*~ Previous channel ManagedChannelImpl{logId=17, target=localhost:12371} was not shutdown properly!!! ~*~*~*
Make sure to call shutdown()/shutdownNow() and wait until awaitTermination() returns true.
java.lang.Throwable: java.lang.RuntimeException: ManagedChannel allocation site
at org.apache.beam.vendor.grpc.v1p54p0.io.grpc.internal.ManagedChannelOrphanWrapper$ManagedChannelReference.<init>(ManagedChannelOrphanWrapper.java:102)
at org.apache.beam.vendor.grpc.v1p54p0.io.grpc.internal.ManagedChannelOrphanWrapper.<init>(ManagedChannelOrphanWrapper.java:60)
at org.apache.beam.vendor.grpc.v1p54p0.io.grpc.internal.ManagedChannelOrphanWrapper.<init>(ManagedChannelOrphanWrapper.java:51)
at org.apache.beam.vendor.grpc.v1p54p0.io.grpc.internal.ManagedChannelImplBuilder.build(ManagedChannelImplBuilder.java:631)
at org.apache.beam.vendor.grpc.v1p54p0.io.grpc.internal.AbstractManagedChannelImplBuilder.build(AbstractManagedChannelImplBuilder.java:297)
at org.apache.beam.sdk.fn.channel.ManagedChannelFactory.forDescriptor(ManagedChannelFactory.java:101)
at org.apache.beam.fn.harness.data.BeamFnDataGrpcClient.lambda$getClientFor$0(BeamFnDataGrpcClient.java:105)
at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at org.apache.beam.fn.harness.data.BeamFnDataGrpcClient.getClientFor(BeamFnDataGrpcClient.java:99)
at org.apache.beam.fn.harness.data.BeamFnDataGrpcClient.createOutboundAggregator(BeamFnDataGrpcClient.java:93)
at org.apache.beam.fn.harness.control.ProcessBundleHandler$1.lambda$addOutgoingDataEndpoint$0(ProcessBundleHandler.java:394)
at java.util.HashMap.computeIfAbsent(HashMap.java:1128)
at org.apache.beam.fn.harness.control.ProcessBundleHandler$1.addOutgoingDataEndpoint(ProcessBundleHandler.java:391)
at org.apache.beam.fn.harness.BeamFnDataWriteRunner$Factory.createRunnerForPTransform(BeamFnDataWriteRunner.java:94)
at org.apache.beam.fn.harness.BeamFnDataWriteRunner$Factory.createRunnerForPTransform(BeamFnDataWriteRunner.java:62)
at org.apache.beam.fn.harness.control.ProcessBundleHandler.createRunnerAndConsumersForPTransformRecursively(ProcessBundleHandler.java:307)
at org.apache.beam.fn.harness.control.ProcessBundleHandler.createRunnerAndConsumersForPTransformRecursively(ProcessBundleHandler.java:261)
at org.apache.beam.fn.harness.control.ProcessBundleHandler.createRunnerAndConsumersForPTransformRecursively(ProcessBundleHandler.java:261)
at org.apache.beam.fn.harness.control.ProcessBundleHandler.createBundleProcessor(ProcessBundleHandler.java:858)
at org.apache.beam.fn.harness.control.ProcessBundleHandler.lambda$processBundle$0(ProcessBundleHandler.java:511)
at org.apache.beam.fn.harness.control.ProcessBundleHandler$BundleProcessorCache.get(ProcessBundleHandler.java:969)
at org.apache.beam.fn.harness.control.ProcessBundleHandler.processBundle(ProcessBundleHandler.java:507)
at org.apache.beam.fn.harness.control.BeamFnControlClient.delegateOnInstructionRequestType(BeamFnControlClient.java:150)
at org.apache.beam.fn.harness.control.BeamFnControlClient$InboundObserver.lambda$onNext$0(BeamFnControlClient.java:115)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.beam.sdk.util.UnboundedScheduledExecutorService$ScheduledFutureTask.run(UnboundedScheduledExecutorService.java:163)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
INFO 2023-06-27T15:23:12.749328456Z
at org.apache.beam.fn.harness.logging.BeamFnLoggingClient.flushFinalLogs(BeamFnLoggingClient.java:385)
at org.apache.beam.fn.harness.logging.BeamFnLoggingClient.lambda$new$0(BeamFnLoggingClient.java:168)
at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1604)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.apache.beam.sdk.util.UnboundedScheduledExecutorService$ScheduledFutureTask.run(UnboundedScheduledExecutorService.java:163)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)

The xlang harness fails to "logging message over FnAPI"
CC: @lostluck  @riteshghorse

Cham - should this be disabled? I am happy to do the PR if you want to comment and assign to me.

I think there was a recent fix to UW related to this that is not in prod yet.
cc: @robertwb

Any update on this P1?

Seems like Just Kafka test is failing now but other tests are passing. Have to check closely to see why the Kafka Go test is failing.
14:25:33 --- PASS: TestBigtableIO_BasicWriteRead (632.92s)
14:25:33 PASS
14:25:33 ok  	github.com/apache/beam/sdks/v2/go/test/integration/io/xlang/bigtable	635.947s
14:25:33 === RUN   TestDebeziumIO_BasicRead
14:25:33     integration.go:364: Test TestDebeziumIO_BasicRead is currently filtered for runner dataflow
14:25:33 --- SKIP: TestDebeziumIO_BasicRead (0.00s)
14:25:33 PASS
14:25:33 ok  	github.com/apache/beam/sdks/v2/go/test/integration/io/xlang/debezium	3.026s
14:25:33 === RUN   TestJDBCIO_BasicReadWrite
14:25:33     integration.go:364: Test TestJDBCIO_BasicReadWrite is currently filtered for runner dataflow
14:25:33 --- SKIP: TestJDBCIO_BasicReadWrite (0.00s)
14:25:33 === RUN   TestJDBCIO_PostgresReadWrite
14:25:33     integration.go:364: Test TestJDBCIO_PostgresReadWrite is currently filtered for runner dataflow
14:25:33 --- SKIP: TestJDBCIO_PostgresReadWrite (0.00s)
14:25:33 PASS
14:25:33 ok  	github.com/apache/beam/sdks/v2/go/test/integration/io/xlang/jdbc	3.026s
14:25:33 === RUN   TestKafkaIO_BasicReadWrite
14:25:33     integration.go:364: Test TestKafkaIO_BasicReadWrite is currently filtered for runner dataflow
14:25:33 --- SKIP: TestKafkaIO_BasicReadWrite (0.00s)
14:25:33 PASS
14:25:33 ok  	github.com/apache/beam/sdks/v2/go/test/integration/io/xlang/kafka	6.027s
14:25:33 FAIL

It has been perma-red for a long time though (https://ci-beam.apache.org/job/beam_PostCommit_XVR_GoUsingJava_Dataflow/)
I think we should downgrade this to P2 since it seems to be more of a "new feature" and is not monitored by a human.

Closing this issue since we're off jenkins and different issues now occur. #28339 tracks more recently.


fix: Add debugging information for JS supported dependencies

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

v0.49.3
GitHub release

Your semantic-release bot :package::rocket:


feat(new-docs): add TSDoc comments to WebWorker

@jackfranklin Thanks for the review! Slowly getting the hang of this :)

@AVGP one small comment then I think we can ship this!


Simple nested structs tests

Hi,
I am not sure whether there are already tests of GEP that walk into nested structs. Here are a few simple ones :)
Thanks,
Zikai

Hi, thank you for the tests!
Just one thing: I see one commit (the one from october 21) that has already been merged, can you please remove it together with the merge commit? After doing this, you can also squash the two commits with the changes (also please use capital letter after colon in the commit message), or leave them as they are and I will squash them before merging.

Hi, thank you for the tests!
Just one thing: I see one commit (the one from october 21) that has already been merged, can you please remove it together with the merge commit? After doing this, you can also squash the two commits with the changes (also please use capital letter after colon in the commit message), or leave them as they are and I will squash them before merging.

I also wonder why there is the dangling commit. Maybe I didn't do it right when merge the upstream.
It's done now (also merge the fix commit).

Hi, thank you for the tests!
Just one thing: I see one commit (the one from october 21) that has already been merged, can you please remove it together with the merge commit? After doing this, you can also squash the two commits with the changes (also please use capital letter after colon in the commit message), or leave them as they are and I will squash them before merging.

I also wonder why there is the dangling commit. Maybe I didn't do it right when merge the upstream.
It's done now (also merge the fix commit).

Thanks a lot!


Open source license designation is missing from project

The designation of the open source license type appears to be missing from the project and should be added to provide certainty about the open source status and use by other projects etc.
Suggest MIT license per https://github.com/bitcoin/bitcoin?tab=MIT-1-ov-file#readme

Thanks, fixed with commit 180e1415f2f729323c9d792df2368aee9d282168. Closing it now.


Pretrained model file

I appreciate your effort. It helps me a lot :)
It would be very helpful if you could share the pretrained model file for XS or XXS.
thank you,

Yes, no problem.
But I had not trained the xs or xxs version of the model in the past.
I will provide the xxs version weights in a few days, because I need few days to train the model.

Thank you I am looking forward to it :)