Release 1.3.0.Beta31

Summary

https://github.com/quarkus-qe/quarkus-test-framework/pull/951
https://github.com/quarkus-qe/quarkus-test-framework/pull/949
https://github.com/quarkus-qe/quarkus-test-framework/pull/947
https://github.com/quarkus-qe/quarkus-test-framework/pull/946
https://github.com/quarkus-qe/quarkus-test-framework/pull/945
https://github.com/quarkus-qe/quarkus-test-framework/pull/944
https://github.com/quarkus-qe/quarkus-test-framework/pull/942
https://github.com/quarkus-qe/quarkus-test-framework/pull/941
https://github.com/quarkus-qe/quarkus-test-framework/pull/940
https://github.com/quarkus-qe/quarkus-test-framework/pull/939

Please check the relevant options

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Dependency update
[ ] Refactoring
[x] Release
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] This change requires a documentation update
[x] This change requires execution against OCP (use run tests phrase in comment)

Checklist:

[ ] Example scenarios has been updated / added
[ ] Methods and classes used in PR scenarios are meaningful
[ ] Commits are well encapsulated and follow the best practices

run tests

OCP JVM fails over OpenShiftStrimziOperatorKafkaWithoutRegistryMessagingIT, I tested it with both released version and  JVM and tests passed. IMO operator is flaky for same test passed in CI just yesterday and there were no changes in repository in the meanwhile: https://github.com/quarkus-qe/quarkus-test-framework/pull/951


Document how to properly set status codes when using SSR

Describe the problem that you experienced
For pages such as 404, 403, 500 etc. you need to set their respective status codes or they're treated as 200. However, the documentation doesn't mention this anywhere.
Enter the URL of the topic with the problem
https://angular.dev/guide/ssr
Describe what you were looking for in the documentation
Code examples and descriptions of how to set status codes on the response from the server when using SSR.
Describe the actions that led you to experience the problem
I was upgrading from v16 to v17, and with that came a new way of handling this. However, you're forced to dig through issues, or in my case, a commit for a new migration that shows what the code should look like after the migration runs (in my case it didn't even run, so had to do it manually).
And even after all that, the code is still not working in production. I've provided the REQUEST and RESPONSE injection tokens in server.ts and then injected this into my 404 page component where I set the status, but the status is always 200 after navigating to the 404 route.
You can see the code for this here:
https://stackoverflow.com/questions/77619409/angular-17-ssr-setting-status-on-response-doesnt-work-despite-using-injectionto
Describe what you want to experience that would fix the problem
I want the documentation page for SSR to properly and thoroughly describe how to add this (including code examples), and also how it works. Because right now it's very difficult to understand what to do, and I've seen multiple questions and issues on this. If the documentation would just state how to do this it will save a lot of people time and frustration.

@alan-agius4 Here you go: https://github.com/chriswoodie/status-repro
Steps to reproduce:

Clone repo
npm install
ng build sdk
ng build
npm run serve:ssr:repro-app

Go to http://localhost:4000/404 and check network status for the 404 page, you will see a 200 status instead of 404.
Turns out it's because of prerendering. If you set this to false for the project in angular.json the status code will be 404, which is correct.
Not sure if this is a bug or intended behaviour?

This is the indented behaviour when using prerendering, since there is no request/response information. If a page depends on such information prerendering needs to be opted out for that page.


Teradici PCoIP Client: init at 3.9.0~dev11

Two issues:

