Score doesn't increment as it should

Describe the bug
Score should increment every time you pass a wall
To Reproduce
Steps to reproduce the behavior:

Start the game
Try to pass a wall
Score would still be 0

Expected behavior
The score should increment every time you pass a wall
Screenshots
Non needed
Desktop (please complete the following information):

Browser Microsoft Edge

Additional context
Add any other context about the problem here.

Duplicate of #20


Long press share not working with GitHawk signature

Bug Report Dump (Auto-generated)

Version 1.21.0<PHONE_NUMBER>)
Device: iPhone X (iOS 11.4)
TestFlight: true

Oooh that’s an actual web view. I guess it doesn’t work out if the box?
Sent with GitHawk


Update Xamarin.Forms Dependency to v<IP_ADDRESS>3

This Pull Request increases the Xamarin.Forms dependency to v<IP_ADDRESS>3.
This is required to accommodate a breaking change introduced in Xamarin.Forms v<IP_ADDRESS>3, as noted in the Release Notes for Xamarin.CommunityToolkit v1.2.0:

The upcoming version of Xamarin.Forms induces a breaking change in Xamarin.CommmunityToolkit by increasing its Xamarin.AndroidX.Core dependency.
In our next release, v1.3.0, we will increase our Xamarin.Forms dependency to use this new version of Xamarin.Forms and resolve the breaking changes.

Hey @brminnick , unrelated to this PR but also related to this PR. I know XF5 SR4 release just a few hours ago, and this was made a few hours ago, but is the path to v1.3.0 expected sooner rather than later or is there still some unknowns that need to be resolved?

Hey Brad! We'll be releasing v1.3.0-pre1 as soon as this PR is reviewed + merged.


Support Enforcement of Descriptions and Tests as a Config Option

Describe the feature
Would anyone be interested in config settings, that could enforce documentation and tests for models? Eg.
# dbt_project.yml
name: 'my_project'
version: '1.0.0'
...
models:
  my_project:
      +require_descriptions: true
      +required_tests:
          - not_null
          - unique
...

and models in the resource path with empty descriptions or without the required tests will result in a failed run/compilation?
Currently we implement these approaches with custom scripts in our CI that parse the manifest.json. I think it would be wonderful if these became builtin options for others to use easily.
Describe alternatives you've considered
Basically parsing the manifest with a python script in the CI. This is sort of a hack.
Who will this benefit?
Adding this optionality in reduces the onus on reviewers to call out missing docs/tests. This helps teams who want to really automate their deployments of dbt. Ideally to the point that something is in the prod database/schema etc as soon as it is merged.
Allowing the option to enforce tests/docs along model paths reduces unnecessary dialogue on PRs: if the CI passes, and these options are enabled, then the submitter has already done their diligence.
Are you interested in contributing this feature?
I am interested in working on this, and am creating this ticket to get feedback and track work on it.

Hmmm. Interesting idea! Thanks for writing up this detailed proposal, @tnightengale. I'd be really curious to hear what other community members think. Here are my two cents:

I agree that enforcing expectations for test and documentation coverage is highly valuable in CI. But... I could see this as being such a pain in development, when you write a model and go to run it only to find that you first have to supply a dummy description and tests on an arbitrary column. (Nothing worse than forgetting to remove those dummy entries, and later catching in PR review or CI checks.) Nor am I a big fan of this answer:

  my_project:
      +require_descriptions: "{{ 'true' if target.name != 'dev' else 'false' }}"

This feels like add-on tooling. I see it in the same category as linters and code generators (e.g. codegen, dbt-helper), which totally have a place in the dbt ecosystem but not in the dbt core codebase per se.

Basically parsing the manifest with a python script in the CI. This is sort of a hack.

I think this feels hackier today than it really is, or ultimately should be. We're stabilizing and documenting the schema of the manifest in dbt v0.19.0. I would love nothing more than for these scripts to be open sourced and widely tested.
I believe that such a check could even be written as a Jinja macro. In that case it could be (a) executed as a run-operation within a CI job definition, and (b) open sourced as a dbt package, and pinned to supported dbt versions.

This exists already via this option
https://github.com/offbi/pre-commit-dbt
or this option
https://github.com/tnightengale/dbt-meta-testing


Unread messages notification (from in a chat) has too much left padding

No content

Issue created by BlueBubbles Bot in the BlueBubbles commnity on behalf of @zach in #feedback.

Fixed on nullsafety


New tutorial: Analyzing CMIP6 data with Climate Science JupyterLab

New tutorial for Climate Science.
questions:

Why using Climate data from the Coupled Model Intercomparison Project (CMIP) Phase 6?
How to use CMIP6 data with Galaxy Climate JupyterLab?
What is pangeo software ecosystem and how to use it to analyze climate data?
objectives:
Learn about Climate data from the Coupled Model Intercomparison Project
Learn to use Climate historical and Climate projections data
Learn about Pangeo Software Ecosystem
Learn to analyze CMIP6 with Galaxy Climate JupyterLab

@Shorla Excellent! The first thing you can do is to go through the training material and try to do what has been written.

Go through the existing material and note/comment on what you do not understand/is unclear
Correct typos or other factual errors
Fix the beginning of the tutorial:

