BUG: solve_ivp inaccurate for piecewise-smooth system

Describe your issue.
When solving a simple piecewise-smooth system using the default configuration for solve_ivp (specifically rtol=1e-3 and atol=1e-6), the solution is significantly incorrect (on the order of 1e-2). I've compared the solution with a manual rk4 solver and as expected the solution quickly converges to the same oscillation, regardless of initial condition. Whereas solve_ivp produces two very different solutions even when the initial conditions differ by 1e-7, and both of these solutions are completely wrong.
The output from solve_ivp can be made accurate by decreasing the tolerances, but I would have thought that the default values should be enough to get a reasonably accurate solution. It seems that the solver is not taking sufficiently small step sizes in order to correctly catch the transition in the ODE. I also tried adding in an event function with the expectation that the step size would correctly shrink close to this transition but it doesn't seem to effect the accuracy, just outputs the time of the event.
The attached code solves the same ODE with manual rk4 and solve_ivp. The rk4 solutions converge correctly despite different initial conditions, and the solve_ivp solutions do not, despite very similar initial conditions.
Thanks
Reproducing Code Example
import numpy as np
from scipy.integrate import solve_ivp
import matplotlib.pyplot as plt

t = np.linspace(0,300,3001)

def dy(t, y):
    x = 0.02 * np.sin(t) + 0.4
    if x >= y:
        b = 0.2
    else:
        b = 0.02
    return b * (x - y)

def rk4(t,y,h):
    k1 =  h*dy(t, y)
    k2 =  h*dy(t, y + k1/2)
    k3 =  h*dy(t, y + k2/2)
    k4 =  h*dy(t, y + k3)
    return (k1 + 2*k2 + 2*k3 + k4)/6

def solve_rk4(dy,t_span,y0,max_step):
    dt = t_span[1]-t_span[0]
    sol = np.empty_like(t_span)
    sol[0] = y0
    sub_step_n = int(dt/max_step)
    for i,t in enumerate(t_span[:-1]):
        yi = sol[i]
        for j in range(sub_step_n):
            yi += rk4(t,yi,max_step)
        sol[i+1] = yi
    return sol

def event(t,y):
    return 0.02 * np.sin(t) + 0.4 - y

sol1 = solve_ivp(dy, t[[0,-1]], (0.42,), events=event, t_eval=t, rtol=1e-3, atol=1e-6).y.squeeze()
sol2 = solve_ivp(dy, t[[0,-1]], (0.4200001,), events=event, t_eval=t, rtol=1e-3, atol=1e-6).y.squeeze()
sol3 = solve_rk4(dy, t, 0.42, 0.1)
sol4 = solve_rk4(dy, t, 0.43, 0.1)
plt.plot(t,sol1,label='solve_ivp 0.42')
plt.plot(t,sol2,label='solve_ivp 0.4200001')
plt.plot(t,sol3,label='RK4 0.42')
plt.plot(t,sol4,label='RK4 0.43')
plt.legend()
plt.show()

Error message
NA

SciPy/NumPy/Python version information
blas_mkl_info:   NOT AVAILABLE blis_info:   NOT AVAILABLE openblas_info:     libraries = ['openblas', 'openblas']     library_dirs = ['/usr/local/lib']     language = c     define_macros = [('HAVE_CBLAS', None)]     runtime_library_dirs = ['/usr/local/lib'] blas_opt_info:     libraries = ['openblas', 'openblas']     library_dirs = ['/usr/local/lib']     language = c     define_macros = [('HAVE_CBLAS', None)]     runtime_library_dirs = ['/usr/local/lib'] lapack_mkl_info:   NOT AVAILABLE openblas_lapack_info:     libraries = ['openblas', 'openblas']     library_dirs = ['/usr/local/lib']     language = c     define_macros = [('HAVE_CBLAS', None)]     runtime_library_dirs = ['/usr/local/lib'] lapack_opt_info:     libraries = ['openblas', 'openblas']     library_dirs = ['/usr/local/lib']     language = c     define_macros = [('HAVE_CBLAS', None)]     runtime_library_dirs = ['/usr/local/lib'] Supported SIMD extensions in this NumPy install:     baseline = SSE,SSE2,SSE3     found = SSSE3,SSE41,POPCNT,SSE42,AVX,F16C,FMA3,AVX2,AVX512F,AVX512CD,AVX512_SKX,AVX512_CLX,AVX512_CNL,AVX512_ICL     not found = AVX512_KNL

Hi @liamwheen, thank you for reporting.
As you said solve_ivp is making some choices as to what should be the default values. Behind the scene it's calling things like solve_rk4. solve_ivp is simply a wrapper.
Changing default value is very tricky as backward incompatible. But if there are some parameters that are concerning and we should change without doubt, then we could consider it (after a deprecation period, depending on the exact case, etc.)
Do you have recommendations? Otherwise I am not sure there is anything to do here.

I would not consider this a bug as such. The hand-coded solver you have shown is a fixed-step solver whereas solve_ivp is an adaptive solver using an embedded error estimator so this is not an apples-to-apples comparison. If you set max_step=0.1 so that the solver takes at most the same size step as your fixed method, you get the same results. The mechanism for adjusting the step size has no knowledge that your RHS function has a piecewise definition so as long as the error is low it will start taking larger steps hence why it misses some of the dynamics when using the default arguments.

Thanks @j-bowhay, I will let you make the call here (feel free to close) 😃

I would argue for closing, the default values are battle tested and give good results for most problems. Of course, it is possible to construct examples to trip the solver up with these values but this example is a compelling enough reason to change them.

Great thanks 👍

OK that makes sense. Would it be feasible for the events function to help the solver with piecewise functions though? If the large step has changed the sign of the events function could/should it not then step back and more carefully solve around that point? I don't know how the process works but would have thought that the extra information could be incorporated into the variable step size method to be more robust to piecewise RHS.
Thanks for the quick response.

as long as the error is low it will start taking larger steps

It seems that all of the methods listed above (LSODA, RK45 etc) suffer from this for this particular ODE.
Does SciPy have any routine that can robustly handle an ODE like this by choosing appropriate stepsizes or is this class of problems out of scope unless max_step is used?
Either way perhaps the docs should mention this. The docs currently say about the methods:

If not sure, first try to run ‘RK45’. If it makes unusually many iterations, diverges, or fails, your problem is likely to be stiff and you should use ‘Radau’ or ‘BDF’