I could not "unvendor" libQt5Declarative.so.5.6.3 as I can't find it in any Nix package (see https://stackoverflow.com/questions/55071459/how-can-i-build-libqt5declarative-so) cc: @ttuegel @acowley
I cannot actually connect to an Amazon Workspace as I get this error: "The message is missing some content" (see https://communities.teradici.com/questions/10133/error-message-on-ubuntu-1604.html?childToView=10746#answer-10746)

Other than that, it's ready to roll :-)
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

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

Regarding point (1), @ttuegel explained that this libQt5Declarative.so.5.6.3 is likely a proprietary shared library which can no longer be built from QT tarballs but which has apparently been built by some from this repo: https://github.com/qt/qtquick1/tree/5.6.2 — but that's not a Yak I'm prepared to shave now.
Still waiting for Teradici support to help with (2).


footer renders stacked vertically for generated PDF

Description of the bug

Steps To Reproduce
each element in the footer stacks on top of each other
Additional Information
No response

Is this actually a "generated PDF" or is this from using the PrintButton component? The print button only calls window.print() in the browser and does not use the PDF service.

Is this actually a "generated PDF" or is this from using the PrintButton component? The print button only calls window.print() in the browser and does not use the PDF service.

Yes, this is from the printButton component

Not sure if I would classify this as a bug, but maybe more of a feature request to make the page more print friendly in general by adding some specific print styling using media queries to hide unecessary things and improve the layout somewhat. I mean, does the footer need to be shown at all in print?

Not sure if I would classify this as a bug, but maybe more of a feature request to make the page more print friendly in general by adding some specific print styling using media queries to hide unecessary things and improve the layout somewhat. I mean, does the footer need to be shown at all in print?

Not sure if I would classify this as a bug, but maybe more of a feature request to make the page more print friendly in general by adding some specific print styling using media queries to hide unecessary things and improve the layout somewhat. I mean, does the footer need to be shown at all in print?

No need to show the footer at all, its mainly used to send a copy of the summary before submitting


Correct handling of interior boundaries (related to "land masks")

I wanted to raise an issue that has come up via @stb2145's work with SODA.
The basic issue is that interp and diff are not aware of "interior boundaries", i.e. grid cells that are next to land. In the presence of such boundaries, the methods need to modify their weights to account for the "missing" data, applying some sort of boundary condition (e.g. Dirichlet or Neumann). Without explicit knowledge of land masks, the current implementation either grows the mask on the input data (in the case of NaN-filled data) or else gives a wrong answer near boundaries (in the case of 0- or constant-filled data). That's why I label this a bug.
I put together an example of a workaround outside of xgcm here:
https://nbviewer.jupyter.org/gist/rabernat/ade98c74909271a0d4dd8f7d7c435640
Basically this workaround uses the sort of kernel-based approach we are using in gcm-filters, also prototyped for xgcm in https://github.com/ocean-transport/coiled_collaboration/pull/12.
Shanice: to apply this method on dask-backed data, you would want to use apply_ufunc rather than the direct call to the interp_right_with_land function shown in the notebook.
Going forward, we need to decide if we want to refactor xgcm to allow for these sorts of kernel functions.
(Discussed tangentially in #293, #273)

I have updated the gist with an example of using this via apply_ufunc:
https://nbviewer.jupyter.org/urls/gist.githubusercontent.com/rabernat/ade98c74909271a0d4dd8f7d7c435640/raw/726d9e3a80b08875d6aa959252388a3794a78fc9/land-aware-interp.ipynb

This is marked as 'bug', why is the stale bot doing stuff here?

I think it is worth starting a chat about how to implement this on a high level, since we will soon have an opportunity to implement this similarly to what @rabernat has done above with #344.
On a very general level this involves 'filling' some grid points with values. This might have to involve adding the concept of a 'mask' similar to 'metrics' to xgcm (#293).
I am  proposing the API should look something like this:
grid.interp(..., internal_boundary='something')

Do folks here have thoughts about this signature?
I think this will work nicely from a performance standpoint, since we could wrap the  filling within the ufunc step in the former, but not in the latter. We can discuss later how to exactly do this (e.g. writing a ton of new ufuncs or adding a kwargs and a call to a separate function in the gridops.py module).
In terms of terminology, I am not a big fan of internal_boundary, but for the time being we need to separate physical boundaries (e.g. land) and domain boundaries (what to do with the edge of the array). Does anyone have suggestions for a more intuitive name?

Do folks here have thoughts about this signature?

I don't like internal_boundary. The grid_ufunc approach will bring some changes to how we think about boundaries. The Grid will now handle the "global array boundary" (i.e. what to do at the edges of the array) automatically, based on the grid topology. (For non-periodic Grids, one option may be to create a virtual land mask for points outside of the domain).
The only true "boundary conditions" from a PDE point of view will be the "internal" boundaries, i.e. cells that border some sort of land mask. Thus it should be simple enough to have just one "boundary" argument.
We would need different grid_ufuncs in the presence of such boundaries. With no land, we just have
@as_grid_ufunc(signature="(X:center)->(X:left)", boundary_width={"X": (1, 0)})
def interp_center_to_left(a):
    return 0.5 * (a[..., 1:] + a[..., :-1])

With land, we need another argument:
@as_grid_ufunc(signature="(X:center),(X:center)->(X:left)", boundary_width={"X": (1, 0)})
def interp_center_to_left_w_mask(a, wet_mask):
    # wet_fac = 0: water on left AND right
    # wet_fac = 1: water on left OR right
    # wet_fac = 2: no land nearby
    wet_fac = wet_mask[..., 1:] + wet_mask[..., :-1]
    return (a[..., 1:] + a[..., :-1]) / wet_fac

In this sense wet_mask is a property of the Grid, like the metrics. It would be great to have a way for the Grid to automatically fill in such arguments when the grid_ufunc is invoked.

The explosion of ufuncs feels wrong to me.
In this case though, can a grid not have wet_mask=1 (appropriate DataArrays actually) by default? In which case xgcm expects all ufuncs to handle it.  This makes sense given this point:

In this sense wet_mask is a property of the Grid, like the metrics.

The explosion of ufuncs feels wrong to me.

Can you say more about why?
There are performance tradeoffs. The first ufunc will be faster and allocate less memory. If we don't care about land masks, it's unambiguously better. I have no problem writing lots of different ufuncs to cover different special cases. The point of the protocol is to eliminate the boilerplate code so we can focus on the core computation.
The main challenge I see will be figuring out which ufunc to dispatch given our current API.

Because it instantly doubles the number of ufuncs anyone else has to write if they're doing something custom about land edges.

The first ufunc will be faster and allocate less memory.

Sure, but to check whether wet_mask is all True takes 8ms in a 170ms calculation at the upper end of chunksizes we tend to recommend. Is it really worth increasing the amount of code by ~ 30%?
# 400MB data chunk
data = np.ones((100, 1000, 1000), dtype=np.float32)
wet_mask = np.ones((100, 1000, 1000), dtype=bool)

def interp(data, wet_mask):
    if not wet_mask.all():
        int_mask = wet_mask.astype(np.int8)
        data = int_mask * data
        wfac = int_mask[..., :-1] + int_mask[..., 1:]
        return (data[..., :-1] + data[..., 1:]) / wfac
    else:
        return (data[..., :-1] + data[..., 1:]) / 2

%timeit wet_mask.all()
%timeit interp(data, wet_mask)
wet_mask[-1] = False
%timeit interp(data, wet_mask)

8.66 ms ± 385 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)
174 ms ± 10.9 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

/tmp/ipykernel_1264027/2687882246.py:10: RuntimeWarning: invalid value encountered in true_divide
  return (data[..., :-1] + data[..., 1:]) / wfac

349 ms ± 20.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

From a code simplicity point of view it would be nice to find a way to do this generally (and optionally) within apply_as_grid_ufunc.

First of all, thanks for all the comments. These are super helpful.

I don't like internal_boundary. The grid_ufunc approach will bring some changes to how we think about boundaries. The Grid will now handle the "global array boundary" (i.e. what to do at the edges of the array) automatically, based on the grid topology. (For non-periodic Grids, one option may be to create a virtual land mask for points outside of the domain).

Neither do I. If we introduce breaking changes we could switch to something like pad for the array boundaries (in line with the functionality we will be putting in soon) and use boundary for physical boundaries only?
From a performance point, could we not shift this logic to the grid creation?
if not wet_mask.all():
   int_mask = wet_mask.astype(np.int8)

in most cases this will be some 2d field and the overhead to grid creation should be minimal, but saving us the computation for each of the computation steps.
The grid would then carry the information whether there is an 'applyable' mask and if not we could just default to None, and the ufuncs could skip the filling step altoghether?
In a naive setup:

def diff_forward(a):
    return a[..., 1:] - a[..., :-1]

def apply_mask(a, mask, physical_boundary):
   # fill values with appropriate method
   return filled_a

@as_grid_ufunc(signature="(X:center)->(X:left)", mask=None,physical_boundary='something', boundary_width={"X": (1, 0)})
def diff_center_to_left(a):
    if mask:
        a = apply_mask(a, mask, physical_boundary)
    return diff_forward(a)

@as_grid_ufunc(signature="(X:left)->(X:center)", mask=None, physical_boundary='something', boundary_width={"X": (0, 1)})
def diff_left_to_center(a):
    if mask:
        a = apply_mask(a, mask, physical_boundary)
    return diff_forward(a)

If I am not missing something here, this would not be significantly slower when mask=None? I think @TomNicholas s design specifically allowed for more kwargs added this way?
I think overall this discussion is very valuable, because I anticipate that we might add some more inputs that are similar to metrics (e.g. partial cells) and then the increase in ufuncs would become really unwieldy.

Really enjoying the discussion. Everyone has such good points.
I think we are focused on different aspects that are not always mutually compatible. I am thinking about performance above all, since that is the reason we did the whole massive refactor in the first place--I want the grid_ufuncs to as fast as possible at the numpy level in every different scenario. Deepak seems to be thinking about the xgcm user experience. Tom is thinking about the code architecture part. Julius is trying to reconcile all of the above.
To clarify my suggestion, I am not proposing that xgcm users would have to know the difference between interp_center_to_left and interp_center_to_left_w_mask. I am envisioning an extra layer of "dispatch" between Grid.interp and these lower level ufuncs. I have no problem with us implementing a bunch of specialized grid_ufuncs for different circumstances, if there are performance advantages. But users should still just be able to call Grid.interp and have it do the "right" thing given their grid.
Specifically, I am assuming the initialized Grid object will already know whether it has a wet_mask or not. Then .apply_grid_ufunc will somehow* know whether to call  interp_center_to_left or interp_center_to_left_w_mask. So we skip even the if not wet_mask.all() call. Deepak's timing in https://github.com/xgcm/xgcm/issues/324#issuecomment-988246258 does also show that the difference between the two grid_ufuncs is nearly 2x, so picking the right one is important. Could we write them in numba and get 10x?
This is essentially a multiple-dispatch style problem, and as such it is a bit awkward in python. But I think we can make it work at least internally within xgcm for our specific use cases. The key question is: how does apply_as_grid_ufunc figure out which method to use under which scenario?
Maybe we need some sort of higher order concept of a grid_ufunc which has rules about dispatching to other private, more specialized methods? That sounds complicated though.
Deepak's comment also reveals the value of benchmarking, which we should do regardless of how we implement.

Thanks for the detailed comment, Ryan.
I ultimately think that we can make this discussion more quantitive by following this suggestion first?

Deepak's comment also reveals the value of benchmarking, which we should do regardless of how we implement.

Should we try to start benchmarking the code somehow before merging @TomNicholas refactor?
For this effort to be transparent I think we need to be a bit more precise with the meaning of "performance" here.
To me there are two aspects to the overall performance: The amount of dask chunks created (the main change of @TomNicholas refactor AFAIKT) and the amount of time each chunks needs for execution (@dcherian benchmark above). These can have non-trivial effects on high level method performance (e.g. when the chunking is suboptimal I can see a case where improving the ufunc speed has marginal influence on overall performance due to the dask task overhead?)
I believe we should test/benchmark each of these individually + test a 'typical' high level computation on a few sizes of datasets.
Having these datapoints for each PR would give us some less speculative ground to make a decision on. This is however a substantial amount of work?
Some more comments on the above:

will somehow* know whether to call interp_center_to_left or interp_center_to_left_w_mask.

As far as I understood, Toms dispatch is already pretty flexible and could probably handle this already (@TomNicholas correct me if I am wrong here).

I have no problem with us implementing a bunch of specialized grid_ufuncs for different circumstances, if there are performance advantages.

I would like to comment on this and would lean towards @dcherian here, because this could get out of hand rather quickly even for us maintainers.
From our discussion I always had the impression that if the user wants to squeeze the last bit of performance out of a calculation they would write their own specialized ufunc? We want the 'stock' ufuncs to be fast, but if we can save hundreds of lines of code and sacrifice only a few percent performance, I would personally go that route.
Connected to this: As I said above, I think we will not at all need the .all() call in the ufuncs. So if all that we add is if mask: will that actually affect the performance?

Should we try to start benchmarking the code somehow before merging @TomNicholas refactor?

The only "benchmarking" I have done so far was checking that the new dask algorithm creates the expected graph, same as what Ryan did in his notebook. I have a ToDo somewhere to at least write a test which checks if a change accidentally increases the number of required dask tasks. I have not really been thinking about the speed of the ufuncs themselves, partly because I was trying to do it in such a way that the ufunc could be anything, and also because my understanding was that dask graph performance at scale was the primary motivation (so that our group can handle LLC4320 data specifically).

As far as I understood, Tom's dispatch is already pretty flexible and could probably handle this already (@TomNicholas correct me if I am wrong here).

FYI This is where the ufunc dispatch code lives at the moment - right now it just looks for any grid ufuncs defined in the gridops.py module which match in name and signature, but you can see the pseudocode intended to match any kwarg.
The way I was imagining the dispatch working was to select via the kwargs given to the as_grid_ufunc decorator, but still allow arbitrary kwargs to be passed to the function. That would mean there was a difference between this
@as_grid_ufunc(signature="(X:center)->(X:left)", boundary_width={"X": (1, 0)})
def interp_center_to_left(arr, wet_mask=DEFAULT):
    ...

which means the one interp_center_to_left function needs to handle both wet and dry cases so to speak, and this
@as_grid_ufunc(signature="(X:center)->(X:left)", boundary_width={"X": (1, 0)}, wet_mask=DEFAULT)
def interp_center_to_left(arr):
    ...

which could allow for two different interp_center_to_left ufuncs, which are chosen between based on the presence of the wet_mask kwarg in the user's call.
A third option is to have the latter syntax, but instead of dispatching on wet_mask it gets handled generically in some way inside apply_as_grid_ufunc.

This is essentially a multiple-dispatch style problem, and as such it is a bit awkward in python.

There is more than one library for multiple dispatch in python, but I doubt that's the right solution here...

Also I think we should concentrate on making this work in the simplest way first, and then if that turns out not to be fast enough we make more granular ufuncs later. That way we get the benefit of improved dask graphs, but don't increase code complexity unless we need to.

I'm fine with that approach.


Fix access issue with intel-sgx-deb.key

Description of the changes
intel-sgx-deb.key is copied at root directory / few steps above but accessed using current working directory. It wasn't accessible in an image where current working directory is not a root directory /.
How to test this PR?
Create a distro image which have current working directory other than root directory / and specify the same distro image in configuration file and do the GSC build.

This change is

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions, not enough approvals from maintainers (3 more required), not enough approvals from different teams (2 more required, approved so far: ) (waiting on @jkr0103)

a discussion (no related file): Could I ask @sahason and @anjalirai-intel if this change looks correct to them? Just want to be sure we don't do any mistake with this PR.
-- commits line 7 at r1: Slight rewording:
Access `intel-sgx-deb.key` using absolute path

Previously, `intel-sgx-deb.key` was copied at root directory (/) but
accessed using current working directory (i.e., as a relative path). This led
to failures in images where current working directory is not a root dir.

Signed-off-by: jkr0103<EMAIL_ADDRESS>
(Need to fix the lines wrap to standard 72 chars per line.)

LGTM, and also no issues reported from ci run


cmd: improve user interface for help message by add default text

Default values were missing in help text after v0.6.1, this patch fixes it.
And sorted out some usage information.

Current help message:
NAME:
   containerd-nydus-grpc - Nydus remote snapshotter for containerd

USAGE:
   containerd-nydus-grpc [global options] command [command options] [arguments...]

COMMANDS:
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --version                                   print version and build information (default: false)
   --root value                                directory to save the working state of nydus-snapshotter (default: /var/lib/containerd-nydus)
   --address value                             gRPC socket path of nydus-snapshotter (default: /run/containerd-nydus/containerd-nydus-grpc.sock)
   --config value                              path to nydus-snapshotter configuration (such as: config.toml)
   --nydusd-config value, --config-path value  path to nydusd configuration (such as: nydusd-config.json or configuration_v2.toml) (default: /etc/nydus/nydusd-config.json)
   --daemon-mode value                         spawning nydusd daemon mode, possible values are: "multiple", "shared" or "none" (default: multiple)
   --fs-driver value                           image service based on which fs driver, possible values are: "fusedev", "fscache" (default: fusedev)
   --log-level value                           logging level, possible values are: "trace", "debug", "info", "warn", "error" (default: info)
   --log-to-stdout                             print log messages to standard output (default: false)
   --nydus-image nydus-image                   nydus-image binary path, it will be searched from $PATH if this option is not provided (such as: /usr/local/bin/nydus-image)
   --nydusd nydusd                             nydusd binary path, it will be searched from $PATH if this option is not provided (such as: /usr/local/bin/nydusd)
   --help, -h                                  show help

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.06 :tada:

Comparison is base (f848ed1) 37.13% compared to head (7216120) 37.20%.

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

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #456      +/-   ##
==========================================
+ Coverage   37.13%   37.20%   +0.06%
==========================================
  Files          60       60
  Lines        6912     6919       +7
==========================================
+ Hits         2567     2574       +7
  Misses       4048     4048
  Partials      297      297

Impacted Files
Coverage Δ

internal/flags/flags.go
100.00% <100.00%> (ø)

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

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

@sctb512 Please check the optimizer E2E test. It randomly fails, which is somewhat upset.


Add Nango

Added Nango to the list of SaaS Tools, it's open-source but the category seemed most fitting for what it does.
Let me know if there is anything that needs to be changed.

Thanks!


Update or delete custom units

Describe the solution you'd like
The custom units created can not be altered or deleted. If the user writes in wrong conversion unit or his units tend to change in future, then the user requires update or delete for his custom conversion.
Additional context
Required to do this

Custom units can now be deleted. I have linked the PR with the issue.


Image Resizer

Pull Request Template
image resizer -
Added the script and added documentation with instructions. The script has been fully passed flake8 test.
Issue no.(#175) -
Self Check(Tick After Making pull Request)

[x] This issue was assigned to me.
[x] One Change in one Pull Request
[x] My file is in proper folder (Name of folder should be in lowercase with no space in between)
[x] I am following clean code and Documentation and my code is well linted with flake8.
[x] I have added README.md and requirements.txt with my script

Two small suggestion @happyeric77

[ ] Add error handling if someone tries to resize it into a bigger size
[ ] Make script as smooth as possible for end-users means try to include "argparse" library which triggers from terminal no need to  put image path and name again and again in code

thanks for the suggestion @pawangeek
Let me restructure and commit again.

image resizer -
Two updates as belew:

Add argparser for user to manipulate the function on console prompt. Also add the instruction into README.
Add the error handling to prevent user inputing the value larger than original size.

Issue no.(#175) -
Self Check(Tick After Making pull Request)

[x] This issue was assigned to me.
[x] One Change in one Pull Request
[x] My file is in proper folder (Name of folder should be in lowercase with no space in between)
[x] I am following clean code and Documentation and my code is well linted with flake8.
[x] I have added README.md and requirements.txt with my script

Perfect @happyeric77

@all-contributors add @happyeric77 for code


[processBridge]: Error: Cannot get npm

Extension Version: 0.1.11
VS Code Version: 1.6.1
OS Version: Windows 10 x64
Node.js Version (result of command node -v): 6.5.0
NPM Version (result of command npm -v):

Steps to Reproduce:

When entering the command Ctrl + C P sends the error [processBridge]: Error: Cannot get npm

Log:
Error: Cannot get npm
at initModule (C:\Users\Diego.vscode\extensions\anseki.vscode-color-0.1.11\node_modules\process-bridge\process-bridge.js:216:13)
at getHostCmd (C:\Users\Diego.vscode\extensions\anseki.vscode-color-0.1.11\node_modules\process-bridge\process-bridge.js:329:9)
at C:\Users\Diego.vscode\extensions\anseki.vscode-color-0.1.11\node_modules\process-bridge\process-bridge.js:392:19
at Object.exports.sendRequest (C:\Users\Diego.vscode\extensions\anseki.vscode-color-0.1.11\node_modules\process-bridge\process-bridge.js:466:34)
at pickConvert (C:\Users\Diego.vscode\extensions\anseki.vscode-color-0.1.11\lib\color-helper.js:179:15)
at exports.pick (C:\Users\Diego.vscode\extensions\anseki.vscode-color-0.1.11\lib\color-helper.js:218:24)
Thanks

Hi @BlixsoftMexico,
That seems a part of log. The all of log is needed to find the cause. Could you please check that?
Also, could you please show me the version of NPM?

Hi!
This is all showing the console.

But, as I said, the version is needed to find the cause.

I found the problem, I have not used a long time and I VS Code watching operation.
The problem was that I had not installed Node.js package containing npm 2.15.9.
Now I jump these alerts in the console.
[Extension Host] Try to get npm via usage info.
threadService.ts:222[Extension Host] npm directory path: C:\Program Files\nodejs\node_modules\npm
threadService.ts:222[Extension Host] npm path: C:\Program Files\nodejs\node_modules\npm\lib\npm.js
threadService.ts:222[Extension Host] Base directory path: C:\Users\Diego.vscode\extensions\anseki.vscode-color-0.1.11
threadService.ts:222[Extension Host] Retry (Error: Cannot find module 'electron-prebuilt')
threadService.ts:222[Extension Host] Try to load: C:\Program Files\nodejs\node_modules\npm\lib\utils\spawn.js
threadService.ts:222[Extension Host] Spawn in silent-mode: C:\WINDOWS\system32\cmd.exe /d /s /c node install.js
threadService.ts:222[Extension Host]<EMAIL_ADDRESS>node_modules\comma-separated-values
<EMAIL_ADDRESS>node_modules\js-yaml
├──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>node_modules\electron-prebuilt
├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>└──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

I see.
So, was this issue solved?

Of course, solved.
Thank you

😃

Error: Cannot get NPM
at initModule (c:\Users\Karan D.vscode\extensions\anseki.vscode-color-0.4.5\node_modules\process-bridge\process-bridge.js:220:28)
at getHostCmd (c:\Users\Karan D.vscode\extensions\anseki.vscode-color-0.4.5\node_modules\process-bridge\process-bridge.js:331:9)
at c:\Users\Karan D.vscode\extensions\anseki.vscode-color-0.4.5\node_modules\process-bridge\process-bridge.js:394:19
at Object.exports.sendRequest (c:\Users\Karan D.vscode\extensions\anseki.vscode-color-0.4.5\node_modules\process-bridge\process-bridge.js:468:34)
at pickConvert (c:\Users\Karan D.vscode\extensions\anseki.vscode-color-0.4.5\lib\color-helper.js:187:15)
at exports.pick (c:\Users\Karan D.vscode\extensions\anseki.vscode-color-0.4.5\lib\color-helper.js:229:24)
at _executeContributedCommand (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:518:163)
at _.$executeContributedCommand (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:518:538)
at d._doInvokeHandler (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:623:396)
at d._invokeHandler (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:623:88)
at d._receiveRequest (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:621:783)
at d._receiveOneMessage (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:620:605)
at define.constructor._protocol.onMessage.e (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:618:791)
at u.fire (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:50:207)
at v.fire (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:186:579)
at i.constructor.e.onMessage.e (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:783:484)
at u.fire (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:50:207)
at v.fire (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:186:579)
at x._receiveMessage (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:191:17)
at define.constructor._socketDisposables.push._socketReader.onMessage.e (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:188:116)
at u.fire (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:50:207)
at f.acceptChunk (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:184:17)
at define.constructor._register._socket.onData.e (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:183:372)
at Socket.t (c:\Users\Karan D\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\services\extensions\node\extensionHostProcess.js:192:491)
at Socket.emit (events.js:182:13)
at addChunk (_stream_readable.js:283:12)
at readableAddChunk (_stream_readable.js:264:11)
at Socket.Readable.push (_stream_readable.js:219:10)
at Pipe.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)
notificationsAlerts.ts:40 [processBridge]: Error: Cannot get NPM

Hi @karandodwani, thank you for the comment.
Could you write the details with the template?

Extension Version: anseki.vscode-color-0.4.5
VS Code Version: 1.37.1
OS Version: Windows 8.1 x64
Node.js Version (result of command node -v):
NPM Version (result of command npm -v):

I am Not using Node.js ? Is it necessary to use this Extension ?

See document: https://github.com/anseki/vscode-color#install

Extension Version: anseki.vscode-color-0.4.5
VS Code Version: 1.65.2 (Universal)
OS Version: MacOS 12.3 Monterey
Node.js Version (result of command node -v): v17.7.1
NPM Version (result of command npm -v): 8.5.2
Error logs:
[2022-03-24 23:52:08.216] [renderer2] [error] [Extension Host] Error: Cannot get NPM 	at initModule (/Users/envy/.vscode/extensions/anseki.vscode-color-0.4.5/node_modules/process-bridge/process-bridge.js:220:28) 	at getHostCmd (/Users/envy/.vscode/extensions/anseki.vscode-color-0.4.5/node_modules/process-bridge/process-bridge.js:331:9) 	at /Users/envy/.vscode/extensions/anseki.vscode-color-0.4.5/node_modules/process-bridge/process-bridge.js:394:19 	at Object.exports.sendRequest (/Users/envy/.vscode/extensions/anseki.vscode-color-0.4.5/node_modules/process-bridge/process-bridge.js:468:34) 	at pickConvert (/Users/envy/.vscode/extensions/anseki.vscode-color-0.4.5/lib/color-helper.js:187:15) 	at exports.pick (/Users/envy/.vscode/extensions/anseki.vscode-color-0.4.5/lib/color-helper.js:229:24) 	at f._executeContributedCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:85:30255) 	at f.$executeContributedCommand (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:85:30797) 	at n._doInvokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:89:13812) 	at n._invokeHandler (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:89:13496) 	at n._receiveRequest (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:89:12158) 	at n._receiveOneMessage (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:89:10836) 	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:89:8945 	at d.invoke (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:145) 	at w.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:1856) 	at c.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:19017) 	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:104:34267 	at d.invoke (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:145) 	at w.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:1856) 	at c.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:19017) 	at s._receiveMessage (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:23598) 	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:21132 	at d.invoke (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:145) 	at w.fire (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:58:1856) 	at w.acceptChunk (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:15848) 	at /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:66:14978 	at Socket.P (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:104:13790) 	at Socket.emit (events.js:315:20) 	at Socket.EventEmitter.emit (domain.js:467:12) 	at addChunk (internal/streams/readable.js:309:12) 	at readableAddChunk (internal/streams/readable.js:284:9) 	at Socket.Readable.push (internal/streams/readable.js:223:10) 	at Pipe.onStreamRead (internal/stream_base_commons.js:188:23)
Please help me to take a look.