Replace the  Get data section by "Starting Galaxy Climate JupyterLab": for this, you can copy what is
in https://training.galaxyproject.org/training-material/topics/climate/tutorials/fates-jupyterlab/tutorial.html
Step-2: Opening up Climate JupyterLab. After Open the JupyterLab Tool: interactive_tool_jupyter_notebook by clicking here,
add a new step for the creation of a history (copy what is in the current Get data section for the creation of a new history
(remove import the files from zenodo, check datatypes, etc.). We only need to have a clean empty history when starting because
when using Pangeo CMIP6 data, we stream data and do not upload them.
Add a new section (before Plot the snowfall for January between 1985 - 2014 from NorESM2-MM, where we will explore the
Pangeo CMIP6 catalog (we can do something similar to http://gallery.pangeo.io/repos/pangeo-gallery/cmip6/intake_ESM_example.html) org/training-material/topics/climate/tutorials/fates-jupyterlab/tutorialhttp://gallery.pangeo.io/repos/pangeo-gallery/cmip6/basic_search_and_load.html
Add hands-on about the content of the catalog (ask about the name of variables, etc.)

Remove what is not part of the tutorial (from It comes first a description of the step: some background and some theory.
Some image can be added there to support the theory explanation: to # Conclusion.
Add a conclusion about the tutorial.

Do not hesitate to ask questions. Thanks!

@annefou any update on this PR? happy to merge, close or keep open as you see fit, just wanted to get this on your radar again. Thanks!


Stack overflow during grading occurs sooner in the browser than in batch mode

The title says it all: I have written a grader which works in batch mode (when executed via learn-ocaml grade) but fails in the browser (Firefox) with a Stack_overflow exception. This happens when grading the solution of my exercise nondet_monad_cont, which currently is sitting in a pull request in learn-ocaml-corpus. The second half of Question 4 (laziness) is where the grader fails.
Is it possible that the compilation to JavaScript does not do tail call optimization?
Is it possible to somehow ensure that the stack limit is the same under both environments (batch mode and in-browser mode)?
Is it possible for each exercise to indicate what stack size it needs?

Is it possible that the compilation to JavaScript does not do tail call optimization?

Indeed tail call is limited in js_of_ocaml; see the docs.
We use a workaround for Coq https://github.com/ejgallego/jscoq/blob/v8.10/etc/patches/trampoline.patch

Thanks Emilio.
Interesting workaround, which I don't fully understand: doesn't the fact that trampoline itself is tail-recursive still create a problem?
Besides, I suppose that this workaound is applicable to code that is already written in monadic style, but this does not really solve the problem with "normal" code.

Oh, I see, this pattern is recognized by js_of_ocaml.

Indeed, what the workaround does is to help JSOO realize about the tail-rec; for teaching this is a problem indeed.

Does anyone have a suggestion to fix this problem? It's now exposed on the public site.

Does anyone have a suggestion to fix this problem? It's now exposed on the public site.

Hi @fpottier, that's an annoying problem indeed.
FWIW, I recently identified another Stack_overflow problem after I merged learn-ocaml master in the learn-ocaml-editor branch (deployed at https://pfitaxel.github.io/pfitaxel-demo/):

the source of the issue was painful to identify (as there is no backtrace or so) but I pushed a workaround in https://github.com/pfitaxel/learn-ocaml/commit/d337cccf2b276ba51c37784d4d9f69de7f0321bd;
still, this won't be helpful for you as it is orthogonal to your issue: to sum up, mine was directly trigerred by a call to the function descrs_from_string on a large string…
I didn't bisect manually but the first commit that certainly introduced that issue (which didn't occur with the first versions of learn-ocaml/learn-ocaml-editor) is https://github.com/ocaml-sf/learn-ocaml/commit/163b0d12ce6032ceddb40f80a898903fb9d31f49
And unfortunately I don't have a good solution to fix it for the time being, the commit d337ccc being just a raw workaround (replacing the large string with an error message) :-/

Hi @fpottier, that's an annoying problem indeed.
FWIW, I recently identified another Stack_overflow problem after I merged learn-ocaml master in the learn-ocaml-editor branch (deployed at https://pfitaxel.github.io/pfitaxel-demo/):

the source of the issue was painful to identify (as there is no backtrace or so) but I pushed a workaround in https://github.com/pfitaxel/learn-ocaml/commit/d337cccf2b276ba51c37784d4d9f69de7f0321bd;
still, this won't be helpful for you as it is orthogonal to your issue: to sum up, mine was directly trigerred by a call to the function descrs_from_string on a large string…
I didn't bisect manually but the first commit that certainly introduced that issue (which didn't occur with the first versions of learn-ocaml/learn-ocaml-editor) is https://github.com/ocaml-sf/learn-ocaml/commit/163b0d12ce6032ceddb40f80a898903fb9d31f49
And unfortunately I don't have a good solution to fix it for the time being, the commit d337ccc being just a raw workaround (replacing the large string with an error message) :-/


rowData and colData needs to set an empty biocframe object

https://github.com/BiocPy/SummarizedExperiment/commit/2d77759c9b4b0663c37c2e07064fb74a99b21058


Disable ODM test until the issue is fix

Issue: #457
Signed-off-by: lanxia<EMAIL_ADDRESS>

@ShelleyLambert the test has not been disabled. The issue status is in #457 , I can disable it for now.

Yes please.  I thought this had already gone in, in an alternate reality i guess ;)


[SPARK-35175][BUILD] Add linter for JavaScript source files.

What changes were proposed in this pull request?

This PR proposes to add linter for JavaScript source files.
ESLint seems to be a popular linter for JavaScript so I choose it.
Why are the changes needed?

Linter enables us to check style and keeps code clean.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

Manually run dev/lint-js (Node.js and npm are required).
NOTE: This PR only adds linter support. Style errors will be fixed in the followup PRs.

Test build #137736 has started for PR 32274 at commit e2fcd9e.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42263/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42263/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42263/

Test build #137736 has finished for PR 32274 at commit e2fcd9e.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/137736/

Test build #137762 has started for PR 32274 at commit 990e538.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42289/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42289/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42289/

Test build #137762 has finished for PR 32274 at commit 990e538.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/137762/

Does all the current JS pass the linter?

@srowen

Does all the current JS pass the linter?

As I noted in the description, not yet.
I'd like to build a consensus on the basic lint rule in this PR, then I'll fix style based on the rule.

Test build #137903 has started for PR 32274 at commit d6eb61a.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42428/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42428/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42428/

Test build #137903 has finished for PR 32274 at commit d6eb61a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/137903/

Test build #138207 has started for PR 32274 at commit d174384.

@srowen I fixed style based on the current rule and now the linter passes.
Too much style changes included in this PR, so if it's better to do, I'll focus on the linter and separate style change.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42729/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42729/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42729/

Test build #138210 has started for PR 32274 at commit 5bda9fc.

Kubernetes integration test unable to build dist.
exiting with code: 1
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/42732/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/42732/

Test build #138207 has finished for PR 32274 at commit d174384.

This patch passes all tests.
This patch does not merge cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138207/

Test build #138210 has finished for PR 32274 at commit 5bda9fc.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/138210/


Finish the Cuda implementation

For Cuda we can take a lot of the structure alreay implemented for OpenCL.
I also think we should go with implementing the lower-level Cuda Driver API instead of the Cuda Runtime API as it gives us more flexibility and is closer to the OpenCL behavior. Both implementations could be mixed, though.
Thanks to Bindgen, the extraction of the ffi becomes a way easier.

Quite some time has passed since the issue was opened and a significant (usable) part has been implemented.
There are some benefits to having a seperate wrapper crate for CUDA, so that part should be extracted in the future.


[Flatlist] getItemLayout fires multiple times upon every frame scrolled manually

Environment
Environment:
OS: macOS High Sierra 10.13.6
Node: 8.9.4
Yarn: 1.3.2
npm: 5.5.1
Watchman: 4.9.0
Xcode: Xcode 9.4.1 Build version 9F2000
Android Studio: 3.0 AI-171.4443003
Packages: (wanted => installed)
react: 16.4.0 => 16.4.0
react-native: ^0.55.4 => 0.55.4
iOS
Description
Without getItemLayout flatlist works as expected - fast. With getItemLayout we started noticing rows aren't loading instantly when scrolling manually. After removing getItemLayout performance is good again.
We are using shouldComponentUpdate (also tried PureComponent).
In the gif you can see logs that getItemLayout is firing constantly when using flatlist manually - which seems to be why performance is suffering. Is this to be expected?

Reproducible Demo
Simplified my use-case with reusing part of someone else's demo :)
class MyListItem extends React.PureComponent {
    render() {
        return (
            <View
                style={{
                    paddingVertical: 10,
                }}>
                <TouchableOpacity onPress={() => null}>
                    <Text
                        style={{
                            color: '#000',
                            height: 40,
                            justifyContent: 'center'
                        }}>
                        lalalalaal
                      </Text>
                </TouchableOpacity>
            </View>
        )
    }
}

_renderItem = ({ item }) => (
    <MyListItem
        produto={item.produto}
    />
);

render() {
                    return <FlatList
                    data={['one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three', 'one', 'two', 'three']}
                    showsVerticalScrollIndicator={false}
                    initialListSize={4}
                    renderItem={_renderItem}
                    keyExtractor={(item, index) => '' + index}
                    ref={(ref) => { this.flatListRef = ref }}
                    getItemLayout={(data, index) => {
                        console.log("get item layout " + index)
                        return { length: 40, offset: 40 * index, index }
                    }}
                />
}

Expected behavior
getItemLayout only fires when scrollToIndex or similar methods are fired. Or at most when rows are actually re-rendering - though it doesn't look like it's used when simply rendering visible rows.

Even I experience this. getItemLayout gets triggered on scroll

Have not tried it on 0.56. Im on 0.55

@react-native-bot what environment info is missing? Provided it as requested, along with a detailed example and visuals to clearly understand the problem.

the bot closed because of this: https://github.com/facebook/react-native/issues/20467#issuecomment-409150190
(Maybe add a bot feature request that it should warn it might close the issue if the environment info is not filled in, OR not complain about that part when closing and just reference the issue being seemingly stale.)


Paragraph spacing for typst 0.12

Fix https://github.com/mvuorre/quarto-preprint/issues/13
I should create separate branch from my other PR, but I thought about it too late

Thank you but can you remove the duplicate and fix accordingly?


Better prompt option, like $_ in cmd.exe

In Windows cmd.exe, by default the prompt is pushed far from the left edge, by display of the directory path. This is awkward and ugly to the eye, as commands of modest length must wrap to the next line.
Not enough people know about the $_ option a cmd.exe window (or in System Environment variables), as in:

set Prompt=[$P]$_$+$G$G$S

The above 'set' command changes the prompt from a single line to a double line, due to $_.  Compare the next two prompt examples (1 = single line, 2 = double line):

C:\users\genemi\MyFunDirectory>echo Hello World

[C:\users\genemi\MyFunDirectory]

echo Hello World

So, please enable prompt configuration so commands can start near the left edge, while still displaying the database name or whatever in the preceding line.  :-)
Thanks. GeneMi @ microsoft. com  (Tuesday  2017/12/12  18:44pm  Redmond time)

This is fixed in the latest 0.10.0 version.
To achieve a prompt that starts on a newline, you can add the following to config line to your config file. On Windows, the path to the config file is %APPLOCAL%\dbcli\mssqlcli\config.
prompt = '\d\n> '

Thanks!


Interop warning

Warning rule for ES6 imports where the remote module mentions module, module.exports, exports.

call it no-common, off or warning by default


numpy arrays as inputs

Does your package support this? I'd like to include ca in my regular sklearn pipelines, all of them are built using straight numpy arrays as inputs. However your documentation does not claim supporting it, neither any examples I was able to found. What am I missing? )

Numpy arrays are supported, but if you pass numpy arrays you have to specify columns with integer indices not with column names.

Try to update to version 1.3.0, which was published yesterday. Something like this:
 pip3 install --upgrade category_encoders

works for me.
Weight of Evidence (WOE) is available only from 1.3.0.
The mentioned line in TargetEncoder is not present in 1.3.0 anymore. Some basic tests of numpy inputs are in test_encoders.py. And following, just written test:
    def test_np_col(self):
        for encoder_name in encoders.__all__:
            with self.subTest(encoder_name=encoder_name):
                # Encode a numpy array
                enc = getattr(encoders, encoder_name)(cols=[2,3,4,5])
                enc.fit(np_X, np_y)
                tu.verify_numeric(enc.transform(np_X_t))

passes for all encoders.
If the encoders still crash after the update, let us know.

Thank you so much! Indeed it works now ) Turned out I had v. 1.2.8, plus it was installed with some issues.  In 1.3.0 I can confirm integer indices and numpy arrays are working )
However, can you please add to documentation a mentioning that, in case of using Pandas dataframe as input, it can't have a string index? I've had hard times figuring out why both TargetEncoder and LeaveOneOurEncoders were returning nans... You can easily reproduce this in v 1.3.0 by using this code:
import pandas as pd
from category_encoders import *
from sklearn.datasets import load_boston

# prepare some data
bunch = load_boston()
y = bunch.target
X = pd.DataFrame(bunch.data, columns=bunch.feature_names)

X.index=X.index.values.astype(str)

enc = TargetEncoder(cols=['CHAS', 'RAD']).fit(X, y)
numeric_dataset = enc.transform(X)

Fixed with #150 (and previous changes) for all encoders


Getting the readme cleaned up and adding the research padge.

@ldecicco-USGS Seem reasonable? Pretty sure I'll need to update a few things in the readme once I get this PR merged, but this is coming along.

Coverage increased (+0.006%) to 98.499% when pulling 407067f99c5713038175992ebfa0354967bd8bbb on dblodgett-usgs:master into 9507f714a4201aeee9ab582e57fa95fcce9ce695 on USGS-R:master.

I don't know @dblodgett-usgs , tests only cover 98% of the code...

98.499% !!!

Do you want to remove the non-.Rmd  files from the vignette forlder? Or is that helping your vignette issues?

They'll be removed in my next PR... I have build tools set wrong.


Clarifies steps in release

This addresses prereqs of #2856

thanks for the look @anuraaga and @jorgheymans!


MNT: Re-rendered with conda-smithy 3.1.8 and pinning 2018.07.24

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy
[x] Ensured the license file is being packaged.

I forgot to rerender before merging the Jinja2 compiler pull request.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


User dashboard

