Errors picked up in console but not shown inline

Hi,
After following all of the setup instructions, I opened a file that has an linting error that should be flagged and noticed that although the console suggested stylelint had found an error, there was nothing to suggest inline that the line had an error on it.
This is the output from the console:
SublimeLinter: stylelint output:
CssSyntaxError: c:\users\{username}\appdata\local\temp\SublimeLinter3-bateson.j\notify.css:2:1: Missed semicolon
    at Input.error (C:\Users\{username}\node_modules\postcss\lib\input.js:61:22)
    at Parser.checkMissedSemicolon (C:\Users\{username}\node_modules\postcss\lib\parser.js:495:26)
    at Parser.decl (C:\Users\{username}\node_modules\postcss\lib\parser.js:270:50)
    at Parser.word (C:\Users\{username}\node_modules\postcss\lib\parser.js:135:30)
    at Parser.loop (C:\Users\{username}\node_modules\postcss\lib\parser.js:60:26)
    at parse (C:\Users\{username}\node_modules\postcss\lib\parse.js:26:12)
    at new LazyResult (C:\Users\{username}\node_modules\postcss\lib\lazy-result.js:61:24)
    at Processor.process (C:\Users\{username}\node_modules\postcss\lib\processor.js:34:16)
    at lintString (C:\Users\{username}\node_modules\stylelint\dist\standalone.js:88:9)
    at C:\Users\{username}\node_modules\stylelint\dist\standalone.js:70:14

I have placed the .stylelintrc config file in my home directory as well as installed postcss and stylelint in there (and in the project directory just in case as I wasn't too sure)
I was just wondering if you had seen an issue like this before or if I need to set anything in my SublimeLinter user settings?
Any help would be much appreciated,
Thanks
Jim

I'm trying to solve the same problem and I have no idea what's causing this. I'll let you know if I get it solved.

Check this issue: https://github.com/kungfusheep/SublimeLinter-contrib-stylelint/issues/25


Admin panel - Inventory movements

Show all inventory transactions (inv_log) and allow admin to revert transactions.

Log can be seen by admin users since commit #0676e52f34036649baf727eb353f169e923385c3

Unless it is requested, feature will not allow to revert past transaction for now.


Improvements of general hyperbolic framework

This PR improves the general hyperbolic framework from #3598 in several way:

Added Jacobians to of the convection terms of HyperbolicFormIntegrator (AssembleElementGrad() and AssembleFaceGrad()), using also the underlying (new) method of RiemannSolver for gradient (Grad())
Added new methods to RiemannSolver for the average flux (Average()) and its Jacobian (AverageGrad()), which rely on the new methods ComputeAvgFlux(DotN)() of FluxFunction. This is for example used in HDG #4350
Added Godunov flux and extended Rusanov flux
Added a switch for Riemann solvers to example 18(p)
Added the normal flux implementation to AdvectionFlux and BurgersFlux and implemented the new methods
Added a sign parameter to HyperbolicFormIntegrator
Other minor improvements of the code and documentation

❓ Most of the code has been tested in darcy-hdg-dev branch. The regression tests there can be run by from examples folder by regression_test.py

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#4513
@najlkin
@tzanio
@tarikdzanic + @pazner + @mlstowell + @cjvogl
9/21/24
⌛due 10/5/24
⌛due 10/12/24

PR Checklist

[x] Code builds.
[x] Code passes make style.
[x] Update CHANGELOG:

[ ] Is this a new feature users need to be aware of? New or updated example or miniapp?
[ ] Does it make sense to create a new section in the CHANGELOG to group with other related features?

[ ] Update INSTALL:

[ ] Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
[ ] Have the version ranges for any required or optional libraries changed?
[ ] Does make or cmake have a new target?
[ ] Did the requirements or the installation process change? (rare)

[ ] Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)

[ ] .github
[ ] .appveyor.yml

[ ] Update .gitignore:

[ ] Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
[ ] Add new patterns (just for the new files above) and re-run the above test.

[ ] New examples:

[ ] All sample runs at the top of the example source file work.
[ ] Update examples/makefile:

[ ] Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
[ ] Add any files generated by it to the clean target.
[ ] Add the example binary and any files generated by it to the top-level .gitignore file.

[ ] Update examples/CMakeLists.txt:

[ ] Add the example code to the ALL_EXE_SRCS variable.
[ ] Make sure THIS_TEST_OPTIONS is set correctly for the new example.

[ ] List the new example in doc/CodeDocumentation.dox.
[ ] If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add example-specific documentation, see e.g. the src/examples.md.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] In examples.md, list the example under the appropriate categories, add new categories if necessary.
[ ] Add a short description of the example in the "Extensive Examples" section of features.md.

[ ] New miniapps:

[ ] All sample runs at the top of the miniapp source file work.
[ ] Update top-level makefile and makefile in corresponding miniapp directory.
[ ] Add the miniapp binary and any files generated by it to the top-level .gitignore file.
[ ] Update CMake build system:

[ ] Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
[ ] Add/update the CMakeLists.txt file in the new miniapp directory.
[ ] Consider adding a new test for the new miniapp.

[ ] List the new miniapp in doc/CodeDocumentation.dox
[ ] If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
[ ] If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
[ ] Companion pull request for documentation in mfem/web repo:

[ ] Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
[ ] Add the description, labels and screenshots in src/examples.md and src/img.
[ ] The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
[ ] Add a short description of the miniapp in the "Extensive Examples" section of features.md.

[ ] New capability:

[x] All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
[ ] Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
[ ] Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
[ ] Consider adding new sample runs in existing examples to highlight the new capability.
[ ] Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
[ ] If this is a major new feature, consider mentioning it in the short summary inside README (rare).
[ ] List major new classes in doc/CodeDocumentation.dox (rare).

[ ] Update this checklist, if the new pull request affects it.
[x] Run make unittest to make sure all unit tests pass.
[x] Run the tests in tests/scripts.
[ ] (LLNL only) After merging:

[ ] Update internal tests to include the new features.

Hi @najlkin,
Thank you for the great PR.
Including additional numerical flux and average flux is a great improvement.
I took a quick look and it looks good to me. I'll look into more detail early next week.
Would you please include the usage of other fluxes in ex18.cpp and ex18p.cpp to make new fluxes more accessible and for easier testing?
Best, Dohyun

A good point @dohyun-cse :wink: , I added the new Riemann solvers to ex18 and ex18p, so there is a command line switch for them now. Rusanov and Godunov work fine. However, I am getting negative pressure with Engquist-Osher 😕 , any ideas?

Oh, I maybe see it. If u- > u+, then the integral maybe should be interpreted as negative. However, that would mean that there is no difference between Godunov and Engquist-Osher for monotonous fluxes... 🤔

Yes, I think it must be like that to satisfy symmetry when reversing the sweep/axis, i.e., when you swap u- and u+ and the sign of the normal 🤔 . My bad, I did not realize that. I will remove Engquist-Osher as it should coincide with Godunov.

This PR is now under review (see the table in the PR description). To help with the review process, please do not force push to the branch.

Sorry for adding and then deleting in-line comments: I thought it perhaps better to ask the question as a general comment. I understand the FluxFunction interface to be for the evaluation of the hyperbolic flux function.  This motivates the FluxFunction::ComputeFlux function, with the added property of the maximum characteristic speed.  Perhaps this is merely due to my lack of experience with the motivating HDG method, but I don't see computing the average as a property intrinsic to the hyperbolic flux function (i.e., why FluxFunction::ComputeAvgFlux).  Is it typical for there to be an analytic average expression specific to a given flux function that cannot or should not otherwise be evaluated by the RiemannSolver?

@cjvogl , I clarified the definition of the average flux, which is just $\int_{u_1}^{u_2}F(u)du / (u_2-u_1)$. I do not want to evaluate this integral numerically, which would be expensive to do at every integration point in space. Instead, you may evaluate it analytically for simple fluxes like those provided in hyperbolic.hpp, or decide to provide some "good enough approximation" for your custom fluxes 😉 .

I clarified the definition of the average flux, which is just ∫ u 1 u 2 F ( u ) d u / ( u 2 − u 1 ) .

Ah ok, are the ComputeAvgFlux and ComputAvgFluxDotN methods only applicable to scale equations (i.e., $u_1, u_2$ but not $\vec{u}_1, \vec{u}_2$)?

In principle, it can be for vectors. There is the parameter num_equations of FluxFunction, so it is up to you, but the advection and Burgers fluxes, which I use as examples, are scalar. Also it should be mentioned that Jacobians are dense matrices, so you may have cross-component dependencies 😉 .

In principle, it can be for vectors.

Can you update the documentation to indicate how it would be for vectors/systems?

Ok, I have not thought about that question before, but I defined that average component-wise, because only partial averages make sense to me for non-homogeneous things like Euler equations. On the other hand, some alternatives exist when you have something homogeneous like components of momentum 🤔 But that is on the user to abuse the framework 😄

To clarify on the situation with systems, I have not got to that on the side of HDG, so I am not completely sure what will be needed there. I plan to make then another PR and provide examples for the shallow water or Euler fluxes :wink:. This PR is large already, so I did not want to wait for that...

To clarify on the situation with systems, I have not got to that on the side of HDG, so I am not completely sure what will be needed there. I plan to make then another PR and provide examples for the shallow water or Euler fluxes 😉. This PR is large already, so I did not want to wait for that...

That makes sense.  My main concern is that the documentation is sufficient so that it is clear what is currently expected in a derived class. I suppose another option would be to put in a verify statement that checks something like num_equations == 1 is 1 with an error message noting that systems are not yet supported (which would then be removed in a future PR when there are examples for systems).

@cjvogl , that makes sense, but where would you put it? It is just an interface, so FluxFunction::ComputeAvgFlux() has just MFEM_ABORT(). The only implementations are in AdvectionFlux and BurgersFlux, which are both scalar by construction 🤔 .

@cjvogl , that makes sense, but where would you put it? It is just an interface, so FluxFunction::ComputeAvgFlux() has just MFEM_ABORT(). The only implementations are in AdvectionFlux and BurgersFlux, which are both scalar by construction 🤔 .

Ah, good point... maybe just note in the documentation that the average is as you have it with some additional wording to note that systems are not yet support.

@cjvogl , I added some notes to Rusanov and Godunov flux, as the simplification for systems is not really on the side of flux function, where I am just defining a general interface, but rather the implementation in the Riemann solvers, which treat systems by components. It was the case already before for classical Eval() and it is just extended now to Average(), where the flux function is assumed to comply with that.

I might be wrong here but I think this implementation of the Godunov Riemann solver is valid only for scalar conservation laws. For the Euler equations in ex18 you'd need an exact Godunov-type Riemann solver.

