Eufy Security Add-on not starting in Home Assistant

Hi,
just installed Eufy Security Add-on following following integration manual for Eufy Security. After installation add-on wont start. Tried reloading Home Assistant few times and that have no effect on add-on. Basically when you hit button to start add-on it stop right away. Log is saying "2022-07-17 07:26:19.776  INFO  Eufy Security server listening on host <IP_ADDRESS>, port 3000" and configuration tab says "This add-on does not expose configuration for you to mess with…"

I had a fresh install on my dev environment and all is working fine. I dont think this is related to add-on, looks more related to setup, I suggest you to bring up this topic to HA community forum.


Feture Request: Feature to use the askai command from the Emacs buffer.

I am an Emacs user.
I would like to input the selected range in Emacs editing to askai, and have the result inserted at the cursor position.

I have already written about 10 lines of code.
I think it's fine to just write it in the README, so I will send a pull request at a later date.


scipy.optimize has broken my trust.

This submodule has broken my trust.
I am genuinely in awe of how it was included in scipy 1.0.  I am tagging two heavy hitters to attempt to bring discussion to this issue since, in general, scipy.optimize issues seem to go without discussion or fixes.  @pv @teoliphant
As I understand, an effort was made in the last few version of scipy leading up to and including 1.0 to unify the interface of the different optimization routines and eventually deprecate fmin_xxxx.
A fairly large issue with this is that many of the inputs and outputs in the scipy documentation for these functions are simply wrong.
Take, for example the BFGS method.
the documentation for disp is incorrect; convergence messages are not printed, only a blurb at the end.  return_all appears in the call signature at the top and is undocumented.  I looked to fmin_bfgs hoping its more specific documentation would be superior.  The documentation for that is even more misleading.  I hoped that the specified type for the constituents of allvecs being OptimizationResult would mean they hold cost function values and input vector values.  They are simply input vector values.  The documentation here is also misleading.
I also understand that many of the algorithms are wrapped code in another language, e.g. L-BFGS-B is written in FORTRAN77, and this may make their modification difficult.  Earlier today I opened an issue that L-BFGS-B does not respect the maxiter input, #8372.  There are other issues, e.g. lack of respect for user's input dtype because of hard coded doubles in the fortran code, for example.
However, the docs being misleading is a great travesty for the users of this module, which I believe is among the more important/widely used of scipy.  I would work to improve them myself, but I do not feel that my knowledge of the inner workings of the module is great enough to do so without myself making mistakes.
Returning to L-BFGS-B, the wrapped fortran code appears to contain a variety of errors or behaviors that have a varied level of harmfulness.  For example, this is an example output:
RUNNING THE L-BFGS-B CODE

           * * *

Machine precision = 2.220D-16
 N =            4     M =           10

At X0         0 variables are exactly at the bounds

At iterate    0    f=  2.75370D+01    |proj g|=  1.06893D+02

At iterate    1    f=  2.27149D+01    |proj g|=  1.76623D+02

At iterate    2    f=  1.20196D+01    |proj g|=  1.20733D+02

At iterate    3    f=  8.05081D+00    |proj g|=  8.74848D+01

At iterate    4    f=  5.00344D+00    |proj g|=  8.42253D+01

At iterate    5    f=  3.70940D+00    |proj g|=  1.01991D+02

At iterate    6    f=  1.57818D+00    |proj g|=  7.10948D+01

At iterate    7    f=  4.81956D-01    |proj g|=  3.76945D+01

At iterate    8    f=  6.81301D-02    |proj g|=  2.20645D+01

At iterate    9    f=  1.34639D-02    |proj g|=  8.79078D+00

           * * *

Tit   = total number of iterations
Tnf   = total number of function evaluations
Tnint = total number of segments explored during Cauchy searches
Skip  = number of BFGS updates skipped
Nact  = number of active bounds at final generalized Cauchy point
Projg = norm of the final projected gradient
F     = final function value

           * * *

   N    Tit     Tnf  Tnint  Skip  Nact     Projg        F
    4      9     12      1     0     0   8.791D+00   1.346D-02
  F =  1.346394518877836E-002

CONVERGENCE: REL_REDUCTION_OF_F_<=_FACTR*EPSMCH

 Cauchy                time 0.000E+00 seconds.
 Subspace minimization time 0.000E+00 seconds.
 Line search           time 0.000E+00 seconds.

 Total User time 0.000E+00 seconds.

the code writes "iterate" instead of "iteration" (a typo).  This is an annoyance as it is not very professional, but it does not break anything.  The separate timings for Cauchy, subspace minimization, and line search are also always zero.  Same for user time.  It would be nice for these to not be a filler values since this is misleading, but same thing - this is creature comfort problem, not an accuracy problem.
My application is in a topic known as wavefront sensing, or phase retrieval.  We put in some number of parameters, and the landscape of the cost function is highly evolutionary as the optimizer traverses the space.  As a result, when designing a cost function or debugging code it is desirable to know the state of the optimizer, even without knowing its internal mechanisms, as it walks the space.  To do this I do the following:

Save this output text from L-BFGS-B, and scrape the f= values from it.
Use a callback that stores parameter vectors.

I expect these two things to have the same length always, and depend on cost[n] being associated with all_x[n] without registration errors between these two blocks of data.
In my particular application (I can share code on request, but 1000-2000 lines are called to implement my routine split across a few modules; there is no easy "def foo()" analog that I have found to reproduce this) I am having trouble understanding why my cost function appears to not be correlated, based on the output of l-bfgs-b, to the closeness of the current iteration input to truth:

This has cost me dozens of hours of debugging time, only to learn that something is wrong with L-BFGS-B that causes the output of options={'disp': True} to not be the the cost function at a given parameter vector.
Because I capture stdout, I am not able to use print.  I have embedded a line in my cost function that appends the current parameter vector and cost to a .txt file and resorted to matching values in that to L-BFGS-B print output to see what is wrong.  The text from that is below, with numbered lines
00. params = [ 0.  0.  0.  0.] 	 f(x) = 27.5369873872

01. params = [  1.00000000e-08   0.00000000e+00   0.00000000e+00   0.00000000e+00] 	 f(x) = 27.5369884562

02. params = [  0.00000000e+00   1.00000000e-08   0.00000000e+00   0.00000000e+00] 	 f(x) = 27.5369867324

03. params = [  0.00000000e+00   0.00000000e+00   1.00000000e-08   0.00000000e+00] 	 f(x) = 27.5369870096

04. params = [  0.00000000e+00   0.00000000e+00   0.00000000e+00   1.00000000e-08] 	 f(x) = 27.5369875808

05. params = [-0.80769268  0.49476373  0.28537275 -0.14630029] 	 f(x) = 86.4418490547

06. params = [-0.80769267  0.49476373  0.28537275 -0.14630029] 	 f(x) = 86.4418490135

07. params = [-0.80769268  0.49476374  0.28537275 -0.14630029] 	 f(x) = 86.441849366

08. params = [-0.80769268  0.49476373  0.28537276 -0.14630029] 	 f(x) = 86.4418499781

09. params = [-0.80769268  0.49476373  0.28537275 -0.14630028] 	 f(x) = 86.4418482602

10. params = [-0.16406864  0.1005026   0.05796848 -0.02971834] 	 f(x) = 22.714940612

11. params = [-0.16406863  0.1005026   0.05796848 -0.02971834] 	 f(x) = 22.7149388457

12. params = [-0.16406864  0.10050261  0.05796848 -0.02971834] 	 f(x) = 22.7149405671

13. params = [-0.16406864  0.1005026   0.05796849 -0.02971834] 	 f(x) = 22.7149404753

14. params = [-0.16406864  0.1005026   0.05796848 -0.02971833] 	 f(x) = 22.7149421094

15. params = [-0.10087717  0.09158391  0.05575493 -0.06632038] 	 f(x) = 12.0195875306

16. params = [-0.10087716  0.09158391  0.05575493 -0.06632038] 	 f(x) = 12.0195863232

17. params = [-0.10087717  0.09158392  0.05575493 -0.06632038] 	 f(x) = 12.0195878653

18. params = [-0.10087717  0.09158391  0.05575494 -0.06632038] 	 f(x) = 12.0195883001

19. params = [-0.10087717  0.09158391  0.05575493 -0.06632037] 	 f(x) = 12.0195867159

20. params = [ 0.15842029 -0.01548538 -0.01632799 -0.07159999] 	 f(x) = 48.7174210299

21. params = [ 0.1584203  -0.01548538 -0.01632799 -0.07159999] 	 f(x) = 48.7174233933

22. params = [ 0.15842029 -0.01548537 -0.01632799 -0.07159999] 	 f(x) = 48.717421743

23. params = [ 0.15842029 -0.01548538 -0.01632798 -0.07159999] 	 f(x) = 48.7174193993

24. params = [ 0.15842029 -0.01548538 -0.01632799 -0.07159998] 	 f(x) = 48.7174245544

25. params = [-0.05512618  0.07269238  0.04303647 -0.06725192] 	 f(x) = 8.05081234605

26. params = [-0.05512617  0.07269238  0.04303647 -0.06725192] 	 f(x) = 8.05081192026

27. params = [-0.05512618  0.07269239  0.04303647 -0.06725192] 	 f(x) = 8.0508114712

28. params = [-0.05512618  0.07269238  0.04303648 -0.06725192] 	 f(x) = 8.05081281076

29. params = [-0.05512618  0.07269238  0.04303647 -0.06725191] 	 f(x) = 8.05081206742

30. params = [-0.02149653  0.09172596  0.0267816  -0.06652566] 	 f(x) = 5.0034401551

31. params = [-0.02149652  0.09172596  0.0267816  -0.06652566] 	 f(x) = 5.00344002938

32. params = [-0.02149653  0.09172597  0.0267816  -0.06652566] 	 f(x) = 5.00343999403

33. params = [-0.02149653  0.09172596  0.02678161 -0.06652566] 	 f(x) = 5.00344079846

34. params = [-0.02149653  0.09172596  0.0267816  -0.06652565] 	 f(x) = 5.00343931285

35. params = [ 0.03012534  0.12108955 -0.01347029 -0.04719621] 	 f(x) = 3.70939759272