https://github.com/ChallengeForge/TheWeeklyChallenge/assets/31693594/a4e5685e-880c-474d-9130-c502b97f8f4e

Description

Type of Change

[x]✨ New feature (non-breaking change which adds functionality)
[ ] 🛠 Bug fix (non-breaking change which fixes an issue)
[ ] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[x ] 🧹 Code refactor
[ ] ✅ Build configuration change
[ ] 📝 Documentation
[ ] 🗑 Chore

Changes

Please which part of the project your changes affect ?

[ x] Frontend (Templates, CSS, JS)
[ ] Backend (Dancer2, api-docs, Dockerfile)

@manwar I've made updates, kindly review

Thanks for your contributions. @kemsguy7

Thanks for your contributions. @kemsguy7

You're welcome mentor


Add Developers section

I would like to be able to display the developers on the generated page. This would preferably be a table with the roles as a listing in one of the cells.

enhancement deployed in release 4.6
usage:
${project.team}


Accessing a many to one object

Question How can I query the categories of a product? I am trying to match the categories with the passed in the query.
Situation
I want to be able to search for categories of products.
I have two tables for this:
interface Product { @Bindable     @ManyToOne     ProductCategoryEntity getCategory(); }
and
interface ProductCategory { @OneToMany(mappedBy = "category", cascade = {CascadeAction.SAVE})     List<ProductEntity> getProducts(); }
I want to access the categories of products
This is my approach
Selection<ReactiveResult<ProductEntity>> productsSelection = mDataStore.select(ProductEntity.class);   productsSelection.where(ProductEntity.OWNER.eq(merchantEntity));                 productsSelection.where(ProductEntity.NAME.like(query)).or(ProductEntity.CATEGORY.like(query); productsSelection.where(ProductEntity.DELETED.notEqual(true));
This does not match the name of the category as I stated here
productsSelection.where(ProductEntity.NAME.like(query)).or(ProductEntity.CATEGORY.like(query);
How can I go about getting the categories of a product as this is returning null

@npurushe


Clean up test_stream_test and remove stray print statement

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

[ ] Make sure the PR title is formatted like:
[BEAM-<Jira issue #>] Description of pull request
[ ] Make sure tests pass via mvn clean verify.
[ ] Replace <Jira issue #> in the title with the actual Jira issue
number, if there is one.
[ ] If this contribution is large, please file an Apache
Individual Contributor License Agreement.

R: @aaltay

Coverage increased (+0.02%) to 70.84% when pulling 2c88af6dd37e6eb3bbe4133e3ee2cbdeed68be72 on charlesccychen:teststream-evaluator into 3785b5baf4d3c47ea6625fff9babe5854e2e5fdb on apache:master.

LGTM


Closest Obstacle Logger Not Working with No Ships

I believe when there are no ships, this logs closest obstacle as 0. This looks like we hit something when we didn't. Closest obstacle should probably be infinite or some reasonably large number. Now that I think of it, probably should be the range of our AIS (~30km), since we know confidently there's nothing within 30km, but we can't say more than that.
https://github.com/UBCSailbot/local-pathfinding/blob/master/python/log_closest_obstacle.py

Resolved in #217


added validationg for booking, spaceship, spaceshipreview

added the validation for the files of booking, spaceship and reviews
user names it doesnt needed the validations

Looks good!


Improving documentation for new developer contribution and local setup.

This is a great addition of having compose-fullstacksample.yaml . This servers as very simple entry point to setup the entire service and have a look around. Though for those of who just started with this repo, facing following issues. It would be great if we can have some readme or guide on acquiring following placeholders.

#L22  INDEXER_MANAGER_API_KEY= CHANGE_TO_YOUR_APIKEY # How to get "CHANGE_TO_YOUR_APIKEY"
#L31   PROXY_DEBRID_STREAM_PASSWORD=CHANGE_ME # what should be the value of "CHANGE_ME"
A guide or reference around setup of "proxy" network via traefik. Also most of the traefik setup assume of having a domain, what is the recommended way to acquire one for local development ?

Expecting some guidance in this direction
Thanks

How to get "CHANGE_TO_YOUR_APIKEY"- this changes based on if your indexer is prowlarr or jackett. For example - Jackett's api key is displayed at the top of your user dashboard once you bring it online.
what should be the value of "CHANGE_ME" - This is you setting your own password.....
setup of "proxy" network via traefik -- labels included in the compose file does a pretty good job of including what you would need for this stack. The things missing would be traefik itself, and you configuring your own ACME challenge. There's different ways to do that, and there are projects people made out there to 'build' a traefik network from scratch (Auto-Traefik). You just have to search around.
Pick a DNS provider for your domain. Search around for best deal. They're all slightly different.


ModelUtil error in JAXBContext.newInstance()

There are jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.1 and org.glassfish.jaxb:jaxb-core:jar:3.0.2 in the flat classpath.
When the javax.xml.namespace.QName is passed to JAXBContext.newInstance() to create JAXBContenxt, it throws the follow error with JDK17:
Caused by: jakarta.xml.bind.JAXBException: Package javax.xml.namespace with Jakarta XML Binding class javax.xml.namespace.QName defined in a module java.xml must be open to at least jakarta.xml.bind module.
at jakarta.xml.bind.ModuleUtil.delegateAddOpensToImplModule(ModuleUtil.java:132)
at jakarta.xml.bind.ContextFinder.newInstance(ContextFinder.java:270)
at jakarta.xml.bind.ContextFinder.newInstance(ContextFinder.java:263)
at jakarta.xml.bind.ContextFinder.find(ContextFinder.java:395)
at jakarta.xml.bind.JAXBContext.newInstance(JAXBContext.java:691)
at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:339)
at org.apache.cxf.common.jaxb.JAXBContextCache$2.run(JAXBContextCache.java:337)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
at org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:337)
at org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:245)
at org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:499)
at org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:358)`
It looks the ModelUtil has issues to check if there is other module has the implementation in these lines :
Should it return when impModuleandjaxbModuleis the same here ? Or even skip thisModelUtilsoperations fromContextFinder` when it says it's flat classpath ?

Hi @lukasj , can you please have a look at this issue ? If this is a bug, I'll try to send a PR to fix.

Do you have some small reproducible test case?