To me that gives the impression that the default method RK45 is robust but that the price for that robustness is that it is potentially slow and might fail (raise an exception?) rather than giving erroneous output as it seems to in this case.
I realise that it is difficult to define what "robust" means here because it would always be possible to contrive an example that would defeat any given solver but this is pretty well-behaved for a non-smooth system: it's 1D piecewise linear and has a globally attracting solution. If this example cannot be handled with the default parameter values then it's likely that many others cannot either.

@ev-br do you know more? (Apologies in advance as I am always pinging you on both integrate and interpolate and always forget which one you like better.)

It is worth noting that none of the non-stiff solvers in MATLAB give a reasonable solution to this ode with default arguments either. For the other questions, I would defer to an integrate regular

@Patol75 @nmayorov any thoughts?

Given that the RHS is discontinuous, I feel like it is a bit much to ask SciPy's solvers to properly deal with it out of the box. Something I have never quite understood is why the recommended method is RK45. I have always had the feeling that LSODA is more reliable than RK45, and it has the nice property of switching automatically between stiff and non-stiff integrators. In any case, it is perhaps important to emphasise how users should always check the convergence of their solutions manually. In the present case, it would be pretty obvious right away that the default rtol value is too high to capture the solution. Decreasing rtol progressively yields the expected convergence, and that is probably the best you can ask for.

Given that the RHS is discontinuous, I feel like it is a bit much to ask SciPy's solvers to properly deal with it out of the box.

Here the RHS is continuous but not continuously differentiable. In any case it is not smooth.
If the solvers are not expected to be able to handle non-smooth ODEs with default parameters and heuristics then perhaps that is worth mentioning in the docs. Or if there are other solvers that are better suited to that case then those could also be mentioned.
I agree that in general convergence should be checked in some way whether that's through tolerance or directly limiting step size. There just isn't really any discussion of these things in the docs:
https://docs.scipy.org/doc/scipy/reference/generated/scipy.integrate.solve_ivp.html

I have never quite understood is why the recommended method is RK45

Maybe it's a hangover from Numerical Recipes which (from memory...) described RK45 as the default goto method.
I think that the corresponding routines in Julia might default to LSODA. Note that solve_ivp with method='LSODA' still performs very poorly in this case though.

Any doc improvements are extremely appreciated and you folks seem to know what to say (moving this discussion in the doc basically.) 😃

I agree, let's reopen for a doc-only improvement summarising the discussion here: A) The default tolerance may not be suitable for certain odes (eg. non-smooth) and B) the convergence of the solution should always be checked. @liamwheen would you be interested in submitting a pr?

The issue is indeed in the discontinuities of the RHS (or its derivative). I am not aware of methods that can deal natively with that and, as far as I am aware, most integration methods are derived assuming a sufficiently differentiable RHS.
If a step of such a methodxontains such a discontinuity, then I guess an order 1 error is produced.
The only way out is to have one of the step exactly match the time of discontinuity.This can be done with events, albeit manually (i.e. restarting the integration multiple times, once at each discontinuity). This requires setting event.terminal=True, and restarting the integration as required from that point.
This can however be insufficient, as the event detection is done a posteriori, using the dense output (continuous extension) of the solution, which means that the method goes past this event and thus suffers from the discontinuity during the last step of each integration sequence. This can lead to a poor accuracy in the determination of the time of the event.
To solve this issue, one would need to iterate on the last step so that the last time point used by the method truly matches the event time. This however greatly complexities the solution process and defeats the purpose of having an easy-to-use integration library in my opinion.

There are several separate questions here:

Whether to change any defaults of solve_ivp (suggestion above seems to be no, or perhaps prefer LSODA but in any case that wouldn't help for the OP example).
Defining and documenting the limitations of solve_ivp in particular with the default algorithm and tolerances.
Making something more robust that can be used even if it not used by default.

Personally I know how to check the accuracy of an algorithm like this by doing what @liamwheen did: just write my own solver, make the step size small, use extra precision if needed etc. I find it easier to be confident that I am getting the errors right when I can see all the code that is being used. I think that for an easy-to-use integration library though it would be good to have an easy option for something that can be considered more reliable without needing to roll your own. Something like solve_ivp(..., slow_but_more_accurate=True) or solve_ivp(..., check_harder_for_inaccuracies=warn/error).
As for how to make something more robust I'm not sure. I have never looked into the details of how resizable timestep routines are typically implemented but I would have thought that it would not be too hard to add some more robust checking than solve_ivp currently has.
If you change the last lines of the OP script to:
plt.plot(t,sol1,label='solve_ivp 0.42')
plt.plot(t,sol2,label='solve_ivp 0.4200001')
plt.plot(t,sol3,label='RK4 0.42')
plt.plot(t,0.02 * np.sin(t) + 0.4,label='threshold', linewidth=0.5, color='black')
plt.xlim([0, 80])
plt.ylim([0.40, 0.43])
plt.legend()
plt.show()

Then you can get this plot showing the earlier part of the solutions and one of the solve_ivp curves almost immediately going wrong:

Here the black threshold line is the line such that when the solution is above that line it should have negative gradient and when the solution is below the line it should have positive gradient. The green RK4 line tracks this and slopes up when below the line and down when above the line.
The orange solve_ivp line goes wrong before even crossing the threshold and up until about t=40 it spends much of its time above the highest peaks of the threshold line. For about a third of that time it has the wrong sign of the derivative: it goes up when it should go down. An evaluation of the rhs function at one or two points on this line would immediately show that the gradient of the solution does not match the ODE very closely even when the solution curve is not close to the threshold line.

Just to repeat what I said above, all you need to do is to rerun the solver with tighter tolerances to check if the solution has converged. That is what an error estimator is for. This does not warrant an extra option in solve_ivp, but could indeed be explained in the documentation such that everyone is aware. The current problem could be used as a displayed example at the bottom of the documentation page to illustrate that solvers do not handle such a case out-of-the-box but do indeed converge when tolerances are decreased.

Just to repeat what I said above, all you need to do is to rerun the solver with tighter tolerances to check if the solution has converged.

I would just reduce the stepsize and verify the convergence that way. To me though the purpose of a function like solve_ivp is that it is supposed to try to figure out the step size for me without me needing to check convergence myself. If I have to check convergence by adjusting the tolerance then that's not really much better than specifying the step size and having to check convergence in that instead.
I realise that creating a universal solver that works in all cases and is never slow is impossible but that doesn't mean that there can't be room for aiming to satisfy different needs like:

give me something as accurate as you can
give me something usually accurate but without sacrificing performance for common cases that can be fast.
give me something fast but warn if it looks suspect
etc

The first of these "return most accurate possible" is what would be the most useful addition because you could use it as one check for the output of anything else.
Needing to translate those requirements into tolerance thresholds for solve_ivp and then test and tune those thresholds somewhat negates the purpose of having a function like solve_ivp from my perspective (rather than having an alternative function that allows direct control of everything like stepsize and other algorithm details but clearly and explicitly expects me to take full responsibility for the outcome).

That is what an error estimator is for.

I think that the error estimator here is not doing a very robust job of estimating the error in this case and I think that that is actually the root of the problem.

but could indeed be explained in the documentation such that everyone is aware

Yes, I think that is definitely worth doing.

In order to reduce the step size, you need to know its value in the first place. This is not something you can robustly determine prior to evaluating the target function. Setting an arbitrarily small step size is not helpful.
I do not think it is fair to say that the error estimator is failing at doing its job. It is doing what it can based on the tolerance that was supplied and the (discontinuous) nature of the function it is analysing.
Regarding the scenarios you describe, I would say the best case scenario is already the implemented default of solve_ivp. If you want something that can handle a larger variety of cases at the cost of execution time, just set atol=1e-9, rtol=1e-6 and pick a method that can handle stiff systems if necessary.

Here the solution plott is made with the dense output, we have no clue what the time steps actually are.it is likely that they are.much larger than those used by RK4.
Also the implementation of RK4 is wrong here, since the times for the evaluation of the RHS are all set to t in the RK4 function... Since this greatly affects the RHS, I am not even sure the plotted RK4 solution is anywhere close to the real solution... I can't try for myself yet, but I will try to have a look.

I think that the error estimator here is not doing a very robust job of estimating the error in this case

I do not think it is fair to say that the error estimator is failing at doing its job

I don't see how that's unfair. The error here is large and the job of the error estimator is to estimate that so that the step size can be reduced meaning that the final error is hopefully small. This case might be out of scope for what the error estimator is intended to handle but it seems clear that in this case the error estimator is giving a poor estimate of the error and that the method is then using overly large step sizes.

the implementation of RK4 is wrong here

True but it still gives qualitatively the correct result. The error from that will be measurable but is smaller than can be distinguished visually from the plot shown. Also as noted above reducing the tolerance from solve_ivp will give the same results (modulo small errors).

we have no clue what the time steps actually are. It is likely that they are much larger than those used by RK4.

They must be much larger. Pretty much any numerical stepper will give small errors for this ODE provided the step size remains say an order of magnitude smaller than the period of the sinusoid. That is because all solutions regardless of initial conditions converge exponentially towards a single globally attracting periodic solution so any small error will disappear over time.

I am not even sure the plotted RK4 solution is anywhere close to the real solution

It is close to the real solution. This ODE can be solved analytically where it is piecewise smooth and the solution parts joined together. It maybe looks more complicated than it is because of the piecewise nature but really it is just like $$y' = -b_{\pm}(y - f(t))$$
where $b_{\pm}$ is piecewise constant and the function $f(t)$ is in this case some sinusoid function. The solution should always converge exponentially towards the sinusoid except that it does so with one rate $b_-$ from below and another $b_+$ from above. The asymmetry between these rates means that it ends up looking like an asymmetric sinusoid as shown.

This could explain why you do not observe the correct signs the time derivative.

No, I think you misunderstand the point that I was making about the sign of the derivative. I don't mean to compare the orange solve_ivp solution with the green RK4 solution. The point is to compare the orange solve_ivp solution with the black curve that represents the function $f(t)$. We can see that the sign of the derivative is wrong without having any knowledge of the true solution.
The differential equation itself says that when the independent variable $y$ is greater than $f(t)$ the derivative $y'$ should be negative. In terms of the plot what that means is that whenever the orange curve is above the black curve it should be sloping downwards (as the green curve does). What it also means is that in principle it is not difficult to have a numerical routine that would be able to detect this error by comparing the gradient of the estimated solution with what the ODE says the gradient should be for any particular point in the estimated solution. Other approaches might be better but it is certainly not impossible that the error could be detected and controlled in this case.

Hi all, I think I'm experiencing a similar problem where I have an ODE with a piecewise source term and some of the steps are not correctly caught by the solvers (BDF, RK45, Radau).
If I understand correctly, I need to fiddle with events to capture the changes?

Hi all, I think I'm experiencing a similar problem where I have an ODE with a piecewise source term and some of the steps are not correctly caught by the solvers (BDF, RK45, Radau).
If I understand correctly, I need to fiddle with events to capture the changes?
EDIT: here's an example of my problem, the source is below and the solution (top) should increase when the source is non-zero The second step is missed here.

I think your ODE becomes stationary after the second peak, so the integrator will gradually increase its time step. The second peak actually occurs after the time step has been increased so much that the peak is completely missed by the solver. You may mislead by using t_eval. Set it to None and plot your solution with markers to see what steps it has made. Still, you must be somewhat unlucky here; if you use Runge-Kutta solvers (RK45, Radau...), they have multiple internal substeps. Having none of these substeps fall on the discontinuous part is somewhat unlucky in your case !
Most ODE solvers are meant to be used on a continuous RHS. If your RHS is piecewise continuous, you have to either cut your integration into multiple intervals where the RHS is continuous when you know the locations of the discontinuities, or use events to find these locations. At each discontinuity, you can restart the integration with the new RHS function. Otherwise you risk missing small discontinuities, or you will greatly decrease the efficiency of the solve id the integrator captures the discontinuity: either it will fail, or it will need to do unnecessarily small time steps around the discontinuity.


[Investigation] Read performance compared to JDBC

With some reports of a large difference between the connector and default spark JDBC method, investigate this.

In what scenarios is this true?
Scaling bad performance vs fixed overhead
Where in the code is responsible for this overhead/scaling?

Reason: Improves user experience if we can fix any perf issues and can improve adoption if we can show why migration to our connector improves perf

A set of optimizations was implemented since that issue was raised, and it is currently missing context. In case of any future performance concerns, please reopen with more details.


Configure rustfmt

The new config changes how dependencies are formatted at the top of the file.

This can be merged after running the formatter on the project. Many merge conflicts are expected. Therefore, do this when there are not a lot of PRs open.


Record value type lost when key type is generic

TypeScript Version:  4.1.0-dev.20200907
Search Terms:
Generic, Keys, Record
Code
type CustomRecord<Keys extends string> = Record<Keys, string>

function mapValues<Keys extends string> (entries: CustomRecord<Keys>): string[] {
  return Object.values(entries)
    .map((entry: string) => entry)
}

Expected behavior:
No error.
Actual behavior:
TypeScript gives the following error for the function given to map:
Argument of type '(entry: string) => string' is not assignable to parameter of type '(value: unknown, index: number, array: unknown[]) => string'. Types of parameters 'entry' and 'value' are incompatible. Type 'unknown' is not assignable to type 'string'.

Playground Link: https://www.typescriptlang.org/play?#code/C4TwDgpgBAwgrgZ2AewLYCUIGNkCcAmAPANIQgJQQAewEAdvhUrgJZ0DmAfFALxSY4CJMggA0UZmy4AoaQDM4dLMBbI6UVAEMwANU0AbOBATDylGvUYTgrDtwAU9Gy2MAuWIhQZseIqXKcAJTukhwA2gC6UADe0lBQuBDAcLjqAPIARgBW2MAAdABuBkYIjnTOxoFx8VB5WmD2ZTYgIc4cgbzcTrggVQC+0kA
Related Issues: None found

That's becuase Object.values types are not accurate. Here's a better version:
type CustomRecord<Keys extends string> = Record<Keys, string>

const objectValues = <O extends object>(o: O): Array<O[keyof O]> =>
	Object.values(o) as any;

function mapValues<Keys extends string> (entries: CustomRecord<Keys>): string[] {
  return objectValues(entries)
    .map(entry => entry) // `entry` inferred as string
}

Playground
You might want to keep this issue open to improve the library types

This is the correct behavior
type CustomRecord<Keys extends string> = Record<Keys, string>

function mapValues<Keys extends string>(entries: CustomRecord<Keys>): string[] {
  return Object.values(entries).map((entry: string) => entry)
}

// Legal initialization
const obj = { a: 1, s: "" };
// Legal aliasing
const alias: CustomRecord<"s"> = obj;
// Legal call
const arr = mapValues(alias);
// Unsound, number inhabits string
const n: string = arr[0];

See also https://stackoverflow.com/questions/55012174/why-doesnt-object-keys-return-a-keyof-type-in-typescript

Ah my bad forgot you could alias like that. I guess this is something hegel (afaict) mentions too as a disadvantage of TypeScript (second point in the link). I mean TypeScript has it's reasons to allow that it just reminded me of it hence linking haha. I personally would type it like because I don't see myself aliasing like that :P

Well, in this case TypeScript is being sound by preventing you from writing unsound code...

Thanks, this makes a lot of sense! I did not take into consideration that a Record with limited keys is actually weaker than a Record with all keys.

Well, in this case TypeScript is being sound by preventing you from writing unsound code...

Agreed! Although I would say the way Object.values is typed is preventing not TypeScript per se. Allowing that assignment is still kinda a trade-off afaiu.

Well, in this case TypeScript is being sound by preventing you from writing unsound code...

Agreed! Although I would say the way Object.values is typed is preventing not TypeScript per se. Allowing that assignment is still kinda a trade-off afaiu.

After looking into it a bit more, I guess what I want would be something like:
type CustomRecord<Keys extends string> = { [key in Keys]: string }
  & Omit<{ [key in string]: never }, Keys>

A type for an object where every key from Keys is a string and no other key exists. This version doesn't work, but I don't really understand why yet. Will keep you posted once I figured out whether it's a bug, a feature request, or just me not understanding TypeScript well enough ;)

Well that does not work is because you expect this to work ...
const allStringExceptA: Exclude<string, "a"> = "a" // no error

... that's because string is not really a set of all string literals (I mean it is but okay), so Exclude<string, "a"> evaluates to string. Or better to simply put it: TypeScript doesn't have a type that expresses allStringExceptA (yet :P)
Also I would suggest using a Map if it's possible in your situation because then it would solve the problem of aliasing
type CustomRecord<Keys extends string> = Map<Keys, string>

function mapValues<Keys extends string> (entries: CustomRecord<Keys>): string[] {
  return Object.values(entries)
    .map(entry => entry)
}

const obj = new Map<"a" | "s", string | number>([["a", 1], ["s", ""]]);
const alias: CustomRecord<"s"> = obj; // not allowed

And I already know what it is haha, it's not a bug in Object.values ofc and a feature request if you somehow want to disallow that aliasing which would be a duplicate of #12936. And btw, I didn't have this issue, I was just going on round answering some issues haha.
Also I take my words back on how allowing that aliasing is a compromise, I was being silly, I realized that it indeed follows type theory (afaict) and should be allowed. It's because of the leaky things you can do in JavaScript like Object.values (and many more), Hegel goes kinda against the type theory (by default, you can still do it via $Soft).
I'll leave these few scenarios how both handle things in case someone is interested: 1, 2, 3, 4, 5, 6. Technically, Object.values should always return unknown[] in typescript or else it would result in unsound behavior like in 2, but probably typescript makes a little trade-off by not doing that when the key are string idk.


What happens on init_slurm_db

Hello, in docker-entrypoint.sh to init slurm db the script exec this line:
IS_DATABASE_EXIST="`mysql -h $MARIADB_HOST -u root -p"$MARIADB_ROOT_PASSWORD" -qfsBe "select count(*) as c from information_schema.schemata where schema_name='$MARIADB_DATABASE'" -H | sed -E 's/c|<[^>]+>//g>
What are happening on this part?
select count(*) as c from information_schema.schemata where schema_name='$MARIADB_DATABASE'" -H | sed -E 's/c|<[^>]+>//g>

@m0rfeo At the first run of the project, the slurmdbd must create a new database on the MariaDB server. and we cannot start slurmdbd it the database isn't ready yet.
The part of the script you mentioned ensures that the database already exists. If it doesn't, then the script goes to sleep for five seconds and repeats the existence check.
It may look weird a bit but it's simple.

The query should return one column named c and only one row with the value either 0 or 1.
The -H parameter of the mysql command allows returning the query result as HTML, like

c

1

Finally, we need to parse a 0 or 1 from the output presented above so I am using the sed with the regular expression that cuts all unnecessary characters off.

I am open to suggestions about how to make this part more elegant :)