36. params = [ 0.03012535  0.12108955 -0.01347029 -0.04719621] 	 f(x) = 3.70939819132

37. params = [ 0.03012534  0.12108956 -0.01347029 -0.04719621] 	 f(x) = 3.70939842652

38. params = [ 0.03012534  0.12108955 -0.01347028 -0.04719621] 	 f(x) = 3.70939740919

39. params = [ 0.03012534  0.12108955 -0.01347029 -0.0471962 ] 	 f(x) = 3.70939657281

40. params = [ 0.00300894  0.11308784  0.00337076 -0.03858502] 	 f(x) = 1.57818376805

41. params = [ 0.00300895  0.11308784  0.00337076 -0.03858502] 	 f(x) = 1.578184007

42. params = [ 0.00300894  0.11308785  0.00337076 -0.03858502] 	 f(x) = 1.57818379941

43. params = [ 0.00300894  0.11308784  0.00337077 -0.03858502] 	 f(x) = 1.57818414645

44. params = [ 0.00300894  0.11308784  0.00337076 -0.03858501] 	 f(x) = 1.5781830571

45. params = [-0.01561316  0.12143126  0.00100096 -0.01330919] 	 f(x) = 0.481955650202

46. params = [-0.01561315  0.12143126  0.00100096 -0.01330919] 	 f(x) = 0.481955273258

47. params = [-0.01561316  0.12143127  0.00100096 -0.01330919] 	 f(x) = 0.481955840221

48. params = [-0.01561316  0.12143126  0.00100097 -0.01330919] 	 f(x) = 0.481955839908

49. params = [-0.01561316  0.12143126  0.00100096 -0.01330918] 	 f(x) = 0.481955373719

50. params = [-0.00041042  0.12401147 -0.00485423  0.00207093] 	 f(x) = 0.0681301442419

51. params = [-0.00041041  0.12401147 -0.00485423  0.00207093] 	 f(x) = 0.0681301690496

52. params = [-0.00041042  0.12401148 -0.00485423  0.00207093] 	 f(x) = 0.0681301089522

53. params = [-0.00041042  0.12401147 -0.00485422  0.00207093] 	 f(x) = 0.0681299235971

54. params = [-0.00041042  0.12401147 -0.00485423  0.00207094] 	 f(x) = 0.0681302701249

55. params = [-0.00144057  0.12278377 -0.00124594 -0.00264166] 	 f(x) = 0.0134639451888

56. params = [-0.00144056  0.12278377 -0.00124594 -0.00264166] 	 f(x) = 0.0134639411113

57. params = [-0.00144057  0.12278378 -0.00124594 -0.00264166] 	 f(x) = 0.0134638572809

58. params = [-0.00144057  0.12278377 -0.00124593 -0.00264166] 	 f(x) = 0.0134639506651

59. params = [-0.00144057  0.12278377 -0.00124594 -0.00264165] 	 f(x) = 0.0134639172132

The callback creates the following list:
[array([ 0.,  0.,  0.,  0.]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166]),
  array([-0.00144057,  0.12278377, -0.00124594, -0.00264166])]

I have reproduced this for completeness, but the important lines are 00, the initial guess, which matches iterate 0 in the output text from the optimizer.  Iteration 1 matches any of line 12-14.  The parameter vectors are similar to:
[-0.16406864  0.10050261  0.05796848 -0.02971834]

The callback contains this input array at that iteration:
[-0.00144057,  0.12278377, -0.00124594, -0.00264166]

Which would be associated with a cost function 0.013, not 22 and change.  As a result, I am unable to trust the tools I have to diagnose a problem with them.  The output of the L-BFGS-B print simply is not the value of the cost function for the parameter vector at that iteration.  I believe the problem is something like as follows:

The callback is called at the end of a line search before beginning a new gradient hunt
The f= is written at the start of a line search

But I cannot trust the documentation of scipy to be correct that the callback is called at the end of an iteration (~= end of line search in BFGS), and I cannot trust lbfgsb.f to be error free in this way.
Are there plans to improve the optimization module in a "months not years" timespan?  Is anyone willing to rewrite lbfgsb.f or even port it to C/C++ or pure python to solve these problems?  In commercialized applications, it is often desirable for a user to keep their finger on the pulse by monitoring convergence and potentially stopping optimization, hand tuning the inputs, and then continuing the work.  The architecture of optimize.minimize is prohibitive to this.  It would be nice to see a context manager based implementation that allows interruption of the optimizer without losing the current state, as this sort of behavior is only possible at the moment through use of a complicated callback function.

There are many issues to unpack here.

There are other issues, e.g. lack of respect for user's input dtype because of hard coded doubles in the fortran code, for example.

double precision is needed internally when calculating gradients because numerical inaccuracies are created in the gradient otherwise.

the code writes "iterate" instead of "iteration" (a typo). This is an annoyance as it is not very professional, but it does not break anything.

I can assure you that the whole scipy community works very hard to develop this software, in their own free time, doing their best. To me your post comes across as unprofessional. For future information, iterate is well used in this context.
noun: iterate; plural noun: iterates
1.
a quantity arrived at by iteration.

There is an issue with maxiter, reported in #7854, which does need to be corrected, this will eventually be tackled, along with the ~1000 other issues that are destined to be addressed.

As a result, when designing a cost function or debugging code it is desirable to know the state of the optimizer, even without knowing its internal mechanisms, as it walks the space. To do this I do the following: Save this output text from L-BFGS-B, and scrape the f= values from it. Use a callback that stores parameter vectors.

Scraping the output for this purpose is not a robust way to do this. Ideally the callback function should be supplied an OptimizeResult which contains the best x so far, and the function evaluation. This would be a great new feature, but has to take into account back compatibility. In the meantime you should be able to calculate f(x) in the callback function, or even memoize f(x) for given x.

This has cost me dozens of hours of debugging time, only to learn that something is wrong with L-BFGS-B that causes the output of options={'disp': True} to not be the the cost function at a given parameter vector.

I'm sorry that you lost dozens of hours on this. Scraping output is not a robust way of doing this.

Are there plans to improve the optimization module in a "months not years" timespan? Is anyone willing to rewrite lbfgsb.f or even port it to C/C++ or pure python to solve these problems?

We continually look for improvements, but this is mostly done in peoples free time. If you are willing to rewrite the codebase, we would welcome a Pull Request.

It would be nice to see a context manager based implementation that allows interruption of the optimizer without losing the current state, as this sort of behavior is only possible at the moment through use of a complicated callback function.

I have plans to implement this for one solver, but gradual evolution is required, that would require a lot of work for all the solvers, and one would want a fairly uniform approach across them all.

Having had a look at lbfgsb.f, it's highly unlikely that'll be ported to another language anytime soon. In fact there's a benefit to keeping it in fortran - we get to use any updated versions that are released.

This submodule has broken my trust.