@lukasj  Here is the reproducer : https://github.com/jimma/jaxb-modelutil-error
I forgot to mention this error happens on JDK17. My local JDK version is : `openjdk version "17.0.1" 2021-10-19'

thanks! Your reproducer helped me to find another issue - both should be fixed in 4.0.0. Do you need a backport to 3.x? If so, it will take some time (after 4.0.0/EE 10 is done)

Do you need a backport to 3.x? If so, it will take some time (after 4.0.0/EE 10 is done)

Yes. It would be great to backport to 3.x and have a release soon.  Thanks.


Run test CI on pull_request to master & push tags

Change the condition to run Test CI.

Pull Requests from the forked Repository have not been able to run CI.

Coverage remained the same at 95.984% when pulling 44031eef16457f6eeeb56929a2037f4eb82d98e3 on run-ci-on_pull_request into 7dffab6ef577cdfdd98b6e87bd289527aab6da51 on master.


Feature/login signup prompt

Closes
https://github.com/awaazo/awaazo/issues/377
&
https://github.com/awaazo/awaazo/issues/369

Nice work 👍. Here are some things that should be changed to improve our lives later on:

Instead of duplicating the login code in both LoginPrompt and LoginPage, create a single component component/auth/Login.tsx and import it where you need it. This removes the need to test different components with Cypress and redundancy in the code overall.
Rather than repeating login checks and redirection logic in each component, implement a higher-order component for authentication utilities/authHOC.tsx and wrap this around pages or components that can't be accessed unless the user is logged in. This makes the code cleaner and more manageable with high cohesion.

authHoc was added . import it to the pages of the components you need like so , for example:
import withAuth from "utilities/authHOC.tsx"
const MyProfile = () => {   // bla bla bla  };
export default withAuth(MyProfile);

Instead of duplicating the login code in both LoginPrompt and LoginPage, create a single component component/auth/Login.tsx and import it where you need it. This removes the need to test different components with Cypress and redundancy in the code overall.
Addressed in: https://github.com/awaazo/awaazo/pull/378/commits/46ee1105308afc7e2c0b009bda8c55c2974c828d

"Rather than repeating login checks and redirection logic in each component, implement a higher-order component for authentication utilities/authHOC.tsx and wrap this around pages or components that can't be accessed unless the user is logged in. This makes the code cleaner and more manageable with high cohesion."
Addressed in https://github.com/awaazo/awaazo/pull/378/commits/d2c9a81ccb23882f6995be0aa9f84c84dd329e6a

comments are still accessible even if the user is not logged in .

A user can see comments but can't comment/reply .
this approach is fine for this stage of the comments' component development.


Consider using scalafmt?

Would you consider using scalafmt? I am appreciating this library, but I'd like to make a couple of new feature additions / suggestions via PR's to it. Was wondering if you would consider using scalafmt so that it's easy to abide by a common code style?

Sure, I would happily accept a PR.


The request for path /v1.0/sandbox/dev/apps failed with code 422. Reason: The extension specifies a higher compilation target than allowed.

Hello,
Facing the following error while publishing the extension to the sandbox.
The request for path /v1.0/sandbox/dev/apps failed with code 422. Reason: The extension specifies a higher compilation target than allowed.
Can anyone help me to fix this issue..
Thanks

Hi thpeder,
Thanks for your reply.
But if i changed the target value to extension following methods are not found with AL package.
TEMPORARYPATH
Report.SAVEASPDF
BLOBImport
BLOBExport
FileMgmt.UploadFile
ExcelBuf.OpenBook
Is there any chance to have the above methods to al extension package to ignore the compile error.
Thanks.

I'll recommend you searching through issues here on Github.
For example TemporaryPath was discussed here: #479.
If your plans are to only run your code on-premise and never to publish it to AppSource then you can switch back to use "target":"Internal".
To get started on that you can either create a machine on Azure from our template at http://aka.ms/navdeveloperpreview
or use the containers we make available which you can read more about here: https://github.com/Microsoft/nav-docker

It looks like this issue was resolved. If you have more issues please open a new issue


How do you get the slide dimensions?

Issue

When setting the shape's width and height properties, is there an option to set them to the slide's width and/or height ?
Is there any way to get these two sizes?
Also, is there any way to get the information on the Guides of the slide? It would be really useful to place shapes according relative to the guides.
Example
textbox.width = slide.width
textbox.height = slide.height / 10
textbox.left = 0
textbox.bottom = 0

Thanks!

Article URL

https://docs.microsoft.com/en-us/office/dev/add-ins/powerpoint/shapes?view=powerpoint-js-preview#text-boxes

Hi @caredev,
I don't believe this functionality exists today, but I'll have @Rick-Kirkham confirm. Assuming it's not, please create an idea asking for it on our Microsoft365 Developer Platform Tech Community page. There, other developers can view and upvote the idea. This helps us prioritize feature requests when adding new functionality.

Alex is correct. The PowerPoint JavaScript APIs do not provide information about the slide's dimensions or its guides. Please create an idea as Alex suggested. I will close this issue, but if you think it has been closed in error, you can still comment and we will see the comments.


[Avalonia v11] Sometimes, the UI freezes in Release mode when closing the MainWindow with Dune

Not able to reproduce it on my end (I use Windows), this was reported by @kevinferrare (uses Linux, maybe this is related ?)


doesnt work inside php..

FYI:
i think that in half the cases, bootstrap is being used inside Wordpress / druppel etc..
however you plugin isn't activated inside PHP...

It works! Check the below screenshot. can you create a new PHP file and check it again?

VSCode Version: 1.59.0

@sagive Can you check again?

sure, will try asap and update

Works! thank you very much 👍👍


[Performance] Response Time increases for OIDC Password Grant Type flow when IS nodes increases

Describe the issue:

Avg Response Time - Password Grant

Concurrency
2 Node 4 Core
3 Node 4 Core
4 Node 4 Core

50
113.56
141.89
164.81

100
228.52
248.04
459.05

150
349.63
567.26
436.15

300
744.87
1158.39
889.59

500
1247.53
1232.82
2459.05

1500
2615.83
4110.85
5165.08

2000
4165.24
6212.6
7993.54

2500
5276.4
8277.73
10365.55

3000
6364.41
10323.26
13201.92

3500
7643.88
12326.18
15826.28

According to the above data, the response time of the OIDC password grant flow increases, when we increase the number of IS nodes.

But if we perform the test without clustering, the response time won't increases.

4 Nodes 4 Core 95th Percentile of Response Time (ms)
3 Node 4 Core 95th Percentile of Response Time (ms)
2 Nodes 4 Core 95th Percentile of Response Time (ms)

118
115
188

236
225
531

353
615
783

703
1407
1839

1151
2399
2975

2303
4703
5791

3551
7647
8319

5023
10111
9791

9407
12159
13759

6879
10111
14527

By observing those results we can see that when clustering is disabled we can have a performance improvement. Hence we can expect that the issue should be related to clustering cache invalidation messages.
Refer the email:

[IS-5.10.0_performance test] Performance test numbers
IS product scaling and capacity planning for Horizontal and Vertical scales
Presenting our performance results in an optimal way to do capacity planning for our customers

For that database side improvement, following slow query was identified,
SQL=SELECT DISTINCT UM_USER.UM_USER_ID FROM UM_USER, UM_USER_ATTRIBUTE WHERE UM_USER_ATTRIBUTE.UM_USER_ID = UM_USER.UM_ID AND UM_USER_ATTRIBUTE.UM_ATTR_NAME =? AND UM_USER_ATTRIBUTE.UM_ATTR_VALUE =? AND UM_USER_ATTRIBUTE.UM_PROFILE_ID=? AND UM_USER_ATTRIBUTE.UM_TENANT_ID=? AND UM_USER.UM_TENANT_ID=?; time=156 ms;

How to reproduce:
Execute performant test for the OIDC password grant flow with requesting user attributes. Obtain an access token and an id token using the OAuth 2.0 password grant type. Retrieve country, email, first name and last name as user attributes.
deployment.toml configurations
[database.identity_db.pool_options]
maxActive = "500"

[database.shared_db.pool_options]
maxActive = "500"

[database.user.pool_options]
maxActive = "500"

[transport.https.properties]
maxThreads = "500"
acceptCount = "500"

Expected behavior:

When we increase the number of IS nodes, the response time should decrease. Unless there is no RDS bottleneck.

Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: IS-6.1.0, IS-7.0.0. M3
OS: Linux
Database: MySQL
Userstore: JDBC

Related issues:

https://github.com/wso2/product-is/issues/15460

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Correctly handle optional types in parfors lowering

Closes #8453

@apmasell thanks for applying the patch and adding the test as noted in/to resolve #8453.
@DrTodd13 as this contains a fix suggested by me in https://github.com/numba/numba/issues/8453#issuecomment-1253372598, please could you review this? Many thanks!

Thanks for the review @DrTodd13.


Horizontal lookup table packer bugged usable_rows_after calculation

Turns out this now works properly and the error was somewhere else (???)


Backend code uses any as a type annotation, but the correct type is Any

I noticed a few occurrences of any being used as a return type annotation in the Python backend code, e.g.
https://github.com/Azure-Samples/azure-search-openai-demo/blob/main/app/backend/approaches/approach.py#L2
any is a builtin function, not a type.
It should be
from typing import Any

def foo() -> Any:
 ...

Fixed in #339


Add "badge" with # of streams with messages

In my workflow, I have disabled desktop notifications since we have some high-volume streams. Of course, this means I do not know whether anything new has come in.  When I close the desktop app main window, I would love for the tray icon to show whether any new messages have come in in the same way Skype works:  show a number with the number of streams with unread messages.
(this is on Windows 10 by the way)

I can see something like this being useful for some workflows.  If we wanted to make that work, we'd need to expose the data from the webapp codebase to the Electron app; it's all there, so shouldn't be hard, but will require some plumbing.
That said, I'm curious: @ewoutkramer have you thought  about muting the high-traffic streams?

If I understand your suggestion correctly, I should mute all high-traffic streams and re-enable desktop notifications.  That's an improvement - but it won't help me if I was away from the desktop and a message came in.  It would actually improve the features: if you would just count the number of non-muted streams with new messages for display in the badge, I would be totally happy.
Discussing this, I realize my problem is really this:  I have some high-traffic streams that I monitor periodically - so I really open up zulip to read them now and then. But there are others that I'd like to react on as quickly as possible.  I could now divide these two groups by muting all streams except the "urgent" ones - the badge count would tell me that something happened in the urgent streams, even if I missed the desktop notification

@timabbott this is fixed in https://github.com/zulip/zulip/pull/12677, right?

If I understand it correctly, #12677 would restrict the count to private msgs/mentions, not the pinned channels.  Anyway, that's an improvement that I would certainly use!


inputDirectory doesn't support URL's as well as Swagger2markup does

Hi,
in the context of generation from a server endpoint, the constraint File on inputDirectory doesn't allow to specify an URL instead or filesystem
thanks
zucher

Sorry for the late response...
Fair point, but supporting URL for inputDirectory isn't as trivial as swapping out file with URI or URL.  For example, if you were trying to use an "http" url, HTTP doesn't provide any mechanism for "listing" files, so your server would have to meet several conditions to be able to locate any resource files, and even then you'd either have to have your server produce DOM or JSON listings and then parse/traverse them that way.  See this SO post for more discussion/better enumeration of issues: http://stackoverflow.com/questions/11561608/how-to-get-list-of-files-directories-of-an-directory-url-in-java
For this reason (both the amount of work and limited functionality it would buy due to server constraints), I don't plan on working on this, nor do I see a clear, generic solution that wouldn't require customization from server to server.
If there is a use case that I'm missing that better enumerates a more simple use case, I'd be happy to revisit discussion.

Hi redowi,
as stand alone use of Swagger2MarkupConverter converter calls the from methods allows to use URL instead of files, and it's fine working, using a startswith method to discriminate between a file entry of web entry is in this case quite simple, no needs to enumerate.
zucher

Hi redowi,
as stand alone use of Swagger2MarkupConverter converter calls the from methods allows to use URL instead of files, and it's fine working, using a startswith method to discriminate between a file entry of web entry is in this case quite simple, no needs to enumerate.
zucher

PR is merged.

tks, when are you plan to propose a new version ?

Unfortunately #9 hinders me.
I have to check how to create the Maven Plugin plugin.xml with Gradle.

ok thank you :-)

If you use Swagger2Markup, if would love to get your GitHub star in the core project :)

Done

Thx, but I mean https://github.com/Swagger2Markup/swagger2markup :)

On 02/12/2015 16:20, Robert Winkler wrote:

Thx, but I mean https://github.com/Swagger2Markup/swagger2markup :)
—
Reply to this email directly or view it on GitHub
https://github.com/Swagger2Markup/swagger2markup-maven-plugin/issues/2#issuecomment-161330062.

;-)


pnpm's dependenciesMeta.*.injected can't re-sync

What version of Turborepo are you using?
1.6.1
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Linux
Describe the Bug
When using pnpms dependenciesMeta.*.injectedfeature (to make deep peers work), rebuilding the libraries to get thedistfolder back requires "re-syncing" viapnpm install` (which takes ~1s)
See this related issue on the pnpm repo: https://github.com/pnpm/pnpm/issues/4965#issuecomment-1287926075
Expected Behavior
This is more a bug with pnpm, I think, and I don't know what turbo could do differently -- I'm mostly reporting for SEO / audit-trail purposes (so feel free to close this issue, if there is nothing turbo can do). As a work-around I thought of without turbo would no longer work with turbo -- and that work around is to add pnpm i;  as a prefix to every script -- quite obnoxious, and the only real solution is to probably fix the issue in pnpm (which.. I'm not sure even how to approach the problem of re-syncing -- does pnpm need a background daemon that does the re-syncing? I'm not sure).
To Reproduce
I have a sample / repro here: https://github.com/CrowdStrike/ember-headless-table/pull/44
It's gone through a number of iterations, but demonstrates:

cache working
but injected dependency is not detected by downsteam projects in the monorepo

I am never really sure when you are supposed to use dependenciesMeta.*.injected. I currently use workspace:* as the version of my internal packages and it appears that turbo correctly build everything in order so it works.
Why do you need to inject the dependency?

You need to inject a dependency when that dependency is in your monorepo, and that dependency declares peers that the consumers of the dependency is supposed to declare.
Otherwise peers don't resolve correctly

A possibly better workaround: create a root task called resync, make build: //#resync, ^build, and the mess is contained in one nice neat spot that you can easily delete if pnpm gets clever.
For bonus points this addresses merge-caused node_modules out of sync issues at the same time so maybe not worthwhile to delete.

We're not planning to do anything with this (other than recommend the most-elegant of workarounds) so I will close this. 🤷♂ Thank you for filing the issue; it really helps to see what people are encountering.

After further discussion, I discovered that this is a request to run things at the leaf nodes, not at the root: after we have already acquired all of the information necessary to know if we would need to do this.
We should definitely patch up this papercut; we are actually even better positioned to do this.

Test.

Looks like I am having a similar issue now after importing some package heavy project in my monorepo playground.
@NullVoxPopuli  Did you had luck with @nathanhammond suggestion?

@weyert My pitch doesn't work.

In case someone needs this, there is an issue in pnpm with a reproduction repo that we can use to test solutions:

https://github.com/pnpm/pnpm/issues/5479

To be clear though, that fix also causes the behavior reported and linked in the original post in this thread.

@simonihmig came up with a way to make this work over at: https://github.com/CrowdStrike/ember-headless-form/pull/52
It requires this util: https://github.com/CrowdStrike/ember-headless-form/pull/52/files#diff-cba6a6cd1877ea907fa4d3c06bdd8548011bc52b603638c9e8334870e53aca39
does it make sense for turborepo to adopt? or maybe it could be a util for pnpm -- since pnpm is already written in js/ts

Here is a work-around if folks run in to this: https://github.com/NullVoxPopuli/pnpm-sync-dependencies-meta-injected

I'm mostly reporting for SEO / audit-trail purposes (so feel free to close this issue, if there is nothing turbo can do)

Closing this out as the related pnpm discussion also suggests that it's not a turborepo-specific problem.

also suggests that it's not a turborepo-specific problem

there is probably a meta issue here (or somewhere) where folks may want to run something that isn't cached before running a regular task (that could be cached).
for example:
turbo build

for each workspace

run: build

regardless of cache hit/miss: run "X" after "build" is finished -- in this case, it'd be the sync util


Inconsistency between All package on CDN and NMP modules

Which package(s) are affected?
Lit Core (lit / lit-html / lit-element / reactive-element)
Description
We've noticed a bit of an inconsistency between the Lit all CDN package and using the packages via npm. My expectation is that the CDN URL would essentially be a drop in replacement, however there's an edge case due to aliasing of html from the static-html package.
This:
import { unsafeStatic, html } from "lit/static-html.js";

and this:
import { unsafeStatic, html } from<EMAIL_ADDRESS>
are not the same since.
In the former you get html from the lit static package where as in the latter you get html from the core package.
This has proved quite a gotcha for us and as far as I'm aware isn't well documented.
If you'd like me to PR a documentation change, just point me in the right direction.
Reproduction
No reproduction should be necessary
Workaround
No workaround found.
This should probably be documented.
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
All versions
Browser/OS/Node environment
Environment not relevant

Aha, that's a good point. Since the "all" bundle exports everything from a single entrypoint, the static version of html is aliased to staticHtml here https://github.com/lit/lit/blob/25fbfba9c0f1b97d720a981831c59c08472ba6ee/packages/lit/src/index.all.ts#L33-L39
Indeed this isn't documented anywhere in https://lit.dev/docs/getting-started/#use-bundles
There's an edit this page link on the bottom which points to this file https://github.com/lit/lit.dev/blob/main/packages/lit-dev-content/site/docs/v3/getting-started.md which could have a note that the static versions of html and svg are aliased to staticHtml and staticSvg.
Personally, I'm less sold on the need for our bespoke bundles when CDNs can serve npm published packages and their submodules directly like
import { unsafeStatic, html } from<EMAIL_ADDRESS>
which is more of the replacement you were expecting.
And if you really need it all in a single js file, esm.sh has that feature too though it can cause duplicate code to be loaded.
import { unsafeStatic, html } from 'https://esm.sh/lit@3/static-html.js?bundle-deps';

Personally, I'm less sold on the need for our bespoke bundles when CDNs can serve npm published packages and their submodules directly like

I can see that. Deprecate the all bundle?

And if you really need it all in a single js file, esm.sh has that feature too though it can cause duplicate code to be loaded.

This is the unfortunate part for us. We actually have developers use the NPM package version and then use server side import mapping at build time to map all uses to the 1 bundle that we produce and publish to our CDN from the Lit NPM package. Since html will always clash between the 2 packages, we have now realised we need to produce 2 bundles and eat the duplicated code cost since we can't map developers use of html to staticHtml in the all bundle. At least not as it currently stands, we can only import map bare imports to absolute urls.
So our new solution looks like this:
// this gets mapped
import { LitElement, css, html } from 'lit';
// to something like:
import { LitElement, css, html } from 'https://assets.finn.no/npm/lit-3/v3/lit.min.js';

and
// this gets mapped
import { unsafeStatic, html } from 'lit/static-html.js';
// to something like:
import { unsafeStatic, html } from 'https://assets.finn.no/npm/lit-3/v3/static-html.js';

Which costs us IIRC about 7kb extra.

It's not huge but certainly unfortunate none the less.
So if I'm understanding this, you aren't modifying any of the specifiers in the consumer code which is why the alias is problematic.
Trying to orchestrate might not be easy but is it possible that your build for static-html.js could not bundle everything and instead refer to your lit.min.js for what it needs? It really only needs the original html and svg tags https://github.com/lit/lit/blob/main/packages/lit-html/src/static.ts
Maybe a build step that first builds the lit.min.js as a bundle, and another build step that points to the static.ts file above as entrypoint and all it does is modify the import {html as coreHtml, svg as coreSvg, TemplateResult} from './lit-html.js'; so that it resolves to the first build's artifact (or replace './lit-html.js' with 'lit' so the importmap will do that) and minify, without bundling? Perhaps a custom esbuild plugin could rename and mark it as external.

Happy New Year!
That could work. The only downside I can see is that there's an additional waterfall load in there though if you're not using static you wouldn't care and if you are using static you'd use it directly and would preload it so it likely doesn't actually matter I guess.
Thanks for the suggestion!

(or replace './lit-html.js' with 'lit' so the importmap will do that)

Actually, I can probably just define a map of ./lit-html.js to https://assets.finn.no/npm/lit-3/v3/lit.min.js and run a build and build a version of static with just that.


proposal: x/sync/singleflight: add a method for per-caller post-processing of shared result

Background
In order to safely deal with some classes of shared resources that can be acquired via a singleflight group (anything that requires explicit cleanup/freeing; files, shared buffers, etc), there is need for a mechanism to account for all goroutines that received a reference to the shared resource.
It is not sufficient to perform this accouting after the singleflight call returns, since any single waiting goroutine may complete its work on the shared resource before other goroutines start, leading to misbehavior.
Proposal
To solve this missing functionality, there were suggestions (not converted to proposals) to expose singleflights internal count of duplicated calls.
I propose a different approach, inspired by this comment: extend the singleflight.Group API to include a second function parameter, called by every duplicated caller.

	},
)

Pros:

explicit
versatile
has no impact on existing usage
leaves error handling to the consumer (with the exception of panics)

Cons:

increases API surface area
less intuitive API

Relates to golang/sync#9 and golang/sync#20

I don't understand when this post-processing function would be called.  The singleflight code just returns the value to the caller.  It can't know when the caller is done with the value.