@hackprime I undestand why you need to do that and i think that is a correct solution don't affect to the integrity and don't
create security holes.
But i still dont undestand what you wan't to get with this part sed -E 's/c|<[^>]+>//g>.
Thanks for support and congratulations for your proyect.

@m0rfeo sed -E 's/c|<[^>]+>//g' removes unnecessary text from the output of the mysql command using the regular expression as a pattern. In other words, having the following output

c

0

it removes all HTML tags (the <[^>]+> part of the regular expression) and the c character (the c part) from the passed string. So, the output of the sed will be:
0

@hackprime Thanks for the explanation!


feat: add Dictionaries API methods

Codecov Report
Attention: Patch coverage is 57.14286% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 50.56%. Comparing base (165df28) to head (3999f70).

Files
Patch %
Lines

crowdin/model/dictionaries.go
0.00%
7 Missing :warning:

crowdin/dictionaries.go
84.62%
1 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #39      +/-   ##
==========================================
+ Coverage   50.51%   50.56%   +0.06%
==========================================
  Files          44       46       +2
  Lines        2398     2419      +21
==========================================
+ Hits         1211     1223      +12
- Misses       1122     1130       +8
- Partials       65       66       +1

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


Add Bundle::GetSymbol API in CppMicroServices

Bundle should have a Load API that calls LoadLibrary/dlopen on the bundle. Something analogous to Bundle::loadClass in the OSGi Spec.
see
https://osgi.org/specification/osgi.core/7.0.0/framework.api.html#org.osgi.framework.Bundle.loadClass-String-
&
https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html#loadClass(java.lang.String) for details.
In the absence of a Load API, extenders such as Declarative Services have to include the overhead of calling the LoadLibrary/dlopen by themselves. Side effects such as ref count increment and symbol resolution could be avoided if the framework provided the API.