I might be wrong here but I think this implementation of the Godunov Riemann solver is valid only for scalar conservation laws. For the Euler equations in ex18 you'd need an exact Godunov-type Riemann solver.

Well, I was not much concerned much about systems of equations in this PR and, as said above, I plan to make another PR when I get to them. Currently, Godunov is implemented the same way as Rusanov, working component-by-component. I just added it to example 18 on the request above, so please take it as it is for now. It seems to work fine in the example like Rusanov does, but I am open to some documentation changes for the Riemann solvers, for example? Because you are right that their current implementation is very simplistic. I am already mentioning that the Jacobians are only diagonal and fluxes component-wise calculated in the doxygen of their methods.

The example case there is very mild so I wouldn't expect it to fail there, but it would likely start having some issues with more difficult problems. Up to you if you want to leave it in (but maybe add a comment in the example mentioning something like it's not really meant for the Euler equations in its current form). My only worry is that people might take the example case to indicate that it's a Godunov-type Riemann solver for the Euler equations without knowing and use it in their codes which might cause them issues.

@tarikdzanic , I added a note to the description of the switch for Riemann solvers and also a runtime warning to console when Godunov is selected 😉 .

Looks good to me!

@tarikdzanic , I added a note to the description of the switch for Riemann solvers and also a runtime warning to console when Godunov is selected 😉 .

I share @tarikdzanic 's concern that including this RiemannSolver that is intended only for scalar laws in examples that are systems of conservation laws is problematic, mainly because the examples serve as documentation for how to use the HyperbolicFormIntegrator and related classes.  The RusanovFlux is intended for systems of conservation, so I don't think the GodunovSolver should be added to example 18 even if it happens works ok.

I share @tarikdzanic 's concern that it is problematic to include the GodunovSolver that is intended only for scalar laws in examples that are systems of conservation, mainly because example 18 serves as documentation for how to use the HyperbolicFormIntegrator and related classes. The RusanovFlux is intended for systems of conservation laws, so I don't think the GodunovSolver should be added to example 18 even if it happens works ok.

That was the reason why I did not include it in the first place. On the second thought, it might be the reason to include it to show its usage with  HyperbolicFormIntegrator and related classes, just the application is not perfectly suited for it, but the user is clearly informed about that. It is also not like Godunov flux was somehow horrendously wrong. They do nearly the same thing, where Godunov can be translated to Rusanov with $\lambda=\left|\frac{F(u^+)n-F(u^-)n}{u^+-u^-}\right|$, which is just a finite difference approximation of the velocity. The thing is this velocity is taken for each equation independently in Godunov instead of the maximal one over the whole system for Rusanov, which is a crime, but not that bad 😁 . I am fine with either option, i.e., this small demo without sample runs and with a clear warning, or deferring example 18 to the PR for systems. What is your opinion @dohyun-cse ?

I believe the other methods RiemannSolver::Average, RiemannSolver::AverageGrad, FluxFunction::ComputeAvgFlux and FluxFunction::ComputeAvgFluxDotN are included here so that additional methods added to NonlinearFormIntegrator class in #4350 can be implemented in HyperbolicFormIntegrator (also in #4350) . The issue with including the other methods here is that
* the design choice of adding them to RiemannSolver and FluxFunction
* the assumptions of their implementation (e.g., scalar laws vs systems of laws, monotonicity)
cannot be reviewed without the context of the changes to the NonlinearFormIntegrator in #4350 (which is a WIP). I suggest removing them from this PR so they can be reviewed alongside the context in which they are being added in #4350 .

@cjvogl , the thing with #4350 is that it is huge already and still far from merging. It is not in anyone's capacity to review that PR as is (and considering how reviewers were assigned so far, you might become one of them actually 😄 ). What I am trying to do is to spin off smaller PRs focused on certain topics and without much of specific connection of HDG/RT. This is also the case here, I have stripped the code of the specific parts for HDG and the only extra feature here is that calculation of the average flux over an interval, which is a fairly general thing and can be potentially useful for someone else. It is also nothing fancy and just follows the lines of other methods, so I believe it can be easily reviewed here 😉 . If you want to see it in action, I suggested the regression tests in darcy-hdg-dev in the header ☝ .

I believe the other methods RiemannSolver::Average, RiemannSolver::AverageGrad, FluxFunction::ComputeAvgFlux and FluxFunction::ComputeAvgFluxDotN are included here so that additional methods added to NonlinearFormIntegrator class in #4350 can be implemented in HyperbolicFormIntegrator (also in #4350) . The issue with including the other methods here is that

the design choice of adding them to RiemannSolver and FluxFunction
the assumptions of their implementation (e.g., scalar laws vs systems of laws, monotonicity)
cannot be reviewed without the context of the changes to the NonlinearFormIntegrator in #4350 (which is a WIP). I suggest removing them from this PR so they can be reviewed alongside the context in which they are being added in #4350 .

@cjvogl , the thing with #4350 is that it is huge already and still far from merging. It is not in anyone's capacity to review that PR as is (and considering how reviewers were assigned so far, you might become one of them actually 😄 ). What I am trying to do is to spin off smaller PRs focused on certain topics and without much of specific connection of HDG/RT. This is also the case here, I have stripped the code of the specific parts for HDG and the only extra feature here is that calculation of the average flux over an interval, which is a fairly general thing and can be potentially useful for someone else. It is also nothing fancy and just follows the lines of other methods, so I believe it can be easily reviewed here 😉 . If you want to see it in action, I suggested the regression tests in darcy-hdg-dev in the header ☝ .

I believe it can be easily reviewed here

I unfortunately disagree.  As a user, I find abstract classes with numerous methods defined with failures very difficult to work with as a user, especially if there is no code that uses those methods.  Specifically, it then becomes unclear to me what I actually need to implement if I want to derive from that abstract class (e.g., how many methods of RiemannSolver do I need to implement if I want to define a new approximate Riemann solver for the Euler equations... it is clear to me in main and becomes unclear to me in this branch).  As a maintainer, I find introducing "not yet" used methods bad practice: what if someone sees those methods and uses them in a way that contradicts what you are doing in #4350 ?
That all said, there are more reviewers on this PR that will perhaps disagree with my philosophy and provide that second approval to bypass me.