@ianlancetaylor the second function parameter would be called after the first function parameter returns, but before the Do() method returns to the caller, ensuring all callers (the one that actually executed the closure as well as any of the others) get a chance to do something to the shared value. This something must not be all the caller wants to do with the resource (it doesn't need to be "done" with the value), but should be enough to ensure accurate accounting.
One way to use it would be something like:
type ExpensiveResource { /* something */ }

func (ExpensiveResource) Cleanup() { /* something */ }

type sharedExpensiveResource struct {
	readers atomic.Int64
	ExpensiveResource
}

func (s *sharedExpensiveResource) Cleanup() {
	if left := s.readers.Add(-1); left == 0 {
		s.ExpensiveResource.Cleanup()
	}
}

sf := &singleflight.Group{}

func somePotentiallyConcurrentFuntion() {
	out, err := sf.DoShared(
		"foo",
		func() (interface{}, error) {
			s := &sharedExpensiveResource{
				ExpensiveResource: /* expensive stuff */,
			}
			s.readers.Add(1)
		},
		func(in interface{}, error) {
			res := in.(*sharedExpensiveResource)
			res.readers.Add(1)
		},
	)

	res := out.(*sharedExpensiveResource)

	res.DoStuff()
	res.Cleanup()
}

All calls of somePotentiallyConcurrentFunction are guaranteed they will only get to res.Cleanup() after all other calls sharing the same sharedExpensiveResource got their chance to run their "accounting" (in this case res.readers.Add(1)).
Does that clear it up?
Or am I being obtuse? :sweat_smile:

Just to understand the proposal, would it be the same to write
func DoShared() *sharedExpensiveResource {
	out, err, _ := sf.Do("foo",
		func() (interface{}, error) {
			s := &sharedExpensiveResource{
				ExpensiveResource: /* expensive stuff */,
			})
	res := in.(*sharedExpensiveResource)
	res.readers.Add(1)
	return res
}

and then always call that DoShared function instead of sf.DoShared?

I don't understand how readers in the example would ever be accurate?

Is there a key difference that would make it accurate when the proposed DoShared method?

@ianlancetaylor

would it be the same to write

I don't think it would: in this case there is no guarantee the callers of DoShared would have a consistent view of readers. If two goroutines (G1, G2) enter DoShared concurrently and end up in the same singleflight call, they are only guaranteed to be synchronized up to the point where Do returns. After that G1 can do all its work with sharedExpensiveResource and (crucially!) call Cleanup before G2 ever gets to res.readers.Add.
Or am I overlooking something obvious?
@seankhliao sorry, do you mean Ian's example or mine?

@ianlancetaylor the advantage of having a per-caller closure would be allowing each caller to decide if they're still interested in sharing the resource after a potentially long time waiting for the singleflight.
But I admit: that's maybe veering to far into speculation territory. The use-cases that were brought up until now would AFAICT also work with a simple reference counter.


restructure the contributing guide

Have added the communication channels. (#4361)

Removed text having the broken link, which closes #6687

Hey is this issue complete? If not I can work on it.

Hey is this issue complete? If not I can work on it.

I'm working on it.

Untitled Document 5.pdf
@TomNicholas I'm getting this error.
I have done a full clean build, the errors  are decreased. But there are still some errors.

@harshitha1201 if it passes the CI, it should be fine. The error you are getting looks like something to do with importing rasterio, which is an optional backend anyway.

@harshitha1201 if it passes the CI, it should be fine. The error you are getting looks like something to do with importing rasterio, which is an optional backend anyway.

okay! thank you

@keewis I have done some changes, please review.

@headtr1ck I have done some additions and some deletions too to the contributing guide. Please let me know if any changes are needed.

@TomNicholas please review

Thanks @harshitha1201 !

Thanks @harshitha1201 !

Thank you!!


.immutable or .mutable?

Generally I try to make my boolean options and properties positive. Arguably, immutable is the negation of mutable. Following that principle, then, the getter should be spelled mutable, and to check for immutability you'd negate the result.
I don't feel strongly about this, but it's something to think about.

A nice side effect of immutable is that engines which don't implement this property will give the expected result for...
If (ab.immutable)
   ;

...since since immutable will be undefined.

Right; there's a tension here between "booleans should default to false" (which favors immutable) and "booleans should be named with positive polarity" (which favors mutable). I'm fine either way, but more inclined towards immutable.

At the December tc39 meeting, we got agreement on .immutable. Since that is consistent with the current state of this repo, I'm closing this as resolved.


Implement latest copy

Any changes to any page other than Methodology and Data page. The copy is in the source of truth word doc "Living Copy of J40"
Also knock out a quick copy update to the 404 page (linked)

http://usds-geoplatform-justice40-website.s3-website-us-east-1.amazonaws.com/justice40-tool/974-22993b7/en/cejst/#3/32.47/-86.5


Add suport for documentation versions

Hi, I think that maybe a great addiction to nbdev would be some kind of support for multiple versions of the documentation.
This way he could have in docs something like:
 Project
└───Current version
│   │   File One
│   │   etc.
│
└─── Version X.Y.Z
│   │   File One
│   │   etc.

Sounds great, but not on our todo list at the moment, sorry.


Add support for customising instanceof behaviour

This allows types to define custom Rust code as an override for JsCast::instanceof.

Fixes #1367 for types that have built-in cross-realm checks, allowing dyn_ref and dyn_into to accept values from other realms. In particular:

.instanceof::<Array>() will now automatically use Array::is_array instead of actual ... instanceof Array.
.instanceof::<Function>() will use JsValue::is_function. This also simplifies Function::try_from to being an alias for dyn_ref::<Function>().
.dyn_into::<JsString>(), .dyn_into::<Number>(), .dyn_into::<Boolean>() will also now use corresponding checks from JsValue.
In theory, these 3 can break checks if someone has been using boxed primitives (new String(...), new Number(...), new Boolean(...)), but these are extremely rare in real-world JS code and are already not support by JsValue methods. If we do want to support them, I believe it should be done at the JsValue level in as_f64, as_bool, as_string too.

Fixes #1370 - .instanceof::<Symbol>() will now use JsValue::is_symbol - previously it would return false for any value, even actual Symbols, making it impossible to use .dyn_ref::<Symbol>() and .dyn_into::<Symbol>().

cc @alexcrichton @fitzgen

In theory, these 3 can break checks if someone has been using boxed primitives

Heh, looks like some tests actually check this.

It also seems strangely inconsistent that Boolean and Number have fn new bindings to create a boxed primitive, but JsString doesn't... @alexcrichton any chance we could soft-deprecate these on existing primitives?

Ideally we would have some raw layer that just does the instanceof check and matches JS semantics exactly, and then on top of that we would add some sort of "is-a?" predicate that Does What I Mean.
I'm not sure how to do this in a backwards compat way.

I'm not sure how to do this in a backwards compat way.

We can surely separate them by adding
trait JsCast {
  // ...existing definitions

  fn is_a(val: &JsValue) -> bool {
    Self::instanceof()
  }
}

and then overriding this extra method via attribute, but I see little benefit in that because dyn_ref, dyn_into etc. shouldn't blindly use instanceof IMO...

Can we perhaps draw inspiration from JS somehow? How does JS typically handle these differences idiomatically? Can we basically make the idiomatic thing in JS the same idiomatic thing in Rust?

Can we basically make the idiomatic thing in JS the same idiomatic thing in Rust?

That's what this PR attempts to do.
Unfortunately, despite few proposals in the past, there is no central API for cross-realm checks, but the common consensus is that you should use them where available (like in case with typeof or  Array.isArray or Node's Buffer.isBuffer etc.).
For other objects, which don't have corresponding method, the common alternative is to use string tag checks like Object.prototype.toString.call(...) === '[object ...]' but for now I decided not to go there as it adds potentially heavy runtime cost, whereas built-ins are free.

@RReverser is correct: there are many ways to check whether an object is a particular type, so there isn't a single "correct" way to do it in JS.
Instead you need to use typeof or instanceof or {}.prototype.toString.call depending on the situation. So I agree with him that being able to customize the behavior of instanceof is needed.
However, since instanceof is an actual operator in JS, I think it would be far less confusing if it was renamed to something else, like is_a. That avoids any confusion with the instanceof operator. And then we should deprecate the instanceof method.

I think that sounds like the best of all worlds yeah where we:

Add a new method, is_a to JsCast

For now, make it a default method calling instanceof for backwards compatibility reasons

Deprecate instanceof, recommending is_a
Change all dyn_* methods to use is_a
Allow customizing is_a (as this PR does)
Take is_a customizations in this PR for Array/String etc

How's that sound?

That plan sounds great to me.
In an ideal world, I'd change the semantics of JsCast::instanceof be exactly JS instanceof, but I think that is backwards incompatible.

@alexcrichton Sounds perfectly reasonable to me! I'll update the PR.

In an ideal world, I'd change the semantics of JsCast::instanceof be exactly JS instanceof, but I think that is backwards incompatible.

@fitzgen I think that's what @alexcrichton suggests too? (keeping instanceof as an actual JS instanceof for now)

We implement JsCast::instanceof for some things like JsValue that have no JS equivalent.

JsCast::instanceof for some things like JsValue that have no JS equivalent.

Ohh. Yeah, I think these would have to be deprecated.

Btw, do we want to actually call it is_a or just is would be enough? (just to avoid a/an confusion)

@fitzgen In an ideal world, I'd change the semantics of JsCast::instanceof be exactly JS instanceof, but I think that is backwards incompatible.

Personally, I don't see any use for JsCast::instanceof, it's almost never what you want.
On the other hand, a JsValue::instanceof would be useful. It would just use the JS instanceof operator, and nothing else:
impl JsValue {
    pub fn instanceof(&self, class: &JsValue) -> bool {
        // intrinsic which uses `instanceof` in JS
    }
}

This would be useful as a low-level building block, but isn't intended to be used directly (instead JsCast::is_a is preferred).

On the other hand, a JsValue::instanceof would be useful. It would just use the JS instanceof operator, and nothing else:

I was thinking about it too, but for that we need to solve #1406 first (I raised it with this particular issue in mind).

@RReverser Right, but JsValue::instanceof can be added in a separate PR, so it isn't really related to this PR, so we can decide that later.
My point was basically just that JsCast::instanceof isn't needed, so we can just deprecate it.

My point was basically just that JsCast::instanceof isn't needed, so we can just deprecate it.

Maybe better to deprecate in the same PR as JsValue::instanceof is added (in case someone does want a stable way to do that, for whatever weird reason)?

Also, as far as I can tell, for now we don't want to use O.p.toString on types without real cross-realm checks so we still need instanceof for now as a fallback.

@RReverser Except right now JsCast::instanceof doesn't always use instanceof, it's a weird mishmash of some things. So I'm fine with deprecating it in the same release as JsCast::is

Also, as far as I can tell, for now we don't want to use O.p.toString on types without real cross-realm checks so we still need instanceof for now as a fallback.

Why don't we want to use toString?

Why don't we want to use toString?

See above:

@alexcrichton: > For now, make it a default method calling instanceof for backwards compatibility reasons
me: > for now I decided not to go there as it adds potentially heavy runtime cost, whereas built-ins are free.

Aside from perf impact, toString is also pretty unreliable, although for different reasons.

Except right now JsCast::instanceof doesn't always use instanceof, it's a weird mishmash of some things.

Aside from JsValue, when else it doesn't use instanceof?

Aside from JsValue, when else it doesn't use instanceof?

I think just JsValue.

for now I decided not to go there as it adds potentially heavy runtime cost, whereas built-ins are free.

I created some benchmarks: https://jsperf.com/array-type-checking3
The builtin gets ~32,891,703 ops/sec. Using toString gets ~22,678,401 ops/sec.
A cost? Sure, but that's still 22 million ops/sec. So in the situations where a builtin doesn't exist, correctness is more important in my opinion.

toString is also not 100% reliable, although for different reasons.

This is the first time I've heard of that, could you explain more?

@RReverser trying to follow the discussion, were you on board with the previous plan? I was looking at https://github.com/rustwasm/wasm-bindgen/issues/893 again today and realized that this'd be a great way to fix that, so was curious if you're still up for pursuing this change!

trying to follow the discussion, were you on board with the previous plan?

I was :) See https://github.com/rustwasm/wasm-bindgen/pull/1405#issuecomment-478679338
There have been just few follow-up questions which can be summarised as:

Can we use a more generic is instead of is_a / is_an?
Do we want to switch to Object.prototype.toString approach for everything else or do we keep instanceof as a default behaviour for now?

Since this is in theory not called too much (rather the dyn_* methods would be preferred) the name doesn't matter too too much so I'd be wary of taking such a small name as is, but I also don't have much against it. If we're reframing this as "this is a loose check to see if the types are compatible and will work together" then I think it's fine for us to change the internal behavior at any time, so for now I'd probably stick with instanceof and if necessary we could switch to Object.prototype.toString

so for now I'd probably stick with instanceof and if necessary we could switch to Object.prototype.toString

Oh, actually, this brings me back to another question from the beginning of this PR - do we really want to continue to support boxed variants of Number and Boolean? If so, current change to typeof will break them (because for boxed variants it returns object as expected).
Given that we don't support boxed variant of JsString and in general boxing primitives into objects is usually a bad idea and rarely happens in real-world code, I'd suggest to soft-deprecate fn new for these two types, but the final decision is not up to me.

So long as "general idiomatic patterns continue to work" I don't have strong feelings one way or another. I don't really know what it means to not support them or to to support them.

@alexcrichton In JS there is a distinction between primitive and boxed values:

"foo" is a primitive string.
new String("foo") is a boxed string.

Most of the time they behave the same, but there are some differences:
typeof "foo" === "string"
typeof new String("foo") === "object"

"foo" instanceof String === false
new String("foo") instanceof String === true

On the other hand, these are both true:
{}.toString.call("foo") === "[object String]"
{}.toString.call(new String("foo")) === "[object String]"

So you can use that to reliably detect both.
Right now, since JsString uses instanceof, that means that it's not actually possible to use string primitives like "foo" as a JsString.
If it used typeof then it would only work with primitive strings.
If it used {}.toString.call then it would work with both.
Boxed strings are very rare in JS. So using either typeof or {}.toString.call is fine, but using instanceof is not okay.
Since {}.toString.call supports both, it may seem like the obvious choice, but it does have a bit of a performance cost, so using typeof may be better.
On the other hand, some types in JS don't work with typeof, so in those cases I recommend using {}.toString.call, since it's the most reliable method I know of for type detection (and it works cross-realm).

Sorry for the delay here - I think we agreed with the plan for this PR for now, I just need few days to finish as working on few projects in parallel :) (as far as I understand, there is no rush since no one raised these issues before anyway, so hopefully few days is fine)

Ok I fixed issues and decided to rename the method to is_type_of (with a signature T::is_type_of(&JsValue) -> bool) - @alexcrichton you said, it's unlikely to be called directly often and the longer name is preferable, and this seems to reflect what it does the best.
I've also added a default fallback to existing instanceof instead of replacing it altogether, as discussed above.

One more note: I haven't added custom check to type Object yet because it seems to be a breaking change and is tracked separately in #1366.

Noticed that, just like Function::try_from, JsString::try_from can also be updated to being an alias for dyn_ref instead of an unsafe code, so updated it too.

Nice! Could this perhaps switch the direction of the arguments though? Instead of T::is_type_of(&obj) could that be written as obj.is_type_of::<T>()? (sort of like instanceof today). That'd then require a seaparate method which isn't typically called by users but would be used to do the T::some_other_name(&obj).
Additionally, could the documentation be updated to indicate when you might want to use is_instance_of vs is_type_of?

That'd then require a seaparate method

Yeah this was the primary reason I didn't do it - from the discussion above I've got an impression that we don't want to encourage this method to be often called directly?
Also note that semantically it's in obj.is_type_of::<T>() that the name would have to be different, not in T::is_type_of -> T::some_other_name, because the direction of the name is rather opposite from instanceof ("T is type of value" vs "value is instance of T").
But, anyway, I guess we could add obj.has_type::<T>, the question is only whether we actually need it...

I don't really mind too much about the naming, but I suspect that we'll want to recommend that this is called almost all the time instead of is_instance_of. Most users will use dyn_* which won't matter much, but in some cases I suspect that is_instance_of is in used, and we'll want to make sure the recommended form is still of the form self.method_name::<T>() to ensure it reads left-to-right

Ok I can add obj.has_type::<T>() then.

(this was just a rebase to fix conflicts for now)

@alexcrichton Ok done and looks like CI passed.

Thanks @RReverser!


fix(startup script): Added startup script

:tada: This PR is included in version 1.4.22 :tada:
Your semantic-release bot :package::rocket:


new way of the key -> new way the user stars the pointinator!

title says it all
bla bla bla
words words words
bloat to look like much
have fun!

nice onechan <3


require interface to be in UP state and check ifconfig output for interface name

Adds -u flag to ifconfig check to ensure only interfaces that are UP are reported. Furthermore adds a check for the output of ifconfig to ensure that the interface in question in fact is listed.
Otherwise the check will "approve" an interface that is not yet UP, and subsequent calls to fetch the gateway of that interface might fail if issued to quickly thereafter.
Resolves #7691

@nscheer thanks, safe to say this code wasn't changed in a decade which is good and bad at the same time.changing this can easily break behaviour for others as well. I need to dig into the code history first.

@fichtner Thanks for looking into this!
Yes, there might be side effects. Question is if this ever should continue without an interface being UP.
And there still is the 10 second "timeout" when it will continue, no matter what.
Let me know, if I can help or test anything :)

Ok so first things first this was Seth in pfSense via https://github.com/pfsense/pfsense/commit/302d646e9c25 and unfortunately his work seldomly mentions tickets or problem scope. The behaviour changed very little except that they now wait around 30 seconds for this to complete which tells us how problematic this implementation is to this day... yes I know it just continues after that time anyway ;)

Modernizing the existence check out of the way I don't mind making this wait up to 30 seconds as well. The only thing that I think is worth changing is that when 30 seconds passed without the interface being up a log message should be emitted for traceability?

Just a thought: for further consistency we could consider bringing the interface down if it exists before starting mpd5 again?

@nscheer is it ok to offload this to you or do you want me to take this over? just because I'd like to get this into the code rather sooner than later.

@nscheer is it ok to offload this to you or do you want me to take this over? just because I'd like to get this into the code rather sooner than later.

Yes, let me update my branch accordingly. Will get back to you, if something’s unclear.
Might be rather late today, tough :)