I would never trust any low level implementation details unless they are checked and verified by unit tests. On the higher level, I spent weeks over the years fighting with convergence problems across optimizers and scipy version, e.g. a few years ago I wrote this https://github.com/statsmodels/statsmodels/issues/1641 , but I never worried about whether maxiter is defined as number of iterations or number of iterations plus one except in the case of maxiter=0 versus maxiter=1.
Overall I worry that the "feature creep" in optimize introduces a large amount of overhead and makes it more difficult for tools like numba to speed it up. (disclaimer: I don't have much experience with  numba yet.)
Aside: I'm overall pretty happy with scipy optimize improvements and I especially like that development is going into getting new, better or more robust optimizers, (speaking as statsmodels convergence problem hunter).

double precision is needed internally when calculating gradients because numerical inaccuracies are created in the gradient otherwise.

This depends on the value of epsilon and the overall scale of the cost function and I do not believe can be stated as fact.  If a user provides f32s, the library may warn the user but should respect their wishes choice of data type.

To me your post comes across as unprofessional.

Then it is a good thing no one here is acting in a professional role.  I am highly frustrated that an authoritative library like scipy has a submodule which is wrought with errors that are nonobvious and bite you very hard when they appear.  This issue is an expression of that deep frustration.

For future information, iterate is well used in this context.

I would defer to english.se that it is not.

There is an issue with maxiter, reported in #7854, which does need to be corrected, this will eventually be tackled, along with the ~1000 other issues that are destined to be addressed.

There are << 1000 issues specific to the optimization submodule.

Scraping the output for this purpose is not a robust way to do this.

If the output can be trusted, it is a perfectly fine way to do it.  The textual output is machine generated and you can expect scraping it to not silently fail.  My cost function is expensive - about 1s/evaluation - so I would prefer to not play back, say, 150 iterations after it has completed to compute the cost function trajectory.  This takes < 1ms and is, effectively, free.

Ideally the callback function should be supplied an OptimizeResult which contains the best x so far, and the function evaluation. This would be a great new feature, but has to take into account back compatibility.

The mere mention of OptimizeResult worries me, since this is referenced over and over again in the documentation for optimize.minimize and optimize.fmin_xxxx but is rarely actually used.  The bad taste is so strong cleansing that name from scipy.optimizes vocabulary would be preferred if the idea were to be consistently used and documented.
Two months ago I opened an issue about this very thing.  I do not think it was a bad design choice to unify the solver interfaces under optimize.minimize, but they are not truly uniform because of the options dict.  To be pythonic, that should have been **kwargs, but whatever.  Introducing another kwarg/option that changes what is fed to the callback would:

I think not confuse users
Be a decently elegant solution

It would look something like
# in minimize.py::minimize
if callback is not None:
    if cost_all is True:
        callback(x, fx)
    else:
        callback(x)

Very simple.  If there is concern about this breaking compatibility, just make scipy 2.0 with breaking changes, or scipy 1.1 if 0.x versions can make breaking changes.  This change wouldn't be breaking, though.

or even memoize f(x) for given x.

f(x) is passed numpy arrays.  Memoization is nontrivial in that scenario.  You can do np.all(a==b) but FP roundoff might bite you.  There would be an art in using np.allclose to not break the optimizer itself by accidentally returning the wrong cost function value for some small epsilon.

We continually look for improvements, but this is mostly done in peoples free time.

Scipy has long reached critical mass where it is an authoritative package.  Free time or not, version 1.0 signifies production ready for real, and on pypi scipy is listed as development 5, production/stable.  optimize.minimize does not fit that criteria, and should not even be included in its current state.  You may disagree, but as a user with no stake in Scipy other than my familiarity with it and no malice towards what is on the whole a great effort, that is my opinion and I am entitled to it.

If you are willing to rewrite the codebase

I do not have a py2.7 install, and would not want to install one to develop on.  All the tricks like importing six and other black magic to make a module work with 2.7 and 3.x are not things I want to learn.  Of greater importance is that I am not an expert in nonlinear optimization and there would be significant nonzero risk in me making a bad error.

No one is forcing you to use SciPy. If you want commercial support, then you can pay for a MATLAB license.

You may disagree, but as a user with no stake in Scipy other than my familiarity with it and no malice towards what is on the whole a great effort, that is my opinion and I am entitled to it.

You fundamentally misunderstand open source software. Fundamentally. SciPy and other open source software isn't written for you. It's written for its contributors, and you're allowed to use it as a side effect. If you're not a contributor, then you are not entitled to decide what it should be called, its development status, or any other aspect of its development or distribution. Perhaps you can convince a contributor to adopt your opinion, but that's unlikely with the tone that you display here.

You fundamentally misunderstand open source software. Fundamentally.

No, I do not.  I write a few open source packages myself - some on github, some not - and on several occasions have changed the interface to something, or its internal workings, based on user feedback.
You fundamentally misunderstand human interaction.  Fundamentally.

This issue isn't a bug report. It's an attempt to claim the time of others to work on issues that they themselves have decided not to prioritize:

I am tagging two heavy hitters to attempt to bring discussion to this issue since, in general, scipy.optimize issues seem to go without discussion or fixes. @pv @teoliphant

@xoviat please go away.

I think this is not a healthy way to discuss. The license of SciPy clearly mentions the very problem you are addressing.
We are sorry for your experience but we are not obliged to take immediate action to remedy this because an open source library does not operate on the terms you would be expecting as such from a commercial software.
I would really recommend not discussing this further unless there is a code contribution or an isolated issue.

@ilayn I do not think asking for "months not years" is asking for immediate action.
Issues related to scipy.optimize have been largely ignored on this repository.  I think this is a very major problem with optimize.minimize, or at least with method='L-BFGS-B', and think it needs to be addressed.  I pinged two of the biggest names re: scipy to draw attention to this and gave it a dramatic name.  So far, it appears to have worked, but not in the way that I would have wanted.

It might be a major problem for you. Every part of SciPy has different problems big or small. But they are not fixed on demands or frustrations. I have worked on Pull Requests that took more than a year. I do still wait for action on some items. Of course they have to be addressed but definitely not by demanding and complaining about a lot of people's voluntary time and patience.
Those biggest names are not the cavalary you hope them to arrive. You seem to have a point of view that doesn't agree with the reality of how SciPy works.

@xoviat wrote

SciPy and other open source software isn't written for you. It's written for its contributors, and you're allowed to use it as a side effect.

Please be assured that this is not the opinion of all (or even most, I suspect) SciPy developers.  The library is written for the world to use.  If it were written only for its "contributors", I'd stop contributing.
Moreover, by filing this issue, Brandon is contributing.  It took a lot of time to create that initial report; he could have simply stopped using it SciPy.  Feedback--good or bad--is essential, and should not be ignored.  Some of the comments may lean more towards "rant" than "bug report", but try to put yourself in his shoes when he says "This has cost me dozens of hours of debugging time".   You'd probably be ranting too.  Please try to filter out the emotional aspects of the report ("great travesty", etc.) and focus on the defects--big and small--that are being reported.

As I said unless there is an isolated issue or code contribution my recommendation is to stop that kind of discussion. Just to state in case it is not clear, I am not trying to close this issue but it has to be streamlined and cooled down a little bit.

For some reason, I am no longer able to comment with my standard account on this issue (I was personally unaware that it was possible to block a specific user account on a specific thread without blocking the user from the entire repository, however it's possible that one of my comments was flagged).
However, I wanted to note that there was no rational basis to post my original comment and therefore, it must have been made in err.

@xoviat

I have found that the discrepancy between the callback and L-BFGS-B output will manifest with the rosen function.
An example:
from scipy.optimize import minimize, rosen
# import forcefully_redirect_stdout and parse_cost_by_iter_lbfgsb

params = []
def callback(x):
    params.append(x)

with forcefully_redirect_stdout() as out:
    res = minimize(rosen, (0,0,0), options={'disp': True}, method='L-BFGS-B', callback=callback)

costiter = parse_cost_by_iter_lbfgsb(out['txt'])
costiter2 = [rosen(x) for x in params]
print(costiter)
print(costiter2)

You will need the two functions from here, https://gist.github.com/brandondube/2c319727bbc794e97c0806a3abd213ba
The output is:
[2.0, 1.95917, 1.61222, 1.5741, 1.4304, 1.2286, 0.689151, 0.63911, 0.438557, 0.292715, 0.23319, 0.182176, 0.105509, 0.0824601, 0.0544236, 0.0256008, 0.0108747, 0.00610558, 0.00264869, 0.000595762, 6.15612e-05, 2.10079e-06, 1.12758e-07, 2.97115e-08, 3.8601e-11, 1.58921e-11]
[1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11, 1.5892114699716987e-11]

Note that the callback doesn't include the guess (0,0,0), so the second print statement is sheared by one column.  The callback is spammed at the end, one time for each of the times it should have been called along the way.

Ah, I think I know the problem. The callback is getting called at the appropriate times, but the x array that gets passed into the callback is the same object every time. It gets mutated by the minimizer function on each iteration, so when you finally inspect it at the end, the value is whatever it was at the final iteration. Append a copy of x to the list instead.

@rkern  This fixed the problem with the callback being out of sync -- any chance a fix can be made to scipy.optimize.minimize to avoid this behavior?  The parameter arrays are quite small, so I can't imagine making a new one with each tick has particularly big performance implications.

Such a fix would be welcomed, certainly; the cost is indeed small, and it would make typical use cases significantly less error-prone. It'll have to be fixed individually in each minimizer implementation, though, sometimes in Python, sometimes in C, depending on the minimizer.

If the callbacks took an OptimizeResult then the constructor could take care of that.

Sure, but that's an even larger change. :-)

The callback is getting called at the appropriate times, but the x array that gets passed into the callback is the same object every time. It gets mutated by the minimizer function on each iteration,

I can see both points of view here.
It should be enough to just do something along the lines of (provided there's no performance hit):
if callback is not None:
    callback(np.copy(xk))

If the xk is modified during the function evaluation, then that's another matter :-(.

Generally, I don't believe that SciPy should copy the array that is passed to the callback. One of the ways that Python is deceptively simple is that all of its objects are in fact references rather than values. If you were to pass a list into some random function and such a list were to be modified, the list that you had would be modified as well. Similarly, with a NumPy array, you should generally copy the object if you intend to preserve its state.
The behavior here isn't really beginner-friendly, so perhaps a documentation update is in order.

Similarly, with a NumPy array, you should generally copy the object if you intend to preserve its state

You're arguing for the status quo here, as your callback is wanting to preserve the state.

I am arguing for the status quo, while acknowledging that the status quo could trip-up beginners.

Actually not quite-I think we can improve here with a new full_history keyword argument that expands the x, fun, jac, and hess ndarrays returned to array.rank + 1, with the other dimension being the optimization history.

My functions are not mutating x, nor is rosen.  The mutation is done by L-BFGS-B itself.  You could see a hint to this in that the initial guess was a tuple, which is immutable, at least wholly so in this case where the constituents are ints or floats.
Passing a copy of x to the callback will have negligible performance impact.  Numpy's copy will have a few microseconds of python related overhead, followed by the time to duplicate, in general, a 10 float64 or smaller vector.  In an extreme case, perhaps 1 million parameters which is still 8MB.  Memory moves at around 12GB/s on a modern machine, so ~.7ms to duplicate the array.
In such a scenario the cost function or its gradient is almost assuredly very, very expensive so this overhead is still unimportant.

For some reason, I am no longer able to comment with my standard account on this issue (I was personally unaware that it was possible to block a specific user account on a specific thread without blocking the user from the entire repository, however it's possible that one of my comments was flagged).

@tempuser-111 I've checked, we have not blocked any users on any repo within the scipy organisation. And yes, it's not even possible to block a user on a single issue.

@brandondube
The primary concern is backwards compatibility. If there are callback functions that modify the copy, we would at least need to verify that optimization results are not affected. AFAIK, we cannot have silent breakage.
@rgommers
The @xoviat, @tempuser-111, and @tempuser-112 have now been blocked from commenting on this issue, and this specific issue only. I'm currently investigating the reason behind these blocks, but this behavior isn't documented, and I don't think that you or any of the administrators here are responsible for it. I have administrative privileges on some repositories, so I know what you can do on the SciPy repository, and I agree with you that you can't block someone from commenting on a particular issue. Honestly I wouldn't bother discussing it further until I identify the cause.

Okay, so after some analysis, what appears to have happened is that @brandondube blocked these accounts. My conception of GitHub's logic is currently this:
class Thread(object):
    comments = [Comment(), ...]
    user = User()

class Comment():
   user = User()

if thread.user.name == 'brandontube':
  silentlyBlock()

It's somewhat worrying that you can block others from commenting on issues, even if they don't own the repository. I'm collecting more data to confirm my suspicions.

@xoviat I asked you to go away.  I will block every account you use to comment on my issue.

I don't think I should be blocked from commenting on an issue in the SciPy repository, considering that you don't have privileges here. I also have a script to generate these accounts, so it probably takes more time for you to click the block button.

On the contrary, because I created this issue I have ownership and significant privileges on it.
If you make a 15th alternate account, I will file a report with Github, as you are abusing their services.

@rgommers  How can one user block another user?
This is not appropriate behavior for open source.

@brandondube I understand your frustration, both with the library's functionality and Xoviat's comments.  At the same time, it helps to keep in mind that everyone here (including yourself, thank you!) is giving their time freely to debug and improve the library.  When an issue is titled "scipy.optimize has broken my trust", it does not engender a very positive feeling from the developers working on it.  If we steer towards a more technical description such as "scipy.optimize updates parameters in-place" it takes the sting out, and allows us to focus on the issues at hand.
We generally do not prevent others in the community from participating in our comment threads, even when we disagree with their perspectives (perhaps especially then); it's useful to hear those opinions, because one of the strengths of open source is finding a balance between opposing views to build code that is robust for many different use cases.  I think, in this case, you saw the need to protect yourself from Xoviat's comments, which felt personal, and I am sorry for that.  I cannot make you unblock Xoviat, but I do think it would be better if we could all sit around the table and discuss the issues at hand, with an eye towards improving scipy.optimize.
Thank you for giving your time to benchmark and to evaluate the code, and for helping us make a useful submodule even more so.  I hope we can address each of the issues you raised here to your satisfaction and in a timely manner.

@stefanv I am sorry that we disagree, but it is my view that someone who's opening comment is:

No one is forcing you to use SciPy. If you want commercial support, then you can pay for a MATLAB license.

You may disagree, but as a user with no stake in Scipy other than my familiarity with it and no malice towards what is on the whole a great effort, that is my opinion and I am entitled to it.

You fundamentally misunderstand open source software. Fundamentally. SciPy and other open source software isn't written for you. It's written for its contributors, and you're allowed to use it as a side effect. If you're not a contributor, then you are not entitled to decide what it should be called, its development status, or any other aspect of its development or distribution. Perhaps you can convince a contributor to adopt your opinion, but that's unlikely with the tone that you display here.

~ @xoviat
has no place at this table.  My vote in the matter, as creator of this issue, is ultimate and will change under no circumstance.
I hold no ill-will towards scipy.  I depend on much of it for my work, including the interpolation, delaunay, stats, and optimization submodules.  When I discovered after rewriting my entire program at great personal expense to solve a bug that didn't exist in it but instead existed in scipy, I could have walked away and turned to a different optimization package, or changed languages to something else altogether.  Instead I invested still yet more hours in trying to pinpoint the problem and in writing this issue.  I did this in spite of looking at every issue in this repository related to the optimization submodule and seeing that they were almost unanimously unactioned.
When I wrote this issue, I did so from a perspective of already having read many textual outputs from lbfgsb.f.  I assume that because the timers are included, but broken, and the language is slightly wrong (though I now see iterate vs iteration is somewhat contentious) that the error would lie in that subprogram.  I see now that the error is in lbfgsb.f, or the scipy.optimize.minimize callstack anyway.  I am fully aware that the guess is proved as any sequence and cast/converted to an array.  I would not have expected any of the subroutines (L-BFGS-B, CG, etc) to modify that array in-place instead of creating a new array.  This design choice seems illogical to me, as it is prone to having nasty side effects (such as the callback issue) in exchange for being more performant on the scale of single digit microseconds per iteration.

To follow up on what @stefanv is saying - there's a really strong culture in the open-source projects I know, not to block or suppress people, no matter how annoying you may find them or their comments.   Open-source - like Scipy - runs on the fuel of 'everyone is welcome'.      I see you can do it, but we're humbly asking you to be patient; we'll try and help if it gets heated.

The scipy organization administrators can block a user, and they should be the only ones that can do it.
https://docs.scipy.org/doc/scipy/reference/dev/conduct/code_of_conduct.html

To me it is not a question of annoying, but gravely offensive.  There is nothing that can be done to get me to lift the ban I have placed on him.

@josef-pkt - it looks like a user can block other users from an issue they started.  I don't think we can configure that - at least I can't see that option in a quick look in the interface.

It looks like a screwed up permission policy in github. I didn't find any information about this. When I looked for it in the past there was no option for specific issues and I had to completely block a user from the organization.

I think this toxicity will not lead to anything fruitful. I am not happy with watching a frequent contributor is being bashed continuously and banned with the prose of "ultimate owner"not having a "place on the table"  of the issue etc. And I have to repeat, I don't even agree with what xoviat said.
For a few times you had the chance to straighten out this towards a neutral tone yet you chose to impose a nonexisting authority. So until you work out this hostile behavior this is on the verge of online bullying which you also threatened a user reporting to GitHub.
That for me crosses the line, I don't want to participate in any of this any more and will leave the discussion to the board and other willing SciPy members.

As a matter of policy IMO a user blocking a user is inappropriate. I don't believe that there is ownership of issues.
My recommendation is to ask a blocker to remove the block and refrain from using it in the future. Otherwise the issue should be closed and locked out for further comments.

Oh dear - no - I personally think we should reduce the amount of enforcement here, there's already too much.  It's unfortunate we got to this point, and we should really put a rule on this ("don't block from your own issues") somewhere so we can point to it, but I vote for throttling back, and letting this go.  I think it's clear what we prefer.

@ev-br that you would raise the value of @xoviat's voice over improvement of scipy is very saddening to me.
To be clear, I have not done anything special with this issue, merely blocked @xoviat and all of his alts.  If I open another issue on scipy, he will not be able to comment on that either.  His offensive, and abusive tone, is unwelcome and I will not put up with it.

Hi all, can I ask to stop the discussion at this point? It has become unproductive, and has already been reported to the CoC committee at the scipy-conduct email adress. The tone of both the initial post and multiple replies to it, by multiple people, have been unhelpful/inappropriate. The code of conduct committee will follow up with the involved people separately.

Ouch - that's unfortunate, that it went to the scipy-conduct address before someone pointed to  the relevant section of the CoC doc on this thread.

This code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. Please try to follow this code in spirit as much as in letter, to create a friendly and productive environment that enriches the surrounding community.

(no more comments)

The best policy in these situations is to avoid joining in. A policy have I have just broken, but what is a life without risks :)

closed; technical issues extracted into #8417 #8418 #8419

To start with, we apologize for the delay in posting our final summary on this issue. This was mostly not due to lengthly deliberations, we failed to follow up promptly at some point (although the issue with blocking is fairly complex).
The CoC committee has reviewed this thread (including the deleted
comment), and also talked to both @brandondube and @xoviat privately.
We think there are a few different issues here.
First, @brandondube:
the original ticket blended emotion with technical issues; please
understand that this may upset contributors (as witnessed by the
discussion). This can be avoided in the future by focusing on the issue
at hand, and avoiding statements that relate to the competence of the
developers, the professionality of the work done (this is volunteer
time), etc. We do appreciate your detailed initial report, but if you
want to continue participating on the SciPy issue tracker then you
need to find a way to work productively with other contributors, and
to empathize with the volunteers who are trying to improve SciPy while
balancing the needs of many many users, long term maintainability, the
limited time they have available to contribute, etc. We're all on the
same side here. We're closing this thread, technical discussion can
continue on the new issues you opened with more details about your
problem(s). Please keep the above in mind there.
Second, regarding @xoviat's first few posts (one of which has since
been deleted): These were over the line. @xoviat realized this,
contacted us about it privately, and has apologized. (@brandondube, after
talking to you we understand you don't want an apology, but we feel you
ought to know one was offered nevertheless). Having reviewed the posts
in question, we feel an apology is sufficient and consider the matter
settled as far as the SciPy project and the CoC committee is concerned.
Finally, regarding the subsequent interaction between @brandondube and
@xoviat, and the use of Github's blocking feature: this is complicated,
there are a number of things to consider here:

We do affirm that people do have the right to not have interactions
with others forced on them whether they want to or not.
Anything else is raising barriers to victims of harassment.
Therefore @xoviat's subsequent messages under different usernames are
problematic, and should not have happened (especially the last one,
after it was clear to @xoviat that they were blocked).
However, most of those subsequent messages were about finding out what
was going on (it wasn't clear to anyone that @xoviat had been blocked
by @brandondube). The issue here is Github's poor UI for the blocking
feature - we are raising this with Github directly.
Blocking places us in a dilemma - as SciPy developers, we want all
contributors to be able to give input on any change; this includes
@xoviat (he's not being blocked by us from contributing to SciPy as a
result of this issue).
Therefore, we recommend strongly that contributors should not block
each other when an issue first arises. Rather, we would like to see them
raise the issue with the CoC committee first, which can take appropriate
action. Only if that doesn't help should a contributor consider blocking
another contributor.
In case someone does get blocked, we recommend that they provide any
technical input they may have via the mailing list (the person who
blocked them can choose not to participate there, and those posts are
generally quite well monitored by us all for inappropriate content).

We're locking this issue. Further constructive discussion on or request
for clarification about this statement can be done with the CoC
committee directly.
Signed, the CoC committee (@rgommers, @njsmith, @stefanv)


[Clean-up] Unify the logic for getting alternateText for getOptions and getOptionData

Stemming from improvements to the LHN previews https://github.com/Expensify/App/issues/34411
The getOptions and getOptionData methods get the alternateText differently as highlighted in the PR review here https://github.com/Expensify/App/pull/33966#discussion_r1444808394
To improve the DX it would be great to unify this logic and ideally simplify it if possible.
@koko57

@koko57 are there any next steps for this one?

First I would identify how much of the code from here https://github.com/Expensify/App/blob/4a7014b980c6dc50cab671525ba017ceec5a8bdd/src/libs/OptionsListUtils.js#L512-L542 (it's in createOption not getOption now) and here https://github.com/Expensify/App/blob/3ee24ec7868be996c78e1ae8097899ebdf33a709/src/libs/SidebarUtils.ts#L326-L433 can be shared and moved out to shared util function. I started back then with moving the logic for getting last actor displayName to getLastActorDisplayName function. I'm also still thinking that maybe it would be good to create a doc with alternateText examples for each type of the chat for both Sidebar and Search Page. But it's something that I'd definitely leave after all higher-priority issues are done 🙂

ok, I agree! I still remember and will remember of this one. We can come back to this one later 🙂


Adding CoreText design strategy document

:shipit:

:shipit:

@mnithish You can by-pass CI build for doc only change.


Save and continue surrounded by scrollbars

Hello,
I can make a small update (PR) to the UI if it is ok:

I think the button should

not be surrounded by scrollbars
responsive or at least keep the size of the right panel
should not have a border

Something like:

It is ok?

Yes, that sounds fine. Thanks

Why on earth would this be the case!?! But yes please let's fix that. It's awful.

@matryer - apologies, I thought these were comments in my GopherJS version of this repo (https://github.com/myitcv/gopherize.me)!!
@bgadrian - please ignore my responses; I defer entirely to @matryer


[Suggestion] Nerf for OP Weapon

With the mod "Mahou Tsukai", you can get a sword which has interesting stats (Morgan).
The damage cap for this Sword is 640k and you can increase the damage with killing villagers/baby villagers.
As it is now, its pretty easy to farm this (you need 64 nether stars to increase the cap to 640k), throw an enchanted weapon in some
sketchy sea and get the white version of the sword (Caliburn (which should also be nerfed in some way)), kill your best friend (tamed dog) to transform it into Morgan.
My Suggestion would be to change the config so that you need Choombium ingots or something else to increase that cap, otherwise it is way too op.

Thank you, will check it out.


After signing with eth_sign button in example.walletconnect.org, valid = false is shown

Godammit! Ok I'll have another look


Determine project criteria (what are we building)

When we know what we want to do, we should work on creating the USER STORY and ACCEPTANCE CRITERIA in the README, just to get a starting point.

IDEA: Creating a webapp that allows the user to search for a show and the webapp returns the streaming platform the show is available on


Raven_Client#user_context() no longer accepts null as of 1.6.0

This change in sentry-php 1.6.0 means that Raven_Client#user_context() no longer accepts null as the first argument. Passing null now generates a PHP Warning because the null value is passed to array_merge().
I've filed the issue against sentry-php here because it's a backward-compatibility break, but perhaps we should consider only passing arrays to that method from now on. The problematic line in RavenHander is here.

Been fixed in 1.6.1 of sentry I believe so closing this.


faster sharing-aware cost extraction

This:
(a) speeds up the current greedy extraction, and
(b) adds a faster extraction based on the code of @Bastacyclop & @mwillsey
In particular, changing the hashmap library to the rust standard collection reduces the runtime of the greedy extraction from 195 seconds to 47 seconds on my machine using all the test cases in main along with those in the open PRs:
https://github.com/TrevorHansen/extraction-gym/tree/main/data
This PR also adds a new extractor that takes about 9 seconds. It's based on the greedy extractor in #8 combined with the simple extractor in main. This doesn't produce the same results though as the current greedy extractor:
Loaded 422 jsons.
extractors: ['faster-greedy-dag', 'greedy-dag']
data/tensat/nasneta_acyclic.json<PHONE_NUMBER>6670.953<PHONE_NUMBER>5541.84
data/tensat/nasrnn.json 1158.6070294405508<PHONE_NUMBER>824966
data/egg/math_simplify_add.json 3 7
Cummulative time for faster-greedy-dag: 8839ms
Cummulative time for greedy-dag: 47155ms
faster-greedy-dag / greedy-dag
geo mean
tree: 0.9970
dag: 1.0002
micros: 0.9750
quantiles
tree:   0.4286, 1.0000, 1.0000, 1.0000, 1.2447
dag:    0.9957, 1.0000, 1.0000, 1.0000, 1.0225
micros: 0.0910, 0.5888, 1.0630, 1.5546, 3.0305

I think you get different answers depending on the order in which you visit the nodes.
I'm happy to clean this up as required.

Oh interesting. I think this is implying that there are a couple heavy hitters in terms of time spent in extraction. The geometric mean reports that this code is about as fast, but in absolute time it's much faster. Any idea what's going on there?

Oh interesting. I think this is implying that there are a couple heavy hitters in terms of time spent in extraction. The geometric mean reports that this code is about as fast, but in absolute time it's much faster. Any idea what's going on there?

Yes, Max, you're right about that. With the 211 inputs, these 4 problems provide about 95% of the time improvement:

file
faster greedy dag extractor (ms)
old extractor with std hashmap (ms)

data/tensat/nasrnn_acyclic.json
312
2,560

data/tensat/nasneta.json
1,392
15,290

data/tensat/nasneta_acyclic.json
2,602
17,613

data/tensat/nasrnn.json
3,163
8,904

---------------------------------
---------------------------
--------------------------

total
7,469
44,367

The other 207 problems take 1.3 seconds to be solved by the new extractor and 2.8 seconds for the old extractor. So there are a lot more easy problems than hard problems, which hides the improvement in the geometric average.

Awesome, thanks for the PR! Do you happen to have additional benchmarking data as well? As it is, it's quite hard to actually see the benefit of cost-sharing extraction, since few of the benchmarks seem to have it (or at least not that we have found).

Awesome, thanks for the PR! Do you happen to have additional benchmarking data as well? As it is, it's quite hard to actually see the benefit of cost-sharing extraction, since few of the benchmarks seem to have it (or at least not that we have found).

Yes, it makes sense that you'd like more benchmarks that show the benefit of sharing-aware extraction given that it's so expensive to undertake. I'll make some, but will be slow, probably 6 weeks before I can them ready.


Allow alternate pom file

/test jvm-build-service-in-repo-apicurio-e2e

/test jvm-build-service-in-repo-apicurio-e2e

/retest

/retest

This will need https://github.com/redhat-appstudio/jvm-build-service/pull/349 to fix the tests.

/test jvm-build-service-in-repo-apicurio-e2e

This will need #349 to fix the tests.

Rebased and fixed NPE.

/test jvm-build-service-in-repo-apicurio-e2e

/test jvm-build-service-in-repo-apicurio-e2e

protobuf builds now


Upgrade flow

Have separated out the the creation flow from upgrade - this is the upgrade flow only @summikhan11

https://xd.adobe.com/view/24cad77c-7eb9-4623-a2dc-edf64b9e4743-7199/

Don't think this is relevant anymore. @antuz123 to confirm.


Upgrade to bevy 0.11

Any ongoing work with upgrading to bevy 0.11?

No, I expect to upgrade it this weekend

It's done! Enjoy!

Working great! Thanks 🙏


typo in config.yaml

Change CSINode version from v1 to v1beta1.
Closes #122.

OK, thanks for checking.


fix: client.audio.transcriptions.create() return type hint errpr

fix: #1633
I referred to the method client.chat.completions.create and used @overload to solve this problem, but I haven't added the docstring yet.
I want to provide a draft first to see if this modification is acceptable.

Thanks for the PR! We fixed this separately in https://github.com/openai/openai-python/pull/1755


Use alembic CLI directly

With the following patch:
diff --git a/ocdskingfisherviews/migrations/env.py b/ocdskingfisherviews/migrations/env.py
index 504dc9e..7c17d9d 100644
--- a/ocdskingfisherviews/migrations/env.py
+++ b/ocdskingfisherviews/migrations/env.py
@@ -1,8 +1,12 @@
 from __future__ import with_statement

+import os
+import sys
+
 from alembic import context
 from sqlalchemy import engine_from_config, pool

+sys.path.append(os.path.dirname(os.path.dirname(os.path.dirname(os.path.realpath(__file__)))))
 from ocdskingfisherviews.config import Config

 # this is the Alembic Config object, which provides

We can just run alembic from within the ocdskingfisherviews directory (so that it sees alembic.ini), or run alembic -c ocdskingfisherviews/alembic.ini.
This is simpler than writing three commands to wrap the alembic command…

This also means less work if #70 proceeds.


Tab component with icon is not center because if width 100%

<Tab                   label="Home"                   value="/home"                   icon={<HomeIcon />}                 />
If we use Tab with icon it still is on the left because of width 100%.

width: 100%

no width
I think this PR https://github.com/mui-org/material-ui/pull/13230 broke it.
Any solution?

@rainstormza Please provide a full reproduction test case. This would help a lot 👷 .
A live example would be perfect. This codesandbox.io template may be a good starting point. Thank you!

@oliviertassinari update codesandbox.

@rainstormza Thank you! I'm sorry for the regression it's introducing, I wish we had a better way to solve the IE11 issue. You should  be able to work around the problem like this:
  overrides: {
    MuiTab: {
      wrapper: {
        flexDirection: "row",
+       width: "auto"
      },
      labelIcon: {
        minHeight: "48px"
      }
    }
  }


Update dependency org.reflections:reflections in dependencyManagement of quarkus-camel-bom

In quarkus-camel-bom currently version 0.9.12 of org.reflections:reflections is being used. This has a known issue which I am suffering now (https://github.com/ronmamo/reflections/issues/273). Are you planning for updating this in the dependency management of quarkus-camel-bom at some point in time?

Thanks for the report, @albert0815.
Is the https://github.com/ronmamo/reflections/issues/273 issue triggered by Camel code? If so, which extension?
camel-quarkus-bom gets the version of org.reflections:reflections via imported io.debezium:debezium-bom:1.6.1.Final, line 502.
So, ideally the fix should go there.
As a quick workaround, you can add the following before the BOM imports in your pom.xml:
...
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.reflections</groupId>
        <artifactId>reflections</artifactId>
        <version>0.10.2</version>
      </dependency>
      <!-- BOM imports here ... -->
    </dependencies>
  </dependencyManagement>
...

Thanks for the hint about the workaround, this is how I solved this for now. Nevertheless I thought it would be useful to also have it updated in the source. And I assumed source would be here, but that seems wrong :). Somehow I can't create an issue in the debezium repo. Not sure whether you want to keep it here or close it, if this is not something which you can deal with this is fine for me. Thanks for letting me know!

You can file an issue for Debezium here https://issues.redhat.com/projects/DBZ


Unable to place order

Current behavior

Clicking place order on latest develop results with an error in console:
 config__WEBPACK_IMPORTED_MODULE_1__.entities.uniqueEntityId is not a function

The order does not get placed.

Expected behavior

You can place an order by hitting place order button on checkout
Steps to reproduce the issue

add something to cart
try to place order

Repository

Latest develop: b3a61bc6b182af7e0b26ab67b9d4703d1e7492cf
Can you handle fixing this bug by yourself?

[x] YES
[ ] NO

Which Release Cycle state this refers to? Info for developer.
Pick one option.

[x] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
[ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
[ ] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

Browser: Chrome 73
OS: Ubuntu 18 LTS
Node: 10.x
Code Version: develop - b3a61bc6b182af7e0b26ab67b9d4703d1e7492cf

Additional information

Problem solved

Problem solved

How you got the solution ? for me its still there I am not able to place order event in cash on delivery


convert to new override syntax

This is the result of running
../meta-poky/scripts/contrib/convert-overrides.py .
as of meta-poky commit 86ae0ef3da. The meta-poky gatesgarth branch, as
of commit f2d2136dbb, accepts : as an alias for _, so this should
still be gatesgarth compatible.

@Villemoes thanks for doing this.
Did you run some tests on the result?

Sorry, no, this was more of way to start a discussion - I plan to include meta-homeassistant in a BSP based on honister, and this is a necessary first step to even get anything to build against honister (aside from the obvious layer compatible update). I should probably just create a 'honister' branch in my fork and work on that until I have something that builds.

@Villemoes As a remark I suggest using the dunfell branch as a starting point. It's the most up do date one. Master hasn't been touched in more than a year.

@Villemoes As a remark I suggest using the dunfell branch as a starting point. It's the most up do date one. Master hasn't been touched in more than a year.

Thanks. FWIW, the branch https://github.com/Villemoes/meta-homeassistant/tree/honister now builds against meta-poky honister, but I have yet to do some on-target testing.


[Additional Parameter Request] Codeunit 5760 Whse.-Post Receipt - OnBeforeTransLineModify

Hi Team,
In codeunit 5760 we need possibility to have additional checks in the procedure InitSourceDocumentLines. Standard publisher would suit us if it had additional standard parameter WhseRcptHeader type record. OnBeforeTransLineModify would be perfect solution:

[IntegrationEvent(false, false)]
local procedure OnBeforeTransLineModify(var TransferLine: Record "Transfer Line"; WhseRcptLine: Record "Warehouse Receipt Line"; var ModifyLine: Boolean; WhseRcptHeader: Record "Warehouse Receipt Header")

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


spec: pod and mount namespace

The spec states that the shared context for a pod includes the mount namespace. I am not sure what exactly it means given that each application runs in its own chroot and mount points can only shared using explicit bind statements. Shouldn't the spec drop the mount namespace from the shared context?
Also, it is not clear what is the exact behavior of a pod volume with kind=empty that is mounted for several applications. The specs states that writes go to the app's chroot which I read as implying that each app gets its own volume and these are not shared. Or is the intention that such volume is shared but its exact location on the host is implementation-dependent?

I am not sure what exactly it means given that each application runs in its own chroot and mount points can only shared using explicit bind statements. Shouldn't the spec drop the mount namespace from the shared context?

I have actually debated this myself, it might be easier to move to the way Kubernetes describes it which is just that they must be able to share certain volumes. I think there is an issue somewhere for that...

Also, it is not clear what is the exact behavior of a pod volume with kind=empty that is mounted for several applications. The specs states that writes go to the app's chroot which I read as implying that each app gets its own volume and these are not shared. Or is the intention that such volume is shared but its exact location on the host is implementation-dependent?

This is https://github.com/appc/spec/issues/183. Feel free to add some thoughts or put up a proposal there (I'm finding that PRs attract more robust discussion+progress than open issues ;-)

reference: https://github.com/GoogleCloudPlatform/kubernetes/pull/4701#discussion_r25125656

I am fine updating the language to say they can share volumes and remove the mount namespace thing.

addressed in #371


[BUG]

Library name and version
Azure.ResourceManager.Kusto <IP_ADDRESS>
Describe the bug
When accessing the principals using the code from
https://github.com/Azure/azure-sdk-for-net/blob/Azure.ResourceManager.Kusto_1.3.0/sdk/kusto/Azure.ResourceManager.Kusto/samples/Generated/Samples/Sample_KustoDatabasePrincipalAssignmentCollection.cs
hitting the exception
System.FormatException
HResult=0x80131537
Message=One of the identified items was in an invalid format.
Source=System.Text.Json
StackTrace:
at System.Text.Json.ThrowHelper.ThrowFormatException()
at System.Text.Json.JsonElement.GetGuid()
at Azure.ResourceManager.Kusto.KustoDatabasePrincipalAssignmentData.DeserializeKustoDatabasePrincipalAssignmentData(JsonElement element)
at Azure.ResourceManager.Kusto.KustoDatabasePrincipalAssignmentCollection.b__10_1(JsonElement e)
at Azure.Core.PageableHelpers.PageableImplementation`1.d__17.MoveNext()
There is no way to look at what row is causing the data or skipping that row and proceeding ahead. The specific issue seem to be other places when some guid is expected and is null, but is there a workaround?
Expected behavior
Reading the principals using the collection should provide the enumerator with all the list of users
Actual behavior
FormatException is getting thrown after the first user. First user is myself. The remaining users are not showing up or enumerator is not forwarding as the next entry is failing deserialization.
Reproduction Steps
`
ResourceIdentifier kustoDatabaseResourceId = KustoDatabaseResource.CreateResourceIdentifier("6c6bfab7-262d-4277-bc68-ec0fd783ba1e", "PPECommandAndControl", "ppesimselfkusto", "Logs");
        KustoDatabaseResource kustoDatabase = client.GetKustoDatabaseResource(kustoDatabaseResourceId);
       KustoDatabasePrincipalAssignmentCollection collection = kustoDatabase.GetKustoDatabasePrincipalAssignments();
        foreach (KustoDatabasePrincipalAssignmentResource item in collection.GetAll())
        {
            KustoDatabasePrincipalAssignmentData resourceData = item.Data;
            Console.WriteLine($"Succeeded on id: {resourceData.Id}");
        }

`
Running the above code is throwing exception
Environment
Reading principles from Kusto database

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

I have the same question as mentioned in this thread. Even I'm getting the below exception while running
Message:  System.FormatException : One of the identified items was in an invalid format. Stack Trace:  ThrowHelper.ThrowFormatException() JsonElement.GetGuid() KustoDatabasePrincipalAssignmentData.DeserializeKustoDatabasePrincipalAssignmentData(JsonElement element) KustoDatabasePrincipalAssignmentCollection.b__9_1(JsonElement e) PageableImplementation`1.GetAsyncEnumerator(CancellationToken cancellationToken)+MoveNext() Boolean>.GetResult()
I have updated Azure.ResourceManager.Kusto to 1.5.1 from 1.4.0 but I see the issue in newer version too. PR reference: Pull request 9235419: [CG] Migrate E2E to Azure.ResourceManager.Kusto and Azure.ResourceManager.Kusto.Models - Repos (visualstudio.com) Line 142. I think the FormatException is thrown when I try to access existingPrincipalAssignment.Data.DatabasePrincipalId
The issue persists and I can repro in my local dev box.

According to the screenshot and error message, the problem may be caused by the assignment of parameters. However, I am not sure what parameters you passed when calling this method, so it is difficult for me to determine whether the error is caused by the parameters. But according to my test results, there seems to be no problem with the SDK method itself when using regular parameters. So for now, we can only assume that the problem is caused by incorrect parameter passing.


Add templating to initContainer and sidecarContainer

This adds the ability for users to use templating within the initContainers and sidecarContainers.
The following changes have been made:

renames extraDeploy.render helper function to tplRender
removes multiple initContainer keys in deployment when initContainers is specified while using rclone backups
uses tplRender function to process initContainers and sidecarContainers

I created this MR because I was wanting to add minecraft-prometheus-exporter as a sidecar container and use templating functions to use the chart's rcon secret as an env variable.

Sorry about that, chart version bumped


Icon widget has unexpected top padding in web release at mobiles (both Ios and Android)

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
Container(decoration: BoxDecoration(color: Colors.red), child: const Icon(Icons.save))
Build web-release and open it in browser at mobile.
Expected results
Icon inside red container without any paddings.
Actual results
Icon with padding on the top inside red container.
upd: Google Icons has their own padding (empty space) around Icon. So there is no padding at the bottom and 2x padding at the top.
Code sample
Code sample
Container(decoration: BoxDecoration(color: Colors.red), child: const Icon(Icons.save))

Screenshots or Video

Screenshots / Video demonstration

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
 flutter doctor -v
[√] Flutter (Channel stable, 3.10.6, on Microsoft Windows [Version 10.0.19044.1288], locale ru-RU)
    • Flutter version 3.10.6 on channel stable at C:\ProgramData\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision f468f3366c (2 days ago), 2023-07-12 15:19:05 -0700
    • Engine revision cdbeda788a
    • Dart version 3.0.6
    • DevTools version 2.23.1

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
    • Android SDK at C:\Users\Andreus\AppData\Local\Android\sdk
    • Platform android-33, build-tools 33.0.1
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Community 2022 17.4.3)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.4.33205.214
    • Windows 10 SDK version 10.0.22000.0

[√] Android Studio (version 2021.3)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)

[√] VS Code (version 1.74.2)
    • VS Code at C:\Users\Andreus\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.60.0

[√] Connected device (3 available)
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.19044.1288]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 114.0.5735.199
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 114.0.1823.67

[√] Network resources
    • All expected network resources are available.

• No issues found!

Hi @AndyProtech
Although I don't see the issue from your screenshot (perhaps you uploaded wrong demo?), I see it from my side on stable channel. But this issue seems to have been fixed on the latest master channel as I cannot reproduce it there.
Please try running app again on the latest master channel and confirm if this issue is fixed.
flutter channel master
flutter upgrade

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.10.6, on macOS 13.0.1 22A400 darwin-x64, locale en-VN)
    • Flutter version 3.10.6 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision f468f3366c (5 hours ago), 2023-07-12 15:19:05 -0700
    • Engine revision cdbeda788a
    • Dart version 3.0.6
    • DevTools version 2.23.1