As a user, I find abstract classes with numerous methods calls to MFEM_ABORT (or similar) very difficult to work with as a user, especially if there is no code that uses those methods. Specifically, it then becomes unclear to me what I actually need to implement if I want to derive from that abstract class (e.g., how many methods of RiemannSolver do I need to implement if I want to define a new approximate Riemann solver for the Euler equations...

@cjvogl  I agree with you it can get very unclear and convoluted, that is why I have improved the doxygen, so methods of HyperbolicFormIntegrator mention what they are using exactly, so what needs to be implemented.

As a code maintainer, I find introducing "not yet" used methods bad practice

They are not hidden or anything. They are offered to the users, but like many other things they do not have a specific example. What is more, there is a clear intention to deliver that example in the future 👍 .

what if someone sees those methods and uses them in a way that contradicts what you are doing in https://github.com/mfem/mfem/pull/4350 ?

That cannot happen, it is clearly defined here what they do and I am bound by the definition to use them that way as other users/developers.

What if I'm asked to fix or extend those methods before https://github.com/mfem/mfem/pull/4350 is merged?

Please do so, I plan to rebase darcy-hdg-dev branch or merge later changes. In the case of extending them, it is a good practice to discuss the changes with the original author, so I should know about them and we may coordinate them.
Ok, what are the opinions of others?

what if someone sees those methods and uses them in a way that contradicts what you are doing in #4350 ?

That cannot happen, it is clearly defined here what they do and I am bound by the definition to use them that way as other users/developers.

It is dangerous to tempt the users in this way.... just saying.

@cjvogl , I added some notes about usage to FluxFunction and RiemannSolver. That is the maximum I can do, as removing the average-related functions would make this PR nearly useless for the HDG development. I need to chop the beast 🥩 😄 . The functions are not much specific and no worries, the plan is to merge HDG this fiscal year and I am here to oversee it to that end.

To avoid the look that this PR is being neglected by me, I'll note that Jan and I have discussed this offline last week and will meet again this meet to clarify the connection between

RiemannSolver::Average
FluxFuntion::ComputeAvgFlux
$\frac{1}{u_2 - u_1} \int_{u_1}^{u_2} F(u) du$
$\frac{1}{u_2 - u_1} \int_{u_1}^{u_2} \hat{F}(u_1, u) du$
(and the related set of RiemannSolver::Grad, etc.)

Documenting some takeaways from our discussion from today:

RiemannSolver::Average is currently implemented to be a particular average of the numerical flux $\int_{u1}^{u2} \hat{F}(u1,u,x) du / (u2-u1)$ where $\hat{F}$ is a numerical flux that may or may not be based on the solution to the Riemann problem corresponding to $u_t + \frac{\partial}{\partial x_n} (F.\hat{n}) = 0$
this concept of an average in terms of a Riemann solver may also refer to something like $\int_0^1 F'(u(\xi)) d\xi$ where $u(\xi) = u1 + (u2 - u1) \xi$ (see, e.g., Roe linearization).
the RiemannSolver interface can be used to derive general numerical fluxes (i.e., ones not necessarily based on the solution to a Riemann problem)
to avoid the conflict in terminology of an average, a suitable solution is to rename the RiemannSolver class to NumericalFlux (or something similar), with an optional deprecated typedef if backwards compatibility is required

@najlkin , please feel free to suggest changes to this summary

@dohyun-cse , technically, it is not necessary, but it would be very nice if you could make a review of the PR as you are the original author. Your feedback would be appreciated.


chore: Include useful files in crates.io tarball

@ogham it would be nice if you would not strip those files from all your projects, because this blocks me from updating all your crates in Fedora to the latest versions :/

@ignatenkobrain Sorry! I thought I was being helpful by making the size of the package smaller! I have them in some other places which I shall now remove.


[Backport] [2.x] Use BuildParams.isCi() instead of checking env var (#5368)

Backport of https://github.com/opensearch-project/OpenSearch/pull/5368 to 2.x

Codecov Report

Merging #5372 (2bfe7b2) into 2.x (05979b4) will increase coverage by 0.08%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                2.x    #5372      +/-   ##
============================================
+ Coverage     70.67%   70.76%   +0.08%
- Complexity    58335    58398      +63
============================================
  Files          4701     4701
  Lines        279131   279131
  Branches      40753    40753
============================================
+ Hits         197271   197519     +248
+ Misses        65376    65143     -233
+ Partials      16484    16469      -15

Impacted Files
Coverage Δ

...search/indices/recovery/RecoveryTargetHandler.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/indices/forcemerge/ForceMergeRequestBuilder.java
0.00% <0.00%> (-75.00%)
:arrow_down:

.../indices/forcemerge/TransportForceMergeAction.java
25.00% <0.00%> (-75.00%)
:arrow_down:

...regations/metrics/AbstractHyperLogLogPlusPlus.java
51.72% <0.00%> (-44.83%)
:arrow_down:

...cluster/coordination/PublishClusterStateStats.java
33.33% <0.00%> (-37.51%)
:arrow_down:

...nsearch/index/shard/IndexShardClosedException.java
66.66% <0.00%> (-33.34%)
:arrow_down:

...on/admin/indices/forcemerge/ForceMergeRequest.java
52.77% <0.00%> (-33.34%)
:arrow_down:

...rc/main/java/org/opensearch/ingest/IngestInfo.java
51.72% <0.00%> (-27.59%)
:arrow_down:

...opensearch/snapshots/SnapshotRestoreException.java
25.00% <0.00%> (-25.00%)
:arrow_down:

...a/org/opensearch/transport/netty4/Netty4Utils.java
42.42% <0.00%> (-21.22%)
:arrow_down:

... and 471 more

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

Backport (pull_request_target) workflow is failing with below error. I tried to re-run but it fails instantly with same error. The original PR is already merged into main.
@VachaShah : Do you know why is this failing ?
Error: Error: For security reasons, this action should only run on merged PRs.


Fuzzing bug fixes

Description
This PR fixes #4010. These are a collection of bugs found by fuzz testing.
This PR also fixes #3992, #3998 and #4001.
Testing
New fuzz tests were added.
Documentation
No.
Installation
No.

In my view "These are a collection of bug fixes found by fuzz testing." is not a sufficient PR description. I don't know how to review this since I don't know what's being fixed so I can't tell whether it fixes them right. (And I suspect not since the tests appear to be failing.)

I second this. As much as it is going to be painful to do, we should file each internally found bug in github, and fix them in the open.

Issue #4001 is fixed by PR #4002 so I'd recommend that be merged first and this be rebased, or else remove it from this PR.

Issue #3992 is fixed by PR #3991 so I'd recommend that be merged first and this be rebased, or else remove it from this PR.

Issue #3998 is just a perf optimization according to that issue, and is apparently non-trivial, so should be separated from security bug fixes.  The principle is that a fix for #4010 would be a backport candidate (e.g., to v.0.19.1) but a PR for #3998 would not be since it doesn't fix any security issue that affects production.

Issue #3998 is just a perf optimization according to that issue, and is apparently non-trivial, so should be separated from security bug fixes. The principle is that a fix for #4010 would be a backport candidate (e.g., to v.0.19.1) but a PR for #3998 would not be since it doesn't fix any security issue that affects production.

0.19.1 already has these changes that are being merged to main. Without fix to 3998 first, many of the issues would not be even found, that this PR is fixing as otherwise the fuzz tests took too long to run and often timed out without finding any issues.
Hopefully, this is the first and last time where we have to merge so many fixes together. Please approve so that we can get this important payload merged.

In my view "These are a collection of bug fixes found by fuzz testing." is not a sufficient PR description. I don't know how to review this since I don't know what's being fixed so I can't tell whether it fixes them right. (And I suspect not since the tests appear to be failing.)

I second this. As much as it is going to be painful to do, we should file each internally found bug in github, and fix them in the open.

Due to special circumstances we had to take these set of changes this way, after discussing with Microsoft security experts. Hopefully we will only rarely get security bugs, which we will fix according to the MSRC  process.

Issue #3992 is fixed by PR #3991 so I'd recommend that be merged first and this be rebased, or else remove it from this PR.

#3991 is changed to draft.

In my view "These are a collection of bug fixes found by fuzz testing." is not a sufficient PR description. I don't know how to review this since I don't know what's being fixed so I can't tell whether it fixes them right. (And I suspect not since the tests appear to be failing.)

PR description is updated with more context and a new issue #4010 is created that lists all the defects found by fuzzing


CDN

How can we implement this CDN on our sites and what is it for Ved Nig

You can set up your own network of CDN on a single php server. If your site has less than 100k monthly users it will work fine else you'll need to set up a cluster.

See: http://opencdn.hstn.me

It provides you simple links and correct content types A Sample Gif

Similar to Cloudinary but can return anything like .docx or .pdf files stored in your server.

But it increase the scripts fetching response while a landing page is being opened

You can set up your own network of CDN on a single php server.
If your site has less than 100k monthly users it will work fine else you'll need to set up a cluster.
See: http://opencdn.hstn.me

Cool

Wow, I want to learn more about openCdn
I want cdn for https://sairaschoice.com
On Mon, 4 Oct 2021, 10:18 AM Ved Nig, @.***> wrote:

Closed #1 https://github.com/vednig/opencdn/issues/1.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vednig/opencdn/issues/1#event-5401399503, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AOJFMAB7KSAU27TEYN54E6TUFE2JVANCNFSM4XQHSKRQ
.


add "time elapsed since latest vaccine dose" for realistic evaluation

Given the recent research on decline of efficacy of antibodies, and while boosters outside of Israel are being offered basically to the vulnerable only, I think there should be useful to add the option to enter the number of months elapsed since latest vaccine dose. I am now in a hurry, can post references if you wish, but you probably already have all of them.
Thank you a lot for considering this.

I think I can close the issue :)


Change logging of smartdispatch

There are two log parts that ideally I would like to change:
1- The dir name inside SMART_DISPATCH_LOGS:
I get names like this:
2017-10-27_10-25-49_31_AFLW_gan_test_gan_coef/
2017-10-27_10-33-56_31_AFLW_gan_test_gan_coef/
2017-10-27_12-18-48_31_AFLW_gan_test_gan_coef_c_smart/
2017-10-27_12-26-25_31_AFLW_gan_test_gan_coef_c_smart/
So if I have different jobs they are sorted by date which is a bit difficult to find logs corresponding to different experiments, while I would sort them by name and if the date comes afterwards that would be fine (I would know the order of running jobs for a particular experiment). So I would prefer something like this instead:
31_AFLW_gan_test_gan_coef_2017-10-27_10-25-49/
2- the name of the err and out files:
I have log files like this:
8e556a8dfdbc7bbad3cc64869d1d69d30a5a7b26e40939ea9339b77c7636a7d5.err  c1d98dd2cf5e71b2a8b5140914943c6a756651dc52e386076afb0a7718f29cac.err
8e556a8dfdbc7bbad3cc64869d1d69d30a5a7b26e40939ea9339b77c7636a7d5.out  c1d98dd2cf5e71b2a8b5140914943c6a756651dc52e386076afb0a7718f29cac.out
Now if I run 20 jobs, it is not easy to find them (checking logs corresponding to the configurations I run). Instead I would prefer them having the same base name and then having different suffix (e.g. _1 _2 _3 and so on). This is what I get on helios for job_dispatch and it is convenient. It has same base name and then the suffix is always ordered as the jobs are submitted to cluster. the first submitted jobs gets _1, the second gets _2 and so on.
I think the first dir name (since it is date based) makes jobs distinguishable and ordered well and the second just make it easier to see the logs corresponding to different configurations.
Having these two changed, makes navigating in the logs much easier.

I agree with both of your suggestions. @mgermain Do you have any objections?


[VT-10] vit is confused by small commands - :ls and :he

David Patrick on 2013-09-08T04:36:26Z says:
That's right! Help is broken!
and so is :ls.. but only occasionally/ intermittently.
some of the time when I enter ":ls" in vit, it fails, reporting that
Error: task ls: no matches
and can re-enter :ls with the same result.
ALL of the time, :he results in
he: command not found

Migrated metadata:
Created: 2013-09-08T04:36:26Z
Modified: 2014-02-09T01:16:50Z

David Patrick on 2013-09-08T07:03:28Z says:
operator error, vit and the :h command are fine.. I think
rejecting the issue.


Support for Django models

Following the example at dancaron/Django-ORM, is it possible to add Django ORM models to this codebase without converting the whole repository into a Django project and creating Django apps?
I've added pyopencdms/opencdms/models/djangodemo/ with two sets of demo Django models (created from a modified version of Climsoft - these demo models have single-column/surrogate primary keys as required by Django ORM).
In the comments, could you add an initial example of using the Django ORM to create and query a new station? Something along the lines of:
import django
from opencdms.models.djangodemo.metadata import Station

# database connection here - e.g. in-memory SQLite database

new_station = Station(
    stationid=838,
    stationname='BRACKNELL: BEAUFORT PARK',
    latitude=51.3898,
    longitude=-0.784,
    openingdatetime='1965-01-01',
    closingdatetime='2003-06-30',
    country='UK',
    authority='Met Office',
    stationoperational=False,
)

new_station.save()

Closed by #27


increase timeouts for test load control points

again increasing timeouts, hoping that this time it will be enough...

😅 great!


Support private mode 1004 (focus gained/lost events)

Details:

https://terminalguide.namepad.de/mode/p1004/
https://conemu.github.io/en/AnsiEscapeCodes.html#Terminal_modes

Depends on #22.


Config menu for OWML

https://github.com/amazingalek/owml/pull/153 first

Other than what I mentioned things look ok to me

Now that we have a default OWML config, we shouldn't include OWML.Config.json in the releases, right? One of the main advantages of having a separate default config file is that new releases don't replace configs of previous releases (which can be very annoying if you need a custom game path).


  Whilst they seem to be working fine, they don't seem to align with the redux/react docs entirely.
There are 3 areas where improvement could be done:

Remove unnecessary state = *  assignment. We shouldn't mutate the state.
_.merge mutates the state. It should be merge({}, state, action.payload) (Caution: This is rather expensive. Maybe immutable-ops#deepMerge is an option)
Remove unnecessary return state, as the reducer takes care of it. Only in cases where we want action.payload to replace the state we should return action.payload.

Further thoughts:
Maybe, the reducers could be a little more detailed. Just to avoid to have to deal with functionalities like _.merge. If we would know where the change needs to be applied, we could probably get rid of the merge functionality. This would help the state (and  any re-render).

This should mostly be addressed in #38 #39


Allow targeting of specific file extensions for babel rollup plugin

Current Behavior
I'm unable to customize the targeted file extensions for plugins and don't have an easy way to ignore one plugin and extend it how I want it. I need to do so to resolve this issue since I need to have babel run across .svg files to avoid bugs in Edge for my icon library.
Desired Behavior
Allow me to determine the file extensions targeted by each rollup plugin.

As an aside... I just realized I've been shipping ESM to all my applications without bundling the dependency. This library I'm making is being used in multiple apps with the same transpile target... Is there a way for me to get the code-splitting ESM provides, while also getting uglified and minified named modules?

Sorry I didn't respond earlier, needed to be at my computer so I could add links and easier and this one's gonna be backlogged anyway unfortunately.
Basically I don't think it makes sense to add a specific feature for this, but I've been planning (and at some point Jared did too, c.f. https://github.com/jaredpalmer/tsdx/issues/389#issuecomment-568785862) on opening up the Rollup config since a bit before #389 so that anyone can more easily override any plugin's config as necessary. More concretely, that would be something like a deep merge or new functions added in tsdx.config.js, one for each plugin.
That would support this and a variety of things as a generic case, without adding the maintenance cost of a specific feature for this very specific use-case. So this effectively duplicates #389 in that sense, and in the meantime, I'd suggest a similar fix as there, using patch-package for your needs or a really hacky tsdx.config.js override with the current set-up.

As an aside... I just realized I've been shipping ESM to all my applications without bundling the dependency. This library I'm making is being used in multiple apps with the same transpile target... Is there a way for me to get the code-splitting ESM provides, while also getting uglified and minified named modules?

So your bundler (e.g. webpack) will minify any ESM packages during its build process, so this isn't really an issue. There's no way to conditionally switch between a dev or prod bundle in ESM (like TSDX does with CJS), so TSDX leaves that to your bundler.
If you want to produce a minified, production-only ESM build, you can follow https://github.com/jaredpalmer/tsdx/issues/631#issuecomment-602131471, noting all the caveats there-in (unofficial/incidental support, no package.json field for it, etc).


Fix parity in e2e tests

Parity was updated and something broke our e2e tests. We should probably fix the problem end then pin the parity version so this will not happen again.

fixed


Fixed duplicate names where possible

This fixes duplicate names inside the stdlib where possible.
Now the problem: you cannot apply the same list to A and to B in a type as that would result in name sharing, because list binds an r deeply inside.
I will write more on the topic on our mailing list, but let's fix at least booleans for now.

@michaelpj replying to your message from the other PR: this is where things were wrong. I fixed some stuff, but they're still wrong with lists and naturals.

Ah yes, you do indeed need to do this. I guess we need to try very hard to maintain the global uniqueness property for these things, since we may use the in the typechecker after we've done renaming.
As for the list issue, can't you similarly make several copies of list? You need to share the wraped type variable obviously, but the others should be able to use fresh names, surely?

Ah yes, you do indeed need to do this. I guess we need to try very hard to maintain the global uniqueness property for these things, since we may use the in the typechecker after we've done renaming.

My original proposal was to write the stdlib without the global uniqueness property and each time you need to use a term in a context where this property is required to hold, just lift Term to Quote Term, i.e. uniquify everything. I still think this is way better than what we do now.

As for the list issue, can't you similarly make several copies of list? You need to share the wraped type variable obviously, but the others should be able to use fresh names, surely?

Maybe we can define clone :: Term -> Quote Term and use it over already instantiated listA to get a freshened version of it. But that's basically a silly and error-prone version of what I wrote above.
Maybe we can complicate the holed types machinery by adding Quote somehow, but it's already complicated enough.
Or do you have something else in mind?

I think I meant just make a whole new copy of the list recursive type, but you could also make the machinery itself work in Quote. As it is, it's not very useful because you can only use it once.
I wouldn't object to something like a fresh: Term -> Quote Term function. Presumably what it would do is take the max unique, and then increment any uniques in the term which were less than it by that much, returning the maximum value thus created.
I don't see how you can get away without having some notion of fresh names in the stdlib. I think the problem is really that you want to be let-binding these things and using references to them, but we can't do this in Plutus Core.

Just to make sure that I understand what is going on. This machinery is "only" needed to generate tests, right?

I believe @michaelpj wants to use it for type synthesis as well. Is that correct?

The general machinery is also used by the plugin, and by places which need to generate some name-safe boolean types, which we need to do in both type synthesis and evaluation.
This particular bit (the stdlib) is only used by tests and the plugin.

Except the change to the boolean type, which is used more widely.

I think I meant just make a whole new copy of the list recursive type

Okay, I'll do that.

I don't see how you can get away without having some notion of fresh names in the stdlib.

Oh, it's easy: just remove all the uniques altogether and you don't have problems with them anymore. And add them using a renamer pass only when you actually need them. This also makes the renamer well-structured: now it's clear that it receives terms without uniques and returns terms with uniques. And your pure PLC terms are actually pure, so you can apply them to each other without the need to "get" them in the do notation. No fresh names generation in the stdlib, let can be used safely, the type system prevents us from using non-unique terms in a unique context (we do not have this guarantee right now) -- this is like Eden. And all this at the tiny cost of adding a couple of new names which we already have four and I think Manuel said during the last talk that we might add one or two more.

Just to make sure that I understand what is going on. This machinery is "only" needed to generate tests, right?

Booleans are used widely as @michaelpj says. But if a definition is in Quote, it must have unique names, because that's the entire purpose of having Quote in the first place.

@effectfully I'm not sure I understand what you're suggesting. If we don't have uniques, how do we avoid accidentally constructing a term like (lam a t (lam a t a)) and not knowing which a we're referring to? We could just say "don't reuse names in the stdlib", but that seems to be asking for bugs. The moment you have fresh names, you need to be in the monad and we're back here.
We could be more liberal about closed terms, but either we'd want some way to keep those separate at the type level or we should just assume the worst i.e. we need a fresh name monad.

We could be more liberal about closed terms

Yes, I mean closed terms. I can imagine why we might need open terms, but using open terms seems a bad practice to me. We're writing the standard library for a real programming language, why open terms? Or do you have a use case for them?

but either we'd want some way to keep those separate at the type level or we should just assume the worst i.e. we need a fresh name monad.

Why should we assume something if we control the code? If I accidentally defined an open term in the stdlib, I consider this a bug regardless of whether they're allowed or not.

You work with open terms while you're defining closed terms! So we do need the discipline there.
I for one would get confused about whether terms were closed or open and whether I had to work in Quote or not if we don't make the compiler check it.
It does seem like we could gain something from treating closed terms differently. If we made the renamer work on programs that possibly-have-shadowing by assuming that the innermost binding wins, then you can use closed terms freely and they can always correctly be renamed to be globally unique when we need that. (Possibly the renamer already works like that - I haven't looked at it)
The other awkwardness is using such terms where we do want the global uniqueness property, i.e. in type checking. Maybe it was a mistake to do that!

You work with open terms while you're defining closed terms! So we do need the discipline there.

Yes. Basically, make sure your top-level definitions are closed. I think, it's enough in most cases.

I for one would get confused about whether terms were closed or open and whether I had to work in Quote or not if we don't make the compiler check it.

We talked about that with Manuel.

You can't ensure uniqueness at the type level
But you can at least promise uniqueness at the type level, so whoever breaks it, can be blamed
You can permit non-uniqueness at the type level

I'm all for distinguishing between non-uniqueness is permitted and uniqueness is promised.

It does seem like we could gain something from treating closed terms differently. If we made the renamer work on programs that possibly-have-shadowing by assuming that the innermost binding wins, then you can use closed terms freely and they can always correctly be renamed to be globally unique when we need that. (Possibly the renamer already works like that - I haven't looked at it)

I thought this is the whole point of the renamer. No?
I think right now it receives a term with non-unique Uniques and uniquifies them by names the way you describe.

As for the list issue, can't you similarly make several copies of list? You need to share the wraped type variable obviously, but the others should be able to use fresh names, surely?

I have to say I'm lost here. In
getBuiltinCons :: Quote (Term TyName Name ())
getBuiltinCons = do
    list <- getBuiltinList
    a  <- freshTyName () "a"
    x  <- freshName () "x"
    xs <- freshName () "xs"
    r  <- freshTyName () "r"
    z  <- freshName () "z"
    f  <- freshName () "f"
    let RecursiveType wrapListA listA =
            holedToRecursive . holedTyApp list $ TyVar () a
    return
        . TyAbs () a (Type ())
        . LamAbs () x (TyVar () a)
        . LamAbs () xs listA
        . wrapListA
        . TyAbs () r (Type ())
        . LamAbs () z (TyVar () r)
        . LamAbs () f (TyFun () (TyVar () a) . TyFun () listA $ TyVar () r)
        . foldl' (Apply ()) (Var () f)
        $ [ Var () x
          , Var () xs
          ]

Which one of

listA1 & wrapListA1 & listA2
listA1 & wrapListA2 & listA2
listA1 & wrapListA1 & listA2
listA1 & wrapListA2 & listA3

should it be?
I do not understand why I have to think about that. We have a proper string representation of terms without any uniques inside, we have a renamer pass that adds uniques. What's the point of not reusing this existing machinery when defining terms via the AST? Instead I manually resolve all duplicates thereby doing the renamer's work.

I'm also a bit lost, but I thought the point is to avoid running the renamer again when you're in the context of an existing program. The other situations where I guess you need it are when you're making an open term, or similarly if you're doing something where you take a term as an argument and you need to make sure you don't clash with it.
I agree that since you're just making closed terms here it would be nice if it was easier.
The annoying thing about just letting the names not be unique is that it's then unclear whether you have to run the resulting term through the renamed before doing anything (hence why I wish it was visible in the types somehow). Maybe we should just always do that! Or at least always at the start of the typechecking pipeline.
(If you like the string representation there's the quasiquoter, but that runs in Quote so probably also isn't what you want. You can always use runQuote to get a version that is only unique across the scope you ran it in)

I'm also a bit lost

If two of us are lost, nobody should ever be doing this again. I propose we merge this PR as is just to fix the boolean bug and will come up with a proper solution later.

but I thought the point is to avoid running the renamer again when you're in the context of an existing program.

If we use plain ASTs, the dichotomy seems to be "run the renamer dynamically" vs "make the programmer run the renamer in his head statically". But your quasiquotes are an option indeed.

The other situations where I guess you need it are when you're making an open term

I will be dealing with names then -- not with Uniques. Do we do this already somewhere?

similarly if you're doing something where you take a term as an argument and you need to make sure you don't clash with it.

The renamer should work perfectly in this case as well. We just supply the highest Unique from the taken term to it. Do quasiquotes handle this situation somehow?
The gist of what I propose is "supply uniques only in some final stage -- not from the ground up, because otherwise you do the renamer's work". This means we can't rename a term partially like "keep this Unique, but change others", which I think is a good thing, because dealing with Uniques manually is error-prone and because if you want to manually deal with Uniques, just use names, really.

The annoying thing about just letting the names not be unique is that it's then unclear whether you have to run the resulting term through the renamed before doing anything (hence why I wish it was visible in the types somehow).

I proposed this before. Let's continue in slack.

If you like the string representation there's the quasiquoter, but that runs in Quote so probably also isn't what you want.

If I translate lists directly to some quasiquote, will names there be unique?

This fixes some bugs so let's merge it, Roman has some ideas for how to take this forward, discussed on Slack.


Adding TypeScript declarations

This commit adds declarations for TypeScript.
Note that they have not been thoroughly tested. I am not too experienced in writing declaration files for older EcmaScript standards. It should be independently verified before being merged into production, if possible.

Seems good, thanks for the pull req!


[JBPM-8549] - Introducing Kogito Kubernetes Client

See:
https://issues.jboss.org/browse/JBPM-8549
This PR is meant to add a kubernetes client module that doesn't rely on reflection to parse JSON responses, but at the same time uses Fabric8 Kube client as an alternative to perform authentication and configuration of the client within a OpenShift/Kube cluster.
It's meant to be simple to tackle the Kogito Cloud use cases, like service discovery.
Tested against JDK8, JDK11, GraalVM and native images on docker containers and an OpenShift 3.11 cluster.
Signed-off-by: Ricardo Zanini<EMAIL_ADDRESS>

@mswiderski the code is now refactored and integrated with workitems. After this PR I'm going to work on a demo of how to use this workitem on OCP and also run more integration tests with KNative, Openshift 4 and Native images.
Once we have Quarkus, I should replace the KubernetesServiceDiscovery for the extension. Though, for SpringBoot we also have to support the same client. I don't want to add the Quarkus dependency to this project based on what we discussed. The bright side of having this agnostic implementation is that we can run anywhere, with any framework.

Onboarding example working on OpenShift 3.11 querying the standard Service API. The onboarding service image can be pulled from: https://quay.io/repository/ricardozanini/onboarding-service
@sutaakar if you'd like to test this PR this is the image. The HR and Payroll can be built as well with this PR: https://github.com/kiegroup/kogito-cloud/pull/23
I have s2i images built with GraalVM 19.x if you prefer.

I just create a project to make it easy to test this PR:
https://github.com/ricardozanini/onboarding-example-templates
Creating an environment with Istio + KNative for more tests.

@ricardozanini Thanks, will take a look on this later today or tomorrow morning

@sutaakar @ricardozanini is this ready to be merged and does it have any dependency to other PRs? Tomorrow is 0.2.0 release so if we want it to be in then it should be merged today

@mswiderski @sutaakar I found a bug when using KNative with OCP 4.x. The KNative Serving API deprecated the domain property from the status model, so we need to change it to url. It's pretty simple, but it's late night here and I'll add some tests to have it cover it. It was the last test that I can think of to merge this PR for 0.2.0.
Nevertheless, this error also happens in the actual version of the DiscoveredWorkItem. I'll support both KNative versions 0.6.x (with domain) and 0.7.x. Tomorrow I should update this PR with this fix and the related image in my Quay repo.
Also, I just updated the test repo with KNative instructions on OCP 4.x:
https://github.com/ricardozanini/onboarding-example-templates
@mswiderski this will work for you? I'd be very happy to have this PR for 0.2.0 :heart:

@mswiderski as talked earlier, I'll update this PR tomorrow morning (15 hours from now) with this fixes and unit tests to cover it so we can have a nice merge for the 0.2.0.
This PR needs to be merged as well:
https://github.com/kiegroup/kogito-bom/pull/36

@mswiderski @sutaakar last update to this PR. Things are running smoothly and now we have unit test coverage for Knative Operators + Istio.
Tested onboarding sample on OCP 3.11, OCP 4.1, OCP 4.1 + KNative Operators.
If there's nothing more to add, we are ok to merge.


[loc][Query][VS_PythonTools] Localizability of 0; "PytestResultsXmlNotFound"

Hi,
please help localization team to answer question from translator.
In case translator is not sure about context/meaning/localizability of string we raise a question.
Source:
Results for pytest not found {0}
File Name:
localize\ENU\Microsoft.PythonTools.Common.dll
==========================================
Query:
Please explain what the placeholder will be replaced with. Thanks

https://github.com/microsoft/PTVS/labels/needs triage

The place holder is expected to be a file path to the test results.

Thanks!


Translation documentation page

Add translation-specific pages that displays the copyright notifications, links and maybe background info on each of the translations ?

Where would this information be stored? In the respective bible modules?

Ek dink nogal so ja....


Start checking for 'hanging promises' in our tests.

Using node's async_hooks API in our tests, we can do something like this:
  beforeEach(() => {
    this.asyncResources = new Map();
    this.asyncHook = async_hooks.createHook({
      init: (id, type, trigger) => {
        if (type == "PROMISE") {
          this.asyncResources.set(id, trigger);
        }
      },
      promiseResolve: (id) => {
        if (this.asyncResources.has(id)) {
          this.asyncResources.delete(id);
        }
      }
    });
    this.asyncHook.enable();
  });

  afterEach(() => {
    this.asyncHook.disable();
    console.log(this.asyncResources);
  });

The idea being that there shouldn't be any async resources left over that weren't triggered by some kind of parent context.
I played around with this briefly in the firebase manual tests - there are a bunch of leftover promises so we've probably got a bit of work to do.
See https://nodejs.org/api/async_hooks.html for more documentation.

Intellij/WebStorm can detect these:
Result of method call returning a promise is ignored inspection
This inspection reports function calls that return a Promise that is not
later used. These are usually unintended and indicate an error.
On Mon, Aug 27, 2018 at 10:44 PM shans<EMAIL_ADDRESS>wrote:

Using node's async_hooks API in our tests, we can do something like this:
beforeEach(() => {
this.asyncResources = new Map();
this.asyncHook = async_hooks.createHook({
init: (id, type, trigger) => {
if (type == "PROMISE") {
this.asyncResources.set(id, trigger);
}
},
promiseResolve: (id) => {
if (this.asyncResources.has(id)) {
this.asyncResources.delete(id);
}
}
});
this.asyncHook.enable();
});
afterEach(() => {
this.asyncHook.disable();
console.log(this.asyncResources);
});
The idea being that there shouldn't be any async resources left over that
weren't triggered by some kind of parent context.
I played around with this briefly in the firebase manual tests - there are
a bunch of leftover promises so we've probably got a bit of work to do.
See https://nodejs.org/api/async_hooks.html for more documentation.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PolymerLabs/arcs/issues/1821, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAF5y_lVub8Mwc_rLY1Iqeaf-bqD8h3kks5uVNjGgaJpZM4WO81y
.

Unfortunately it isn't this simple. For example, set() and get() are async methods - and sometimes it's correct to await them, because you want to know that something has been stored before you continue.
On the other hand, sometimes it's completely acceptable to ignore the returned promise - e.g. if an event handler provides some update data and you use the data to set() a variable (or store() a collection) it isn't a programming error to drop the returned promise.
While awaiting here merely results in mild additional resource / memory usage there are scenarios where awaiting could significantly increase the cost of a function.
@mykmartin and I have talked a couple of times before about wanting to have an 'ignore' keyword that could be used with async function returns. With this then something like intellij's linting would be lovely because every return site could be audited and either awaited or explicitly ignored.
async_hooks doesn't look at static promise usage (like intellij); instead it allows live inspection of current pending promise state. Instead of finding promises that are ignored, it should theoretically allow us to find promises that were never resolved() at the end of each test.


PYTHONPATH is not available in environment when using python.buildEnv or python.withPackages

Issue description
When troubleshooting an issue (rstudio/reticulate#487 ) with the R package reticulate (designed to allow the use of python packages within R) it was discovered that the issue was related to reticulate relying on PYTHONPATH for finding the python packages of interest.
This was eventually solved with a call to mkShell and shellHooks to manually set PYTHONPATH but this seems like a counter-intuitive/hacky way to make python packages available to other software within a given environment.
I'm far from a competent python developer and I don't have a good understanding of what goes on to wrap python for use within Nix so it may be that there is an existing, less manual method for making python packages available to other software.
Steps to reproduce
Current documentation suggests a number of ways to make python package available for development purposes but given that this application required both R and Python a shell.nix file seemed to be the best option. Using this as a shell.nix file:
let pkgs = import <nixpkgs> {}; in
  let
  tarPyPacks = pkgs.python3.withPackages (p: [
    p.Keras p.numpy p.tensorflow
  ]);
  tarRPacks = pkgs.rWrapper.override {
    packages = with pkgs.rPackages; [
      reticulate keras tensorflow
    ];
  };
  in pkgs.mkShell {
    name = "forwardProgress";
    propagatedBuildInputs = [
      tarPyPacks
      tarRPacks
    ];
   }

echo $PYTHONPATH does not return a value, nor does os.environ['PYTHONPATH'] from within the python REPL.
Attempting to use reticulate functions within the generated environment causes a segfault, though I think that has more to do with their error handling.
Changing the shell.nix file as follows remedies the problem:
let pkgs = import <nixpkgs> {}; in
  let
  tarPyPacks = pkgs.python3.withPackages (p: [
    p.Keras p.numpy p.tensorflow
  ]);
  tarRPacks = pkgs.rWrapper.override {
    packages = with pkgs.rPackages; [
      reticulate keras tensorflow
    ];
  };
  in pkgs.mkShell {
    name = "forwardProgress";
    propagatedBuildInputs = [
      tarPyPacks
      tarRPacks
    ];
    shellHook = ''
       export PYTHONPATH="${tarPyPacks}/lib/python3.7:${tarPyPacks}/lib/python3.7/site-packages"
     '';
   }

Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

system: "x86_64-linux"
host os: Linux 4.19.36, NixOS, 19.03.172500.aade6ded796 (Koi)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 2.2.2
channels(root): "nixos-19.03.172500.aade6ded796"
channels(andrew): "nixos-18.09beta11.c0bde692f6c"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

This is important to my use case.

For a shell I don't think you need the wrappers:
  mkShell {
    propagatedBuildInputs = [
      R
      rPackages.reticulate
      rPackages.keras
      python3
      python3Packages.keras
      python3Packages.tensorflow
    ];
  }

If anyone is still looking at this, PYTHONPATH is not modified instead there is a separate NIX_PYTHONPATH environment variable containing all of the packages that need to be loaded with the environment, these packages are loaded by sitecustomize.py code, you can read more about it here


added UMD support #8

Fix #8. Maybe readme should contain more tips about these changes, but I'm not a native English speaker, so you'd better write about it yourself

Thanks for putting together the pull request. LoadJS is now available on npmjs.com:
https://www.npmjs.com/package/loadjs


New nightly shows warnings that will become hard errors in the future

Nightly from 2018-07-29
warning: variable does not need to be mutable
   --> futures-io/src/lib.rs:365:21
    |
365 |                 let mut out = self.get_mut().as_mut();
    |                     ----^^^
    |                     |
    |                     help: remove this `mut`
    |
    = note: `-D unused-mut` implied by `-D warnings`
    = warning: This error has been downgraded to a warning for backwards compatibility with previous releases.
            It represents potential unsoundness in your code.
            This warning will become a hard error in the future.

    Checking futures-util-preview v0.3.0-alpha.1 (file:///Users/josef/Documents/GitHub/futures-rs/futures-util)
warning: variable does not need to be mutable
   --> futures-util/src/sink/with.rs:124:28
    |
124 |             State::Process(mut fut) => Some(try_ready!(fut.poll(cx))),
    |                            ----^^^
    |                            |
    |                            help: remove this `mut`
    |
    = note: `-D unused-mut` implied by `-D warnings`
    = warning: This error has been downgraded to a warning for backwards compatibility with previous releases.
            It represents potential unsoundness in your code.
            This warning will become a hard error in the future.

warning[E0499]: cannot borrow `promoted` as mutable more than once at a time
  --> futures-util/src/io/read_exact.rs:43:61
   |
43 |                 let (_, rest) = mem::replace(&mut this.buf, &mut []).split_at_mut(n);
   |                                                             ^^^^^^^ mutable borrow starts here in previous iteration of loop
   |
note: borrowed value must be valid for the lifetime 'a as defined on the impl at 35:6...
  --> futures-util/src/io/read_exact.rs:35:6
   |
35 | impl<'a, R: AsyncRead + ?Sized> Future for ReadExact<'a, R> {
   |      ^^
   = warning: This error has been downgraded to a warning for backwards compatibility with previous releases.
           It represents potential unsoundness in your code.
           This warning will become a hard error in the future.

Note: These warnings are special because they don't break the CI even though we deny warnings.

That read_exact one is concerning. I guess it's a bug that the new borrow checker is now noticing, specifically if the this.buf = rest; line was missing then that line would have left this.buf pointing at a stack allocated buffer.
Can hopefully steal the std::io::Read::read_exact implementation: https://github.com/rust-lang/rust/blame/f338dba29705e144bad8b2a675284538dd514896/src/libstd/io/mod.rs#L687
(I also really want to know how having an unused mut binding could lead to unsoundness, I'm probably gonna try and track down that issue at some point).

One potential fix that shouldn't impact the size/performance of ReadExact much, but I'm still hoping there's something nicer (could probably make this a little nicer with a helper function):
diff --git futures-util/src/io/read_exact.rs futures-util/src/io/read_exact.rs
index 420ea191..da99a97e 100644
--- futures-util/src/io/read_exact.rs
+++ futures-util/src/io/read_exact.rs
@@ -14,7 +14,7 @@ use std::mem::{self, PinMut};
 #[derive(Debug)]
 pub struct ReadExact<'a, R: ?Sized + 'a> {
     reader: &'a mut R,
-    buf: &'a mut [u8],
+    buf: Option<&'a mut [u8]>,
 }

 impl<'a, R: ?Sized> Unpin for ReadExact<'a, R> {}
@@ -24,7 +24,7 @@ impl<'a, R: AsyncRead + ?Sized> ReadExact<'a, R> {
         reader: &'a mut R,
         buf: &'a mut [u8]
     ) -> ReadExact<'a, R> {
-        ReadExact { reader, buf }
+        ReadExact { reader, buf: Some(buf) }
     }
 }

@@ -37,16 +37,27 @@ impl<'a, R: AsyncRead + ?Sized> Future for ReadExact<'a, R> {

     fn poll(mut self: PinMut<Self>, cx: &mut task::Context) -> Poll<Self::Output> {
         let this = &mut *self;
-        while !this.buf.is_empty() {
-            let n = try_ready!(this.reader.poll_read(cx, this.buf));
-            {
-                let (_, rest) = mem::replace(&mut this.buf, &mut []).split_at_mut(n);
-                this.buf = rest;
-            }
-            if n == 0 {
-                return Poll::Ready(Err(eof()))
+        let mut buf = this.buf.take().unwrap();
+        while !buf.is_empty() {
+            match this.reader.poll_read(cx, buf) {
+                Poll::Ready(Ok(0)) => {
+                    this.buf = Some(buf);
+                    return Poll::Ready(Err(eof()));
+                }
+                Poll::Ready(Ok(n)) => {
+                    buf = &mut buf[n..];
+                }
+                Poll::Ready(Err(e)) => {
+                    this.buf = Some(buf);
+                    return Poll::Ready(Err(e));
+                }
+                Poll::Pending => {
+                    this.buf = Some(buf);
+                    return Poll::Pending;
+                }
             }
         }
+        this.buf = Some(buf);
         Poll::Ready(Ok(()))
     }
 }

@MajorBreakfast did you and @cramertj discuss using async internally? read_exact is one combinator that is so much more readable when defined using an async block.

I was thinking of wrapping the async block inside a trivial ReadExact struct, but now I realise that relies on having nameable existential types itself anyway, and at that point you may as well make ReadExact the named existential type.

For reference https://github.com/rust-lang/rust/issues/52671 provoked the change that caused the ReadExact issues. Whether this sort of code should be allowed is still under dispute, so that warning may just resolve itself.

The warnings are gone now


android tv support

Describe your suggested feature
aniyomi on a android tv doenst properly work
do u have a android tv version planned? if not then you might consider releasing one
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I will fill out all of the requested information in this form.

https://github.com/jmir1/aniyomi/issues/162 it's here already

https://github.com/aniyomiorg/aniyomi/issues/162


[tests-only] [full-ci] Bump core commit id for tests

Description
There have been a few API test additions and changes recently in core. Get these running in oCIS.
https://github.com/owncloud/core/pull/39701 run chunking upload tests using the spaces dav path
https://github.com/owncloud/core/pull/39705 Test moving a folder into a sub-folder of itself
https://github.com/owncloud/core/pull/39703 Acceptance tests for deep moves and fix 39702
Related Issue
https://github.com/owncloud/QA/issues/713
How Has This Been Tested?
CI
Types of changes

[ ] 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)
[ ] Technical debt
[x] Tests only (no source changes)

Checklist:

[ ] Code changes
[ ] Unit tests added
[ ] Acceptance tests added
[ ] Documentation ticket raised:

needs core PR https://github.com/owncloud/core/pull/39708 first

https://drone.owncloud.com/owncloud/ocis/8914/30/6 was canceled.
build restarted!

There is a problem with a new scenrio that hangs the server. Issue #3023
We need core PR https://github.com/owncloud/core/pull/39711 merged so that we can skip the scenario.


Update README.md

Add banner, MPI + compiler info, binder under consideration.

Codecov Report

Merging #848 into master will increase coverage by 7.97%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #848      +/-   ##
==========================================
+ Coverage   80.86%   88.84%   +7.97%
==========================================
  Files         100      100
  Lines       11342    11342
  Branches     2235     2235
==========================================
+ Hits         9172    10077     +905
+ Misses       1903      981     -922
- Partials      267      284      +17

Impacted Files
Coverage Δ

devito/data/allocators.py
73.46% <0%> (+0.68%)
:arrow_up:

devito/operator.py
93.47% <0%> (+0.72%)
:arrow_up:

devito/dle/rewriters.py
80.35% <0%> (+0.89%)
:arrow_up:

devito/tools/utils.py
75% <0%> (+0.89%)
:arrow_up:

devito/ir/iet/visitors.py
83.14% <0%> (+0.92%)
:arrow_up:

devito/parameters.py
84.61% <0%> (+0.96%)
:arrow_up:

devito/ir/support/space.py
86.15% <0%> (+1.03%)
:arrow_up:

devito/logger.py
84.5% <0%> (+1.4%)
:arrow_up:

devito/dle/parallelizer.py
94.57% <0%> (+1.55%)
:arrow_up:

devito/archinfo.py
73.38% <0%> (+1.61%)
:arrow_up:

... and 19 more

Continue to review full report at Codecov.

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

@FabioLuporini the issue with MPI notebook is happening again...

@georgebisbas because it's still missing the #NBVAL_IGNORE_OUTPUT ?_?
Look at Cell 4 !

Many thanks for this 🙏
Can you inject the NBVAL thing as per comment above into this PR? so that we fix it once and for all

Codecov Report

Merging #848 into master will increase coverage by 7.97%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #848      +/-   ##
==========================================
+ Coverage   80.86%   88.84%   +7.97%
==========================================
  Files         100      100
  Lines       11342    11342
  Branches     2235     2235
==========================================
+ Hits         9172    10077     +905
+ Misses       1903      981     -922
- Partials      267      284      +17

Impacted Files
Coverage Δ

devito/data/allocators.py
73.46% <0%> (+0.68%)
:arrow_up:

devito/operator.py
93.47% <0%> (+0.72%)
:arrow_up:

devito/dle/rewriters.py
80.35% <0%> (+0.89%)
:arrow_up:

devito/tools/utils.py
75% <0%> (+0.89%)
:arrow_up:

devito/ir/iet/visitors.py
83.14% <0%> (+0.92%)
:arrow_up:

devito/parameters.py
84.61% <0%> (+0.96%)
:arrow_up:

devito/ir/support/space.py
86.15% <0%> (+1.03%)
:arrow_up:

devito/logger.py
84.5% <0%> (+1.4%)
:arrow_up:

devito/dle/parallelizer.py
94.57% <0%> (+1.55%)
:arrow_up:

devito/archinfo.py
73.38% <0%> (+1.61%)
:arrow_up:

... and 19 more

Continue to review full report at Codecov.

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

@georgebisbas can you inject the NBVAL tag for the failing MPI cell into this PR?

@georgebisbas can you inject the NBVAL tag for the failing MPI cell into this PR?
pushed

Codecov Report

Merging #848 into master will increase coverage by 7.97%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #848      +/-   ##
==========================================
+ Coverage   80.86%   88.84%   +7.97%
==========================================
  Files         100      100
  Lines       11342    11342
  Branches     2235     2235
==========================================
+ Hits         9172    10077     +905
+ Misses       1903      981     -922
- Partials      267      284      +17

Impacted Files
Coverage Δ

devito/data/allocators.py
73.46% <0%> (+0.68%)
:arrow_up:

devito/operator.py
93.47% <0%> (+0.72%)
:arrow_up:

devito/dle/rewriters.py
80.35% <0%> (+0.89%)
:arrow_up:

devito/tools/utils.py
75% <0%> (+0.89%)
:arrow_up:

devito/ir/iet/visitors.py
83.14% <0%> (+0.92%)
:arrow_up:

devito/parameters.py
84.61% <0%> (+0.96%)
:arrow_up:

devito/ir/support/space.py
86.15% <0%> (+1.03%)
:arrow_up:

devito/logger.py
84.5% <0%> (+1.4%)
:arrow_up:

devito/dle/parallelizer.py
94.57% <0%> (+1.55%)
:arrow_up:

devito/archinfo.py
73.38% <0%> (+1.61%)
:arrow_up:

... and 19 more

Continue to review full report at Codecov.

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

Why? Was it failing?
Unfortunately yes.

I think I have to withdraw my previous suggestions. The MPI-notebook issue is more serious than I thought, so we have to treat it separately in a different branch/PR. We should pull of the NBVAL tags from this PR. Apologies

I think I have to withdraw my previous suggestions. The MPI-notebook issue is more serious than I thought, so we have to treat it separately in a different branch/PR. We should pull of the NBVAL tags from this PR. Apologies

NP, I will remove them now..

Codecov Report

Merging #848 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #848      +/-   ##
==========================================
+ Coverage   88.83%   88.84%   +<.01%
==========================================
  Files         100      100
  Lines       11342    11342
  Branches     2235     2235
==========================================
+ Hits        10076    10077       +1
+ Misses        982      981       -1
  Partials      284      284

Impacted Files
Coverage Δ

devito/data/allocators.py
73.46% <0%> (+0.68%)
:arrow_up:

Continue to review full report at Codecov.

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

Merged, thanks


TypeInitializationException Linux arm64

Summary of your issue
I try to change my system from windows to Linux.
System.TypeInitializationException: The type initializer for 'OpenCvSharp.Internal.NativeMethods' threw an exception.[...]
Environment
Linux 5.4.180 arm64 (aarch64)
Net6.0
OpenCv4.6.0
OpenCvSharp4 Version <IP_ADDRESS>20608
OpenCvSharp4.Extensions Version <IP_ADDRESS>20608
OpenCvSharp4.runtime.linux-arm Version <IP_ADDRESS>20608
What did you do when you faced the problem?
I setup a project and started to debug it and got an error as soon as I hit the first line of code that uses the OpenCvSharp4 library.
I tried to check the .so file with ldd in the {build folder}/runtimes/linux-arm/native ldd libOpenCvSharpExter.so but the Output is:
not a dynamic executable

Example code:

var _cam = new VideoCapure(0);

Output:

System.TypeInitializationException: The type initializer for 'OpenCvSharp.Internal.NativeMethods' threw an exception.
 ---> System.DllNotFoundException: Unable to load shared library 'OpenCvSharpExtern' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libOpenCvSharpExtern: cannot open shared object file: No such file or directory
   at OpenCvSharp.Internal.NativeMethods.redirectError(CvErrorCallback errCallback, IntPtr userdata, IntPtr& prevUserdata)
   at OpenCvSharp.Internal.ExceptionHandler.RegisterExceptionCallback()
   at OpenCvSharp.Internal.NativeMethods.LoadLibraries(IEnumerable`1 additionalPaths)
   at OpenCvSharp.Internal.NativeMethods..cctor()
   --- End of inner exception stack trace ---
   at OpenCvSharp.Internal.NativeMethods.videoio_VideoCapture_new3(Int32 device, Int32 apiPreference, IntPtr& returnValue)
   at OpenCvSharp.VideoCapture..ctor(Int32 index, VideoCaptureAPIs apiPreference)
   at ModiUtils.VideoInputDevices.ModiOpenCV.Webcam.Open(WebcamSettings webcamSettings) in /home/username1/OpenCvSharp4OnLinux/WebcamOpenCV.cs:line 5

What did you intend to be?
that the library would be useable on linux like on windows just install the nuget packages and it runs if you install the runtime package.

I guess when this is not becoming fixed I guess I have to learn C++.


Fails to execute when using a custom npm prefix

My .npmrc uses a custom prefix to install binaries into $XDG_DATA_HOME:
prefix=${XDG_DATA_HOME}/node

This breaks docker-langserver because it's using a relative import to execute the server:
cat $XDG_DATA_HOME/node/bin/docker-langserver

   1   │ #!/usr/bin/env node
   2   │ /* --------------------------------------------------------------------------------------------
   3   │  * Copyright (c) Remy Suen. All rights reserved.
   4   │  * Licensed under the MIT License. See License.txt in the project root for license information.
   5   │  * ------------------------------------------------------------------------------------------ */
   6   │ require("../lib/server");

@jzelinskie Thank you for your bug report. I'll do some searching to see what the right solution is here.

@jzelinskie I looked at both Mocha and TypeScript and they both seem to do the same thing here.
Do you have an example of an open source project that works for your setup?

It was forever ago that I reported this and I can't seem to reproduce this on my new laptop.
$ cat .npmrc
prefix=${XDG_DATA_HOME}/node
$ echo $XDG_DATA_HOME
/Users/jzelinskie/.local/share
$ which docker-langserver
/Users/jzelinskie/.local/share/node/bin/docker-langserver
$ docker-langserver --stdio
^C

@jzelinskie Thanks for getting back to us. Have a nice day!


Change RuntimeParameters

I would ask how to change the RuntimeParameters from standard to FILL. Also, how to change MaxRange and Confidence? The same you do in the Depth View.

How did you specify the confidence threshold values?

This how you cold set the confidence:
zed = sl.Camera()
zed.set_confidence_threshold()

You could check the comment of the funcation.


feat: DLT-1678 build all themes

Tokens - Build all themes
Obligatory GIF (super important!)

:hammer_and_wrench: Type Of Change
These types will increment the version number on release:

[x] Feature

:book: Jira Ticket
https://dialpad.atlassian.net/browse/DLT-1678
:book: Description

Changed sd-transforms to build all themes instead of just light and dark, this will build CSS/LESS output and enable expressive theme to be built.
build-token-transformer work will be delayed as right now needs to be manually setup and that'd is hard to maintain, created a ticket to do that in the future: https://dialpad.atlassian.net/browse/DLT-1687

:bulb: Context
Themes and Brands are growing rapidly on dialtone-tokens, we need to build them all in a more automated way, right now we're only outputting dialtone-theme light/dark as default.
:pencil: Checklist
For all PRs:

[x] I have ensured no private Dialpad links or info are in the code or pull request description (Dialtone is a public repo!).
[x] I have reviewed my changes.

How can I test that this works with the expressive theme? Right now tokens/$themes.json only includes dark and light.

How can I test that this works with the expressive theme? Right now tokens/$themes.json only includes dark and light.

This will include cox and tmo themes, expressive is being added on another PR

How can I test that this works with the expressive theme? Right now tokens/$themes.json only includes dark and light.

This will include cox and tmo themes, expressive is being added on another PR

How can I test cox and tmo then? Is the file tokens/$themes.json going to be updated in another PR?

How can I test cox and tmo then? Is the file tokens/$themes.json going to be updated in another PR?

cox / tmo should already be included in $themes.
If you build tokens and look in dist/css there should be new files like variables-tmo-light.css


Provide a way to give extra data to the tracker on announce

This PRs is dependent on feross/bittorrent-tracker#107 and  feross/torrent-discovery#15 to provide a callback for the client to get updated params and send it along with the announce message to the tracker.
It sends updated download stats (uploaded/downloaded/letf and adds a callback in th options to extend it with additionnal data.
The callback is called before every announce to get updated data from the client.

What's your use case for sending extra parameters to the tracker? Some kind of authentication?

LGTM :+1: after the inline comments and https://github.com/feross/bittorrent-tracker/pull/107 comments are addressed.

For now I am sending per wire statistics in order to track data transfer between peers, the bitfield to compute video playing stats (see when the consumer seeks and stops the video...) but later I want my tracker to provide an optimized peerlist to reduce latency. So I will probably retrieve more metrics.

Good news! This is released as 0.80.0.

Thank you for finishing this.

Of course! Thanks for the PR!


Multiple Knative endpoint in the same route will cause the pod continuously restart

I tried a CBR pattern to call Knative serving services.
But I see very funny behaviour with the Camel K instance, it keeps terminating and restarting into an infinite loop.
.when().simple("${body.genuses} == 'xxx'")
  .marshal(jacksonDataFormat)
  .to("knative:endpoint/xxx")
.otherwise()
   .to("knative:endpoint/yyy")

Is that something that I should not do?

I'd be surprised if that didn't work. I guess you've checked that there aren't multiple operators contending the resource.
Do you see some error logs when the pods start?
We should add a CBR example to the e2e tests.


[Feature Request] Open new request in editor without a modal

Currently, hitting Ctrl + N opens a modal dialog, prompting for request name, method and body type. These are all optional and configurable in the editor. It would be nice to have the new request just pop up in the editor with default values and allow the user to change whatever values they see fit.
This behaviour is currently implemented in VS Code. Creating a new file in explorer, adds a file in the folder explorer with focus to name it. Hitting Ctrl + N opens a new blank file in the editor without any additional prompts.
Why I think this a better workflow
The current behaviour makes me think of a name for the request first which is a distraction from the primary task of writing the request. Usually a file is named after contents are added to it. Because the file name is based on the contents. I don't know what to name a request till I write it, change it, change it again, change it again and change it again and decide to open a new request.

I got an idea: preserve current behaviour and add a new keyboard shortcut,  i.e. Quick Create Action which creates a new request without the modal dialog prompt

I like that idea
Sent with GitHawk


Pins should give a location to a Dataset

The Pin model should have a foreign key to a parent dataset, foreign key to a child dataset, and point location of the child within the parent. Functionally, this will be similar to the Dataset Embedding model, except that the child dataset takes up no space within the parent and should be rendered as a dot rather than a tile image. Pins can also have preview images to show on hover and a color. Jobs that create datasets should also create Pins.
@naglepuff and @mcovalt would this work?

A next step would be adding functionality to the frontend to allow the user to place a pin arbitrarily and write a new Dataset with text content to act as a note.


Transaction signers described at different levels

At the moment, there are two ways to specify the signers of a transaction, the SignedBy constraint and the mechanisms of MonadMockChain, namely signingWith. At first, the two seem redundant, but as far as I understand, they are there for different reasons:

The SignedBy constraint translates to a plutus-apps MustBeSignedBy constraint, which makes sure that certain public keys are part of the requiredSignatories of the transaction as it is submitted to the chain.
The function signingWith adds signatures (wallets, really) that are involved already at the stage of transaction generation. In particular, they are used to decide who pays collaterals and whose money is used to balance the transaction.

Another distinction is when the signatures are needed. As far as I understand it:

Transactions will only be valid if all public keys that spend something on the transaction also sign it. In particular, this comes before any scripts that might be involved in the validation of the transaction. In my opinion, these signatures should always be present on the transactions cooked-validators generates, as we're interested in testing the behaviour of scripts.
Scripts might require a certain signature to be present through the function txSignedBy, even if the assoicated public key spends no money in the transaction. In that case, we'd like to be able to generate both the transaction that should validate and the one that misses the signature required by the script. I think that something like signingWith is an useful idiom to do so. (Even if PR #179 proposes an alternative).

Are my comments above accurate?

I think you explained the distinction between the two very well. The way I see it is that singingWith brings in scope wallets which can then be used in SignedBy, in addition to be used for collaterals and reimbursements. This is very confusing though and can be the subject to many errors and misinterpretations. I am wondering if we could make it clearer. A way would be to automatically propagate the list of signatories at the MockChain level to actual signatories in the sent transaction, but I don't know if that is 100% sound.


Correct link to team

r? @therealprof
(rust_highfive has picked a reviewer for you, use r? to override)

bors r+


Change url of javadoc

Fix change url of javadoc
2 warnings generated.
ERROR: /Users/thinker0/line/heron/heron/api/src/java/BUILD:8:1: error executing shell command: '/bin/bash -c rm -rf bazel-out/darwin-fastbuild/bin/heron/api/src/java/heron-api-javadoc.zip.source && mkdir bazel-out/darwin-fastbuild/bin/heron/api/src/java/heron-api-javadoc.zip.source && unzip -...' failed (Exit 1)
javadoc: warning - URL http://docs.oracle.com/javase/8/docs/api/package-list was redirected to https://docs.oracle.com/javase/8/docs/api/package-list -- Update the command-line options to suppress this warning.
javadoc: error - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/8/docs/api/ are in the unnamed module.
1 error
1 warning

CI still reports: javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/8/docs/api/ are in the unnamed module.

This is a JDK bug and is supposed to be fixed in latest version of 12 and
13.
https://github.com/aws/aws-sdk-java-v2/issues/1270#issuecomment-496608014
2020년 4월 17일 (금) 오후 1:47, Ning Wang<EMAIL_ADDRESS>작성:

CI still reports: javadoc: error - The code being documented uses modules
but the packages defined in https://docs.oracle.com/javase/8/docs/api/
are in the unnamed module.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-heron/pull/3512#issuecomment-615039224,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACXLGJDDSSCRSXRTW4Z72DRM7NPNANCNFSM4MKLXFUQ
.

It seems to work fine on my local jdk13 macbook.
2020년 4월 17일 (금) 오후 2:06, thinker0<EMAIL_ADDRESS>작성:

This is a JDK bug and is supposed to be fixed in latest version of 12 and
13.
https://github.com/aws/aws-sdk-java-v2/issues/1270#issuecomment-496608014
2020년 4월 17일 (금) 오후 1:47, Ning Wang<EMAIL_ADDRESS>작성:

CI still reports: javadoc: error - The code being documented uses modules
but the packages defined in https://docs.oracle.com/javase/8/docs/api/
are in the unnamed module.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-heron/pull/3512#issuecomment-615039224,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACXLGJDDSSCRSXRTW4Z72DRM7NPNANCNFSM4MKLXFUQ
.

It seems to work fine on my local jdk13 macbook. 2020년 4월 17일 (금) 오후 2:06, thinker0<EMAIL_ADDRESS>작성:
…
This is a JDK bug and is supposed to be fixed in latest version of 12 and 13. aws/aws-sdk-java-v2#1270 (comment) 2020년 4월 17일 (금) 오후 1:47, Ning Wang @.***>님이 작성: > CI still reports: javadoc: error - The code being documented uses modules > but the packages defined in https://docs.oracle.com/javase/8/docs/api/ > are in the unnamed module. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#3512 (comment)>, > or unsubscribe > https://github.com/notifications/unsubscribe-auth/AACXLGJDDSSCRSXRTW4Z72DRM7NPNANCNFSM4MKLXFUQ > . >

This is strange. I cant imagine the error is because of http:// to https://. Let me trigger the build again.

Do we want this merged in or closed?

I think this should be closed.  We are java 11 now.


Remove unused comments

Description
Changes proposed in this pull request:

remove comments describing job source

Related issue(s)

https://github.com/kyma-project/serverless/issues/848#issue-2222275134

/retest

/lgtm


feat: Upgrade remaining edtr-io

Fixes #138

[ ] I guess we need to add that nodejs libraries are not bundled in the final script

I guess we need to add that nodejs libraries are not bundled in the final script

I'm not sure if I understand. Since we use a docker image with node, it has already the nodejs libs, hasn't it?

I'm not sure if I understand. Since we use a docker image with node, it has already the nodejs libs, hasn't it?

Nevermind is not needed


TRPO runtime warning in line search

new line search seems numerically unstable:
TensorForce/tensorforce/models/trpo_model.py:247: RuntimeWarning: invalid value encountered in subtract
prob_ratio = np.exp(new_log_prob - log_prob)

Log likelihood of Beta seems to produce infinity occasionally


Help installing ag on a machine without sudo access

Hi,
I checked that my machine has pkg-config, automake and lzma ( I am not sure if that is different from liblzma-dev). It doesn't have PCRE.
I built PCRE from http://www.pcre.org/ but that did not work. I kept on getting the below error when running ./build.sh for ag
./configure: line 3930: syntax error near unexpected token PCRE,' ./configure: line 3930: PKG_CHECK_MODULES(PCRE, libpcre)'
I used the following command for configure:
./configure --prefix=$HOME/usr_local CPPFLAGS="-I$HOME/usr_local/include" LDFLAGS="-static -L$HOME/usr_local/include  -L$HOME/usr_local/lib"
because I install PCRE to my local folder $HOME/usr_local and I plan to install ag to the same.
When I acked for libpcre in $HOME/usr_local, it was actually there and still it failed the configure step.
As I don't have admin rights, I can't use yum or apt-get.
Any help will be appreciated, thanks.

Just a note that this error is caused by missing pkg-config. It seems to be already noted in the README that this is required.

I have installed pkg-config, but still has this error, on CentOS 6.4. Anyone has idea?

Simply having pkg-config available is not sufficient on CentOS 6.4. Modifying $PKG_CONFIG_PATH and even putting a newer version of pkg-config in the path ahead of the OS-installed one didn't seem to work for me either. The only way I found to get it working was to make the manual changes to configure and Makefile as @DonghuaLau suggests.

Just wanted to add a note here, since I was having issues with this as well and this showed up frequently in the top results on google: The latest versions of  PCRE is actually PCRE-2, which is incompatible with ag. Instead, you'll need to download and install v8.44, which is the last release (as of right now) for the original PCRE. Once I'd done that, I was able to build without much of an issue using the latest  pkg-config, automake, and xz


Create Verbose flag (query_tweets)

Hi,
Currently, running query_tweets prints a large number of logs, which sometimes crash the browser session (for eg. if you use Google Colab) especially if you are iterating over a list of keywords. Additionally, it is not exactly a pretty way to visualize progress if you are iterating over several keywords.
By keeping the logger mode as a parameter (eg. verbose, etc.)  rather than fixed to logger.INFO in ts.logger, we can solve this issue.
Thanks

You can easily disable the log with:
import logging
logging.disable(logging.INFO)

ps.: This example disables INFO globally


Change version.h and libpistache.pc install source location to use CMAKE_CURRENT_BINARY_DIR

Fixes #559

Codecov Report

Merging #560 into master will increase coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #560     +/-   ##
=========================================
+ Coverage   70.39%   70.49%   +0.1%
=========================================
  Files          49       49
  Lines        6951     6951
=========================================
+ Hits         4893     4900      +7
+ Misses       2058     2051      -7

Impacted Files
Coverage Δ

src/common/reactor.cc
80% <0%> (-0.41%)
:arrow_down:

src/client/client.cc
81.29% <0%> (+1.52%)
:arrow_up:

Continue to review full report at Codecov.

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

Thanks!


JEOL DX duplicates of JCAMP format

a jcamp file format has extension .dx or .jdx.
based on class label (and in the absence of other metadata) JEOL DX format seems to indicate a file with .dx extension produced by JEOL instrument.
if not, then specifics must be added

I confirm. It is 'dx'

Yes, JEOL DX format indicates a file with .dx extension produced by JEOL instrument.
No changes needed here.

@DSchober, a change is needed: JEOL DX format needs to be deprecated, and closing the issue should only be done when this action is performed, ideally with a commit

There are more file formats for the specific Vendors, a few are indicated at
http://www.acdlabs.com/products/fileformats/   (see below)
This branch actually does not indicate the actual file extensions, but rather mentions the Vendor software for which then the specific FID and parameter files with extensions would be put under data file/FID file and acquisition parameter file respectively.
Not sure how relevant Jeol be in the future. It looks like this particular class described MS data anyway. Now after looking into it, I agree it should be deprecated here.
Here a more extensive list of file extension to Vendor associations (from link above):
Agilent (Varian, Inc.) 	data, *.fdf, fid0001.fdf, *.txt, fid, phasefile 	acq, proc, procpar 	acq_2, text
Bruker Corporation 	ser, rr, .fid, *r, 1i, 2rr,
. (DISNMR) 	acqus, procs, acqu2, proc2s, *.fqs, *.fa1, *.fa2, *.fp1, *.fp2 	title, intrng, *.tit, *.ti2
JCAMP† 	*.dx; *.jdx
JEOL Ltd. 	*.als, *.nmfid, *.nmf, *.nmdata, *.nmd, *.gxd, *.bin, . (Delta) 	*.gxp, *.hdr 	exp.param, exp.par
Tecmag 	*.tnt, . (MacNMR)


Possible documentation broken link

Hi! I am not sure I should start an issue here, but it's not clear which option should I choose from suggested ones for Contributing to Yii2
In official documentation there is a subject "Auth Clients" and it seems everything looks fine with URL at https://github.com/yiisoft/yii2/blob/master/docs/guide/security-overview.md
But at the site there is also navigation at left side that has wrong URL for this topic pointing to: http://www.yiiframework.com/doc-2.0/guide-README.html
instead of:
https://github.com/yiisoft/yii2-authclient/blob/master/docs/guide/README.md
I guess last one is correct, isn't it?

And I have no idea where can I make a pull request to fix it and is it possible at all.

Duplicate of #9922