No problem. Let me know if I can help 👍

@fichtner I rebased on master and added the minimal changes I thought were needed.
Usually I'd like to mention the threshold value (i.e. 30 seconds) in the log message - but I'd rather introduce a constant for that than having the literals spread all over the place. Didn't know if there where any project specific style guides about that.
Let me know if I should adjust that.

Since we are talking about modernizing:
You just added the flag parameter to does_interface_exist and it has a default value.
Is it correct that this function is „newer“ than the legacy list function?
What do you think of adding an enum of interface states and require this in does_interface_exist? This way, we’d enforce correct use and have it self documenting. The enum can be backed by the string values the legacy function expects.
This would clean up the api a bit and we’d already use the enum for the first time.

We try to modifications in these parts of the code unless there is a fundamental technical issue that needs fixing. I just adopted the same style as legacy_interface_listget() as you can see this code is rarely touched over the years because risks of regressions are real.
There is probably very little benefit from sinking time here into a once-used API. Eventually when the MVC/API efforts shift to interface pages this whole code base is in need of a major overhaul anyway. But even then I doubt there is much need of checking if an interface exists and is up with this instance being the first in the code after many years without it.

Cheers,
Franco

Agreed, thanks for the clarification!

@nscheer merged, thanks! I modified it a bit. Can you make sure it still works as intended?

@nscheer FYI https://github.com/opnsense/core/commit/7c9b97ab74c

@fichtner Nice! Yes, still works as intended!

Thanks, will be in 24.7.2. 😊


Web interface for editing an assignment

An Edit button should appear for each assignment on https://ok-server.appspot.com/manage#/assignment/

This should be supported by the API.


preprocess

when I run your preprocess.py, it shows an error of KeyError:  'axis'

What's more, what are the 'pbd' that occur during the training process?

What's more, what are the 'pbd' that occur during the training process?  When I finish the traning, there is no ckp output


JsonSerialization

Description
This PR adds System.Text.Json serializer as a fallback.
We can configure the options in RemoteConfig.
Not registered protobuf types are serialized with json serializer but a warning is logged.

Very nice! 👍🏻


'appVersion' & 'releaseStage' management

'appVersion' & 'releaseStage' management for Bugsnag Configuration options

I did not allow myself to change #setAppVersion but in the absolute it should be named in a more generic way (initialization?)


GH-36641: [C++] Remove reference to acero from non-acero file