[✓] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-33, build-tools 32.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E222b
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.80.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.68.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 13.0.1 22A400 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 114.0.5735.198

[✓] Network resources
    • All expected network resources are available.

• No issues found!

[!] Flutter (Channel master, 3.13.0-3.0.pre.91, on macOS 13.0.1 22A400 darwin-x64, locale en-VN)
    • Flutter version 3.13.0-3.0.pre.91 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 5a866a031f (3 hours ago), 2023-07-16 17:36:30 -0700
    • Engine revision 683087731f
    • Dart version 3.1.0 (build 3.1.0-315.0.dev)
    • DevTools version 2.25.0
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 32.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-33, build-tools 32.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14E222b
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.80.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.68.0

[✓] Connected device (3 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D • android-arm64  • Android 11 (API 30)
    • macOS (desktop)  • macos            • darwin-x64     • macOS 13.0.1 22A400 darwin-x64
    • Chrome (web)     • chrome           • web-javascript • Google Chrome 114.0.5735.198

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

Hi @AndyProtech Although I don't see the issue from your screenshot (perhaps you uploaded wrong demo?), I see it from my side on stable channel. But this issue seems to have been fixed on the latest master channel as I cannot reproduce it there.
Please try running app again on the latest master channel and confirm if this issue is fixed.
flutter channel master
flutter upgrade

flutter doctor -v (stable and master)

I have latest stable version installed (you could see this in Flutter Foctor output.
I made better example for you.

Your flutter doctor above is stable release (I also see the issue on this version). You should switch to master channel as I mentioned above comment and check (as I see the issue is fixed)

Your flutter doctor above is stable release (I also see the issue on this version). You should switch to master channel as I mentioned above comment and check (as I see the issue is fixed)

Thank you for the answer


babel-loader dependency issue

Windows Env:
npm: 8.4.1
node: 17.5.0
Steps to reproduce:

npm install
npm start

I am planning to update the setup to CRA v5 or Vite.js at some point.
Until then, you can try to bypass the error by adding SKIP_PREFLIGHT_CHECK=TRUE to your .env file as suggested in order to make it work.

Is there any update here? I have tried all of the steps in the output. And changing the .ENV does not work for me. I have also tried adding babel-loader and babel-eslint as optional dependencies in the package.json?

Hi! I am also having the same issue. I have setup the SKIP_PREFLIGHT_CHECK=true in .env file however I am getting types error. How can I resolve this issue?

I wanted to mention that you guys need to use yarn install instead of npm install

@andreycruz16
My two cents on this, I was also facing the same issue, then I see one of the log messages during this process is exactly this  ../../../package.json having no license field. I was like..... wait whattttt ? if I am running yarn start from root dir in this project why app is finding package.json 3 levels above ? then when I looked into my directories, I found I have node_modules, package.json, yarn.lock. I deleted them and performed these steps again.

rm -rf node_modules yarn.lock
yarn install
yarn start

I could overcome the issue. However, I am still unable to run app successfully, its related to another issues on this project, looking into it.


A tenant owner can delete Storage/Ingress Classes

What's wrong
Giving storage/ingress classes access to the tenant owner, he can delete/modify them. That's could be an issue in case the storage/ingress class belongs to another tenant too.
Hot to reproduce

As cluster admin, create a storage/ingress class and assign it to a tenant

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: rook-retain
  labels:
    name: rook-retain
provisioner: rook
reclaimPolicy: Retain

As cluster admin, create a tenant and assign the storage class to it

apiVersion: capsule.clastix.io/v1alpha1
kind: Tenant
metadata:
  name: oil
spec:
  owner:
    kind: User
    name: alice
  storageClasses:
    allowed:
    - rook-retain
    allowedRegex: ""

As tenant owner, Alice can get the storage class

$ kubectl get sc
NAME          PROVISIONER   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
rook-retain   rook          Retain          Immediate           false                  4h7m

Alice can delete the storage class
$ kubectl delete sc rook-retain
storageclass.storage.k8s.io "rook-retain" deleted

@prometherion i can fix it in the PR #91.
Check request.Method, if isn't GET - fallback to impersonateHandler and return. WDYT?

@prometherion @MaxFedotov this issue brings to review the current approach for this feature.
An alternative approach would be:

in a shared scenario, where multiple tenants share nodes, storage/ingress classes, the tenant owner is not allowed to get/list/delete/patch any shared resource. It does make sense, imho.

in the bring-your-own-device scenario, with dedicated nodes, storage/ingress classes, by default, tenant owners can get/list/delete/patch dedicated resource. It's responsibility of the cluster admin to assign dedicated resources to the tenants. In such case, there are no shared nodes, storage/ingress classes between tenants even if multiple tenants belong to the same owner, e.g. Alice.

This approach simplify the model without needing to add additional labels as
capsule.clastix.io/enable-node-listing
capsule.clastix.io/enable-node-update
capsule.clastix.io/enable-node-deletion

and make the usage more clear to the users.
Also we have to take care of RBAC:
$ kubectl auth can-i get sc/rook-retain
Warning: resource 'storageclasses' is not namespace scoped in group 'storage.k8s.io'
no - RBAC: clusterrole.rbac.authorization.k8s.io "capsule-tenant:argoproj.io" not found

$ kubectl get sc/rook-retain
NAME          PROVISIONER   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
rook-retain   rook          Retain          Immediate           false                  15m

A bit confusing, isn't?

Honestly, I would go for the additional labels, so capsule.clastix.io/enable-{storageclass,ingressclass}-{listing.update,deletion}: annotations are not cool, we all know, but it's good enough for the current status of Capsule itself.
Regarding RBAC, you're totally right: it's absolutely confusing, but I'd track this in another issue and plan the implementation for the next release cycle, 0.1.0 is coming.

@prometherion i can fix it in the PR #91.
Check request.Method, if isn't GET - fallback to impersonateHandler and return. WDYT?

Yes, just open a new PR pointing to this issue to keep track of all the implementations :)

@prometherion we're specifying permissions, i.e. workaround RBAC with annotations. Is there any better way?

@prometherion just an update on the RBAC. After a deep dive into the issue, noted we get the same behaviour by pointing the kubectl to APIs server without going through the capsule-proxy
$ kubectl auth can-i get namespace/oil-development
Warning: resource 'namespaces' is not namespace scoped
no

$ kubectl get namespace/oil-development
NAME              STATUS   AGE
oil-development   Active   18h

The reason is that a SelfSubjectAccessReview is performed against the APIs server using the current namespace, e.g. that one set in the kubeconfig file:
{
   "kind":"SelfSubjectAccessReview",
   "apiVersion":"authorization.k8s.io/v1",
   "metadata":{
      "creationTimestamp":null
   },
   "spec":{
      "resourceAttributes":{
         "namespace":"default",  // <-- note here
         "verb":"get",
         "resource":"namespaces",
         "name":"oil-development"
      }
   },
   "status":{
      "allowed":false
   }
}

In this case, we got a negative answer because no permissions in the default namespace for Alice
{
   "kind":"SelfSubjectAccessReview",
   "apiVersion":"authorization.k8s.io/v1",
   "metadata":{
      "creationTimestamp":null,
      "managedFields":[]
   },
   "spec":{
      "resourceAttributes":{
         "namespace":"default",
         "verb":"get",
         "resource":"namespaces",
         "name":"oil-development"
      }
   },
   "status":{
      "allowed":false
   }
}

Changing the namespace
$ kubectl auth can-i get namespace/oil-development -n oil-development
Warning: resource 'namespaces' is not namespace scoped
yes

In this case, the SelfSubjectAccessReview is performed against the APIs server using the current namespace
{
   "kind":"SelfSubjectAccessReview",
   "apiVersion":"authorization.k8s.io/v1",
   "metadata":{
      "creationTimestamp":null
   },
   "spec":{
      "resourceAttributes":{
         "namespace":"oil-development", // <-- note here
         "verb":"get",
         "resource":"namespaces",
         "name":"oil-development"
      }
   },
   "status":{
      "allowed":false
   }
}

Having this time a positive answer:
{
   "kind":"SelfSubjectAccessReview",
   "apiVersion":"authorization.k8s.io/v1",
   "metadata":{
      "creationTimestamp":null,
      "managedFields":[]
   },
   "spec":{
      "resourceAttributes":{
         "namespace":"oil-development",
         "verb":"get",
         "resource":"namespaces",
         "name":"oil-development"
      }
   },
   "status":{
      "allowed":true,
      "reason":"RBAC: allowed by RoleBinding \"namespace:admin/oil-development\" of ClusterRole \"admin\" to User \"alice\""
   }
}

As conclusion, we do not have to fix this in capsule-proxy, just ask clarifications to the kubernetes community.

So, what do we do? The same thing with annotations as for nodes?

@MaxFedotov as short term solution I would say yes according to @prometherion suggestion. In the long term, I prefer to implement RBAC similarly we made with namespaces. This will require the involvement of the Capsule Operator itself (creating/assigning RBAC roles) and use the capsule-proxy only for filtering.
For example:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: storage-class-viewer
rules:
- apiGroups: [""]
  resources: ["storageclass"]
  resourceNames: ["rook-retain", "rook-delete"]
  verbs: ["get", "list", "watch"]

By using regular RBAC instead of annotations, it should be more understandable by end users, imho.


RenameVariables: Exclude variables from renaming

Closes #540
Exclude ${_} and ${\n} from renaming by default. Allow to configure variables that should have their case preserved using ignore_case parameter.
I'm still not sure - should I rename ${None}, ${true}, ${True}, ${False} etc to ${NONE}, ${TRUE}, ${FALSE}? Or ignore case for such built-in variables.

Codecov Report
Patch coverage: 100.00% and project coverage change: -0.02 :warning:

Comparison is base (bca7a32) 96.97% compared to head (8f05702) 96.96%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #543      +/-   ##
==========================================
- Coverage   96.97%   96.96%   -0.02%
==========================================
  Files          49       49
  Lines        4829     4840      +11
==========================================
+ Hits         4683     4693      +10
- Misses        146      147       +1

Impacted Files
Coverage Δ

robotidy/transformers/RenameVariables.py
97.51% <100.00%> (-0.27%)
:arrow_down:

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

I'm still not sure - should I rename ${None}, ${true}, ${True}, ${False} etc to ${NONE}, ${TRUE}, ${FALSE}? Or ignore case for such built-in variables.

I don't have a strong opinion here, but since they are somehow "global variables" (in a way they are accessible from anywhere), maybe they should be converted to uppercase to indicate that they are special?

I'm still not sure - should I rename ${None}, ${true}, ${True}, ${False} etc to ${NONE}, ${TRUE}, ${FALSE}? Or ignore case for such built-in variables.

I don't have a strong opinion here, but since they are somehow "global variables" (in a way they are accessible from anywhere), maybe they should be converted to uppercase to indicate that they are special?

Thats one way of looking at it, sounds fine. I can go with it and change it in the future if needed. It is currently converting all globalną variables to upper case so nothing will change. And since I have added parameter ignore_case user can on their own to ignore the variable from case convertion.


Cannot create a project in azure devops demo generator

Hi,
I am using the the devops test labs and while trying to create a project, I am getting the error that I do not have permission to create a project.
Can you help?

Hi, @rahagarwal Thank you for reaching us.
If the issue is related to permission, please try to get full permission to create a project or create your own organization and try it.
Thanks


Require a method with kwargs

Hello,
While trying the new support for callable structs (it works perfectly, thanks!), I found that methods with keyword arguments are not supported:
using RequiredInterfaces

abstract type CallableAbstract end

@required CallableAbstract begin
    (c::CallableAbstract)(; kwargs...)
end

throws an error: ERROR: LoadError: ArgumentError: Invalid required function!.
Is there a way to make it work?

Keywords are a bit tricky; the way they're handled by Julia is pretty internal, especially when it comes to required/optional keywords. For example:
julia> struct Foo end

julia> (f::Foo)(a; b=2, d, kwargs...) = "bar"

julia> using RequiredInterfaces; const RI = RequiredInterfaces
RequiredInterfaces

julia> RI.instancemethods(Foo, (Any,))
# 1 method for callable object:
 [1] (f::Foo)(a; b, d, kwargs...)
     @ Main REPL[2]:1

To a high-level inspection, the methods defined here all look the same, even though only d is required to be passed:
julia> Foo()(1)
ERROR: UndefKeywordError: keyword argument `d` not assigned
Stacktrace:
 [1] (::Foo)(a::Int64)
   @ Main ./REPL[2]:1
 [2] top-level scope
   @ REPL[5]:1

julia> Foo()(1; d=3)
"bar"

I don't think it's impossible to add, but this is likely a bit trickier and requires a bit of a redesign of how the checking for interface compliance is done.


Added methods for manage chat join requests

Hi, added some methods for closed chats

hi, would you mind to add tests for this feature?

@fabio-ivona add tests


Nightly release pipeline: add commit id

Is it possible to have a way to correlate the nightly releases to specific commits from this repository?
I'd like to know which commit corresponds the version I'm running
https://dotnet.myget.org/feed/fsharp/package/vsix/VisualFSharp/<IP_ADDRESS>31602

@smoothdeveloper, is this for debugging purposes? If #2675 is merged and the pdb files are packaged with the nightly builds, then they will contain the commit id. You should even be able to debug into the exact source code without having a local clone. That is the goal anyhow. Once nightly builds show up with source link enabled, I'll show how to get the commit id.

@ctaggart, thanks for the update, the main purpose was to know which commit the nightly I'd install is made from (so I know which feature is there or not & else).
Having ability to debug and source link as extra side effects is very nice!

Hmmm. I'm not sure we'd really do this anymore given that the VF# tools are quite stable now, and nightly usage is down significantly as a result. Each build is seeing 0-5 installs which is quite small.


Pg_restore directory format still not working -5.1.6

Once again thanks for the great tool. I cannot restore a Postgres database using restore option. I don't recollect this feature working.
Steps

Select  DB/ Tools/Restore
Format  : Directory
Backup File :  Click browse button
Dialog-box opened does not support selecting a directory

Also, when I go the route of copying directory path into Backup file text-field and click start I am getting the error  IO Error: Utility 'pg_restore.exe' not found in client home 'C:\dbeaver\postgresql-x64-9.6'. This is strange as the pg_restore should not be within dbeaver path. Is the Postgres installation path configurable from within DBeaver?

This is similar to #4106 . Old client home configurations seems to be not working after upgrade. Workaround: add PG client home manually one more time (on connection edit properties page).
Problem with directory selection will be solved in the next version, thanks for noticing.

Native client selector was fixed, PG locally installed client home resolution was fixed.
Please check this in EA version (https://dbeaver.io/files.ea)


[boost-atomic] Build error

ackage: boost-atomic:arm64-osx -> 1.79.0
Host Environment

Host: arm64-osx
Compiler: AppleClang <IP_ADDRESS>30022
vcpkg-tool version: 2023-06-07-25da717d8191c36743f0f8a25eecfa9ff6f8d195
vcpkg-scripts version: 85c222bc3 2023-06-09 (11 hours ago)

To Reproduce
vcpkg install
Failure logs
-- Using cached boostorg-atomic-boost-1.79.0.tar.gz.
-- Cleaning sources at /Users/sh00479ml/Documents/projects/bybit/source/C/ClionProjects/HelloWorld/deps/vcpkg/buildtrees/boost-atomic/src/ost-1.79.0-8319493156.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /Users/sh00479ml/Documents/projects/bybit/source/C/ClionProjects/HelloWorld/deps/vcpkg/downloads/boostorg-atomic-boost-1.79.0.tar.gz
-- Using source at /Users/sh00479ml/Documents/projects/bybit/source/C/ClionProjects/HelloWorld/deps/vcpkg/buildtrees/boost-atomic/src/ost-1.79.0-8319493156.clean
CMake Error at /Users/sh00479ml/Documents/projects/bybit/source/C/ClionProjects/HelloWorld/deps/installed/arm64-osx/share/boost-build/boost-modular-build.cmake:108 (vcpkg_cmake_get_vars):
  Unknown CMake command "vcpkg_cmake_get_vars".
Call Stack (most recent call first):
  buildtrees/versioning_/versions/boost-atomic/ba96ddc357592c3644f666fbc68d052ad3f0f397/portfile.cmake:17 (boost_modular_build)
  scripts/ports.cmake:147 (include)

Additional context
vcpkg.json
{
  "$schema": "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
  "name": "my-project",
  "version-string": "2023.3.25",
  "builtin-baseline": "91dd61bd441a68b4017b61011d0350b2e6aeeccf",
  "dependencies": [
    "benchmark",
    "gtest",
    "fmt",
    "gmp",
    "mpfr",
    "boost-uuid",
    "boost-lockfree",
    "boost-multiprecision"
  ],
  "overrides": [
    {
      "name": "abseil",
      "version": "20211102.1"
    },
        {
      "name": "boost-typeof",
      "version": "1.79.0"
    },
    {
      "name": "boost-uninstall",
      "version": "1.79.0"
    },
    {
      "name": "boost-unordered",
      "version": "1.79.0"
    },
    {
      "name": "boost-utility",
      "version": "1.79.0"
    },
    {
      "name": "boost-uuid",
      "version": "1.79.0"
    },
    {
      "name": "boost-variant2",
      "version": "1.79.0"
    },
    {
      "name": "boost-variant",
      "version": "1.79.0"
    },
    {
      "name": "boost-vcpkg-helpers",
      "version": "1.79.0"
    },
    {
      "name": "boost-winapi",
      "version": "1.79.0"
    },
    {
      "name": "mpfr",
      "version": "4.1.0#4"
    },
    {
      "name": "gmp",
      "version": "6.2.1#9"
    }
  ]
}

This issue hasn’t been updated in 3 month, if it is still an issue, please reopen this issue.


Endpoint customizer

This provides a UI in the frontend for testing and customizing the endpoint badge. This came out of a discussion in #2904.
This screen targets developers / service providers, though we could also consider extending this idea by adding a second page which is is nice, clean, and linkable, where service providers could send users in order to customize their badges.
Conflicts with #2906. The diff will clean up after #2907 is merged.

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @paulmelnikow!

  Generated by :no_entry_sign: dangerJS against 8e5c38c611e61dca9ec8b9ecb8eb857476392db1

This pull request introduces 3 alerts when merging 8e5c38c611e61dca9ec8b9ecb8eb857476392db1 into 89ee5d1cb185334e95e97a3d29d18af3f08f3c54 - view on LGTM.com
new alerts:

3 for Unused variable, import, function or class

Comment posted by LGTM.com

I'm confused by the discussion in #2904 and not entirely sure how that issue relates to this feature, but considering this in isolation, it seems like a useful feature :)

😀
Yea, that's a nice point.
I took this approach because it was easy, since all of the query string customization is handled in a tabular form:

Agree is nicer, though. I'll take a quick pass through and see what's involved.
It's bound to be a deeper refactor with a gnarlier diff. What do you think about merging this and then tackling that in a follow-on?

Have updated this post-Gatsby.

It's bound to be a deeper refactor with a gnarlier diff. What do you think about merging this and then tackling that in a follow-on?

Thoughts?


Just to note this feature is used in a few places

https://github.com/Microsoft/visualfsharp/blob/4394ee7d14653bfcd7d6a52868e4ca277bbc4f8f/src/fsharp/fsc.fs#L1928
Just to note this feature is used in a few places, the quotation compiler, I think the pickler that Eirik wrote might also use it, and Falanx too has a beta feature using this API.

@7sharp9 maybe send a PR to remove that comment?
probably if someone go ahead and remove that code because read that comment, will not search in issues.

Just to note this feature is used in a few places, the quotation compiler, I think the pickler that Eirik wrote might also use it, and Falanx too has a beta feature using this API.

FWIW I consider this an experimental part of FCS that may be removed in the future - it was added by Eirik for MBrace but they used a very different implementation path in the end.

Its used in Eiriks quotation compiler too from this entry point: https://github.com/eiriktsarpalis/QuotationCompiler/blob/master/src/QuotationCompiler/QuotationCompiler.fs#L129

Ah yes that was salvaged from that MBrace work.
Still, it's always been a bit out-of-scope for FCS, and no current use case in actively maintained F# IDE, documentation or script evaluation tooling, which are the three things that tends to keep FCS honest.

Im think Fantomas might also use that endpoint too.

Fantomas does not use this: https://github.com/fsprojects/fantomas/search?q=main1OfAst&unscoped_q=main1OfAst
I'll close this discussion; we don't have active plans to remove this


Update oci-java-sdk-objectstorage to 2.42.0

Updates com.oracle.oci.sdk:oci-java-sdk-objectstorage from 2.21.0 to 2.42.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.oracle.oci.sdk", artifactId = "oci-java-sdk-objectstorage" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.oracle.oci.sdk", artifactId = "oci-java-sdk-objectstorage" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #952.