Override localstack image to 3.5.0

Type of change

Bugfix

Description
The system tests are trying to assert that we are using a particular
version of localstack but the helm chart install
localstack/localstack:latest
Additional Context
System tests are failing
Checklist
Please go through this checklist and make sure all applicable tasks have been done

[ ] Write tests
[ ] Make sure all tests pass
[ ] Review performance test results. Ensure that any degradations to performance numbers are understood and justified.
[ ] Make sure all Sonarcloud warnings are addressed or are justifiably ignored.
[ ] Update documentation
[ ] Reference relevant issue(s) and close them after merging
[ ] For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

@strimzi-ci run system tests

:arrow_forward: Build started - check Jenkins for more info. :arrow_forward:

@franvila do you prefer using a rolling tag here, rather than having to keep localstack up to date?
I wonder if using latest is a bit too bleeding edge in localstack's case.
This is our default tag. It refers to the latest commit which has been fully tested using our extensive integration test suite.

This also entails major releases, which means that this tag can contain breaking changes.

Maybe we could use stable, it would fail the same way but would point at a released tag. If we use latest we would have to go and track down which localstack commit was involved in a test failure.

:heavy_check_mark: Test Summary :heavy_check_mark:
BUILD NUMBER: 93
KAFKA VERSION: 3.7.1
TOTAL: 21
PASS: 18
FAIL: 0
SKIP: 3

keen to merge this while we figure out the right thing to do, so I can re-run system tests on another PR