Hi @hknguyenvu, thank you for the comment.
That seems to be a part of log, and it is a lack of information.

Hi @hknguyenvu, thank you for the comment. That seems to be a part of log, and it is a lack of information.

Thanks. I have updated the log

I see.
The NPM seems to be not installed. You said that you have Node.js v17.7.1, and the log said that Node.js v14.16.0 is running.
Therefore it seems that multiple Node.js exist in your computer. And Node.js v14.16.0 doesn't have NPM.
Try this:
cd /Users/envy/.vscode/extensions/anseki.vscode-color-0.4.5
npm i<EMAIL_ADDRESS>
And restart VS Code, and run the extension.

When I check on my terminal with command npm -v, I see my version is 8.5.2
Is this line related?
Extension Host] Error: The programmatic API was removed in npm v8.0.0

Is your extension not compatible with npm v8.x?

The Node.js might not be available in a process VS Code will run.
Therefore the commands may solve the issue.

Yah, after running that command and restart the vscode, the extension works now.
Thanks for your help.


finish ray program in HTML export

Need to decide on format for transferring ray data. Javascript array handling clumsy compared to Numpy. Maybe in Javascript we just have LineProgram. with the lines loaded from a file.

Done in 866d3b5f720a29929cdd2bf6258dd75f4a2483f7