Adding a placeholder issue for creating the RFC document. I searched but I couldn't find one.

Completed in PR #450


Is there any way to implement firebase crash reporting in flutter?

i found two libraries.
bugsee and sentry but they are provides paid service.
help me to implement firebase crash reporting in flutter.
if you have documentation then please send me link.

not yet as far as I am concerned.
also, it's possible that Crashlytics will replace firebase crash reporting
Google already integrated firebase with it and recommended using Crashlytics over firebase crash reporting too.
there should be a progress in this, but nothing clear yet.
and you are not alone, a lot want this feature too, add your vote here
https://github.com/flutter/flutter/issues/14765

Closing as dup of #14765
Thanks @ebeem


[#5] [Integrate] As a user, I can make a shortened link

#5
What happened 👀
Add shorten link api to the screen ShortenLinkViewController.
Insight 📝
Add some extensions.
Add Factory.
Put ShortenLinkViewController on PopupController.
Proof Of Work 📹
https://user-images.githubusercontent.com/6356137/142807935-7d8448aa-b286-41e2-8036-6d06545c3b9a.mp4

I rebased this, please check again.


Add Ground Item Sounds hub plugin

What is the source of the packaged sounds?

What is the source of the packaged sounds?

I made them


Change default pin for RA_HOMING_SENSOR_PIN to pin 3 on mksgenlv21

I am proposing to change the default pin for hall sensor from 53 to 3.
The board is designed to use pin 3 for homing the X-axis motor (RA-axis on OAT). And when using a hall sensor the 3-pin JST connector work perfectly in this port without splitting the cable to connect signal, voltage and ground in different places. It is a clean install.
Premise:
This change is based on the premise that the most common use-case would be to only use one method of homing per axis (at a time).
My assumption is that you would reasonably only use either a hall sensor for very exact homing, or the TMC sensorless homing (If it is implemented).
On mksgenlv21 a jumper controls if the diag-pin is connected to pin 3 or not. Jumper missing, free to use for hall sensor. Jumper in place, connected to X-diag in use for potential sensorless homing with TMC stepper.

Rebased on 1.11.5 from develop branch.

We discussed this internally and agree with your reasoning, but each of the X/Y/Z min/max pins have been allocated already for future features (they're shared with the diag pins).
X-min/max and Z-min/max are going to be used for limit switches for each axis on the OAM.
Y-min/max are already used for the separate debug serial port which is needed for development purposes.
The best alternative is pin D11. It is adjacent to a 5V and gnd pin, so a single 3-pin Dupont connector can be used for the hall sensor.
Please change the pin and version number to the next available increment and we'll get this merged.

I believe I have made the requested changes now. @CTetford


pagination

Thanks for a good database adapter for peewee.  Just starting to like this, then I find out paging is still in your TODO list. Are you planning to add it sometime soon?

The code says:
    # TODO: implement limit and offset properly, we can use:
    # SELECT *
    # FROM (SELECT ROW_NUMBER() OVER(ORDER BY id) RowNr, id FROM tbl) t
    # WHERE RowNr BETWEEN 10 AND 20

I never used MsSQL, but how about this:
https://technet.microsoft.com/en-us/library/gg699618(v=sql.110).aspx

looks like it took Microsoft until SQL Server 2012 to fix this:
https://dba.stackexchange.com/questions/136259/offset-fetch-in-sql-server-2008
That's quite frustrating.

I only ever used this with older version of MSSQL (2005 and 2008) and the pagination looked very frustrating to implement. It looks simple enough to implement in 2012+ but I don't use MSSQL anymore so hard to find time to code it.

Not so much an issue, more an FYI. There is another chap attempting (or at least got further with) pagination:
https://github.com/brake/peewee_mssql


Run CI on CentOS 7

A lot of Kubernetes users (using IPVS proxy) run on CentOS 7 which is based on Linux 3.10. In the past there have been compatibility issues with older kernel where certain netlink attributes do not exist. For example, for Linux < 3.18 the address family doesn't exist so we had to create some workarounds (https://github.com/moby/ipvs/pull/15 and https://github.com/moby/ipvs/pull/19). The address family compatibility issue would have been caught if we ran tests on CentOS 7.

Looks like we would need to use self-hosted runners for this https://github.com/actions/virtual-environments/issues/45

Yes, for any specific targets we'd need self-hosted runners, otherwise we'll get Azure kernels.


Have report link default to dispute

Change default landing page for Reports nav:
in src/modules/app/components/app/app.jsx change
      {
        title: "Reporting",
        iconName: "nav-reporting-icon",
        icon: NavReportingIcon,
        mobileClick: () =>
          this.setState({ mobileMenuState: mobileMenuStates.FIRSTMENU_OPEN }),
        route: REPORTING_REPORT_MARKETS
      },

to route to REPORTING_DISPUTE_MARKETS
and change to order of Reporting nav to be
Dispute
Next Dispute
Reports
Resolved
Also:
Split out markets in dispute and upcoming dispute.
Remove upcoming reports from Reports page.
This will reduce data per page and speed up loading and help navigation to what users are interested in.

V2 Reporting entirely different.


Update Mavlink submodule to bring in new object tracking messages

I had to cherry-pick 2 commits from upstream to not break the mavlink compatibility.
We should then organize a proper upstream mavsdk merge next week.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
10 unchanged lines in 2 files lost coverage.
Overall coverage remained the same at 33.871%

Files with Coverage Reduction
New Missed Lines
%

src/third_party/mavlink/include/mavlink/v2.0/common/mavlink_msg_storage_information.h
5
0%

src/third_party/mavlink/include/mavlink/v2.0/common/mavlink_msg_sys_status.h
5
0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
6011

Relevant Lines:
17747

💛  - Coveralls


bug with timeformat

Hello,
I am on this since many hours and i don't understand at all.
I have read many issue in the repository to help me but cannot find any way.
Here is a log example :
<IP_ADDRESS> - https - www.mysite.com - - [2017-09-01T06:27:36+02:00] "POST /pro/sync?version=5&group_id=75716&code_version=17.1.0&guid_pro=b05318735deb3436af14af1ce55d49d479b8e19a HTTP/1.1" 200 365 Time Taken 0.013
<IP_ADDRESS> - https - www.mysite.com - - [2017-09-01T06:27:36+02:00] "POST /pro/sync?version=5&group_id=95649&code_version=17.1.0&guid_pro=5bf2c2c708b868e4ee5d93970f9e5b78d721c1ff HTTP/1.1" 200 365 Time Taken 0.014
<IP_ADDRESS> - https - www.mysite.com - - [2017-09-01T06:27:37+02:00] "POST /pro/sync?version=5&group_id=75480&code_version=17.1.0&guid_pro=6dafd16e1ad4bef5bdae6f9497ee1c303f502c71 HTTP/1.1" 200 365 Time Taken 0.013
<IP_ADDRESS> - https - www.mysite.com - - [2017-09-01T06:27:37+02:00] "POST /pro/sync?version=5&group_id=85875&code_version=17.1.0&guid_pro=a8f06901108f8e2b6aa575529076c67e7820b7c6 HTTP/1.1" 200 365 Time Taken 0.013
<IP_ADDRESS> - https - www.mysite.com - - [2017-09-01T06:27:37+02:00] "POST /pro/sync?version=5&group_id=41659&code_version=17.1.0&guid_pro=b64387e855525e95a8b1d2337444448bf42a358c HTTP/1.1" 200 365 Time Taken 0.014
<IP_ADDRESS> - https - www.mysite.com - - [2017-09-01T06:27:38+02:00] "POST /pro/sync?version=5&group_id=85459&code_version=17.1.0&guid_pro=5f65e4f96ed6530c09656cd0afc4aff4a8dd0427 HTTP/1.1" 200 365 Time Taken 0.012
Here is my config :
time-format %H:%M:%S%^
date-format %Y-%m-%d
log-format %h - %^ - %v - %^ - [%dT%t] "%r" %s %b Time Taken %T
Bug :
Parsed 10 lines producing the following errors:
Token '06:27:30+02:00' doesn't match specifier '%t'
Token '06:27:30+02:00' doesn't match specifier '%t'
Token '06:27:31+02:00' doesn't match specifier '%t'                                                                                Token '06:27:31+02:00' doesn't match specifier '%t'
Token '06:27:31+02:00' doesn't match specifier '%t'
Token '06:27:31+02:00' doesn't match specifier '%t'
Token '06:27:31+02:00' doesn't match specifier '%t'                                                                                Token '06:27:32+02:00' doesn't match specifier '%t'                                                                                Token '06:27:32+02:00' doesn't match specifier '%t'
Token '06:27:32+02:00' doesn't match specifier '%t'
Format Errors - Verify your log/date/time format
It works if i use : log-format %h - %^ - %v - %^ - [%dT%^] "%r" %s %b Time Taken %T
But i don't have the time distribution and really need it, i am analysing a server crash.

This should do it:
goaccess access.log --log-format='%h %^ %^ %v %^[%dT%t+%^] "%r" %s %b %^ %^ %T' --date-format='%Y-%m-%d' --time-format=%T --ignore-panel=OS --ignore-panel=BROWSERS --ignore-panel=REFERERS --ignore-panel=REFERRING_SITES

You are my hero today :)


[ISU-155]:[nhurde]:Add render texture quad function to base texture c…

…lass.

Fixed/Revised via https://github.com/pawbyte/Game-Pencil-Engine-Editor/pull/160


LoggingSpanCollector logs span data as JSON

It used to log object references, which was not very useful:
apr 11, 2016 10:05:53 PM com.github.kristofa.brave.LoggingSpanCollector collect
INFO: com.twitter.zipkin.gen.Span@a6aa0157

It now logs spans in JSON format:
apr 11, 2016 10:25:23 PM com.github.kristofa.brave.LoggingSpanCollector collect
INFO:
{"traceId":"172152af88585c29","name":"get","id":"172152af88585c29","timestamp":1460406308237000,"duration":15212000,"annotations":[{"endpoint":{"serviceName":"eirslett-test","ipv4":"<IP_ADDRESS>"},"timestamp":1460406308237000,"value":"sr"},{"endpoint":{"serviceName":"eirslett-test","ipv4":"<IP_ADDRESS>"},"timestamp":1460406323449000,"value":"ss"}],"binaryAnnotations":[]}

I believe the test failures are unrelated?

I think we recently fixed this. have a look?
https://github.com/openzipkin/brave/blob/master/brave-core/src/main/java/com/twitter/zipkin/gen/Span.java#L255

Yes indeed! Sorry, I missed that!


primary name changes

Hi Kim,
What would happen if a primary name changes  to the existing extensions which use the old primary name. Do they get fixed automatically? I am thinking this would be the same situation if a systemtic ID was used in an extension for an unnamed gene which was subsequently named. I don't know if we have any examples of this either. I guess we need to
Report any use of extensions which do not match the primary name.
We might have a test case soon.
Original comment by: ValWood

I'm going to close this because I think we're already doing what you need.  Please re-open if I have that wrong.


Propose Get pool id maches fix.

The --matches filters only the subscription or product information.
Sample tests:
subscription-manager list --available --pool-only | grep 1234
1234
subscription-manager list --available --pool-only --matches 1234
subscription-manager list --available --pool-only --matches 'OpenShift' | grep 1234
1234

This is not a good fix because not every pool which contains OpenShift has OpenShift in the name. Also with this approach, it would be possible only to use pool IDs, but I guess we want to have the possibility to use both, pool names and IDs. But currently only pool names work.

Are you sure ?
It should contain at least the name of the product under "Provides".
For instance:
subscription-manager list --available --matches 'OpenShift'
Subscription Name:   Employee SKU
Provides:            Oracle Java (for RHEL Server) - AUS
Oracle Java (for RHEL Client)
Red Hat Enterprise Linux 7 High Availability High Touch Beta
Red Hat Enterprise Linux High Availability (for IBM z Systems)
                 Red Hat OpenShift Enterprise JBoss FUSE add-on
                 Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support

                 Red Hat Enterprise Linux Server - Extended Life Cycle Support (for IBM z Systems)
                 Red Hat JBoss A-MQ Interconnect
                 Red Hat Certificate System with Advanced Access
                 Red Hat Enterprise Linux High Performance Networking (for RHEL Server)

                  .…
                 Red Hat **OpenShift** Enterprise Infrastructure
                  ….

                 Red Hat **OpenShift** Container Platform

Anyway the matches is used only to speed up the search in subscription-manager, because you cannot use the poolId as matches, it will always empty.

Ah, OK, so it does match also in the provides field and this is only a speed up in the search.. I got it wrong before.

aos-ci-test

In that case, I think it's OK, @cooktheryan what do you think? If you don't see any obvious problem, I think we can merge this.

Hello,
I did test the diff and it does work so thank you for that.
Unfortunately we cannot merge.  The team had a discussion regarding this role.  There are other pitfalls that need to be addressed.  The openshift-ansible team has developed an rhsm role.  The team is in favor of dropping this role and integrating into that role.  That work be happening in the very near future.
Thanks!


fix: don't move preview window while it's focused

Fixes a bug introduced by #705
Currently, if the hunk preview window is focused and the user moves their cursor inside the preview window, the preview window will gradually move down and too the right by on column and row per move. This is because the floating preview window is incorrectly being adjusted to have its position be relative to the cursor which is offset by the floating window boarder.
This commit updates the WinScrolled autocommand introduced by #705 to be scoped to buffer of the file so that this doesn't happen.

I just saw #708, sorry about that 😅
This commit reverts the revert made for that issue and fixes the moving window problem.

Cool. Let's give it another try.


Implement Into TextProp for signals

I'm surprised the impl on line 1357 didn't already cover these.

The CI is failing on updated nightly clippy warnings that came from outside your commit -- would you mind rebasing so the tests will run on your own code?
At a glance, I would have to assume that this implementation will conflict on nightly with the implementation for Fn() at line 1357 that you point out. These could be cfg-gated to only be used if that feature is not enabled.

I have the most recent changes from main merged into this PR now. Is the cfg gate you have in mind enabling these only if it is not nightly?

Correct. If you look at any of the failing checks here, they are along the lines of
error[E0119]: conflicting implementations of trait `From<signal_wrappers_read::Signal<_>>` for type `TextProp`
    --> /home/runner/work/leptos/leptos/leptos_reactive/src/signal_wrappers_read.rs:1368:1
     |
1357 | / impl<F, S> From<F> for TextProp
1358 | | where
1359 | |     F: Fn() -> S + 'static,
1360 | |     S: Into<Oco<'static, str>>,
     | |_______________________________- first implementation here
...
1368 | / impl<T> From<Signal<T>> for TextProp
1369 | | where
1370 | |     T: Into<Self> + Clone,
     | |__________________________^ conflicting implementation for `TextProp`

This is because, as you predicted, these implementations create a conflict with the blanket implementation for Fn().
Fn() is only implemented for these types when the nightly feature is enabled, so you can add #[cfg(not(feature = "nightly))] to your additional implementations to avoid the conflict.


CS50 guide renders incorrectly

Attach (recommended) or Link to PDF file here: https://cs50.harvard.edu/college/2019/fall/guide.pdf
Configuration:

Web browser and its version: Firefox 69
Operating system and its version: macOS 10.14
PDF.js version: 2.2.199
Is a browser extension: no

Steps to reproduce the problem:
Open the linked PDF
What is the expected behavior? (add screenshot)
The PDF should be rendered as it is in Preview and the Chrome viewer:

What went wrong? (add screenshot)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Duplicate of #269.


build: update internal Angular dep to 5.0.0

Replaces #8223.

Silly CLA bot, Alex and I are both Google employees.


Apollo2 withMessages

I updated the withMessage HOC to use the new Apollo Link State API instead of Redux. It can serve as an example too.
Updating react-apollo to v2 seems to fix issues with undefined results in the graphql tag.

The syntax with Apollo Link State is far more verbose than with Redux. It seems that the Apollo devs are waiting from more feedback from the community before they provide helpers. There are some redundancies between the gql queries and the mutations.
So I think it would be relevant to implement some helper functions, maybe smth similar to Redux or Rematch API, or even maybe to generate the mutations and defaults from a schema?

Goodbye GraphiQL/network tab: you can't debug State link with usual tools since queries are not on the network. Instead you have to use the Chrome Apollo tools (which are fine).

Also, I am not sure if moving the apolloClient folder to client is a good idea. The problem is that then you have to wrap a lot of code into Meteor.isClient. Yet it does not make sense to create an apollo-client on the server (eg defining an InMemory cache), how was this handled this in the first place with the v1?

The default state is correctly set and retrieved, however I did not test the mutations yet.
I am trying to migrate an existing app to the new version. So far breaking changes are mostly related to RR4 (routes won't change for an obscure reason, and the API has changed, e.g currentRoute is not available anymore). The app seems ok with Apollo v2, since there are not much breaking changes. I guess SSR is also disabled?

Awesome, having a sample implementation of local state will be a big help. Like in the other PR I would probably try to avoid using Meteor.isClient but it's not a big deal.

The syntax with Apollo Link State is far more verbose than with Redux. It seems that the Apollo devs are waiting from more feedback from the community before they provide helpers. There are some redundancies between the gql queries and the mutations.
So I think it would be relevant to implement some helper functions, maybe smth similar to Redux or Rematch API, or even maybe to generate the mutations and defaults from a schema?

I would say let's keep it verbose for now and avoid adding too many abstraction layers, and then once we have enough practice using it we can "vulcanize" it with an intermediary layer like we do with React Router. Using a simplified state management API like Rematch for apollo-link-state would be great, in fact that could/should be something that exists outside of Vulcan I guess?

Also, I am not sure if moving the apolloClient folder to client is a good idea. The problem is that then you have to wrap a lot of code into Meteor.isClient. Yet it does not make sense to create an apollo-client on the server (eg defining an InMemory cache), how was this handled this in the first place with the v1?

We should ideally never use Meteor.isClient as other non-Meteor frameworks don't usually support mixing client/server code in the same file. So it'll just create headaches in the future if we rely on that pattern. And we do need to load some Apollo Client code on the server for rehydration and SSR, but I'm not super familiar with that part of the code yet.

The app seems ok with Apollo v2, since there are not much breaking changes. I guess SSR is also disabled?

Yes, I wanted to get the client part working first before worrying about SSR.

Btw feel free to merge the PR yourself, let's focus on making things work for now and we can refine everything later.

Okay then we can move the apollo client back into modules if it works as expected, that was premature optimization. We can still write 2 different client/server implementation when things are clearer or if it becomes necessary.
I'll merge for now, I might be able to come back at it next week depending on my planning. There might be small bugs left in the Flash messages mutations since I could not test them yet but they will be easy to notice and fix.
For documentation purposes regarding your question on the previous PR:

registerDefault is equivalent to defining redux initialState
registerMutation is equivalent to defining a redux action and a corresponding reducer. Syntax is the same as a resolver (object, args, context). However you mutate the state (more close to vuex than redux here)
cache is equivalent to the redux state. It is available as context.cache in the mutations, cache.writeData allows to mutate it
the apollo client is thus the store
GraphQL queries with the @client directive are equivalent to redux selectors
graphql acts like mapDispatchToProps  (for mutations) and mapStateToProps (for simple queries)
you have access to the full power of GraphQL, so you can mix client and server stuff, e.g if you want to retrieve both network and local data in the same query

Definitely, I will think about it. state is a better fit than cache here, since a cache is usually something that is managed automatically contrary to application state.


Version 2.5.2 not found

[!] CocoaPods could not find compatible versions for pod "SwipeCellKit":
In Podfile:
SwipeCellKit (= 2.5.2)

It does exist. Make sure you are using Xcode 10.2


[Question] When will support be given to versions 8 of php?

Hi,
Currently versions 8 of php are not officially supported (in release), but the curious thing, according to what I have read in the develop branch, is that it is supported.
Are you planning to create a new release to include full support for php 8 versions?

Yes.

Is there any notion of a timeline for compat with PHP 8+? Soon various platforms are going to force higher PHP versions...

@johnnietheblack We've been working steadily on this behind the scenes for the last few months. I'm not willing to commit to a timeline, but it's coming.

@jrfnl  Appreciate your work on this!  Any updates on PHP8.0 support?  PHP7.4 will be EOL'd in 1 month.

Working hard on it and getting closer towards a release.

Working hard on it and getting closer towards a release.

@jrfnl Do you need any help to get it done faster? I would love to help you with this.

@sandeshjangam Help is always welcome.
How you can help will depend largely on your pre-existing PHPCS/Tokenizer knowledge (as I don't want to slow things down at this moment by taking on coaching - after the release I'll happily coach people):

For a list of tasks we're working through, have a look at: https://github.com/WordPress/WordPress-Coding-Standards/issues/1877
For low-hanging fruit, have a look at: https://github.com/WordPress/WordPress-Coding-Standards/issues?q=is%3Aissue+is%3Aopen+label%3A"Status%3A+good+first+issue"+milestone%3A3.0.0 and https://github.com/WordPress/WordPress-Coding-Standards/issues/1722

Feel free to claim any of the low hanging fruits and if you want to take on anything more advanced, please ping me with what you're planning to work on, so we can prevent multiple people working on the same thing.

@jrfnl Thanks for the details. I will have a look and will go for low-hanging fruits for now.
But after the release, I am happy to learn from you...

@sandeshjangam We're doing some issue/PR triage at the moment and just came across PR #1265. This might be a nice one to get you started ? See my comment for a list of things which need to be done to get that PR to a mergable state.

Hi. Any news regarding the PHP 8+ support ?
P.S: I would help - but i am not so experienced yet.

This will be handled when WPCS 3.0 comes out. See this pinned thread for the status of that.
I'm going to close (and pin) this conversation since the question is answered by the equally general question "When will WPCS 3.0 come out?", which is handled elsewhere.


Provide more granular file change events based on VS Code file create/delete events

…/delete events

@rchande: Out of curiosity, have you tested that this works? I'm curious since the protocol didn't match omnisharp-roslyn at first.

@DustinCampbell I did test this--verified in the debugger that we were getting hit for both create and delete events.


[Bug]: Metadata text display

Issue description
Text within the transaction metadata splits text in the middle of words to fit within the text box.
Expected behaviour
Text within the transaction metadata (contained within the text box) should spill onto the next line whist keeping each word whole.
Actual behaviour
Text within the transaction metadata splits text in the middle of words to fit within the text box.
Can the issue reliably be reproduced?
Yes
Steps to reproduce the issue
View a transaction on the explorer that has alot of text in its metadata such as: https://explorer.shimmer.network/shimmer/transaction/0xb0e57228c7fe10048a29bf4c393534370820a83a943a0bcb0b8a8f9f2285042b
Errors
No response
Duplicate declaration

[X] I have searched the issues tracker for this issue and there is none

Code of Conduct

[X] I agree to follow this project's Code of Conduct

For example


Run child in separate process group

This prevents the shell from sending it SIGINT when Ctrl-C is pressed.  That, in turns, gives lrt a chance to signal and wait for clean shutdown.
Also remove -i flag from go build, which is deprecated

Cool! I didn't know about the default for ctrl+c be "kill the whole process group", that makes sense now I think about it though.
I'm happy to merge this and see how it feels in actual usage. :gem:
That said, I do worry that this will cause backends to leak if you kill lrt at the wrong time, or in the wrong way. Do we need to/can we do anything ensure that if lrt itself exits the child processes will also exit?

I don't think there's anything that can fully prevent that race (sending
SIGKILL to lrt will not kill the child).  We potentially could do
something in run.sh, but I can't think of anything simple to add in that
vein.
On Fri, May 21, 2021 at 12:43 AM, Conrad Irwin @.***>
wrote:

Cool! I didn't know about the default for ctrl+c be "kill the whole
process group", that makes sense now I think about it though.
I'm happy to merge this and see how it feels in actual usage. [image: 💎]
That said, I do worry that this will cause backends to leak if you kill
lrt at the wrong time, or in the wrong way. Do we need to/can we do
anything ensure that if lrt itself exits the child processes will also
exit?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/superhuman/lrt/pull/1#issuecomment-845734791, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIID4MXZEZ3RGDU2KWZ4OLTOYFJVANCNFSM45ISPV6A
.