There are 3 implementations of AbstractAwsKmsTestKmsFacade, one of them is AwsKmsTestKmsFacade which starts up the image with testcontainers. It lives in AwsKmsTestKmsFacade. I think this is eventually the base class service loaded into the integration tests where we test the record encryption filter against vault and localstack.
Then there is the systemtest KubeLocalStackTestKmsFacade which also extends `AbstractAwsKmsTestKmsFacadewhich uses the helm chart to install localstack but then uses the image version from AwsKmsTestKmsFacade to check that the expected localstack version has been deployed.
So systemtests aren't using that localstack/localstack:3.5 reference except to version check the helm deploy.
I'm missing the context for why it is like this and it does feel spookily like this has been discussed recently.

I thought that setting the version of the helm chart 0.6.15 was enough, like in Vault. But the way it is implemented is different.
helm install localstack --timeout 120s --debug localstack/localstack --version 0.6.15 --namespace localstack --values /home/cloud-user/jenkins/workspace/kroxylicious/kroxylicious-system-tests-pr/kroxylicious/kroxylicious-systemtests/target/classes/helm_localstack_overrides.yaml --wait

Thanks for that finding!


When using an import-map with esm.sh's ?alias feature, the caching fails

Reproduce:

Deno v1.23.3
import_map.json:

{
  "imports": {
      "@mui/": "https://esm.sh/@mui/material<EMAIL_ADDRESS>  }
}

Deno then reports back with:

Package address targets must end with "/".

I couldn't find a current code snippet, but for version 1.9.1 I found this check, which doesn't account for esm.sh alias feature, because it just checks the last character of the value string.
If you have any further questions, please let me know

I am not sure what the spec says about handling query parameters in targets.  If it is allowed, I suspect we need to change how we resolve specifiers to preserve the query paramaters.

It was mentioned as a solution/workaround here https://github.com/denoland/fresh/issues/411#issuecomment-1177462538 and is documented beneath the "Aliasing dependencies" headline directly on esm.sh


Updated based on discussion with Vic Pongracz & Mike Wasson

Submitting changes based on FastTrack for Azure team review

OPS Build status updates of commit f8ab769:
:clock10: Preparing: average preparing time is 45 sec(s)

OPS Build status updates of commit f8ab769:
:clock10: Preparing: average preparing time is 45 sec(s)

OPS Build status updates of commit f8ab769:
:clock10: Incremental building: average incremental building time is 23 sec(s)

OPS Build status updates of commit f8ab769:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/resiliency/index.md
:warning:Warning
View
Details

toc.json
:warning:Warning

Details

building-blocks/extending-templates/toc.json
:warning:Warning

Details

bread/toc.json
:warning:Warning

Details

docs/resiliency/index.md

Line 207: [Warning] Invalid file link:(~/resiliency/azure/architecture/resiliency/disaster-recovery-azure-applications#deployment-topologies-for-disaster-recovery).
Line 251: [Warning] Invalid file link:(~/resiliency/azure/architecture/patterns/circuit-breaker).
Line 258: [Warning] Invalid file link:(~/resiliency/azure/architecture/patterns/bulkhead).
Line 268: [Warning] Invalid file link:(~/resiliency/azure/architecture/patterns/compensating-transaction).
Line 289: [Warning] Invalid file link:(~/resiliency/azure/service-fabric/service-fabric-controlled-chaos).
Line 305: [Warning] Invalid file link:(~/resiliency/azure/azure-resource-manager/resource-group-overview#template-deployment).
Line 306: [Warning] Invalid file link:(~/resiliency/azure/virtual-machines/windows/infrastructure-automation#cloud-init).
Line 307: [Warning] Invalid file link:(~/resiliency/azure/virtual-machines/windows/infrastructure-automation#azure-devops-services).

toc.json

[Warning] Error happen when converting toc.json to Pdf. Details: Could not find file 'T:\jpku\toc.json'.

building-blocks/extending-templates/toc.json

[Warning] Error happen when converting building-blocks/extending-templates/toc.json to Pdf. Details: Could not find a part of the path 'T:\jpku\building-blocks\extending-templates\toc.json'.

bread/toc.json

[Warning] Error happen when converting bread/toc.json to Pdf. Details: Could not find a part of the path 'T:\jpku\bread\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

OPS Build status updates of commit 249f303:
:clock10: Pending: waiting for processors (19 builds ahead of you)
:warning: OPS Build is busy, click here to report any potential performance downgrade issues, or you could view OPS Portal for trend of build queue length.

OPS Build status updates of commit 249f303:
:clock10: Incremental building: average incremental building time is 23 sec(s)

OPS Build status updates of commit 249f303:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/resiliency/index.md
:warning:Warning
View
Details

toc.json
:warning:Warning

Details

building-blocks/extending-templates/toc.json
:warning:Warning

Details

bread/toc.json
:warning:Warning

Details

docs/resiliency/index.md

Line 207: [Warning] Invalid file link:(~/disaster-recovery-azure-applications.md#deployment-topologies-for-disaster-recovery).

toc.json

[Warning] Error happen when converting toc.json to Pdf. Details: Could not find file 'T:\2lnw\toc.json'.

building-blocks/extending-templates/toc.json

[Warning] Error happen when converting building-blocks/extending-templates/toc.json to Pdf. Details: Could not find a part of the path 'T:\2lnw\building-blocks\extending-templates\toc.json'.

bread/toc.json

[Warning] Error happen when converting bread/toc.json to Pdf. Details: Could not find a part of the path 'T:\2lnw\bread\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

OPS Build status updates of commit 249f303:
:clock10: Preparing: average preparing time is 45 sec(s)

OPS Build status updates of commit 249f303:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/resiliency/index.md
:warning:Warning
View
Details

toc.json
:warning:Warning

Details

building-blocks/extending-templates/toc.json
:warning:Warning

Details

bread/toc.json
:warning:Warning

Details

docs/resiliency/index.md

Line 207: [Warning] Invalid file link:(~/disaster-recovery-azure-applications.md#deployment-topologies-for-disaster-recovery).

toc.json

[Warning] Error happen when converting toc.json to Pdf. Details: Could not find file 'T:\aztp\toc.json'.

building-blocks/extending-templates/toc.json

[Warning] Error happen when converting building-blocks/extending-templates/toc.json to Pdf. Details: Could not find a part of the path 'T:\aztp\building-blocks\extending-templates\toc.json'.

bread/toc.json

[Warning] Error happen when converting bread/toc.json to Pdf. Details: Could not find a part of the path 'T:\aztp\bread\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

 Details: Could not find file 'T:\j1id\toc.json'.

bread/toc.json

[Warning] Error happen when converting bread/toc.json to Pdf. Details: Could not find a part of the path 'T:\j1id\bread\toc.json'.

building-blocks/extending-templates/toc.json

[Warning] Error happen when converting building-blocks/extending-templates/toc.json to Pdf. Details: Could not find a part of the path 'T:\j1id\building-blocks\extending-templates\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

 Details: Could not find file 'T:\epn2\toc.json'.

bread/toc.json

[Warning] Error happen when converting bread/toc.json to Pdf. Details: Could not find a part of the path 'T:\epn2\bread\toc.json'.

building-blocks/extending-templates/toc.json

[Warning] Error happen when converting building-blocks/extending-templates/toc.json to Pdf. Details: Could not find a part of the path 'T:\epn2\building-blocks\extending-templates\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

 Details: Could not find a part of the path 'T:\lhzx\bread\toc.json'.

toc.json

[Warning] Error happen when converting toc.json to Pdf. Details: Could not find file 'T:\lhzx\toc.json'.

building-blocks/extending-templates/toc.json

[Warning] Error happen when converting building-blocks/extending-templates/toc.json to Pdf. Details: Could not find a part of the path 'T:\lhzx\building-blocks\extending-templates\toc.json'.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Fixes Unselect From List due to Selenium changes.

Since Selenium version 2.53.0 deselect_by_value/label returns boolean, and
Exception if element is not found.
This fix keeps compatibility with versions <=2.52.0.

Seems that I forgot to use my own PR Template ;)


Unknown Type Warning, When Clearly Known

Hi guys,
I think the compiler should be a bit smarter when it encounters something like the following.
const example = {}; // namespace

(function(example){
    class Fruit {
        constructor() {}
    }

    example.Fruit = Fruit; // export
})(example);

(function(example){
    class Banana extends example.Fruit { // WARNING THROWN HERE
        constructor() {}
    }

    example.Banana = Banana; // export
})(example);

In that example, the compiler will complain that example.Fruit is an unknown type when Banana attempts to extend it. The code is valid though, V8 has no problem with it.
I have a feeling the mismatch in declaration of superclass type warning generated by the next bit of code is also related to that.
const example = {}; // namespace

(function(example){
    example.Fruit = class {
        constructor() {}
    }
})(example);

(function(example){
    const Fruit = example.Fruit;

    example.Banana = class extends Fruit { // WARNING THROWN HERE
        constructor() {}
    }
})(example);

Is there any chance of resolving this at your end?

We don't currently have plans to handle addition of types to namespaces in this dynamic way. It is hard to solve this in general, so we'd have to add special-case code to recognize the pattern presented here.

I have plans to tackle some of the most popular special cases. That's tracked in #789
Specifically, tracing properties added to namespaces through IIFEs is the major blocker. Also promoting types to the global namespace when added as a property to the global object within an IIFE.

Thanks guys. This issue definitely isn't an important one, it's just one of those small niggly things.


BUG: #18481 made BFGS minimization less accurate

Describe your issue.
#18481 appears to have made BFGS minimization less accurate. We noticed this in the JAX upstream nightly tests, which began failing after #18481 was merged: https://github.com/google/jax/actions/workflows/upstream-nightly.yaml
I suspect the dtype changes in approx_derivative are to blame.
Reproducing Code Example
import numpy as np
import scipy

def func(p):
    x, y = p
    return (x ** 2 + y - 11.) ** 2 + (x + y ** 2 - 7.) ** 2

x0 = np.ones(2, dtype='float32')
result = scipy.optimize.minimize(func, x0, method='BFGS')

print(f"{scipy.__version__=}")
print(result)
np.testing.assert_allclose(result.x, [3, 2])

Error message
Output before #18481:
scipy.__version__='1.11.1'
  message: Optimization terminated successfully.
  success: True
   status: 0
      fun: 2.288511533827582e-15
        x: [ 3.000e+00  2.000e+00]
      nit: 8
      jac: [-1.907e-08  2.738e-08]
 hess_inv: [[ 1.612e-02 -9.549e-03]
            [-9.549e-03  3.517e-02]]
     nfev: 39
     njev: 13

Output after #18481:
scipy.__version__='1.12.0.dev0+1440.64be173'
  message: Desired error not necessarily achieved due to precision loss.
  success: False
   status: 2
      fun: 9.628441344453949e-06
        x: [ 3.000e+00  2.000e+00]
      nit: 6
      jac: [ 6.255e-04  2.977e-04]
 hess_inv: [[ 1.615e-02 -9.191e-03]
            [-9.191e-03  3.561e-02]]
     nfev: 291
     njev: 70

---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-1-d421a22eaf1d> in <cell line: 13>()
     11 result = scipy.optimize.minimize(func, x0, method='BFGS')
     12 print(result)
---> 13 np.testing.assert_allclose(result.x, [3, 2])

/usr/lib/python3.10/contextlib.py in inner(*args, **kwds)
     77         def inner(*args, **kwds):
     78             with self._recreate_cm():
---> 79                 return func(*args, **kwds)
     80         return inner
     81

/usr/local/lib/python3.10/dist-packages/numpy/testing/_private/utils.py in assert_array_compare(comparison, x, y, err_msg, verbose, header, precision, equal_nan, equal_inf, strict)
    795                                 verbose=verbose, header=header,
    796                                 names=('x', 'y'), precision=precision)
--> 797             raise AssertionError(msg)
    798     except ValueError:
    799         import traceback

AssertionError:
Not equal to tolerance rtol=1e-07, atol=0

Mismatched elements: 2 / 2 (100%)
Max absolute difference: 0.00049761
Max relative difference: 0.00016587
 x: array([2.999502, 1.999956])
 y: array([3, 2])

SciPy/NumPy/Python version and system information
The error is seen on the nightly scipy version:
$ pip install -i https://pypi.anaconda.org/scientific-python-nightly-wheels/simple --pre -U scipy

@jakevdp, thank you for this report. I'm glad a jax(+scipy) developer is involved with this conversation, your expertise is vital here.
The PR was made in response to #15602 (important to read for background) that pointed out that optimize infrastructure was casting a lot of inputs to np.float64 before evaluation. Thus, if the end user wished to work at a 32-bit precision this would be overridden by optimize, which would do all its work in 64-bit precision, and be sending float64 arrays back to the objective function for evaluation. The OP in #15602 mentioned that sometimes working in 32 bit precision was desired for various types of optimisation (e.g. deep learning frameworks).
The changes in #18481 are designed to respect the float width of the input array (or at least respect it more than previously). Specifically there are internal ScalarFunction, VectorFunction classes that take care of memoisation, grad/hess calculations. These functions were doing casting to float64, but now they remember the original dtype. Thus, if a 32-bit x0 is passed to the original minimize call, then the input dtype is noted in ScalarFunction, and all future operations are done with that dtype. i.e. calls to the objective/grad/hess functions are done with float32. In this case (because callable(jac) is not provided) it means that you're doing numerical differentiation with 32-bit precision. This will be the cause of the precision loss.
If the input array is changed to 64-bit then the problem should not be present.
These changes to respect x0.dtype may not be consistent/perfect throughout the minimize stable, i.e. some minimizers may still cast to float-64. Whilst i haven't checked BFGS probably does nothing to change the bitness because it's pure Python.
In the original issue I did point out that:

Most of them (i.e. gradient calculation) would require double precision to work properly.

the reply to that point was

all the deep learning frameworks use single precision by default or sometimes even lower in order to optimize the throughput.

What do you think about the changed behaviour @jakevdp? Will this have serious downstream harm?  Personally I do all my own work with float64, so won't experience issues. I'd like to hear about wider ramifications.
cc'ing @paulestano for contributions to conversation.

By judicious use of print debugging the logic flow the callstack is:

_optimize._minimize_bfgs -> _optimize._line_search_wolfe12 -> _linesearch.line_search_wolfe1, _linesearch.scalar_search_wolfe1. The last function calls out to minpack2.dcsrch.

When the overall optimisation first starts minpack2.dcsrch returns task values of b'CONVERGENCE', with finite values for stp. After several top level iterations minpack2.dcsrch returns a task of b'WARNING: ROUNDING ERRORS PREVENT PROGRESS'. At this point the linesearch is regarded to have failed, see here and here, with _optimize.line_search_wolfe12 returning None. BFGS tries to fallback to _linesearch.line_search_wolfe2, but this fails as well. At this point the optimisation halts, and you get the top level minimisation halting.
Thus, the rounding errors seem to prevent BFGS working properly.
There are a few possible solutions:

back out the changes made in #18481
intercept x0 in BFGS and make sure we use float64 internally in that minimize method
try and change the linesearch code to work more easily with float32

At the current time I think BFGS and CG are going to be susceptible to this issue.

Thanks for the explanation! I think it makes sense to allow users to operate in f32, especially in a future world where the array API is supported and users can swap-in different backends in place of numpy. I can easily accommodate this downstream by casting to f64 or changing our test tolerances.
But I think as part of this change, it would be worth exploring whether the scipy.opimize machinery actually is functioning as expected in single-precision – this bug may be a sign that there are effectively (though probably not deliberately) some hard-coded assumptions about float precision within the implementations.

I'm guessing that judicious improvement of amin, xtol in line_search_wolfe1 and scalar_search_wolfe1 might improve the situation somewhat.
It looks like amin is approximately np.sqrt(np.finfo(np.float64).eps) (1.49e-8). The default value used in the linesearch code is 1e-8.
xtol seems to be an order of magnitude larger than np.finfo(np.float64).resolution. The default value used in linesearch is 1e-14, but float64 resolution is 1e-15.
If my assumptions are correct it might be possible to adjust the line-search code to account for float precision. We need advice from someone who is familiar with linesearches though, this is not my area of expertise.
From what I can tell of the fortran code in minpack2 there's nothing exploiting floating point precision in there. @ilayn, it looks like this minpack2 code should be relatively straightforward to port from Fortran to Python. There's only one goto.

I'm almost done with PROPACK and looking not bad with ARPACK. Then I can take a stab at it. Looks like a relatively good and readable Fortran code.

I think the way forward for this is to:

respect user options (e.g. xrtol) if they provide them.
if jac is calculated via finite differences and x0 is float32, then adjust xtol, amax, amin to sensible values for float32 as outlined above.
If jac is callable, then leave alone. The reason being that the OP problem seems to work when analytic derivatives are provided.

Hello.
I do believe this kind of behaviours to be expected: here you're combining finite difference and reduced precision arithmetic to estimate the gradients. Hence, you introduce 2 different noise sources in one of the most critical variables of the optimization process.
Adjusting xtol , amax and amin may mitigate some of the issues but I suspect there will still be some functions converging in $\texttt{FP64}$ and not $\texttt{FP32}$ using finite difference. This could also happen with poorly conditioned problems and/or with problems of bigger dimensions. In the paper I mentioned in #15602 the authors compute the gradients explicitly. If this is of interest it might be worth introducing some unit-tests with something like CUTest.
On another note, I noticed that this problem does converge when finite_diff_rel_step is manually set to np.finfo(x0.dtype).eps when $\texttt{FP32}$ is used and to  np.finfo(x0.dtype).eps ** 0.5 when $\texttt{FP64}$ is used. I am not sure to fully understand this part of the code but it might be worth looking into this as a simple fix might just be to enforce  finite_diff_rel_step=np.finfo(x0.dtype).eps if FP32 else np.finfo(x0.dtype).eps ** 0.5.
Adapting previous code enforcing finite_diff_rel_step=np.finfo(x0.dtype).eps and the use of 2-point.
import numpy as np
import scipy

def func(p):
    x, y = p
    return (x**2 + y - 11.0) ** 2 + (x + y**2 - 7.0) ** 2

x0 = np.ones(2, dtype="float32")
type_info = np.finfo(x0.dtype)
print("epsilon={}".format(type_info.eps))
jac = None
hess = None
result = scipy.optimize.minimize(
    func,
    x0,
    jac="2-point",
    hess=hess,
    method="BFGS",
    options={"finite_diff_rel_step": type_info.eps},
)

print(f"{scipy.__version__=}")
print(result)
np.testing.assert_allclose(result.x, [3, 2])

epsilon=1.1920928955078125e-07
scipy.__version__='1.12.0.dev0+1469.849c27d'
  message: Optimization terminated successfully.
  success: True
   status: 0
      fun: 2.9132250201047702e-12
        x: [ 3.000e+00  2.000e+00]
      nit: 11
      jac: [-7.470e-06 -3.397e-06]
 hess_inv: [[ 2.144e-02 -1.669e-02]
            [-1.669e-02  4.247e-02]]
     nfev: 71
     njev: 18

Thank @paulestano. I'm pretty sure that the optimal step sizes are being used for general finite differencing. The code you referred to in numdiff has been worked on a fair bit.

Thank you for your answer @andyfaff.
I thought numdiff had only been used in $\texttt{FP64}$ before #18481 was merged. Was another part of scipy using numdiff
with $\texttt{FP32}$ inputs?
My argument was that, currently, if $\texttt{FP64}$ is used then _eps_for_method returns EPS**0.5=1.49e-8 which is fine. However, in the case where $\texttt{FP32}$ is used, then _eps_for_method should return  EPS**0.5=0.0003452 which I feel might be too big as a relative step. Once again, I'm not very familiar with the code and I might be missing something here.

_numdiff.approx_derivative has been respecting float width for a while, albeit with a few tidyups in 18481. The main change with that PR is that ScalarFunction (which uses approx_derivative for grad calculation) now also respects float width. ScalarFunction is used by many of the minimizer methods to deal with memoisation/fun/grad/hess calculations. Not all minimisation methods may fully respect float width, that's probably an ongoing project.
The step size calculation for numerical differentiation should be the same whatever the float width (i.e. balancing roundoff and secant error). i.e. for forward/reverse differences it's supposed to be sqrt(eps) (https://en.wikipedia.org/wiki/Numerical_differentiation).
I just tried adjusting amin, amax, xtol, in the manner I described above. There are still roundoff errors when using the minimiser. I find it interesting that L-BFGS-B doesn't have this issue.
What's happening is that further improvement of the step isn't found, which triggers the warning. If one looks at the example given in the first post the solution is actually pretty good. It's just classified as a fail because of the warning message being raised.

Hello @andyfaff. Thank you for the clarifications on numerical differentiation.
I also noted that L-BFGS-B does converge with no warning. After a little bit of debugging it seems like L-BFGS-B still does not respect float width (or at least typing). I manually logged the types of self.x and self.x_dtype in ScalarFunction class
Running the snippet from above using L-BFGS-B I get:
self.x_dtype=dtype('float64')
self.x.dtype=dtype('float64')

While for BFGS
self.x_dtype=dtype('float32')
self.x.dtype=dtype('float32')

You can also see that the output of the snippet from above is actually the same in single and double precision.
This probably comes from the fact that L-BFGS-B fortran code does expect double precision inputs  and it could also potentially explain the better stability of L-BFGS-B.
I am also looking at potential fine-tuned values for xtol , amax and amin but I believe that modifying these values might generate new warnings within the fortran code. For instance,   if we increase xtol to account for FP32 precision we may hit $x \leq xtol$ and this would also trigger a warning (not a roundoff one though). Same goes if we hit amin or amax while the wolfe conditions are not reached. This could potentially explain the former very low (respectively high) values for amin (resp. amax).

The limitations of finite difference gradients are well known, I am not surprised that it can alead to optimization failures for simple functions in single precision. Aligning the possible types of gradient/objective function values across all of scipy.optimize is not possible due to the difficulties with the old Fortran libraries unfortunately.
My take on this: let's add a warning in the documentation that if no analytical gradient can be provided, the approximated gradient might become inaccurate.

@dschmitz89 I think the limitations of finite difference are well known but I'm interested in the interactions between the approximation errors (from numerical differentiation) with the arithmetic errors (coming from finite precision computation). It seems like for double precision arithmetic errors are neglectible when using numerical differentiation while it's not the case when using single precision.
Hence, I do believe we should add a warning but only when FP32 is used with finite difference, as it seems to be working fine in FP64.

@paulestano : sorry for the late reply. By warning, do you mean throwing a warning at runtime at the beginning of the optimization if the gradient is approximated in single precision? That is an option but could also be perceived as spam by users sd often single precision is good enough. Any strong opinion here @andyfaff ?

It's a messy situation. I assume that respecting float width is important for some users.

I'm pretty sure that the finite difference code is choosing sensible step sizes for both float widths
However, the range of minimisers in optimize were not originally coded with adaptability to float width in mind.
Some codes may be more easily adapted to deal with float width than others (i.e. Fortran based minimisers).
-For BFGS (mostly Python) I don't think the algorithm is natively hostile to single precision. I guess that adapting c1/c2 may yield some relief when working in single precision. But I don't know how to choose a better c1/c2 for single precision compared to double precision.

I think a sensible route is amend documentation to point out pitfalls first. Then figure out better c1/c2/amin/amax values. If it still causes issues we can think about a warning.

I had a debugging session on this issue this morning, with the OP problem. Adjusting c1/c2 didn't solve the issue.
I then started playing around with the same problem in double precision to try to get it to fail. You can achieve the same 'failure' (i.e. precision loss) by setting gtol to a low value, e.g. 1e-11. If this gtol value is set too low then the BFGS code continues to do a line search (https://github.com/scipy/scipy/blob/main/scipy/optimize/_optimize.py#L1488), but in a region where the dsrch code will fail because of precision losses.
I therefore think the ultimate cause is that the default gtol is set too low for this particular problem in single precision; setting gtol=1e-3 allows the single precision to complete without issue.
Thus, I think the solution to this issue is to amend the documentation to say something along the lines of:

if you see Desired error not necessarily achieved due to precision loss, then consider setting gtol to a higher value. The precision losses typically arise if the finite differences differentiation cannot provide sufficient precision to satisfy the gtol termination criterion; typically when working in single precision (i.e. a callable jac is not provided).

I think adjusting c1 and/or c2 to a low precision setting might be interesting but I can't find any relevant publication on it.
I think gtol=1e-5 might be a bit low indeed when you combine single precision and finite differences.
As a comparison sklearn uses a tolerance of tol=1e-4 in double precision for logistic regression problems (convex problem).

closed by #19259


Remove the locationCommand

What changes are proposed in this pull request?
Remove the locationCommand
Why are the changes needed?
Remove the locationCommand
Does this PR introduce any user facing changes?
NA

alluxio-bot, merge this please


Bump supported MassTransit versions to latest/7.1.5

Would like to use the latest version of MassTransit with this package.
As far as I can see, this should not cause any issues.

It's just, I don't think it's working at the moment (I thought it was, but it only works when publisher/consumer are in the same process, so effectively it doesn't work)

It's just, I don't think it's working at the moment (I thought it was, but it only works when publisher/consumer are in the same process, so effectively it doesn't work)


Modifying task behaviour

Problem description
What I would specifically like to do is call a predefined task, but then with an environment variable set (but not every time).
My particular example
pixi run build <- builds the project
pixi run build-Werror  <- builds the project but with the CXXFLAGS environment variable set for ensuring all warnings are treated as errors
So ideally rather than copying and pasting the entire build command prepended with setting the flag, it would be possible to define a task that does this. depends_on superficially could be used for this, but each command is run in its own shell so the environment can't be modified.
Proposals,
#  if only modifying the environment (set variable for session)
build-Werror = {depends_on="build" environment=["CXXFLAGS='-Werror'", "MY_OTHER_VAR='HELLO'"]}

# More generic run in one session
build-Werror-var = {cmd="export CXXFLAGS='-Werror'"}
build-Werror = {depends_on=["build-Werror-var" , "build"] one_session=True}

Or a way of doing variable definition/replacement, but I understand toml doesn't support that

I don't fully understand your proposal.
Would you want something to "extend" another task?
Here is an issue that wants to extend tasks with arguments. Maybe the use-case is close to that.
I was just checkout how easy it would be to run the different tasks in one shell environment. And it would be doable by concatenating them and pushing them to the execution shell. But I'm unsure if that would give annoying side effects

I see, we'll keep it in the back of our mind. We're also happy with contributions on this topic! @baszalmstra is doing an overhaul of the run code so after that is should be easier to extend the code with more features. (#556)

Im closing this in favor of https://github.com/prefix-dev/pixi/issues/957 . Feel free to reopen if you feel these two issues are not related!


Remove package versions in User's Guide Installation

Describe the Task
The only version of relevance is the Python version.  Maintaining versions in multiple locations will result in confusion if the documentation is inconsistent with the requirements.txt.   Refer the user to the requirements.txt instead with instructions for pip and conda installation using the requirements.txt
N.B.
opencv-python is the package name for pip installation
opencv is the package name for conda installation
Time Estimate
1 day
Sub-Issues
Consider breaking the task down into sub-issues.

[ ] Add a checkbox for each sub-issue here.

Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
Define the source of funding and account keys here or state NONE.
Define the Metadata
Assignee

[ ] Select engineer(s) or no engineer required
[ ] Select scientist(s) or no scientist required

Labels

[ ] Select component(s)
[ ] Select priority
[ ] Select requestor(s)

Projects and Milestone

[ ] Select Repository and/or Organization level Project(s) or add alert: NEED CYCLE ASSIGNMENT label
[ ] Select Milestone as the next official version or Future Versions

Define Related Issue(s)
Consider the impact to the other METplus components.

[ ] METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

Task Checklist
See the METplus Workflow for details.

[ ] Complete the issue definition above, including the Time Estimate and Funding Source.
[ ] Fork this repository or create a branch of develop.
Branch name: feature_<Issue Number>_<Description>
[ ] Complete the development and test your changes.
[ ] Add/update log messages for easier debugging.
[ ] Add/update unit tests.
[ ] Add/update documentation.
[ ] Add any new Python packages to the METplus Components Python Requirements table.
[ ] Push local changes to GitHub.
[ ] Submit a pull request to merge into develop.
Pull request: feature <Issue Number> <Description>
[ ] Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Development issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version
[ ] Iterate until the reviewer(s) accept and merge your changes.
[ ] Delete your fork or branch.
[ ] Close this issue.

@bikegeek  or @fisherhucar would you have a couple minutes to meet and get me up to speed on this?  I'm free until 4pm today. Thanks!

I want to point the requirements sections in the User's Guide to the
requirements.txt file, like what was done in METcalcpy
https://github.com/dtcenter/METcalcpy/issues/352
Minna Win
Pronouns: she/her
NSF NCAR
DTC & Research Applications Lab
Phone:<PHONE_NUMBER>
My work hours may not be your work hours. Please do not feel obliged to
reply to this email outside of your normal working hours.
On Wed, Feb 28, 2024 at 2:16 PM lisagoodrich @.***>
wrote:

@bikegeek https://github.com/bikegeek or @fisherhucar
https://github.com/fisherhucar would you have a couple minutes to meet
and get me up to speed on this? I'm free until 4pm today. Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/dtcenter/METplotpy/issues/412#issuecomment-1969929263,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4UJHQ43HSFFVJZWOT5S5DYV6NBJAVCNFSM6AAAAABBNFUGJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRZHEZDSMRWGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

@bikegeek thanks for the clarification.
I just created a branch, Feature_412_remove_package_versions and I feel silly.  I think this work has already been done.  There is already a literal include in the develop branch. https://github.com/dtcenter/METplotpy/blob/develop/docs/Users_Guide/installation.rst.
Should I delete my branch and close the issue?
Or is there another place that also needs a "literal include"?
Thanks.

I found some hard-coded versions in the polar ice-plot:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/polar_plot.html
the s2s blocking:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/s2s_blocking.html
the difficulty index:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/difficulty_index.html
weather regime plots:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/weather_regime.html
hovmoeller plot:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/hovmoeller.html
spacetime (cross-spectra) plot:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/spacetime.html
stratospheric diagnostics:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/stratosphere_diagnostics.html
*Could you please leave the package names in the documentation but remove
the versions and add a link to the requirements.txt file with some text
like: "For version numbers, please refer to <requirements.txt> "? *
Note the physics tendency does have a hard-coded version for one package,
but this is necessary.  We can leave that documentation unedited.
Thanks for working on this.
Regards
Minna
Minna Win
Pronouns: she/her
NSF NCAR
DTC & Research Applications Lab
Phone:<PHONE_NUMBER>
My work hours may not be your work hours. Please do not feel obliged to
reply to this email outside of your normal working hours.
On Thu, Feb 29, 2024 at 4:05 PM lisagoodrich @.***>
wrote:

@bikegeek https://github.com/bikegeek thanks for the clarification.
I just created a branch, Feature_412_remove_package_versions and I feel
silly. I think this work has already been done. There is already a literal
include in the develop branch.
https://github.com/dtcenter/METplotpy/blob/develop/docs/Users_Guide/installation.rst
.
Should I delete my branch and close the issue?
Or is there another place that also needs a "literal include"?
Thanks.
—
Reply to this email directly, view it on GitHub
https://github.com/dtcenter/METplotpy/issues/412#issuecomment-1972122296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4UJHVGSSVCZ7FKZSABH7DYV6Z2RAVCNFSM6AAAAABBNFUGJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZSGEZDEMRZGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

@lisagoodrich Let me know if you have any questions about this work.  I understand what Minna is asking for, so if it is not clear to you, I should be able to help.
@bikegeek, can you please clarify one point?  Are the links above the only ones you want changed or are there others that perhaps you didn't link to that you also want changed and we should check all others (with the exclusion of the physics tendency which needs the hard-coded version for one package)?

I already went through the plot types and identified these as the ones that
need changes.
Minna Win
Pronouns: she/her
NSF NCAR
DTC & Research Applications Lab
Phone:<PHONE_NUMBER>
My work hours may not be your work hours. Please do not feel obliged to
reply to this email outside of your normal working hours.
On Fri, Mar 1, 2024 at 5:53 PM Julie Prestopnik @.***>
wrote:

@lisagoodrich https://github.com/lisagoodrich Let me know if you have
any questions about this work. I understand what Minna is asking for, so if
it is not clear to you, I should be able to help.
@bikegeek https://github.com/bikegeek, can you please clarify one
point? Are the links above the only ones you want changed or are there
others that perhaps you didn't link to that you also want changed and we
should check all others (with the exclusion of the physics tendency which
needs the hard-coded version for one package)?
—
Reply to this email directly, view it on GitHub
https://github.com/dtcenter/METplotpy/issues/412#issuecomment-1974145877,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4UJHXRWQ2UD5YKAWMCCQTYWEPHFAVCNFSM6AAAAABBNFUGJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGE2DKOBXG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

@bikegeek I spoke with @jprestop about this and I need some clarification on the packages list in Required Packages section of the Polar Ice Plot.  Here is a link to my branch:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/polar_plot.html#required-packages
Version numbers for the following packages, along with the packages themselves, are not listed in the requirements.txt file but are listed as requirements.
metplotpy
cartopy
pyproj
pyresample
pillow
@jprestop suggests I stop work on this now, until we hear back from you, as she
thinks we are likely to encounter this problem with the other plots as well.

I'm pretty busy on some other deadlines, if you are OK with stopping this
work, that is fine.
Minna Win
Pronouns: she/her
NSF NCAR
DTC & Research Applications Lab
Phone:<PHONE_NUMBER>
My work hours may not be your work hours. Please do not feel obliged to
reply to this email outside of your normal working hours.
On Mon, Mar 4, 2024 at 12:12 PM lisagoodrich @.***>
wrote:

@bikegeek https://github.com/bikegeek I spoke with @jprestop
https://github.com/jprestop about this and I need some clarification on
the packages list in Required Packages section of the Polar Ice Plot. Here
is a link to my branch:
https://metplotpy.readthedocs.io/en/develop/Users_Guide/polar_plot.html#required-packages
Version numbers for the following packages, along with the packages
themselves, are not listed in the requirements.txt file but are listed as
requirements.
metplotpy
cartopy
pyproj
pyresample
pillow
@jprestop https://github.com/jprestop suggests I stop work on this now,
until we hear back from you, as she
thinks we are likely to encounter this problem with the other plots as
well.
—
Reply to this email directly, view it on GitHub
https://github.com/dtcenter/METplotpy/issues/412#issuecomment-1977279599,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA4UJHWIVBWJABIFHTHWEBDYWTBQNAVCNFSM6AAAAABBNFUGJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXGI3TSNJZHE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Documentation: create State interface doc

Redux state will have a clear interface defined by the available actions.
We should document:

the available actions, so if I create a new component, I know how to use each action
the state that will be updated when using an action
the parameters that API and URL interfaces expect and in which format they should serialize responses.

Done


Nullptr checks in test files don't work at all

Consider
https://github.com/espressif/esp-nn/blob/34e97138de6e80ab6e047262c1c8b77514739a39/tests/src/convolution_test.c#L215-L229
If input_orig = NULL = 0, then,
        input = 16 + input_orig - ((uint32_t) input_orig & 0xf);

will compute input = 16 + 0 - (0 & 0xf) = 16;
And since 16 != NULL, this will not trigger the if(input == NULL) check at all.
You need to perform the null checks on the original data, not this weird 16 byte aligned value.
What I find also weird is how it clearly tries to do a 16-byte alignment, by adding at maximum 15 to the original pointer value, but the overallocation is by +32? Should that not need only 15 really, in the worst case that 15 bytes need to be skipped? If 16 bytes were needed to be skipped, it would already be 16-byte aligned.
Not doing this correctly has lead to me hardcrashing.
writing to input buff at input = 0x10
Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x400d1f98  PS      : 0x00060e30  A0      : 0x800d12da  A1      : 0x3ffb7fa0
A2      : 0x00000002  A3      : 0x00000008  A4      : 0x00069200  A5      : 0x00000000
A6      : 0x00000010  A7      : 0x3ffb83a0  A8      : 0x00000010  A9      : 0x3ffb7f80
A10     : 0x00000056  A11     : 0x3ffb85dc  A12     : 0x0008125c  A13     : 0x00000000
A14     : 0x00000002  A15     : 0x00000002  SAR     : 0x00000013  EXCCAUSE: 0x0000001d
EXCVADDR: 0x00000010  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xffffffff

Backtrace: 0x400d1f95:0x3ffb7fa0 0x400d12d7:0x3ffb84b0 0x400d898d:0x3ffb84d0 0x400898bd:0x3ffb84f0
  #0  0x400d1f95 in esp_nn_depthwise_conv_s8_test at src/esp-nn-test-funcs/convolution_test.c:236 (discriminator 3)
  #1  0x400d12d7 in loop() at src/main.cpp:53
  #2  0x400d898d in loopTask(void*) at C:/Users/Max/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp:50
  #3  0x400898bd in vPortTaskWrapper at C:\Users\Max\.platformio\packages\framework-espidf@3.40407.240606\components\freertos\port\xtensa/port.c:142

Fair point. Checks indeed need to be done on the original pointers. I shall fix these. And the removal of over-allocation too.
That given, looks like you get a crash since, allocations are failing. Please use SPIRAM for the tests. The allocations needed for some tests are huge.


When updating RDBMS event tables, only the first attribute of the table can be given for on condition

Description:
When updating a RDBMS event table, we can use on condition. But for that, it only works fine when the first attribute of the table is provided. When other attributes are provided for the on condition, it fails.
Suggested Labels:
3.1.x, eventtable, rdbms, siddhi
Suggested Assignees:
@grainier
Affected Product Version:
3.1.x
OS, DB, other environment details and versions:
Tested on ubuntu 16.04 and JDK 1.8
Steps to reproduce:
Following query will work fine.
define stream StockStream (symbol string, price float, volume long);
define stream UpdateStockStream (symbol string, price float, volume long);
@from(eventtable = 'rdbms' ,
datasource.name = 'RDBMSTestConstants.DATA_SOURCE_NAME' ,
                   table.name = 'RDBMSTestConstants.TABLE_NAME',
                   bloom.filters = 'enable')
define table StockTable (symbol string, price float, volume long);

@info(name = 'query1')
from StockStream
insert into StockTable ;

@info(name = 'query2')
from UpdateStockStream
update StockTable
on StockTable.symbol == symbol ;

But following will fail.
define stream StockStream (symbol string, price float, volume long);
define stream UpdateStockStream (symbol string, price float, volume long);
@from(eventtable = 'rdbms' ,
datasource.name = 'RDBMSTestConstants.DATA_SOURCE_NAME' ,
                   table.name = 'RDBMSTestConstants.TABLE_NAME',
                   bloom.filters = 'enable')
define table StockTable (symbol string, price float, volume long);

@info(name = 'query1')
from StockStream
insert into StockTable ;

@info(name = 'query2')
from UpdateStockStream
update StockTable
on StockTable.volume == volume ;

Note that the 2nd on condition has Stock.volume == volume where volume is the 3rd attribute. Hence it fails.
Related Issues:
none

Fixed in #574


Add meta-rules evaluation to UI

Since the move to breadcrumbheaders, we've hidden the button to enable meta rule evaluation, which we need to have somewhere in the UI

Currently the model editor visualizer allows you to run when selecting an object using the available context menu

Not currently using breadcrumb header so no longer needed.


Make the BlangNodeTransformer resilient

Description:
$subject.

Please find a summary of crashing here.

Closing this issue as we have handled scenarios case by case as per the above doc and BLangNodeTransformer crashing is now almost extinct.


Other RLT simulator Compilation Errors in top_name.v, relay_station.v, and async_mmap.v Due to Undeclared Parameters and Variables

In the generated files top_name.v and relay_station.v, there are several I/O ports with parameter bit-widths that have not been declared. This omission causes compilation errors in other RTL simulators.
Additionally, in async_mmap.v, the variable write_data_empty_n is used before its declaration, which also leads to a compilation error in RTL simulators.
Could the authors of TAPA address these issues? Thank you for your assistance.

Hi @logosAllen,
How do I reproduce the simulator errors? I do run iverilog on the Verilog files and it's not reporting errors.

Hi @Blaok ,
I use VCS.
Errors come from:
relay_station.v:
https://github.com/UCLA-VAST/tapa/blob/4847fa5d6d0c14d0a7872059c2a8632bafedec6c/backend/python/tapa/assets/verilog/relay_station.v#L246-L270
async_mmap.v:
https://github.com/UCLA-VAST/tapa/blob/4847fa5d6d0c14d0a7872059c2a8632bafedec6c/backend/python/tapa/assets/verilog/async_mmap.v#L295-L301

I don't have access to VCS, but c57b3a38449f28079d690d488f9d22ffa4fc8c5d should fix this. Feel free to reopen if not. Thanks for the detailed report!

Hi @Blaok ,
I left out this module, it has the same issue.
https://github.com/UCLA-VAST/tapa/blob/84fc3d043bb0391b100d683947552a600daf5467/backend/python/tapa/assets/verilog/relay_station.v#L335-L345
Thank.

Hi @Blaok,
Also, there are some port bit mismatch in synthesized [top kernel name].v file.
The m_axi_XX_ARLOCK and m_axi_XX_AWLOCK are one bit.
But the m_axi_XX_ARLOCK and m_axi_XX_AWLOCK of sub modules are two bit.
Thanks.

I left out this module, it has the same issue.
https://github.com/UCLA-VAST/tapa/blob/84fc3d043bb0391b100d683947552a600daf5467/backend/python/tapa/assets/verilog/relay_station.v#L335-L345

Thanks, fixed in 60cc41ce7580ce2578f7d78ba8ab5b0b0fe1a034.

Also, there are some port bit mismatch in synthesized [top kernel name].v file. The m_axi_XX_ARLOCK and m_axi_XX_AWLOCK are one bit. But the m_axi_XX_ARLOCK and m_axi_XX_AWLOCK of sub modules are two bit.

This unfortunately cannot be fixed because it is an HLS bug. According to ARM's official documentation, AxLock is supposed to be a single 1-bit for AXI4, but HLS generates 2 bits. Only AXI4 supports 8-bit AxLEN; TAPA just has to throw away the 1 extra bit from AxLOCK.


c++ mode not formatting correctly with clang-format and format-all

What did you expect to happen?
When using :editor format and :lang (cc +lsp), calling evil-indent on a region should call clang-format and respect my .clang-format at the root of the project.
What actually happened?
When using :editor format and :lang cc:
Selecting a region and doing M-x format-all-buffer does the correct thing, which is to call clang-format and correctly use the .clang-format file at the root of the project.
Selecting a region and calling evil-indent does the INCORRECT thing, it says that it formats but it doesn't follow my .clang-format file, I don't know if it even uses clang-format.
When using :editor format and :lang (cc +lsp):
Selecting a region and doing M-x format-all-buffer does the INCORRECT thing, it formats wrongly and prints "LSP ::  No formatting changes provided"
Selecting a region and calling evil-indent does the same INCORRECT thing
When using :editor format and :lang (cc +lsp) and an elisp fix:
Using the following fix:
(setq-hook! 'c++-mode-hook
   +format-with-lsp nil)

THEN calling format-all-buffer does the correct thing, and evil-indent still does not.
Describe your attempts to resolve the issue
Using the following elisp fix:
(setq-hook! 'c++-mode-hook
   +format-with-lsp nil)

allows me to call the (format-all-buffer) function and have the expected format behaviour, but this is a workaround, it should work out of the box without it.
Steps to reproduce
Just enable :editor format, :lang (cc +lsp), install clangd & clang-format, have a custom .clang-format tool at the root of the project and observe that it is not respected.
System Information
doom/info pastebin: https://pastebin.com/raw/ecA8MPtr

evil-indent does not call the formatter, you can use SPC c f which will call the formatter

evil-indent does not call the formatter, you can use SPC c f which will call the formatter

Okay, thanks I didn't know that.
The bit about the elisp should be handled by the cc module tho in my opinion. It is basically saying to use clang-format over LSP formatter (whatever that is)

Okay, thanks I didn't know that.
The bit about the elisp should be handled by the cc module tho in my opinion. It is basically saying to use clang-format over LSP formatter (whatever that is)

The LSP formatter is clang-format. For the most part your code is redundant as long as you are calling the format functions.

The LSP formatter is clang-format. For the most part your code is redundant as long as you are calling the format functions.

Here are two screenshots of SPC c f
This is without my fix:

This is with my fix:

Clearly the formatting is different.

Here are two screenshots of SPC c f
This is without my fix:

This is with my fix:

Clearly the formatting is different.


demo-resume-page

Complete demo resume page

@Arpita-Jaiswal can you take a look at the code that resume authors would be writing? Currently its a big component that takes a lot of parameters, we need to create a better design.


Add "Download CSV" option for transaction history

@kristykjlee Do we need this feature now?

This has been moved to the Design Repository

I'd like to work on this so i can export my transactions for tracking transaction history - thanks


Disambiguation Menu

See the fix here:
https://github.com/KVonGit/quest-js/wiki/Disambiguation-Menu-Fix

This is now fixed.  No need to add the modified ResolveNameFromList function anymore.


Forwarding only - use ufw for other stuff

Sweet pair-programming by freethenation and I

magic_func?
hairpin nat
documentation on UFW
disable docker & LXC networking
NAT to containers without forwarding

Fixed everything except hairpin nat / localhost routing. I still haven't quite figured out how to do that one. Also, I haven't really tested IPv6 yet.


Create access and secret key on ranger/server container starting

Hello,
In order to use tools like ansible, we have to set the access key (CATTLE_ACCESS_KEY) and the secret key (CATTLE_ACCESS_KEY) for access to the api when the container ranger/server is started.
Something like that could be very useful:
$ docker run -d -p 8080:8080 rancher/server \
-e CATTLE_ACCESS_KEY=xxx
-e CATTELE_SECRET_KEY=yyy

With this trick, ansible is able with one deployment file to create server, create registry, add each hosts to the server and POST container creation on the right host. And no action is needed in the backoffice (in order to allow automatic deployment without any human intervention, except for run ansible script)
Or if you have an alternative solution ;)
Thanks

We have this implemented with the concept of service accounts.
http://docs.rancher.com/rancher/latest/en/rancher-services/service-accounts/


Haptic Feedback

Describe the feature you'd like to have in Pock
A clear description of what you want to happen.
Integrating haptic feedback with the touch bar, so if we unwillingly touch anything, we are notified by 3d touch or haptic feedback.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Have used a few apps from the internet that have it done, but they're clunky and resource dependent
Additional context
Add any other context or screenshots about the feature request here.
n/a

bumping


Add option in Find to ignore matches in comments

Would be quite useful to have a checkbox (or something) in the Find dialog to ignore search matches in comments.

@jrking123 thanks for your feedback!


Can't even start

Hi,
maybe I'm to ignorant in Python but I cannot handle this:
I start the CLI script on Ubuntu 16 and get
peter@kanne:~/scribus_script$ ./ScribusGeneratorCLI.py test.sla
Traceback (most recent call last):
  File "./ScribusGeneratorCLI.py", line 119, in <module>
    generator = ScribusGenerator(dataObject)
  File "/home/peter/scribus_script/ScribusGeneratorBackend.py", line 63, in __init__
    logging.config.fileConfig(os.path.join(os.path.abspath(os.path.dirname(__file__)), 'logging.conf'))
  File "/usr/lib/python2.7/logging/config.py", line 77, in fileConfig
    formatters = _create_formatters(cp)
  File "/usr/lib/python2.7/logging/config.py", line 113, in _create_formatters
    flist = cp.get("formatters", "keys")
  File "/usr/lib/python2.7/ConfigParser.py", line 607, in get
    raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'

Any ideas?

Hello @ingpk,
Sorry to read you have trouble with this script.
I have no idea why this error occurs for you, as there is indeed a "formatters" section in the logging.conf file, despite what your error message reports.
Could you please try to (download the whole script again)[https://github.com/berteh/ScribusGenerator/archive/master.zip], and let me know if that fixes your problem.
B.

hello @ingpk.
any feedback to know if that solved your problem?
I cannot reproduce the problem: works fine for me in Ubuntu.

@ingpk @berteh  You missed logging.conf file. I reproduced your problem and fixed by copying "logging.conf" to scribus scripts folder. Cheers.

thanks @McQueenPL  for finding the problem and fixing it.
I close the bug but feel free to re-open it @ingpk  if you still experience the issue with this fix.

I'm coming here as a rather rookie Scribus user wanting to do some merging and this also got me. It stems from the very vague installation instructions;

Download the script and uncompress it anywhere on the local machine. It can be placed with the standard extension scripts.

If, like me, you don't want to trash system directories you'll want to copy (preferably by soft link, but that somehow doesn't work) only the needed files into /usr/share/scribus/scripts. Doing this for only *.py files and the pic directory will end up with the GUI being shown but bails out like this on generation attempts.
It doesn't look like there is a nice way out of this as the m_scriptDir variable used by the scripter extension in isn't very flexible.
Explaining this a little better in the readme would be good. I'll try to wrap up a PR.


Omit mut from Tokenizer

This PR implemented a stateless version of Tokenizer for multithreading.

@vbkaisetsu
Could you review the current API design found in the cargo doc rather than the many file changes included in this PR?
If there are detailed modification points, could you give me them with another PR?

@vbkaisetsu Could you approve it again because of the merge?


Do we need save_result ? Don't seem to be using it anywhere else

https://github.com/infraspecdev/spellcheck-action/blob/5ffc9e0b81b75fac3d444f2135573c9ccecbd80c/src/spell_check.py#L154

Removed the save_result function b29d1995f3e72bea6e19642a1b6f3b5ec06222ab


Televisions shouldn't spam chat

Description

Currently it's a huge pain to watch the chat when TVs just spam is constantly with no way of turning them off. I'm tryna catch the baddies!!! Not have the messages be covered by the same one over and over!
Reproduction

have a camera and a bunch of tvs :trollface:
Screenshots

https://github.com/space-wizards/space-station-14/assets/122584947/148955c9-3b90-4e82-91f0-602e2c28a582

should just show messages ingame not in chat like north star gloves


DataExtractor error

Error "System.InvalidOperationException"
"var switchJson = DecodeFile(newMsts.First(m => m[Variable.KeyName].ToString() == "F_SUBLIMATION_RECIPE_MST"));"
in Program.cs.
MST already is 1444.

Solved. Problem was app version. Second time I have this problem.


[uwebsockets] update to 20.61.0

Library name
uwebsockets
New version number
20.61.0
Other information that may be useful (release notes, etc...)
https://github.com/uNetworking/uWebSockets/releases/tag/v20.61.0

Looks like v20.62.0 is available now so this request is now outdated
https://github.com/uNetworking/uWebSockets/releases/tag/v20.62.0


Add D bindings to Raylib

These bindings were created for D, as to supersede the Scheme48 bindings (issue #2043) which I'm not going to work on.
Scheme48 has not been developed since April 2014 so it's useless to keep these bindings if that's okay.

I don't understand what makes a stable language useless? Would you prefer Chez Scheme or Racket for current implementations?
I am not objecting to this contribution. I am just curious about the remark.
I know there are c99 discrepancies now, and /std:c11 is better for initializers that exist in some of the raylib files. I don't here any complaints about obsolescence though.

The problem with Scheme48 is that it doesn't let the programmer access C structs specifically which is sometimes needed.
I've opted for D since it's far easier generating bindings to it


⚠ Jenkins Plugins Artifactory has degraded performance

In b1767a6, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1322 ms

Resolved: Jenkins Plugins Artifactory performance has improved in b9aa389 after 12 minutes.


Chess: Move D8 to B6

Please do not change the title. Just click "Submit new issue".

@tmchuynh done! Successfully played move d8b6 for current game.
Thanks for playing!


doc: docker plugin  default docker container runtime path change

doc update form to https://docs.docker.com/engine/extend/

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks! Please sign CLA first.

this path is likely to vary in different environments, it's mentioned in the code snippet comments as well, closing


Fix NPE in ImageReference#isValidTag() and add more descriptive error messages

Fixes #1534

Should the build fail, or should we just warn+skip null tags?

That's a good question. I think warn+skip seems reasonable. This can be handy if you a fixed pom.xml template while you want to skip additional tags when an env variable is not defined.

This doesn't seem much different from #416 / #1401 where we fail the build.

Hmm... I was initially thinking CMD args is a bit different story because all the values in the list are related to form a single semantic CMD configuration. That is, there must be something wrong if any of the values are null, whereas in this case, each tag value is independent of each other so it's OK if some of them are null.
However, I am totally fine with failing for any null and have stronger consistency around config. I actually like it.

PTAL: Took a different tack and now validate the values provided from Maven.  Kept the helper message for Containerizer.withAdditionalTag() to provide useful information as to which tag was invalid.


Updated DefaultViewService IdentityServer3 NuGet reference.

The existing one, 2.3.0-build00379, apprarently cannot be found.  Replaced with v2.3.0.

Hi @NetChris, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;

Closing this PR as it is is eclipsed by 50710c30873bc8bfaeb8221b7475f7a9982444ef.

Ah yes, thanks -- I meant to come back in here and talk to you about that. Sorry.

No worries at all!


Implement ABIF ballot format read/write

Test cases on https://electowiki.org/wiki/ABIF, discussion still ongoing.

Compatibility with the Pivot format https://pivot-libre.github.io/bff/ is also desirable.


Add initial project files

ditto.

I have cleaned the repository and added your suggestions. I have tried to start the world on webots.cloud but unfortunately I still get the same error message telling me that it can't find the .wbt file. Can it be related to its name containing a hyphen symbol ('-') ?

It could be (even so it should not), could you try to rename the world to test?

Sure we should fix the problem, changing the name to e_puck.wbt still triggers the error message.

Can it be related to its name containing a hyphen symbol ('-') ?

This used to be a problem as it was fixed in simulation.php here #3

@ThomasOliverKimble Could you check why it fails? The only reason I see is a wrong parsing of the URL, as the same project works in your own repo: https://github.com/ThomasOliverKimble/GuidedTour/blob/guided-tour/e-puck/worlds/e-puck.wbt

The issue with the world loading has been fixed in #4874. The repository is now completely cleaned and works fine on webots.cloud.

Sure we should fix the problem, changing the name to e_puck.wbt still triggers the error message.

fixed with webots PR #4874

I have replaced the C controller by a Python one. It should be equivalent.


HTML starter kit & Bootstrap reactive menu

Acquiring & running the 2.1 HTML starter kit (i.e., opening index.html in Firefox) I notice the following behavior: When the browser window is made narrower than 768 pixels the menu appropriately collapses to the icon form. However, clicking on the menu icon causes it to change its rendering but not to show the collapsed menu. It is as if the Bootstrap js code is not running. I am not familiar enough yet with this environment to debug.

Please add bootstrap on main.js to let bootstrap javascript to be loaded:
define(['durandal/system', 'durandal/app', 'durandal/viewLocator', 'knockout', 'bootstrap'],
function (system, app, viewLocator, ko) {
...

@EisenbergEffect this is in fact not a bug and the solution proposed by @derkan is correct, this item can be closed


[Feature] Only start chatroom timer when all players are there

Need to discuss with clients about the time control in a game - either to set the barrier at chatroom, or set hard limit on both readings and chatroom.

Adjusted to only start the timer when all players have reached the chatroom step.

Leave this as is and ask for clients opinions.


Change input predicate offset to message & coin

Resolves #166

do we still need Input::coin_predicate_len? Seems like we only need Input::predicate_len now.

do we still need Input::coin_predicate_len? Seems like we only need Input::predicate_len now.

True, should be either deprecated or removed. Since we are already breaking the API, I just removed them:
https://github.com/FuelLabs/fuel-tx/pull/174/commits/e8faf6ca42a12dbbb984dbb41671b170b4eef0eb


Getting error while previewing the content

Steps -

Setup ACMS headless V2 site using https://github.com/acquia/drupal-recommended-project template
Use the demo content while setup
Not setup NextJS site while headless V2 setup
Once site is installed, manually enable nextJS
Setup nextJS site using the acquia nextjs starterkit
Once setup is done, verify nextjs site is opening fine
Then edit an article content and add a new revision in draft state and check the preview of the content
Notice the error in preview
Also notice error now on NextJS site as well (seems something is cached)

This seems happening because of some change in consumer module. And because of that clientID is not set for headless consumer.
To fix this, edit the headless consumer and add the client id manually or generate that. Then copy this client id from drupal and update in .local.env in nextjs app as currently we are using UUID of consumer and not the client id.


Run terraform init at invocation image build time

Currently, we (re)-run terraform init at run time before any lifecycle action (install, uninstall, etc.)
Once we have the context necessary to do so, let's consider running terraform init at invocation image build time.  See https://github.com/deislabs/porter-terraform/pull/3#discussion_r274564588 for the genesis of this idea.
Porter ticket in https://github.com/deislabs/porter/issues/262
For due diligence, here are the init docs: https://www.terraform.io/docs/commands/init.html

+1
leaving 'terraform init' at run time means inability to execute for air gapped environments, since terraform plugins are fetched during that time

@oleksiidzhulai thank you for the reminder on this ticket.  I'll start on this work...


Why some loss functions in README figure1 have same color?

I wonder whether loss functions with same color in README figure1 have similar mathematical characteristics? I want to combine two loss functions with same color, does it make sense?

Hi @RGBli ,
To be honest, I do not know. There is little theory study on these loss functions.
You can try to add any of them in your experiments:)


bug: list contents visible after navigating to next page

Bug Report
Ionic version:

[x] 4.11.0
Current behavior:

When navigating from a page with a list view to a detail view (which contains a footer) part of the list's contents remain visible behind the footer. They do not remain visible for very long--maybe half a second--but it's long enough to be noticeable.
Expected behavior:

The list contents should never be visible after navigating away from the list.
Steps to reproduce:

Using the sample application, select one of the list items and watch the background of the footer on the page.
Related code:

Download the sample application here: andy-rash/IonListAndFooterBug.
Other information:

I thought that perhaps this was caused by running the app using the Chrome DevTools, but I was also able to reproduce the bug when running the app on my dev phone (Samsung Galaxy S8, Android 9 (Pie)).
Ionic info:

Ionic:

   Ionic CLI                     : 5.4.2 (/Users/andy/.nvm/versions/node/v11.15.0/lib/node_modules/ionic)
   Ionic Framework               : @ionic/angular 4.11.0
   @angular-devkit/build-angular : 0.803.9
   @angular-devkit/schematics    : 8.3.9
   @angular/cli                  : 8.3.9
   @ionic/angular-toolkit        : 2.0.0

Cordova:

   Cordova CLI       : 9.0.0<EMAIL_ADDRESS>   Cordova Platforms : android 8.1.0
   Cordova Plugins   : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 4.1.2, (and 4 other plugins)

Utility:

   cordova-res : 0.8.0
   native-run  : 0.2.8

System:

   Android SDK Tools : 26.1.1 (/Users/andy/Documents/SDKs/Android)
   ios-deploy        : 1.9.4
   ios-sim           : 8.0.1
   NodeJS            : v11.15.0 (/Users/andy/.nvm/versions/node/v11.15.0/bin/node)
   npm               : 6.12.0
   OS                : macOS Catalina
   Xcode             : Xcode 10.3 Build version 10G8

Thanks for the issue. This issue is happening because:

You had class="ion-padding" applied to the footer (this added padding around the footer, making the leaving page visible under the footer)
You did not put your footer content in a toolbar.

Doing both of those things should resolve your issue. Can you try that and let me know how it goes?

@liamdebeasi  yes, that did help. I didn't realize .ion-padding would do that.
To replicate the look I had before, I applied a custom class to the ion-toolbar adding padding all around. When I was doing this, I noticed that ion-toolbar has this CSS rule applied to it:
ion-footer ion-toolbar:last-child {
    padding-bottom: var(--ion-safe-area-bottom,0);
}

...which I assume is related to e.g. the iPhone X safe area.
In light of that, do you know if adding my own custom CSS rule to add uniform padding around the ion-toolbar would step on the toes of some other Ionic CSS functionality?
Thanks for your input!

I think if you added the ion-padding class as a div inside ion-footer and then gave that div a background color, that should be fine. The ion-toolbar element is what actually has the white background, not the ion-footer.


Handle JPZ puzzles with split words

see e.g. https://ams.cdn.arkadiumhosted.com/assets/gamesfeed/independent/daily-crossword/c_221213.xml

Resolved with https://github.com/crosswordnexus/pypuz/pull/15


update release images to use go1.19.2 and cosign v1.12.1

Summary

update release images to use go1.19.2 and cosign v1.12.1

Codecov Report

Merging #2315 (9d38dcb) into main (7978172) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2315   +/-   ##
=======================================
  Coverage   30.06%   30.06%
=======================================
  Files         131      131
  Lines        8062     8062
=======================================
  Hits         2424     2424
  Misses       5314     5314
  Partials      324      324

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

Question: should we set 1.19 here too https://github.com/sigstore/cosign/blob/main/go.mod#L3 ?

we are not doing this right now because downstream users that are using go1.18 can import the module, otherwise, they need to upgrade to 1.19


Badge builder!

Closes #9

Preview version is deployed here: substats-git-badge-builder. Any suggestions? @kidonng

LGTM! Just some suggestions.


An unhandled exception has occurred. See browser dev tools for details. Reload

Hi,
I am currently reading the Blazor Succintly eBook and found some problems when trying to run EditTicket control (page 73).
Considering the possibility that I had made a mistake when following the construction of the application, I downloaded the source code from GitHub and got the same error, see below:

Best Regards,
Luiz Pires

What version of Syncfusion and .Net Core are you using?
Also, what are the exact steps you did that produced the error?
Thank You

Hi,
Syncfusion.Blazor version <IP_ADDRESS> and .Net Core 3.1
The error occurs immediately after clicking the Edit button. The form freezes.
Thank You

I wrote this for a different version of Syncfusion (and it was tested, I promise! :))
Please open a help desk ticket with Syncfusion because they could have introduced a bug.
Thanks!

Ok,
Thank You

If they need me to change my code (I shouldn't!), please let me know. Thank You

(reopening this for now...)

Hello Michael,
You do not need to make changes to the SyncHelpDesk Application code, see below for the solution to the question answered by Syncfusion support.
"We have validated the reported issue and the reported issue occurs while placing the GridCommandColumns at the first position. Since it is a known issue we have resolved the issue and it was included in our latest patch release <IP_ADDRESS>. So kindly upgrade to our latest version to resolve the reported issue."
Thank you very much for your attention and support.
Luiz Pires

Luiz, Thank you for following up!


[BUG]

Function triangulate_face() in triangulation.scad fails when the face is not a simple polygon. For instance:
p = [ [0,0,0], [1,0,0], [1,1,0], [0.5,-1,0],[0,1,0] ];
echo(triangulate_face(p,[0,1,2,3,4]));

WARNING: Invalid type of parameters for cross(), in file triangulation.scad, line 148
For this example, find_convex_vertex() can't find a convex face vertex and returns an undef value that is an operand of a cross().
We have two possibility to overcome the issue:

check the returned find_convex_vertex() value and call an assert if it is undef;
the triangulate_face() returns an undef value when the check fails as a signal that the triangulation is impossible because the face is not simple.

The later alternative would be interesting as it allows the caller function to identify the issue and take an appropriate action. Ideally those two alternative might be optional to the caller function by an additional parameter whose default to the first alternative.

There is another issue with triangulate_face(). It fails for some simple faces like:
p = [ [0,0,0],   [1,0,0],     [1,1,0],     [0.7,0.5,0],
      [0.6,1,0], [0.5,0.1,0], [0.4,0.5,0], [0,1,0] ];
echo(triangulate_face(p,[0,1,2,3,4])); // ECHO: [[1, 2, 3], [3, 4, 0], [0, 1, 3]]
t = triangulate_face(p,[0,1,2,3,4]);
translate([2,0,0]) polygon([for(pi=p) [pi.x,pi.y]]);
for(ti=t)
   color(ti/7)
     polygon([for(i=ti) [p[i].x,p[i].y]]);

The triangulation in this example doesn't refers to the vertices 5 an 6.

It should pretty definitely assert an error if it finds a self-crossing face perimeter.  Returning undef, while in theory allowing more flexibility, in practice tends to hide problems, and propagate bad data to places that make more cryptic errors.

I agree. An option would be to return an empty vnf when the face is not simple and a parameter 'check' is true. If 'check' is false (the default), an error would be asserted. The objective here is to avoid a previous simple face test before the triangulation.

Regarding the second example given, that is behaving correctly.  It never references vertices 5 and 6 because you never gave it a face with them in it.

Added the assert at this time.