New Compromised User report details missing

In MC203355 there is notice about a new Compromised Users Report that is not documented on this page.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 51e62b98-5f0c-8fc3-8163-c028fa5a6445
Version Independent ID: b8262fa8-ff97-db0a-b2b5-4dd624fb057b
Content: View reports for Office 365 Advanced Threat Protection, malware reports, phish reports, compromised accounts, URL protection status, threat reporting, report threats - Office 365
Content Source: microsoft-365/security/office-365-security/view-reports-for-atp.md
Service: o365-seccomp
GitHub Login: @denisebmsft
Microsoft Alias: deniseb

Disregard. Information about this report is now available here with a link from the SCC - https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/view-email-security-reports?view=o365-worldwide#compromised-users-report-new.

@kellybos - Thank you for submitting feedback.
From your last comment, it appears that you found the resolution of your issue so I will go ahead and close this issue.
Please feel free to open a new issue if you find any documentation error or if there is a specific area of the docs that we can improve on and we will be glad to help fix it. Thank you.


Update introduction-to-ensembles.qmd

I'm seeing that the your turn doesn't render in the ensembles slides but I am not seeing why. This PR was copying in the exact code from the models as a spectrum slides which do work

engine: knitr is missing from the header
(can update the output filename, too, whilst you're there)


refactor: moving bouncer to blockifier - adding the bouncer object and the transactional part

This PR includes the Bouncer struct and the TransactionBouncer commit and abort.
The complex logic of tx data updates in the transactionBouncer will be added in the next PR

This change is

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 70.19%. Comparing base (6a7742c) to head (454cd6e).
Report is 10 commits behind head on main.

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

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1566      +/-   ##
==========================================
+ Coverage   70.05%   70.19%   +0.14%
==========================================
  Files          60       60
  Lines        8244     8283      +39
  Branches     8244     8283      +39
==========================================
+ Hits         5775     5814      +39
- Misses       2003     2004       +1
+ Partials      466      465       -1

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


Cannot save entire JSON map to property

I have a situation where the fields of a map are always changing and I need to expose some metadata that is consistent but also the data fields.
Looking for something like this:
@JsonSerializable(createToJson: false)
class Entry {
  final Meta meta;

  @JsonKey(restJson: true)
  final Map<String, dynamic> data;

  Entry(this.meta, this.data);

  factory Entry.fromJson(Map json) => _$EntryFromJson(json);
}

The idea is that the entire json map would be stored at Entry.data and would be packaged up with all of its metadata.
Is there any way to achieve this today?

My modified generated code looks like this
// GENERATED CODE - DO NOT MODIFY BY HAND 😂

part of 'entry.dart';

// **************************************************************************
// JsonSerializableGenerator
// **************************************************************************

Entry _$EntryFromJson(Map json) {
  return Entry(
      json['__meta__'] == null ? null : Meta.fromJson(json['__meta__'] as Map),
      json['id'] as int,
      (json)?.map((k, e) => MapEntry(k as String, e)));
}

Oh, so you want the ability to store the json content as well as the fields?
I doubt I'll do that work, but I'd accept a pull request.

I started poking around the repo but didn't get very far. Any suggestions for strategy? I was thinking of just adding a "restData" property to @JsonKey()

Also, here is a more accurate representation of what I'd like to generate
// GENERATED CODE - DO NOT MODIFY BY HAND

part of 'entry.dart';

// **************************************************************************
// JsonSerializableGenerator
// **************************************************************************

Entry _$EntryFromJson(Map json) {
  return Entry(
      json['__meta__'] == null ? null : Meta.fromJson(json['__meta__'] as Map),
      json['id'] as int,
      ((json ?? {})..removeWhere((k, e) => k == "__meta__" || k == "id"))
          .map((k, e) => MapEntry(k as String, e)));
}

Instead of removeWhere you likely want Map.fromEntries(json.entries.where((e) => const !['__meta__', 'id'].contains(e) or something.
I'd also suggest adding a different annotation all together. Something like JsonRest – since the other values on JsonKey would be noise.

Sounds like a new annotation like @JsonRest({bool trimmed = true}) would be appropriate. I'll put a couple hours into this later and see how far I get.

@lukepighetti
Another question: would you want the extra things dumped back out in toJson?

Hi @kevmoo, I've been away from GitHub the last couple months. I don't personally have a need for that feature.


Negative inc of vector && clblasConjTrans supported

Hi @ptillet
We used clBLAS test suite to test the functional correctness of current ISAAC code and found that there are two points that ISAAC blas code didn't align with blas api standard.
1, negeative inc for vector; 2, clblasConjTrans on parameters.
This patch supported negative inc for vector and clblasConjTrans, and can pass all the clblas correctness test.

Thank you! :)


AppData: Remove .desktop from ID

ID should not include .desktop

@amka when it's convenient, could you make another release? We want to make sure this resolves the icon issue we're seeing in AppCenter.

@cassidyjames Done. 0.1.3 release published


"Just do it" install script

When we have the infrastructure in place (images pushed to Docker Hub, etc) an inexperienced user should be able to run a single command and get up and running - possibly without even cloning the repo.
We hate it but possibly even the classic curl | bash one liners you see all over the internet...

@kristiankielhofner Any ETA on a Docker image for WIS?


Refetch is ignored if fired during initial fetching of a query

Describe the bug
Hello!
I have recently discovered a certain behavior in react-query, which causes some edge cases in our application. This is related to the query refetching during the initial load of the query.
Inside our application, we currently use the refetch method from queries for refetching the data upon receiving certain events. It usually works perfectly well - refetch cancels any running requests if there are any (because of the default cancelRefetch = true), and makes sure that we always receive newest data. However, it seems there is an exception - looks like refetch is ignored if it's called during the initial query fetch.
After looking into react-query source code, I noticed this part:
  fetch(
    options?: QueryOptions<TQueryFnData, TError, TData, TQueryKey>,
    fetchOptions?: FetchOptions,
  ): Promise<TData> {
    if (this.state.fetchStatus !== 'idle') {
      if (this.state.dataUpdatedAt && fetchOptions?.cancelRefetch) {
        // Silently cancel current fetch if the user wants to cancel refetches
        this.cancel({ silent: true })

which to me indicates that fetch is only being canceled if dataUpdatedAt is not a falsy value, and dataUpdatedAt becomes truthy one of two ways: when initial fetch succeeds, or if initialData is provided  inside the query.
Is there maybe any other way to force refetching even though query is still initially loading? I assume such behavior could randomly cause issues in architectures where refetch is used as a reaction to events, even though I couldn't found similar reported issues inside tanstack-query repo.
Your minimal, reproducible example
https://codesandbox.io/p/sandbox/react-query-refetching-during-initial-fetch-kg6knf
Steps to reproduce
In our app we encounter issues with the following scenario:

User opens a page where query is mounted for the first time, and starts the initial fetch.
During the initial fetch we receive a websocket event from backend, informing us that the data got updated and needs to be refetched, so we call the "refetch" method of the query from step 1
Refetch is ignored because the query is still fetching initially
The initial fetch of the query from step 1 completes, containing old incorrect data

In the codesandbox I added two components side to side to demonstrate the issue - both examples contains identical code, except that in one of them the query has initialData defined.

Upon enabling the query which does not have initialData, it can be seen that refetch is ignored, and the difference between start and end is the original 2s
Upon enabling the query which has initialData, it can be seen that refetch is not ignored, and the difference between start and end is 3s, because refetch triggers fetching again after 1s

Expected behavior
As a dev i would expect to have a way to refetch the query even if such need arises during the initial fetch of the query.
How often does this bug happen?
None
Screenshots or Videos
No response
Platform

Browser: chrome

Tanstack Query adapter
None
TanStack Query version
v5.13.4
TypeScript version
No response
Additional context
No response

I think you're right, that's why the flag is called cancelRefetch and not cancelFetch - it can only cancel a refetch, and a refetch is a fetch where we already have data.
Not sure why we have that implementation / limitation. I would argue that cancelFetch is more appropriate - why would we only do this for refetches. But not sure if we can fix this in a non-breaking way? If we change the implementation and remove the this.state.dataUpdatedAt check - it would change the behaviour and the cancelRefetch name would be confusing.
I tried that, but we do have a test that covers this scenario:
https://github.com/TanStack/query/blob/1f0088e5fa9030cbabc7a881c3e6b9cc127f70d9/packages/react-query/src/__tests__/useQuery.test.tsx#L514-L546
So, I really don't think we can change this right now. next major maybe? I always prefer less code and less surprising behaviour, but I also don't want to change this now without renaming the flag.

For your cases - what you can do is call queryClient.cancelQueries({ queryKey }) to manually cancel it instead of letting refetch take care of it. That should work.

Hi @TkDodo, thanks for your answer!
I agree that the current flag name (cancelRefetch) works exactly as the name implies - it only cancels refetches. cancelFetch would make more sense, since the current behavior of cancelRefetch creates that blind spot, which might not be obvious for library users. Both flags could potentially coexist, but it would only make dx more confusing IMO, so I also agree with you that it would only make sense introducing it as a breaking change somewhere down the road (if such decision would be made).
P.S queryClient.cancelQueries was what I tried initially - this does not seem to cancel the initial fetch either, only the following ones. This also matches with the cancelQueries description, where canceling refetches is mentioned as a use case:

This is most useful when performing optimistic updates since you will likely need to cancel any outgoing query refetches so they don't clobber your optimistic update when they resolve.

this does not seem to cancel the initial fetch either

Hmm I looked at the code and queryClient.cancelQueries should also cancel initial fetches.
I wrote a quick test for that to confirm, and it passes:
test('should also cancel initial queries', async () => {
  const key = queryKey()
  void queryClient.fetchQuery({
    queryKey: key,
    queryFn: async () => {
      await sleep(10)
      return 'data'
    },
  })
  await queryClient.cancelQueries({ queryKey: key })

  const state = queryClient.getQueryState(key)

  expect(state).toMatchObject({
    data: undefined,
    status: 'pending',
  })
})

Aaah, sorry, seems to be my mistake, related with how query client was being imported. Query canceling seems to be working just as described. Thanks for your help! I believe this issue can be closed

@AlgirdasVZ @TkDodo Thank you. This issue allowed me to half solve a use case in our product.
Just mentioning my use case if it will help someone else.

Form including simple inputs
using useQuery with refetch as manual submit activation for the form. The query is without side affect - just calculation returned from the server.
Each change in the form (dirty state) activate reset of the query state.

3 made the dataUpdatedAt 0 so the requests were not canceled if the user clicked on the submit couple of times.
I am not sure if this scenario is best practice use for react-query, but regardless, the mention to use initialData to effect dataUpdatedAt gave a somewhat solution for this case.


Update default branch name from master to main in CONTRIBUTING.md

Description
I guess default branch has been changed from master to main, right?
Currently, default is main and target branch of each PR is also main.
So I updated the document.

Related Issue
no issue, is it right?

Motivation and Context
master branch has not deleted today. (BTW, It sounds good to delete master branch if maintainer is OK)
If newbie or creator or who follow the CONTRIBUTING.md faithfully might make a PR to master branch.
I can prevent it by updating document.

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Great catch, thank you!

Thank you for your review and merging it!


Jira cards

MOB-91

GitHub issues

Closes #

HOW DO I TEST OUT THIS PR?
Review the Scheduled firestore Export function.
WHICH ENDPOINTS SHOULD BE READY FOR TESTING?:
IS THERE ANY JENKINS CONSOLE LINK FOR CODE COVERAGE AND BUILD INFO?
ARE THERE ANY RELATED PRs?

Thank you @123MwanjeMike
I've resolved that now.

Thanks @BenjaminSsempala I see the src/firebase/backup/package-lock.json file has no corresponding package.json file. Could we have this removed since there's already another package-lock.json file in functions directory that has a corresponding package.json file

Hi @BenjaminSsempala, please add a README file


central repository sync

Could you upload spek to the central maven repository as well?
The problem is that if I build an app tested with spek, then I will not be able to upload to central because from central repository all artifacts depending on external repositories are rejected. see [1]
Thank you!
1: http://blog.sonatype.com/2010/03/why-external-repos-are-being-phased-out-of-central/

Now that a 1.0-eap is available can getting this into The Central Repository be prioritized higher? Thanks.

Absolutely. Will be putting it there with the release.


Pearson vortex test

PR co-authored with @sandreza
This PR tests Oceananigans with the Pearson vortex test from p. 310 of "Nodal Discontinuous Galerkin Methods: Algorithms, Analysis, and Application" by Hesthaven & Warburton.
Error after 100 time steps:
i: 100, t: 0.008, Δu: (avg=0.000224, max=0.000224), Δw: (avg=0.000224, max=0.000224)

which compares well with the DG error (considering our low-order numerics).
We discovered that recomputing w from continuity breaks this test because du/dx = 0 and dv/dy = 0 by construction so w = 0 even though this is wrong. This is probably because we need to impose Neumann boundary condition on w, but recomputing w from continuity requires us to assume the value of w[i, j, :], which we take to be 0 since we usually run with a rigid lid. So we switched to explicitly time stepping w which means this PR is "DO NOT MERGE" is its current state.
Note: Before the test is merged, more comments are needed in the pearson vortex test.

Never mind, I rewrote the test to act in the x,y plane with more complicated time-dependent boundary conditions at the top and bottom for u and v.
It still works and doesn't require changes to the time stepping (which have been reverted).
Will add this to the tests.

Interestingly, all the tests still pass when we explicitly time-step w instead of recompute it from continuity. So still not clear whether we need to do the recomputation.

Ali, what are the time-dependent conditions at top? Free slip should be
good: du/dz=0
On Tue, Aug 6, 2019, 6:38 PM Ali Ramadhan<EMAIL_ADDRESS>wrote:

Never mind, I rewrote the test to act in the x,y plane with more
complicated time-dependent boundary conditions at the top and bottom for u
and v.
It still works and doesn't require changes to the time stepping (which
have been reverted).
Will add this to the tests.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/climate-machine/Oceananigans.jl/pull/336?email_source=notifications&email_token=AKXUEQUPZKYNNCILQG2ECITQDH4PTA5CNFSM4IJ2G5UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3WVFWI#issuecomment-518869721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKXUEQTOLS6ZGXSWBIYRBQDQDH4PTANCNFSM4IJ2G5UA
.

@johncmarshall54 Good point.
The flow field satisfies
u(x, y, z, t) = -sin(2π*y) * exp(-4π^2 * ν * t)
v(x, y, z, t) =  sin(2π*x) * exp(-4π^2 * ν * t)

from which we can get both time-dependent Dirchlet conditions
u(z = 0) = -sin(2π*y) * exp(-4π^2 * ν * t)  # example BC for u_top

and zero Neumann boundary conditions du/dz = 0 so I decided to impose the more complicated Dirchlet condition thinking they were more correct for some reason.
Just switched to using zero Neumann boundary conditions and it works just as well so that's nice (and more concise)!

We originally did the recompilation of w from continuity partly because we thought this may prevent an accumulation of error that could otherwise occur, and partly because @sandreza convinced us this was more correct. But I would argue that because we haven't done model verification we aren't sure whether this is correct or not.
Another issue, or annoyance, with recomputing w from continuity is that it is only valid in the case of rigid lids on top and bottom.

agree with Greg. I would prefer we get w by stepping forward for w because
then there are no concerns about rigid lids etc. We ended up using
continuity because the elliptic inversion was missing a div.v/delt source
term. When that problem got fixed I believe integrating forward for w works
just fine. Ali, can you confirm?
On Wed, Aug 7, 2019 at 8:16 AM Gregory L. Wagner<EMAIL_ADDRESS>wrote:

We originally did the recompilation of w from continuity partly because we
thought this may prevent an accumulation of error that could otherwise
occur, and partly because @sandreza https://github.com/sandreza
convinced us this was more correct. But I would argue that because we
haven't done model verification we aren't sure whether this is correct or
not.
Another issue, or annoyance, with recomputing w from continuity is that it
is only valid in the case of rigid lids on top and bottom.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/climate-machine/Oceananigans.jl/pull/336?email_source=notifications&email_token=AKXUEQUD4TCBCCFDIMAPNC3QDK4KXA5CNFSM4IJ2G5UKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3YGJQY#issuecomment-519070915,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKXUEQQPFPDDHQ2JSNTPR3TQDK4KXANCNFSM4IJ2G5UA
.

--
John Marshall
Cecil and Ida Green Professor of Oceanography
Massachusetts Institute of Technology
http://oceans.mit.edu/JohnMarshall/

We have some pretty strict incompressibility tests which did pass when I switched to explicit time-stepping for w. So it seems like it works just fine.
We could make the switch in another PR.

Seems like there are no objections to this PR so I'm merging.

Few comments here:

I sent an email to Ali (@ali-ramadhan) and Chris (@christophernhill) on Apr 02 2019,
and Ali opened issue #161 the same day and included a copy of my email content in it.
So, "originally" w was stepped forward, not the other way.
do we currently have a good Float32 test ?
machine truncation error in solver when we switch to variable vertical resolution ?
I disagree with the last point, recomputing w from continuity is fine with free surface
and with flow through the bottom (cf, MITgcm). In fact, it might be even more useful
with a non-linear free-surface since, in this case, some linearization is needed when
solving for pressure.

On Wed, Aug 07, 2019 at 05:16:43AM -0700, Gregory L. Wagner wrote:

We originally did the recompilation of w from continuity partly because we thought this may prevent an accumulation of error that could otherwise occur, and partly because @sandreza convinced us this was more correct. But I would argue that because we haven't done model verification we aren't sure whether this is correct or not.
Another issue, or annoyance, with recomputing w from continuity is that it is only valid in the case of rigid lids on top and bottom.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/climate-machine/Oceananigans.jl/pull/336#issuecomment-519070915

@jm-c, my comment referred to the non-validity of this algorithm in cases with either open or periodic vertical boundary conditions.

@jm-c I hope you don't mind if I move your comments to the newly opened issue as this PR is closed now.

@glwagner and my point was that it could be use with open vertical boundary conditions but, indeed,
it does not handle the periodic vertical BC.
On Wed, Aug 07, 2019 at 07:31:50AM -0700, Gregory L. Wagner wrote:

@jm-c, my comment referred to the non-validity of this algorithm in cases with either open or periodic vertical boundary conditions.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/climate-machine/Oceananigans.jl/pull/336#issuecomment-519123720


add OpenAI Interface address for New utility: Advanced Paste, an AI powered tool to convert your clipboard content into another format.

Description of the new feature / enhancement
add OpenAI Interface address for New utility: Advanced Paste, an AI powered tool to convert your clipboard content into another format.
Scenario when this would be used?
For example: i want to use Azure OpenAI or other LLM AI tool which compatiable with openAI interface
if we can set the AI interface address prefix, it is can use other LLM AI tool
Supporting information
No response

It seems that OpenAI endpoint address is just hard-coded now.  Adding an endpoint option and allowing users to use their own Openai-compatible services like vLLM shouldn't be difficult.

bump! very surprised it wasn't done in the first time

/dup #32960


feat: manifest list writer

This adds a manifest list writer based on the discussion in #72.

CC @Xuanwo @JanKaul PTAL

@barronw This is great! One question, do we need the Avro file (the one in testdata/)? I don't see it being referenced, and we generally try to avoid binary data in the repository.

The Avro files are used to test ManifestList::parse_with_version in test_parse_manifest_list_v1 and test_parse_manifest_list_v2.
ManifestList::parse_with_version is used to test ManifestListWriter, so I don't think we should also use ManifestListWriter to generate the Avro files to test ManifestList::parse_with_version.

@Fokko Are there any other changes that need to be made?

@barronw No, I think we're good 👍

Thanks for working on this @barronw and @liurenjie1024, @Xuanwo and @ZENOTME for the review 👍


Add Sticky Messages Feature

I've marked this PR as a draft since the feature implementation has not been completed yet.
Some changes:
if not isModerator(message.author) should use an await
There is a different code implementing permissions verification for the stick and unstick commands, let both utilise the same.
Instead of onmessage, let the commandhandler which has already been setup and is being used for other commands be used to handle this command too.

Should we close this pr as its already been completed #104

Implemented in #102


Log which character attachment was marshalled on

Fixes #1300.

Git. 🙃

try rebasing your branch with my master, it still looks weird


Automatic dependency declaration in combination with initscript doesn't seem to work in all cases with gradle 4.X

Hi,
I experienced a strange issue with automatic dependency declaration in combination with initscript.
In general what I'm doing is declaring a dependency and repository inside the initscript and use it inside the build.gradle. The dependency is declared with projectsLoaded->allprojects->buildscript->dependencies
For full reference I have attached a sample.zip config where I currently can reproduce the issue.
The file includes three files

init-gradle-3.X.gradle -- initscript
init-gradle-4.X.gradle -- initscript
build.gradle -- default build script

Expected Behavior

gradle --init-script init-gradle-3.X.gradle foo works with every gradle version

Current Behavior

gradle --init-script init-gradle-3.X.gradle foo works fine up to gradle 3.X and breaks with gradle 4.X
gradle --init-script init-gradle-4.X.gradle foo works fine up to gradle 4.X (tested gradle 2.X and gradle 3.X)

Context

I use this to maintain automatic dependency and repository injection for multiple projects.
Steps to Reproduce (for bugs)

Download and extract
sample.zip
Use gradle 4.X and execute
gradle --init-script init-gradle-3.X.gradle foo
The
gradle --init-script init-gradle-4.X.gradle foo
command works fine.
Your Environment

------------------------------------------------------------
Gradle 4.1
------------------------------------------------------------

Build time:   2017-08-07 14:38:48 UTC
Revision:     941559e020f6c357ebb08d5c67acdb858a3defc2

Groovy:       2.4.11
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_144 (Oracle Corporation 25.144-b01)
OS:           Linux 4.10.0-32-generic amd64

------------------------------------------------------------
Gradle 4.0
------------------------------------------------------------

Build time:   2017-06-14 15:11:08 UTC
Revision:     316546a5fcb4e2dfe1d6aa0b73a4e09e8cecb5a5

Groovy:       2.4.11
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_144 (Oracle Corporation 25.144-b01)
OS:           Linux 4.10.0-32-generic amd64

------------------------------------------------------------
Gradle 3.5
------------------------------------------------------------

Build time:   2017-04-10 13:37:25 UTC
Revision:     b762622a185d59ce0cfc9cbc6ab5dd22469e18a6

Groovy:       2.4.10
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_144 (Oracle Corporation 25.144-b01)
OS:           Linux 4.10.0-32-generic amd64

Thanks for reporting. I'm glad to see you have solved this
This is due to an execution order change in Gradle 4.0. Basically, projectsLoaded and allprojects are both registering closures that won't be executed immediately, so some unexpected issues may happen when they are nested. This should be avoided. I'll close this, please feel free to reopen it if you still have questions.


AutoSizer does not show list items with scrollToIndex

Demo here: https://plnkr.co/edit/6GFoRcQrM3jdy3aYGvly?p=preview
I have a list that pans out when a user clicks the open button. However, when I use it with scrollToIndex to scroll to a specific list item, it seems to hide the items that are above the index. And if you change the index to a larger number, the entire list disappears. This problem goes away when you scroll onto the list, but it returns you to the top instead of the indexed item.

Not sure what the demo is showing but it's not using AutoSizer correctly. (The width and height parameters are ignored in favor of hard-coded values.) Here's a fork that seems to work fine: https://plnkr.co/edit/5NsaqR?p=preview
Closing this for now since it seems to work okay for me. We can keep talking here though if I'm overlooking something. 😄

Are you saying that the AutoSizer can only pan out vertically instead of horizontally?
Did you see how the demo doesn't show the menu items before the scrollToIndex? Or you can check this one (https://plnkr.co/edit/uYtFXdNNw1a5CRwKgaO8?p=preview). When I pick a large scrollToIndex number... the entire list is missing.

No. I was juust saying that the original Plnkr is strange. This is not how AutoSizer should be used:
<AutoSizer>
  {({height, width}) => ( // height and width are not used, so why use AutoSizer?
    <List
      width={this.state.open ? 500 : 0}
      height={700}

I think the problem you're reporting is that the combination of setting scrollToIndex with a height and/or width of 0 causes the scrollToIndex property to be ignored, since no cells are rendered when height or width are 0.
If you change...
width={this.state.open ? 500 : 0}

...to...
width={this.state.open ? 500 : 1}

...your example works. I'll re-open. Feel free to submit a PR if you'd like. 😄

Yes. I tried to do 1 instead of 0 and used a CSS visibility to hide the list. It works but it seems to be a hack.

Yeah. I was just thrown by the original Plnkr b'c it seemed like it was doing things that weren't valid.

I will see if there's a fix for this over the weekend :)

Resolved via 67f9dc5

Fix released with 9.8.0


Added regression test for requests page

Motivation and context

Added test for #8575
How has this been tested?

Checklist

[ ] I submit my changes into the develop branch
[ ] I have created a changelog fragment
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (see GitHub docs)
[ ] I have increased versions of npm packages if it is necessary
(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

Summary by CodeRabbit

New Features

Introduced a new test case for handling export request failures on the requests page, ensuring user-friendly error messaging.

Bug Fixes

Enhanced error handling to prevent UI crashes during export status request failures.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 74.25%. Comparing base (bce96ea) to head (6c78921).

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #8608      +/-   ##
===========================================
+ Coverage    74.22%   74.25%   +0.03%
===========================================
  Files          403      403
  Lines        43375    43375
  Branches      3925     3925
===========================================
+ Hits         32195    32210      +15
+ Misses       11180    11165      -15

Components
Coverage Δ

cvat-ui
78.69% <ø> (+0.16%)
:arrow_up:

cvat-server
70.47% <ø> (-0.08%)
:arrow_down:


Make grafana.ini template compatible with both Python 2 and 3

When using this role in an environment where the default python
interpreter is python3, the ansible run fails when jinja2 tries to
process templates/grafana.ini.j2.
This is because in Python 3, dict objects no longer have the
.iteritems() method (see e.g.: https://wiki.python.org/moin/Python3.0,
under "Built-in Changes").
For the purposes it's used in the template, .items() is functionally
equivalent to .iteritems() except that it also works in Python 3.

Thanks!


crashlytics action fails when setup_jenkins enabled

New Issue Checklist

[x ] Updated fastlane to the latest version
[x ] I have read the Contribution Guidelines

Issue Description
The job fails when setup_jenkins is enabled.
Otherwise it succeeds but I want all artefacts stored in a single directory.
Complete output when running fastlane, including the stack trace and command used
/usr/local/bin/fastlane build_deploy --verbose

https://gist.github.com/dodikk/aefa4db8a5532cb220027cb7b29c3f54
Environment
fastlane --version
fastlane 1.70.0

Do you use bundler, rbenv or rvm?

No

Hi @dodikk hope you are doing well! Can you try setting the parameters, output_directory and derived_data_path?
That should let you get up and running :+1:

Can you try setting the parameters,  output_directory and derived_data_path?

@TKBurner , thanks for the reply.
Which action are you referring to? Which line of my fast file should I look at?

@dodikk This is on the setup_jenkins action. Let me know how it goes :+1:

@dodikk  The underlying error seems to be coming from gym, in the move_ipa method
ArgumentError: same file: /Users/Shared/Jenkins/jenkins_fastlaneworkspace/OlaCabs_ios_app/output/OlaCabs-Debug.ipa and /Users/Shared/Jenkins/jenkins_fastlaneworkspace/OlaCabs_ios_app/output/OlaCabs-Debug.ipa

It is trying to move the generated ipa to Gym.config[:output_directory] but they're the same.
Hope this helps!

@dodikk Let me know if you got up and running! Thanks 👍

It is trying to move the generated ipa to Gym.config[:output_directory] but they're the same.

@asfalcone , not sure how I can apply this information.

@dodikk Let me know if you got up and running!

We used copy_artifacts action to achieve the results.
setup_jenkins is no more used in our builds.
Sorry for replying this much late.

You need to add output_directory param to setup_jenkins here and set it to something other than "./output" which is where gym is already putting the .ipa. Let me know if setting that changes the behavior. 👍  Thanks.

I'm going to close this issue since it has been open for a while without follow up.


[CAMEL-19324]Be able to convert all elements from CXF MessageContents…

…List.class to String.class if not in "CXF Context"
Description

Target

[ ] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[ ] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[ ] I checked that each commit in the pull request has a meaningful subject line and body.

[ ] I formatted the code using mvn -Pformat,fastinstall install && mvn -Psourcecheck

Thanks @davsclaus !


Tooltip explaining why tangential arc is disabled for first path

When users start a sketch, they can (currently) only start with a straight line. The tangential arc tool is greyed out for the first path.
I found this confusing, but then Mike explained that the first segment can't be a tangential arc, because there's no previous line for it to be tangent to. This is obvious in hindsight but I was very confused by it!
So I suggest adding a tooltip to the greyed-out, inactive Tangential Arc button explaining why. "The first path can't be a tangential arc, because there's no previous line to be tangential to!"
This will be less confusing once we have buttons for other kinds of arcs (non-tangential)

This issue was addressed in a batch PR #4341 that included the commits from the PR #4315.


Added Explanation about array.

Made some changes to the file i.e. adding some information about the array for a general idea about arrays.

Remember to raise an issue prior to PR.


[Feature] Estimate Tutor Grading Effort

Checklist

[ ] I tested all changes and all related features with different users (student, tutor, editor, instructor, admin) on the test server https://artemistest.ase.in.tum.de.
[x] Server: I followed the coding and design guidelines.
[x] Server: I added multiple integration tests (Spring) related to the features (with a high test coverage)
[x] Server: I added @PreAuthorize and check the course groups for all new REST Calls (security)
[x] Server: I implemented the changes with a good performance and prevented too many database calls
[x] Server: I documented the Java code using JavaDoc style.
[x] Client: I followed the coding and design guidelines.
[x] Client: I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
[x] Client: I added authorities to all new routes and check the course groups for displaying navigation elements (links, buttons)
[x] Client: I documented the TypeScript code using JSDoc style.
[x] Client: I added multiple screenshots/screencasts of my UI changes
[x] Client: I translated all newly inserted strings into English and German.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.

Motivation and Context

One objective way of evaluating tutor grading effort is estimating the overall or average time spent manually assessing text submissions.
We have already introduced Tracking of user interactions in assessment of text exercise which already collects and tracks when tutor interactions are ocurring. The solution would be to perform a time-series analysis on that collected data regarding interactions and extracting the approximate time spent by grading the submissions. This PR resolves #3921  by analysing the text assessment events.
The result of this PR is showing statistical data regarding distribution of time spent grading a text exercise.
This feature is implemented to assisst in an objective evaluation of the tutor effort while grading text submissions manually. As the automated feedback suggestion mechanism is updated/improved, this feature will therefore be used to assess whether there is a significant time improvement on the tutors end or not.
Description

Steps for Testing

Log in to Artemis
Navigate to Course Administration
Open prepared course with already assessed submissions by tutors. Use user 15.
Open some of the text exercises detail page present there.
Click on "Tutor Effort Statistics" button shown.
Check that the graph shows as shown in the screenshots attached.
The graph should show without any warning or errors.

Review Progress

Code Review

[ ] Review 1
[ ] Review 2
[ ] Review 3
[ ] ....

Manual Tests

[ ] Test 1
[ ] Test 2
[ ] Test 3
[ ] .....

Test Coverage

Screenshots

Statistics page:

Statistics page when there is no data present:

Thanks for the review @Olimbia23. Applied the suggestions here

Thank you for applying my suggestions @ndricimrr 😊
Approve the code 🎉

Applied your suggestions @imstreetspirit


UI for searching for one of your accounts

When users have a lot of accounts, it makes it difficult to find a specific account that they want to either get the balance of or have access allowed to. Attached are some screenshots:

@corwinharrell I'd find this pretty useful (feels like it could be useful for signing and login routes too?)


free up gulp-jspm

If you're not sure whether you're going to actually build this package, free up the name on npm. So someone else might actually build it.
this is an open source community where everyone can benefit from. not a domain name registrar parking domains with ads on :)

of course, sorry for potentially blocking this for someone else. I didn't
manage to get it going.
I just unpublished the package. Keep me up to date :)
cheers
Andreas
On Wednesday, May 27, 2015, Sander Houttekier<EMAIL_ADDRESS>wrote:

If you're not sure whether you're going to actually build this package,
free up the name on npm. So someone else might actually build it.
this is an open source community where everyone can benefit from. not a
domain name registrar parking domains with ads on :)
—
Reply to this email directly or view it on GitHub
https://github.com/andreasgrimm/gulp-jspm/issues/2.


Tutorial fails to run

I am attempting to run the Getting Started Tutorial and have strait copy pasted the code thinking I screwed something up. When attempting to run I get a fatal crash. Get the following exception:
System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=Veldrid
StackTrace:
at Veldrid.D3D11.D3D11Shader.CompileCode(ShaderDescription description) in C:\projects\veldrid\src\Veldrid\D3D11\D3D11Shader.cs:line 83
at Veldrid.D3D11.D3D11Shader..ctor(Device device, ShaderDescription description) in C:\projects\veldrid\src\Veldrid\D3D11\D3D11Shader.cs:line 27
at Veldrid.D3D11.D3D11ResourceFactory.CreateShaderCore(ShaderDescription& description) in C:\projects\veldrid\src\Veldrid\D3D11\D3D11ResourceFactory.cs:line 60
at Veldrid.ResourceFactory.CreateShader(ShaderDescription description) in C:\projects\veldrid\src\Veldrid\ResourceFactory.cs:line 393
at GettingStarted.Program.LoadShader(ShaderStages stage) in C:\Codebases\VeldridTest2\VeldridTest2\Program.cs:line 127
at GettingStarted.Program.CreateResources() in C:\Codebases\VeldridTest2\VeldridTest2\Program.cs:line 76
at GettingStarted.Program.Main(String[] args) in C:\Codebases\VeldridTest2\VeldridTest2\Program.cs:line 33

Changing the LoadShader switch to use .hlsl instead of .hsls.bytes corrects the issue.

I'm receiving this error compiling using both SPIR-V with Veldrid.Spirv or direct HLSL in Veldrid 4.6.1


Regular crashes over last couple of weeks ? Connection Refused

Describe the bug
Add On crashes, watch dog doesn't restart it,
Add on has worked solidly for a long time, but in last couple of weeks or so have been getting frequent crashes.
Can't be 100% sure what version of home assistant or supervisor started the problems.
Application version
v1.2.3
Texecom alarm type
Premier Elite 24 (V5.02.01LS1)
Home Assistant version
Home Assistant 2023.3.5
Supervisor 2023.03.1
Operating System 9.5
Frontend 20230309.1 - latest
Debug log
2023-03-17 01:00:31 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)...
node:events:368
      throw er; // Unhandled 'error' event
      ^
Error: connect ECONNREFUSED <IP_ADDRESS>:10001
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '<IP_ADDRESS>',
  port: 10001
}

Hi, did you get a resolve to this? I have a very similar issue.
HAS is fully up to date. The add-on runs for a while and the stops and fails to restart. The error message consistently being as follows:
“ERROR: Unhandled rejection - Command 25 timed out 5 times and could not be completed“
Any help would be appreciated

After around two years wiuth no problems, my texecom2mqtt seems to stop every day and fails to restart.  Apart from standard Home Assistant updates:
Home Assistant 2023.4.6
Supervisor 2023.04.1
Operating System 10.0
Frontend 20230411.1 - latest
I have stopped using Zigbee devices as I can use existing Texecom "Ricochet" PIRS and Door/Window detectors.
Any ideas/updates.

We've been having similar issues too, seems to crash when there is an exit error on the alarm.
Shame the project appears to be abandoned as it works better than other integrations.
If it was open source we could have a go at fixing it.
Hopefully the dev is still around :)

Also having this problem, worked a treat for over 2 years. Then it started with the odd crash, now it's like 4-5 times a day.
I disabled watchdog to see if I can grab exactly what's causing the problem...here is the log output
2023-07-28 11:35:36 - ERROR: Corrupt response from panel: CRC 91 is invalid (message: 744d087e193d005b)
2023-07-28 11:35:36 - INFO: Panel disconnected, exiting now
I think this would be the same as other.  It's becoming pretty frustrating.. 😬

Ours seems to have a guaranteed crash on an arm fail. Other scenarios I haven’t been able to confirm the crash reason.

I have a very similar issue: when I have a power outage, connection to the Smartcom is lost (through things like network switches being offline). I get a 'Host unreachable' error rather than 'Connection refused' error, but from the same line of code.   The watchdog doesn't seem to restart it.  Or maybe it tries but gives up too quickly.
So I've implemented my own simple watchdog: every 15 mins, it looks to see whether my alarm is 'unavailable', and if so, it tries starting the add-on.  On my initial tests, this seems to work nicely!
- alias: Texecom2mqtt watchdog
  id: "texecom2mqtt_watchdog"
  initial_state: on
  mode: restart
  trigger:
    - platform: time_pattern
      minutes: "/15"
      seconds: 00

  condition:
    - condition: state
      entity_id: alarm_control_panel.house_alarm
      state: "unavailable"

  action:
    - service: hassio.addon_start
      data:
        addon: c15a2434_texecom2mqtt

If you're not doing this through the GUI, the add-on name at the bottom can be deduced by looking at the URL when you're viewing the add-ons page.
This was inspired partly by this post where people had problems with Zigbee2MQTT crashing.

Ooooh! That looks very useful. I will have a go myself as the app does not
seem to restart on its own as I find it "stalled" from time to time.
On Thu, 12 Oct 2023 at 12:41, Quentin Stafford-Fraser <
@.***> wrote:

I have a very similar issue: when I have a power outage, connection to the
Smartcom is lost (through things like network switches being offline). I
get a 'Host unreachable' error rather than 'Connection refused' error, but
from the same line of code. The watchdog doesn't seem to restart it. Or
maybe it tries but gives up too quickly.
So I've implemented my own simple watchdog: every 15 mins, it looks to see
whether my alarm is 'unavailable', and if so, it tries starting the add-on.
On my initial tests, this seems to work nicely!

alias: Texecom2mqtt watchdog
id: "texecom2mqtt_watchdog"
initial_state: on
mode: restart
trigger:

platform: time_pattern
minutes: "/15"
seconds: 00

condition:

condition: state
entity_id: alarm_control_panel.house_alarm
state: "unavailable"

action:

service: hassio.addon_start
data:
addon: c15a2434_texecom2mqtt

If you're not doing this through the GUI, the add-on name at the bottom
can be deduced by looking at the URL when you're viewing the add-ons page.
This was inspired partly by this post
https://community.home-assistant.io/t/tenacious-watchdog-for-add-ons-example-for-zigbee2mqtt/521888
where people had problems with Zigbee2MQTT crashing.
—
Reply to this email directly, view it on GitHub
https://github.com/dchesterton/texecom2mqtt-hassio/issues/82#issuecomment-1759445262,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABFWRDQEPSGNTHKLHVKKRNDX67JN5ANCNFSM6AAAAAAV6INXFQ
.
You are receiving this because you commented.Message ID:
@.***>

Thanks - might be just what I need.

In case anyone needs the Node-RED equivalent

[{"id":"23254f671972abaa","type":"debug","z":"7e84ab06f46c8a03","name":"texecom2mqtt stopped","active":true,"tosidebar":false,"console":true,"tostatus":false,"complete":"\"The texecom addon became unavailable. Attempting restart.\"","targetType":"jsonata","statusVal":"","statusType":"auto","x":490,"y":440,"wires":[]},{"id":"39ec83dce9f97913","type":"api-call-service","z":"7e84ab06f46c8a03","name":"Start it","server":"82070ffe.b97dd","version":5,"debugenabled":false,"domain":"hassio","service":"addon_start","areaId":[],"deviceId":[],"entityId":[],"data":"{ \"addon\": \"c15a2434_texecom2mqtt\" }","dataType":"json","mergeContext":"","mustacheAltTags":false,"outputProperties":[],"queue":"none","x":430,"y":500,"wires":[[]]},{"id":"6097cfd23c08ee70","type":"poll-state","z":"7e84ab06f46c8a03","name":"Texecom2MQTT unavailable","server":"82070ffe.b97dd","version":3,"exposeAsEntityConfig":"","updateInterval":"15","updateIntervalType":"num","updateIntervalUnits":"minutes","outputInitially":false,"outputOnChanged":true,"entityId":"alarm_control_panel.texecom_alarm","stateType":"str","ifState":"unavailable","ifStateType":"str","ifStateOperator":"is","outputs":2,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"}],"x":160,"y":440,"wires":[["23254f671972abaa","39ec83dce9f97913"],[]]},{"id":"82070ffe.b97dd","type":"server","name":"Home Assistant","version":5,"addon":true,"rejectUnauthorizedCerts":true,"ha_boolean":"y|yes|true|on|home|open","connectionDelay":true,"cacheJson":true,"heartbeat":false,"heartbeatInterval":30,"areaSelector":"friendlyName","deviceSelector":"friendlyName","entitySelector":"friendlyName","statusSeparator":"at: ","statusYear":"hidden","statusMonth":"short","statusDay":"numeric","statusHourCycle":"h23","statusTimeFormat":"h:m","enableGlobalContextStore":true}]

I was getting this error regularly too with an Elite 48. My SmartCom had verion 3 firmware and the pannel was running 5.01.03 LS6 firmware. I upgraded the SmartCom to version 4.05.01 then the pannel to version 6.05.03 LS6 (using Texecom Cloud). I've not seen this error again since I upgraded over a week ago. Arming and disarming the alarm through Home Assistant seems more reliable now as well.

Ive updated all firmware on both smartcom and Panel elite 24 still get disconnected below is my latest error log
2024-02-15 05:02:22 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)...
node:events:368
throw er; // Unhandled 'error' event
^
Error: connect EHOSTUNREACH <IP_ADDRESS>:10001
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1161:16)
Emitted 'error' event on Socket instance at:
at emitErrorNT (node:internal/streams/destroy:157:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -113,
code: 'EHOSTUNREACH',
syscall: 'connect',
address: '<IP_ADDRESS>',
port: 10001
}
Is this the case of just host unreachable
Don't know why it would be unreachable as haven't dropped connection to it

I've improved performance by putting the docker on the "host" network.
I use a ComWiFi, and I need to reset the COM port  BEFORE docker starts else it gets confused/upset.


Fix: Remove comments associated with deleted properties in pom.xml

Fixes #35
Enhance the removeOffendingProperties method in PomModifier.java to remove comments associated with deleted properties.

Identify comments directly above the properties jenkins-test-harness.version and java.level and remove them along with the properties.
Update unit tests in PomModifierTest.java to verify the removal of comments associated with deleted properties.

For more details, open the Copilot Workspace session.

@coderabbitai review.

https://github.com/coderabbitai review


Improve partial affinity refresh

Changes made while debugging #66

add audit against computed partial range
call #ensurePeerDisconnected for symmetry and more consistency
a bit more log info

r @Raynos @rf

:ok:


Support signing interface in Azure KeyVault

Fixes GH-917
Release Note

Add support for Azure as a Signing Key Manager

/retest


delete all Please enter the commit message for your changes. Lines starting

need to fix the code scanning alert


Update chai

I have rebased and add one commit (1f1e6cd) to remove uses of chai-as-promise for recent changes

avatar
board
encryption
user
metrics

no longer relevant


Copying default security to user namespace when API level security is not defined

Description:
whenever user does not defined securities in swagger definition should use default security schema. It should copied to the user namespace as well. The flow copies the security when resources level securities are not defined. should do the same when API level securities not defined.
Suggested Labels:

Suggested Assignees:

Affected Product Version:
OS, DB, other environment details and versions:
Steps to reproduce:
Related Issues:

Resolved in https://github.com/wso2/k8s-apim-operator/pull/83


Storage service testapp

Mostly just a WIP to serve as a reference until I get around to making it more robust.

Killing this PR now that we've got an e2e scenario internally.


eps range

Should the following
https://github.com/phajy/Sesto2024/blob/0d2ed51889ff1fd7df30d616b42b3a537a7eb846/src/jp-fit.jl#L22
be changed to
eps_range = collect(range(-0.5, 3.0, N))

Yes, it should!