Rationale for this change
Files in modules which do not depend on the acero module should not reference files inside the acero module.
What changes are included in this PR?
There were no changes to the body of any functions.  I simply moved functions around so that the acero include was no longer needed.  There were some conflicts that arose between the class bit_util and the namespace bit_util and so I got rid of the class in favor of the namespace as that is more similar to how we handle bit_util elsewhere.
Are these changes tested?
Sort of.  I would like to add an AVX2 CI system as well.  I'm not confident any of the CI builds are building with AVX2 enabled.  Also, even if we have an AVX2 CI system it would not have caught this issue since the code was only needed definitions from the acero header and was not relying on any actual compiled symbols.  However, I think setting up tests to catch this sort of invalid include are beyond the scope of this PR.
Are there any user-facing changes?
No.

Closes: #36641

Sort of. I would like to add an AVX2 CI system as well. I'm not confident any of the CI builds are building with AVX2 enabled.

Probably not, though it should be easy to enable one of them. AVX2 is probably available on most server x86 CPUs nowadays?

I opened https://github.com/apache/arrow/pull/36662 to exercise compile-time AVX2 on CI.

@raulcd This would be nice to have in 13.0.0 if not too late.

Thanks, yes, I will cherry-pick


Error when preview definition

Description

LspSaga preview_definition() not correct working
Expected Behavior

See preview_defination

Actual Behavior

Error message

** Neovim version **
v0.6.0-dev
** Branch use **
Main

which branch, if main what nvim version are you on?

I am having the same issue. I am using the main branch.
:version output:
:version
NVIM v0.6.0-dev+594-g36538417f
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wm
issing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -D
MIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/n
vim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az65-601

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/share/nvim"

Screenshot of error:

I would try using the lsp builtin function lua vim.lsp.buf.definition() to see if this one returns a definition.
In general the function lua require('lspsaga.provider').preview_definition(), which I have substituted to the regular gd mapping from lspconfig, returns an error when a definition isn't found, such as:
stack traceback:
        ...onfig/nvim/plugins/lspsaga.nvim/lua/lspsaga/provider.lua:501: in function 'preview_definition'
        [string ":lua"]:1: in main chunk

This happens when searching a definition for keywords such as class or def (using pylsp), cases were lspconfig would simply do nothing if not going to the beginning of the word.
In other cases, like requesting the definition of a function whose definition is right under the cursor, so same behaviour for lspconfig, if opens the hover windows showing the right definition.
How saga behaves in this case:

after calling lua require('lspsaga.provider').preview_definition()

which is the current portion of code.
Maybe lspsaga should print a message when lspconfig wouldn't move at all, something like "you dumb are right on the definition you are asking".
@typoon does the error always happen or the behaviour is consistent with what I have just described?

So, the case where I am having this issue is in a .js file using tsserver.
If I stop the cursor over the forEach function and run :lua vim.lsp.buf.definition() I get redirected to the file lib.es5.d.ts which is the file that contains the definition of forEach.

The code I am using is the one below:
    ret = {};
    // Add some stuff to ret here
    Object.keys(ret).forEach(domain => {
        // Do some stuff using the keys from `ret`
    });

Now, if I try to use Lspsaga preview_definition I get:

Here is the cursor position for both cases (on top of the letter f in forEach):

There are cases in which the Lspsaga preview_definition works. For example in some ruby code I tested it worked fine. I can't say though if this issue happens only with JS code, or other languages as well.

I am having exactly the same issue with both tsserver, and angularls. The :lua vim.lsp.buf.definition() works, but the Lspsaga preview_definition does not. :-(

I added a print(vim.inspect(result)) just before
lspsaga.nvim/lua/lspsaga/provider.lua
Line 500 in 859b564
if vim.tbl_islist(result) and not vim.tbl_isempty(result[1]) then
It's showing me a table that starts with index 2, instead of 1:
{
[2] = {
result = { {
originSelectionRange = {
end = {
character = 15,
line = 53
},
start = {
character = 3,
line = 53
}
},
targetRange = {
end = {
character = 18,
line = 62
},
start = {
character = 6,
line = 62
}
},
targetSelectionRange = {
end = {
character = 18,
line = 62
},
start = {
character = 6,
line = 62
}
},
targetUri = "file:///"
} }
}
}
Hence the error in my situation. I don't know anything about Lua specifically, but I reckon that's a problem.

I think I know what's going on. I found this issue in the nvim repo, apparently vim.lsp.buf.formatting_sync uses the clientId as the key in the results returned. So it's not correct to assume that the result is always under key 1, so this bug only occurs when the client in question is not the one with id: 1 as can be found when doing :LspInfo.
So to fix this, we either need to know about the clientId or use the suggestion in that issue which is to use next() to fetch the next result in the table.

I wrote my own monkey patch using next(), and it's surfaced an interesting situation for me. I basically have two clients who are simultaneously attached to the buffer I am working in. vim.lsp.buf.formatting_sync uses both clients to request the definition preview, but it entirely depends on the order of the clients (seems to be chronologically based on their id), which result is used.
In my case, it's both tsserver and angularls, based on the order in which the clients were started either the result from tsserver is used, or the result from angularls. So it raises the question, how to deal with the following situations:

All of the n attached clients return a valid range?
One of the n attached clients has a valid range?

I'd say that for case 2 it's easy, just grab the result from the client that's actually worth showing. But for the other I am not sure, I think the cleanest would be just to show all the results that are given?

I'd say that for case 2 it's easy, just grab the result from the client that's actually worth showing. But for the other I am not sure, I think the cleanest would be just to show all the results that are given?

Interesting issue. I'd vote for having their contents merged and split with section titled with the lsp server e.g.
From Angularls: ────────────────────────────
and deciding what comes first based on what is most matching what the user expect i.g. valid range

I'm having the same issue with Rescript language server, doing the same print that @wesselvdv did, for some reason I get a table inside a table:
{ {
    result = {
      range = {
        end = {
          character = 8,
          line = 0
        },
        start = {
          character = 4,
          line = 0
        }
      },
      uri = "file:///Users/matheus.ashton/dev/pessoal/pet-manager/./src/App/Router.res"
    }
  } }

How can I fix this?

LspSaga preview_definition()

try without brackets.
Lspsaga preview_definition in C mode vim/nvim


[Bug] Sychronization fails for large RDF dataset

Community Note

Please use a 👍 reaction to provide a +1/vote. This helps the community and maintainers prioritize this request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Describe the bug
A customer is attempting to synchronize Explorer to a large RDF graph loaded into a Neptune cluster with Summary API support. The dataset, DBLP, in RDFXML format, has a size of 24GB, and contains ~364m triples accounting for duplicates.
On synchronization, we can confirm that this is not due to connectivity issues with the Neptune cluster, as the initial Summary API request succeeds. However, when the remaining SPARQL HTTP requests are executed to fetch the remaining schema information, all of them error out with a 504 Gateway Timeout due to a base limit of 60 seconds per fetch request.
If we execute some of these same SPARQL queries through graph-notebook, they are able to succeed. For example, the predicatesByClass query completes in ~86 seconds - this does not exceed the base Neptune query timeout of 2 minutes, but is too high for Explorer.

Fixes tried
I've looked into possible solutions involving hard-coding an increased timeout limit into the request. The fetch API, as used in the base _requestAndCache method in AbstractConnector, seems to accept a custom timeout through its signal init setting when it is defined as AbortSignal.timeout([time_in_ms]).
At the upper level, the fetchSchema method in SPARQLConnector defines the init settings to be passed down to the base fetch call. I tried modifying this line to also pass in the custom signal setting with timeout at 500k ms:
 const ops = { ...options, abortSignal: AbortSignal.timeout(500000), disableCache: true };

Unfortunately, this did not have an effect (or I implemented it incorrectly), as the schema query requests still timed out at exactly 60 seconds.

OS: Mac OS X
Browser: Google Chrome 114.x / Firefox 102.x
Graph Explorer Version: 1.2.0 / latest mainline build
Graph Database & Version: Amazon Neptune <IP_ADDRESS>

To Reproduce
Steps to reproduce the behavior:

Bulk load the DBLP RDF dataset (dblp.rdf.gz here) into your Neptune cluster.
Attempt to initiate sync to Neptune on SPARQL graph type.
Wait ~60 seconds, observe sync error.
Open browser console and see 504 errors.

Expected behavior
Connection sync should complete on large RDF datasets. We should increase the timeout to be much higher, or give the user an option to set a custom query timeout limit in the Connections UI.
If applicable, add screenshots to help explain your problem.
In Firefox:

In Chrome:

I seem to be having the same problem here.
I have 2 clusters on AWS Neptune.
Environment 1 has approximately 64GB and contains 120,302,148 triples.
Environment 2 has approximately 70GB and contains 145,403,562 triples.
I got these sizes in GB from the last snapshot.
The AWS Graph Explorer works, syncing correctly to Environment 1, but the synchronization fails for Environment 2.
There are several successful requests, but then it fails!
Could this be related to your issue @michaelnchin ?
I'd like to help with this issue, but I'm not sure how I can contribute.

Resolved in https://github.com/aws/graph-explorer/pull/199.


Introduce limits on the number of events allowed per command context

The changes here introduce hard limits to the number of events the system can accept per operation.
Each command operation will consist of at least 2 operations in a transactional batch, one for upserting the stream metadata and the other for adding events.
The following limitations are introduced:

A maximum of 10 events per command context (CQRS)
A maximum of 50 events per stream batch (Event Store)

CosmosDb Transactional batch operation limitations
Currently, there are two known limits:

The Azure Cosmos DB request size limit constrains the size of the TransactionalBatch payload to not exceed 2 MB, and the maximum execution time is 5 seconds.
There's a current limit of 100 operations per TransactionalBatch to ensure the performance is as expected and within SLAs.

This resolves #39

@LarsSkovslund I wrote this last night and thought that we can use this as a starting point for implementation detail discussions