Reload translation dictionaries in runtime

Hello! We have idea in our electron application. We implemented localization with online dictionaries for that. We want to implement periodical polling and reload translation dictionaries silently during runtime, so if we release some localization fixes user app will silently reload translation and user will not be required to reload/refresh electron application.
It would be great to have some method to force reload of translation dictionaries. Right now they are cached and looks like there are no ways to reload them in runtime.
Or there is already some way to reload translation dictionaries?

I have the same problem, didn't find a way to reload translation already loaded
Am I missing something ?

@SimonCorellia I have not solved this problem - you can refresh page if you want to load new dictionaries.

Yes, I did that too but it's not the best solution IMO

@Dedrus @SimonCorellia as a workaround you can load the translation and use the setTranslation.
Maybe we can expose a function that clears the cache, and after calling it you can load whatever you need to reload.

@shaharkazaz  Hi
As a workaround, I use the this.translocoService.ngOnDestroy() to clear the cache
It's not the best solution because it destroys a subscription but it's the only way I found to clear it and to cover all my cases
Could you provide a function to clear the cache ? Or I could provide a pull request for that...
Let me know

@SimonCorellia Why isn't setTransaltion working for you? what's the flow?

Client requirement....., users can't access the app until there is translations loaded, and when we change the language, we need to reset the app, reload translations from the backend and then, access the app

@shaharkazaz @SimonCorellia looks like setTranslation works like charm! Thanks for advice, we will use it.

I think a clear cache function in Transloco service would be great. Is it hard to design/implements?

@f-aubert You are welcome to open a PR for it 🙂  should be pretty easy to implement.

If I expose the following deleteCache:
  deleteCache(...paths: string[]) {
    if (!paths.length) {
      this.cache.clear();
    } else {
      for (const path of paths) {
        this.cache.delete(path);
      }
    }
  }

How would you use it? You need to trigger a reload.
@simon-knu How are you using the ngOnDestroy?

@shaharkazaz Yes, I would use it like that
The reload would be trigger by an user action
I'm using the ngOnDestroy before calling the "translocoService.load" method
I have to do that because I need to have the latest translations. I can't trust the cached value, the translations can be updated at runtime (on the server) and it's critical for the app to have the correct translations

@simon-knu let me clarify my question, all the directives need to get the updated values, what causes the stream to push the new value?
They are registering onInit to the previous cached load stream. That's why I'm surprised that just calling the onDestroy before the load works.
Can you share a reproduction of what you are doing?
Another option I thought of is adding an override option to the load method.

@shaharkazaz Sorry, I can't share a reproduction now, but maybe in a few days
Your proposal is good for me, it will handle perfectly what I need to do
As I said back in the days 😄,

Client requirement....., users can't access the app until there is translations loaded, and when we change the language, we need to reset the app, reload translations from the backend and then, access the app

What I meant was that :
When the user switch to a different language, the app needs to be "reset".
We have to reload the translations from the backend and then, display the app again.
A quick example : if I'm in French mode, I go in English mode, and I switch back to French, I need, every time, to load the translations from the backend before displaying the app

I don't think that the common use case for those commented here.
The solution should support runtime updates and not require the entire app to reload, just like the original use case that started this issue
Can people here share their use-cases so I can think of the best solution here?

I don't think that the common use case for those commented here.
The solution should support runtime updates and not require the entire app to reload, just like the original use case that started this issue
Can people here share their use-cases so I can think of the best solution here?

So my Issue as stated in the recently closed PR is that a user would navigate to the next page but there has been an update in the meantime and now translation files are missing.
I would potentially make some sort of service or something like that where there is a hardcoded version and the last version is written to localstorage and when there is a miss match, the translation files are fetched and the new version is written to the localstorage. I am also running into the issue where I have to delete my cache to get the new translations which is not user friendly at all.


scipy.signal: Add the class ltid for linear discrete-time systems. Closes #2912

This extends the current system representation to discrete-time systems. The overall idea is to have a master class LinearTimeInvariantSystem, that combines all the functionality, but is not actually designed to be called by the user. Below that are lti and ltid, which can be called and return the corresponding subclass (e.g. StateSpace). What's new now, is that these subclasses don't inherit from lti anymore. Instead they return an instance of StateSpaceContinuous or StateSpaceDiscrete, depending on the input arguments. These last subclasses inherit from StateSpace and lti or ltid, which enables the StateSpace class to decide at runtime from which of the two it should inherit. While these last names seem cumbersome, you never actually have to type them, use them, or even see them (unless you call print on a system).
In summary: Everything stays the same for continuous-time systems. But for discrete-time systems there is now ltid and you can call StateSpace(1,1,1,1, 0.05), where 0.05 is the sampling time.
One drawback:

Since lti/ltid classes share functionality, some functions had to be moved to the same file in order to avoid circular imports. Specifically, the files dltisys.py and cont2discrete.py were removed.

This ended up being a rather large commit and took time to get to a state that I think is good. It would be great if you could invest some time to review it. Imho this is the last big user-facing change to the api that needs to happen in order to make linear systems in scipy useful.

I don't know why the test failed, especially since that fail occurs in a seemingly completely unrelated file and the test passes when calling the test-file directly. I'll have a look, but just want to point out that the code actually works :)

That's an impressive PR. I'll have a closer look at it again later, but for now I have one question. Why is there
@property
    def system_class(self):

If someone needs the actual class they might as well use obj.class

Oh, I think that's just some leftover code from a previous design I had for this. Ignore it for now, I'll remove it in time.

This PR has been around now for quite some time without much feedback.
In #2912 there was a discussion on fs vs sampling_time. Most people seemed to prefer sampling_time which is implemented here. I'm fine with that.
I think it would be good if this would be merged as soon as possible since then we can add lfilter/filtfilt variants to it as well as SecondOrderSections(LinearTimeInvariant).

Yes, part of this is my fault since I was extremely busy ever since I send in the PR and will be for another week, but afterwards I'll take this up more actively again. As for the sampling_time / fs / dt argument I don't have a strong preference. If we stick to what is already used I would probably prefer dt over fs.
I will sort out the merge conflicts as well as your comment about the system_class as soon as I have time again (after the 16th). Though it would be great if some people could review the code properly in the meantime.

I definitely think this is a good feature. I'll take a closer look into the code when I have some time. Why is the Bode method commented out?
As for the parameter choice: this feels a bit bikeshed-y. I prefer specifying the sampling frequency, but its more important to just be consistent. MATLAB isn't a good model for this; e.g. creating an LTI system takes the timestep, whereas some commands like bilinear take the sampling frequency.

Alright, rebased the code, removed the system_class method, uncommented the bode plot code. Still not sure what to use instead of sampling time.
@e-q The argument against the sampling frequency was that it is infinity for continuous time systems, which is somehow not that nice. (This was brought up in #2912)

Hey @befelix, it's been entirely too long, but I started to try and review this but got caught up in rebase hell...
I'm willing to work through it, as I really want to see this functionality in scipy, but it may be a little slow going, since I'll be learning what you did as I rebase.
If you have the time and willpower, though, it could be nice if you rebase it, and we continue on this PR (maybe my git-fu isn't strong enough, but I think that if I do the rebasing, we'd have to open a new one..)
Let me know what you think!

Thanks for agreeing to review this. I'll try to clean it up and rebase it
within the next week.
On Thu, 3 Mar 2016 01:47 Eric Quintero<EMAIL_ADDRESS>wrote:

Hey @befelix https://github.com/befelix, it's been entirely too long,
but I started to try and review this but got caught up in rebase hell...
I'm willing to work through it, as I really want to see this functionality
in scipy, but it may be a little slow going, since I'll be learning what
you did as I rebase.
If you have the time and willpower, though, it could be nice if you rebase
it, and we continue on this PR (maybe my git-fu isn't strong enough, but I
think that if I do the rebasing, we'd have to open a new one..)
Let me know what you think!
—
Reply to this email directly or view it on GitHub
https://github.com/scipy/scipy/pull/4881#issuecomment-191513081.

@e-q I've rebased the code. Let me know if you find anything strange.

@@            master   #4881   diff @@
======================================
  Files          238     236     -2
  Stmts        43822   43908    +86
  Branches      8215    8238    +23
  Methods          0       0
======================================
+ Hit          34253   34302    +49
- Partial       2602    2610     +8
- Missed        6967    6996    +29

Review entire Coverage Diff as of 28570e9

Powered by Codecov. Updated on successful CI builds.

Awesome, I won't be able to look through until next week, but I look forward to it!

I'm still chewing on this, but here are a few things that have occurred to me so far:
I feel like we don't have to have separate functions for freqresp and dfreqresp, if the function can just figure out whether its discrete or continuous, and call freqs or freqz appropriately. This reduces duplicated code, and fixes the ltid.bode method (which currently fails). In any case, even if this is kept separate, there are currently no tests for dfreqresp.
I think all of the LinearTimeInvariant methods like num, den and so on should use the as_tf kind of functions instead of to_tf. We've seen this cause unneeded latency in places like gh-5613.
Inspecting an lti or ltid object in IPython via sys? is less helpful with the new "Dummy subclass" docstring. I would prefer duplicating the long docstring from the parent class, with appropriate modifications.

Also, lutists.py is getting huge, currently 3369 lines. Maybe the conversion and simulation functions can be broken out into files like lti_conversion.py and lti_sim.py?

Looking at the codecov report I don't see any other big gaps in tests right now.

Thanks a lot for the feedback!
The seperation between freqresp and dfreqresp is necessary for consistency. All the lsim related functions have the split and the discrete time versions take the sampling time as part of the system-tuple. Unfortunately this makes it difficult to differentiate if the system is a discrete-time transfer function with sampling time or a zeros-poles-gain system in continuous time.
I'll add the tests, but it will probably be some time until I can. It could be an option to split this feature from this PR in order to make it less monolithic.
The reason why the _as_ss' is not necessary for the LinearTimeInvariant system properties is that, for example, the StateSpaceclass will overwrite the respectiveA, B, C, and Dproperties with the actual system matrices (no conversion). In any case, my personal long-term goal would be to see these cross-class properties depricated. They are really inefficient to compute, encourage bad behavior, and can now be easily accesses by something likesystem.to_ss().A`, which makes it clear to the user that a system conversion is taking place.
I agree that it would probably be nice to have a separate file only for the system representations and to have conversions and simulations somewhere else. Though, since this is more of an esthetic question, for now I think that splitting up the file would only make the diff-log of this PR even more difficult to navigate.
Let me know if you find anything else!

Thanks for the clarifications.

The seperation between freqresp and dfreqresp is necessary for consistency. All the lsim related functions have the split and the discrete time versions take the sampling time as part of the system-tuple.

I see what you're saying. Really, this is one of the reasons why I'm not a huge fan of the system-as-tuple / argument counting API.
It makes sense to me that the discrete and continuous lsim functions are separate, since the nature of the computation is different. I personally don't feel like this doesn't have to extend to lower level things like freqresp and bode, though I understand that this is impractical with the current API design.
What would be your take on an API where there is no ltid class, but instead lti had a keyword argument Ts or dt that defaults to 0? Of course, one problem with this is that dlsim, etc., already use the (num, den, dt) system-tuple arguments, but is there another strong reason why we shouldn't try something like this?

Also, for the current API, we're missing a dbode method. ltid.bode currently calls bode and thereby the continuous-time freqresp.

Also, for the current API, we're missing a dbode method. ltid.bode currently calls bode and thereby the continuous-time freqresp.

Oh true, I guess this goes back to the question what the proper way is here. boded is sound strange, but the alternative is either to break backwards-compatibility (takes a lot of time and beyond the scope of this PR), or to have bode work for continuous-time tuples, continuous-time systems, and discrete-time systems. Though that might be confusing as well.
I think my current preference would be to remove freqrespd and bode from the dlti class and this PR and to move this discussion into a seperate thread. Should make an eventual merge easier to achieve. What do you think?

What would be your take on an API where there is no ltid class, but instead lti had a keyword argument Ts or dt that defaults to 0? Of course, one problem with this is that dlsim, etc., already use the (num, den, dt) system-tuple arguments, but is there another strong reason why we shouldn't try something like this?

I actually had this as part of the LinearTimeInvariant class at some point, but didn't like it. It seemed much saner to me to use the correct subclass that fits the model directly, rather than relying  on the voodoo-magic of __new__ and having yet another entry point for system creation.
There are discrete-time specific attributes (e.g., at some point there should be an sos system class). It is of course possible to have lti take the place of what LinearTimeInvariant currently serves, but I don't see a way around the current structure with separate subclasses for continuous and discrete time.
Having a consistent API is, in my opinion, the most important feature of any library. So while a long-term goal could be to have a discussion about changing the API, I think this is beyond the scope of this PR.
That being said, I'm of course open to concrete proposals of how to do this better and I really appreciate you taking the time to review this!

I think that dfreqresp and dbode should land in this PR, it's awkward to have the discrete classes without them, in my opinion. In terms of backwards-compatibility and easy inclusion in v0.18, your current approach is probably indeed probably the best.
I suppose my underlying concern in my replies above was to avoid doing something here the makes it harder for scipy.signal to eventually land at a cohesive API, since there are thoughts floating around about a general overhaul of the entire LTI filtering API (as is partially discussed in gh-3259 and probably other places). This is definitely outside the scope of this PR, but the way we handle discrete vs. continuous should definitely be a factor in whatever ends up happening.
I'm going to throw out some pings to people who may have more well-founded opinions / better ideas than I. @rgommers @endolith @WarrenWeckesser @ewmoore  @Eric89GXL

I suppose my underlying concern in my replies above was to avoid doing something here that makes it harder for scipy.signal to eventually land at a cohesive API

I haven't worked with these classes, so take my comments with a grain of salt.
My sense is that, given the tension between wanting a cohesive API (and not hindering progress toward it) and wanting to add features consistent with the current API, we'll have to side with adding features. It will make the eventual merge more difficult, but it would be a shame to miss out on good concrete improvements in the meantime that people will actually benefit from. If we were on the verge of having our API sorted out and unified -- say, within a couple of months, with a PR in progress with some momentum -- I'd say we should hold off. But I'm pretty sure we're not there :) In the meantime my vote is to try to fit with the current API first, and try to reasonably minimize future challenges for unification in the process.
Since I haven't used these specific classes, I don't have any useful comments on the other issues (dbode, boded, etc.).

Hey @befelix, if you don't have time to move this forward, I can take this over and squash and commit this along with dbode and some more tests.

@e-q, that would be really helpful. It will probably be another week before I will have time to add the finishing touches. If you do have time before that it would be great if you could keep our respective contributions separate of course. Thanks!

Okay, I have a question about the discrete-time transfer function. In the code, I have assumed that discrete-time transfer functions numerators&denominators are given the same way as in Matlab and for scipy's continuous-time systems (1 + 2 z^1 + 3 z^2 = [1, 2, 3]). This should allow us to reuse all the conversion functions (eg., tf2ss). Unfortunately, I just saw that freqz and the discrete-time scipy filters take the system in a different form: (1+ 2 z^(-1) + 3 z^(-2) = [1, 2, 3]). It's not difficult to convert between the two representations.
The question now is: which representation should we choose? One is consistent with the conversion functions, the other one with the discrete-time filters.

@e-q:

avoid doing something here that makes it harder for scipy.signal to eventually land at a cohesive API, since there are thoughts floating around about a general overhaul of the entire LTI filtering API (as is partially discussed in gh-3259 and probably other places).

Isn't this part of that?  gh-3259 is just about wanting functions to take a system as input instead of separate lists of coefficients, and this provides a system object for that purpose.

I prefer specifying the sampling frequency

Yeah, me too, since it would almost always be written dt=1/fs anyway, and fs is usually an exact integer.  Does it have any practical effects?  Like sample rate conversion of integers works out exactly 48000 * 147//160 = 44100 , while working with dt gives 44100.00000000001 Hz.
@befelix

The argument against the sampling frequency was that it is infinity for continuous time systems, which is somehow not that nice.

But continuous time system objects don't store the sampling frequency at all?
@e-q

MATLAB isn't a good model for this; e.g. creating an LTI system takes the timestep, whereas some commands like bilinear take the sampling frequency.

well scipy's already inconsistent, too

scipy signal.bilinear uses fs
scipy signal.cont2discrete uses dt

I feel like we don't have to have separate functions for freqresp and dfreqresp, if the function can just figure out whether its discrete or continuous

l like the sound of that at first, but then the w argument will mean different things in each case.
Similarly residue and residuez could be combined if they only accepted system objects and could tell the difference between analog and digital, but they should continue to accept list of coefficients, too, in which case they should stay separate.  Also there's already impulse vs dimpulse, etc.  So I'm fine with leaving digital and analog functions separate.

and call freqs or freqz appropriately.

(Well in the future it should not call freqs or freqz at all since they use tf representation which is numerically lossy. https://github.com/scipy/scipy/issues/5648)

@endolith

Yeah, me too, since it would almost always be written dt=1/fs anyway, and fs is usually an exact integer. Does it have any practical effects? Like sample rate conversion of integers works out exactly 48000 * 147//160 = 44100 , while working with dt gives 44100.00000000001 Hz.

Well this is where different communities have different notions. Signal processing will typically use fs, while control people will use dt, since for them discrete-time systems are often just continuous-time systems that are analytically integrated assuming a constant input.
My goal was to avoid to avoid this whole discussion - the API in the PR is designed to be consistent with all the functions that already existed for discrete-time systems. Hence, I used dt and the discrete-time TransferFunction takes numerators and denominators in the form z^2 + 3z + 5 = [1, 3, 5].
My personal preference for a good api would be to have a keyword argument for sampling time or frequency (or even both). That way one could do things like
TransferFunction(1, [2, 3])
TransferFunction(1, [2, 3], sampling_time=0.1)
TransferFunction(1, [2, 3]), frequency=10)
I guess that would still be possible given that this is new code, but it would just add to the inconsistency at this point.
@e-q Found some time today to add the tests after all. Thanks for your offer to help though!

Open questions:

TransferFunction in terms of z or z^-1 (dlsim and the likes assume z).
Verbosity of parameters: sampling_time vs dt
API consistency (at least for discrete-time system functions) vs 'improving' stuff
Should dbode return frequencies in rad/s?

I've come around to appreciating separate classes/functions for discrete and continuous, especially given that only the discrete systems can be used to filter data. (Maybe it's silly to care, but maybe the class should be named dlti, since all of the other discrete-time functions use d as a prefix rather than as a suffix.)
I do like the idea of being able to use both dt and fs, since we likely have users that are used to each. Naturally, this sets the expectation of enabling a similar capability and implies a fair amount of work, but maybe is warranted given the amount of things that need to be done to get to a v1.0 level of consistency anyways. This could probably be done in a quick follow-up PR though.
@befelix

I'm used to seeing inverse z powers. I think our conversion functions need some work anyways, so I wouldn't be inclined to give their precedents too much weight.
I think dt as a name is fine, we already use fs for sampling frequency.
Yeah, I think rad/s is appropriate, which means dt is needed. This actually strikes me as ok, so that the input system tuple to dbode is the same as one would use for ltid. (The standard WW comment: really it should be rad/[time unit] since dt/fs doesn't have to be in seconds/Hz to be valid). I suppose dbode and its kind could return rad/sample without knowing the sampling time, but the same is achieved with dt=fs=1.

@endolith

I agree on the the freq(s/z) point, see gh-6059

Zooming out a bit, I've been thinking that we need to get consensus on a concrete vision of what we want the scipy.signal API/landscape to look like, so that we can attack it in a more systematic manner, rather than trying to come up with the right design decisions on a PR-by-PR basis. Where would be the right place to do this? @endolith started a to-do list on the github wiki... maybe I'll send an email out to scipy-dev to collect more ideas/opinions, which can then be whittled down to something tractable.

Where would be the right place to do this? @endolith started a to-do list on the github wiki... maybe I'll send an email out to scipy-dev to collect more ideas/opinions, which can then be whittled down to something tractable.

I think the best approach would be for someone to take the time to:

Look at this issue and other related ones (second-order sections and related ones come to mind) where we've talked about this
Synthesize one or a couple different API proposals based on what's been discussed already, along with pros/cons that have been discussed
Make a GitHub issue dedicated to it (better than Wiki because people can comment)
Email the listserv to solicit opinions

A big problem with discussing these issues is that the information is scattered, and there are a lot of potential factors involved. So if someone takes the time to put together a proposal or a couple of proposals it could go a long way I think. I don't think it makes much sense to try to collect opinions from people until these ideas are distilled to such clear, succinct presentations.

@e-q @Eric89GXL

I've been thinking that we need to get consensus on a concrete vision of what we want the scipy.signal API/landscape to look like, so that we can attack it in a more systematic manner, rather than trying to come up with the right design decisions on a PR-by-PR basis.

I agree that would be helpful. Unfortunately I don't use the filtering part of the library enough to be helpful on this, but I'd be happy to be part of the discussion. Here is my opinion on this. I think it should work for most usecases, but like I said: I'm not familiar with all the functionality.
General

There should be not tuple representations of systems. Functions that take arbitrary system tuples followed by a conversion to lti/ltid should take only lti/ltid systems instead. Potentially, they should also only take systems for which there is code around, rather than implicitly doing conversions inside. That is, if the code only works for StateSpace systems, then only StateSpace systems should be accepted as inputs. At the very least, there should be a warning about the conversions in the docstring.
All transfer functions should be in terms of consistent variables, probably z**-1. Matlab's solution here is to take polynomials in z as inputs, but num/den are returned in terms of z**-1. Let's be better than that.

LinearTimeInvariant:

lti / ltid should not be callable. Instead, the subclasses should be used directly. This could be important if the subclasses become more sophisticated and take optional keywords.
(Optional) The system subclasses should not accept instances of other classes as input. Instead, the to_ss()/to_tf()/to_zpk() methods should be used. As a result, the API would read something like StateSpace(a, b, c, d, dt=None) rather than StateSpace(*system, **kwargs), which seems nicer (personal preference).

I like how this is shaping up @befelix! I'm on board with moving away from system-tuples altogether, though I will take @Eric89GXL's suggestion and start piecing things together for a discussion of API proposals.
I'm going to throw a question out here: Is it desirable to allow the creation of discrete-time system without defining the time step? I haven't personally run into this kind of use case, but that doesn't mean all that much...
Since dfreqresp is returning rad/sample, it doesn't need to know dt at all, which made me think of this.

At least in many filtering applications you don't need to know the time step. So I'd say do without it where we can, or default to 1. which will just leave units in rad/samp anyway. Or maybe dfreqresp should take the sample rate into account somehow... not sure.

keyword argument for sampling time or frequency (or even both).

Well it doesn't really matter if the argument is dt or fs; it's trivial to do fs=1/dt or dt=1/fs, so I don't think it needs arguments for both.  I'm just concerned about it using accurate values internally.  Usually sample rates are whole numbers and dt are not, so when combining systems that use dt, you'll be testing floats for equality, for instance?

TransferFunction in terms of z or z^-1 (dlsim and the likes assume z).

I would say both, since they're both used in different communities.  I started to add this to tf2zpk, for instance.  https://github.com/scipy/scipy/pull/4872

Verbosity of parameters: sampling_time vs dt

dt or fs is better than sampling_rate or sampling_time in my opinion.  docstring will explain it
Also how would these filter objects be designed?  Like how does butter(N, Wn, analog=False, output='dlti') know what sample rate to use in the object?
I've been thinking the different normalized frequencies used in different functions (radians / sample in some functions vs half-cycles / sample in others) could be harmonized by adding an fs= parameter anyway:
fs = 48000
f = linspace(1000, 3000, 100)

# Currently different
b, a = butter(4, 2000/(fs/2))
w, h = freqz(b, a, 2*pi*f/fs)

# Simpler to work with
b, a = butter(4, 2000, fs=fs)
w, h = freqz(b, a, f, fs=fs)

I've said somewhere before that I think the filter objects should be callable so it's possible to just create a filter and filter a signal with it, without caring how it's implemented.  It automatically uses the most accurate methods internally (generating as ZPK and then filtering using SOS, for instance).  Something like this:
sig = randn(48000)
# 2 kHz lowpass filter object
lowpass = butter(4, 2000, fs=48000, analog=False, output='lti')
filtered_sig = lowpass(sig)

There should be not tuple representations of systems.

What's the reason for removing them?  Functions like freqresp would not longer accept tuples?

At least in many filtering applications you don't need to know the time step.

I didn't realize python-control already has StateSpace and TransferFunction classes.  Are they different enough that we can't use them?
In theirs

dt=float is a discrete-time system
dt=True is a normalized-frequency discrete-time system(?)
dt=None is a continuous-time system

keyword argument for sampling time or frequency (or even both).

Well it doesn't really matter if the argument is dt or fs; it's trivial to do fs=1/dt or dt=1/fs, so I don't think it needs arguments for both. I'm just concerned about it using accurate values internally. Usually sample rates are whole numbers and dt are not, so when combining systems that use dt, you'll be testing floats for equality, for instance?

I actually had an implementation of having both dt and fs keywords, but then removed it since it seemed somewhat messy. Maybe a more appropriate way would be to have another keyword that just gives the unit of the sampling time - so people could pass Hz, s, etc.

TransferFunction in terms of z or z^-1 (dlsim and the likes assume z).

I would say both, since they're both used in different communities. I started to add this to tf2zpk, for instance. #4872

I agree that it should be possible to specify both, but the default value should be consistent, and the num den properties of the transfer function should correspond to that default. Otherwise the API becomes super confusing if for every function you first have to check which convention it expects. Btw, this is already a problem since dltisys expects z, but the filtering usually z**-1.

There should be not tuple representations of systems.

What's the reason for removing them? Functions like freqresp would not longer accept tuples?

My motiviation for removing them is that they create a lot of duplicate code. For example, if you now say that we could specify transfer functions both in terms of z and z**-1 then basically you need to add the corresponding keywords to any function that takes a linear system tuple as input. That's why classes exist in the first place - so that all the information about the system is in one place.
And yes, freqresp would not accept tuples anymore either if it was only up to me :)

I didn't realize python-control already has StateSpace and TransferFunction classes. Are they different enough that we can't use them?

So they follow the route of having one class that is the same for continuous or discrete time systems. There are a couple of reasons why I don't like this

Methods that only work for continuous-time systems will have to raise an error if called from a discrete-time system (e.g., to_discrete()). With the different classes in this patch this is not an issue.
If statements in every function to check if we're dealing with continuous or discrete time systems seem less clean to me.

Beyond that they use the system tuples and have a very matlab-focused style. Though it's good to know that they have operators (+/-/*) for all systems already implemented. I have a follow-up PR to this one that implements this for StateSpace systems, but since the code for all systems is already in this library one can probably draw inspiration from there.

In theirs
dt=float is a discrete-time system
dt=True is a normalized-frequency discrete-time system(?)
dt=None is a continuous-time system

I like the dt=True option, especially since it evaluates to 1 and all the code should work for this without modification.

Ok, I've started an issue about the broader issues at play. Let's focus on what we need to bring this PR through now. I like the dt=True suggestion, there should be something in the docstrings to talk about that.
Otherwise, I don't think there is anything else blocking this on my end. I'll take another look through it, but is there anything else you want to see done/changed here @befelix / @endolith / @Eric89GXL?

Nothing from my end.

@befelix: Do you have any time to make the adjustments for the dt=True option? Once that's done, I think this can be merged.

@e-q  Sorry for being so quiet. For me the main blocking issue is the question of whether the default should be z or z**-1 for the TransferFunction. Once merged this is difficult to change and the default should ideally be consistent between functions in the long term.
I'll take care of dt=True soon, though my guess would be that only docstring changes are required, since True is pretty much the same as 1.

Alright, dt=True is now part of the docstrings. Didn't require any changes to the codebase.
Is there any hope of getting this into 0.18? What more is needed to get this in?

I'll mark it optimistically for 0.18, since it seemed like the dt was the only lingering issue. @e-q will you have time to look again and merge if you're happy?

TransferFunction([1, 2], [4, 5], dt=1)
Out[28]:
TransferFunctionDiscrete(
array([ 0.25,  0.5 ]),
array([ 1.  ,  1.25]),
dt: 1
)

Does it have to normalize the coefficients?  I would expect it to keep them in the format that was entered, I think.

Does it have to normalize the coefficients? I would expect it to keep them in the format that was entered, I think.
So the old lti class normalized the coefficients. I think it's anooying too, but nothing to be done about this without breaking backwards compatibility. I think we could add a normalize=True keyword argument to the TransferFunction class, but this PR really only changes the way LTI systems are structured, not the way the classes work.

Was it going to have a system.fs property to get the sampling rate as well?
Left that for a future PR since this is already monolithic and it's not clear whether there should be a fs keyword or something similar to the unit keyword of Matlab.

I agree we can get this into 0.18, and I really want to make it happen
@endolith's perspective is a good barometer of what our experienced users will face. All of the classes' docstrings should have a concise instantiation example.
Options for not normalizing, adding a property for fs, etc. are not blocking for this PR. Some small follow-ons would be fine as far as I am concerned.

Thanks for sticking it out @befelix!

Also, for the record, my vote is for negative power polynomials - i.e. z**-1 form - since this is something I see more often in the literature.

Alright, I think most of @endolith's concerns should be adressed now. Also renamed ltid to dlti, which was mentioned way back but somehow forgotten.
Only question I have is whether we should expose the specific subclasses, such as StateSpaceContinuous, to the user. In the end there is no benefit to calling them over StateSpace, so it might just make the API seem a bit cluttered.

Also, for the record, my vote is for negative power polynomials - i.e. z**-1 form - since this is something I see more often in the literature.

@e-q I tend to agree. Only downside is that it doesn't play nice with the discrete-time simulation functions anymore (they take z). I'll see if I can make a commit for this tonight.

@e-q There's an implementation of z**-1 for Polynomials at https://github.com/befelix/scipy/commits/discrete_lti_zinv (latest commit). The only thing missing is a probler implementation of normalize for discrete time systems, but the hack around that is not too bad.
The main reason why I haven't merged this with the PR yet is that I'm a bit concerned how not-nicely this now plays with all the other LTI functions

Conversion functions only work for z, so there's a bit of back-and-forth going on there
The simulation functions take num/den with z, so transfer functions are now handled as a special case

A consequence of this is that all these functions behave differently when called indirectly from the class or directly. For example, TransferFunction(num, den).to_ss() and StateSpace(*tf2ss(num, den)) yield different results.
I think overall it may be better to stick with z instead of z**-1 for now, and migrate all functions together at some point in the future. What do you think?

Hm. Given the extent to which it implies modifying even more code, I'm inclined to agree that z is the better choice for now. We should open up a issue about this though, so that we don't lose track of it.

Hm. Given the extent to which it implies modifying even more code, I'm inclined to agree that z is the better choice for now. We should open up a issue about this though, so that we don't lose track of it.

Alright, I'll open an issue together with some follow-up PRs once this is merged.
So I think I adressed all of @endolith's concerns except for the question whether to expose subclasses such as 'StateSpaceDiscrete' to the user.
Let me know if there are any other concerns/questions. I would really like to wrap this up for 0.18.

I think there enough classes exposed without throwing in the whole zoo. By my count, we'll expose:

lti-> Any of the continuous system representations
dlti -> Any of the discrete system representations
TransferFunction -> Either continuous or discrete tf systems
ZerosPolesGain -> Either continuous or discrete zpk systems
StateSpace -> Either continuous or discrete SS systems

I'm happy with this as it stands, but I'll give people a couple of days to comment further. Barring objections, I'll merge it this weekend.

Only question I have is whether we should expose the specific subclasses, such as StateSpaceContinuous, to the user. In the end there is no benefit to calling them over StateSpace, so it might just make the API seem a bit cluttered.

I agree, better not to expose more classes.

I'm a bit late to the party, sorry. Overall this does look good to me.

Pulling the trigger, I applaud @befelix's efforts! Thanks to everyone for their input and reviews, as well.

Thanks a lot @e-q and everyone who helped reviewing!


Directory: Entire pages scrolls rather than just org grid

What did you expect to happen?
I expect that when scrolling with the cursor inside the organization grid that only the grid's contents will scroll.
What happened?
When scrolling with the cursor inside the organization grid in the Directory, the entire page scrolls. Additionally, when adding additional sample organizations, the page height increases.
Version
Pre-release (Development)
What browsers are you seeing the problem on?
Safari
Relevant log output
No response
Code of Conduct

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

This is addressed in #43

You're right, just saw that was fixed after merging #50 .


Fix 1.3 release test

Please provide a description for what this PR is for.
And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@howardjohn: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-tests_istio_release-1.3
5e407083aa2cf6f19daa53778c5f90f62f59f5fa
link
/test integ-mixer-k8s-tests_istio_release-1.3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Feature/dd tools

The changes introduced by that PR are intended to support direct deposits

Implemented a universal method directDeposit to deposit funds to the current account via direct deposit scheme (both token and native scheme are supported through the type parameter: DirectDepositType.Token\DirectDepositType.Native).

public async directDeposit(
    type: DirectDepositType, // DirectDepositType.Token or DirectDepositType.Native
    fromAddress: string,  // sender address to check approval and using as fallback address
    amount: bigint, // in pool resolution
    sendTxCallback: (tx: PreparedTransaction) => Promise<string>, // should returns txHash
  ): Promise<void>;

sendTxCallback will invoked to send transaction and PreparedTransaction is defined as following:
export interface PreparedTransaction {
    to: string; // dd queue contract address
    amount: bigint; // nonzero for native direct deposits
    data: string; // 0x-based hex string of encoded transaction
}

introduced new optional parameters in Pool configuration: isNative (boolean, should be set as true for WETH-pools to accept native direct deposits) and ddSubgraph (string, the subgraph name to fetching pending direct deposits, currently supported just zkbob-bob-goerli)
added method getPendingDDs to fetch pending direct deposits in the queue (available just for pools with configured subgraphs). It returns an array of DirectDeposit objects:

interface DirectDeposit {
    id: bigint;           // DD queue unique identifier
    state: DirectDepositState; // getPendingDDs will always return records
                               // with `DirectDepositState.Queued` state
    amount: bigint;       // in pool resolution
    destination: string;  // zk-addresss
    fallback: string;     // 0x-address to refund DD
    timestamp: number;    // when it was created
    queueTxHash: string;  // transaction hash to the queue
}

added method directDepositFee which returns fee for the direct deposit in pool resolution (as returned by queue contract)
added method directDepositContract to retrieve DD queue contract address from the pool
added method tokenSellerContract to retrieve token seller contract address from the pool (also available in account-lessmode)

This PR can be tested with associated console branch. Pending direct deposits are currently fetched just in BOB-goerli pool

The latest changes:

added support for the direct deposit limits (the data fetched from the contract directly until relayer doesn't support it)
added ability to use subgraph with arbitrary name. Currently deployed and tested: zkbob-bob-goerli, zkbob-eth-goerli and zkbob-bob-goerli-opt


remove --bare

--processing-platform or --catalog is sufficient

Replaced with --blueprint. Providing the flag is required, otherwise it's not possible to get a data policy that already exists for a certain processing platform.


intial commit

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


stop text overwriting cupcake

Summary
This pull-request provides margins around the cupcake image to stop the text over-writing it
Also updates the text to be more welcoming
Description for the changelog
stop text overwriting cupcake
Other info
Closes #602
Closes #604

This is just a suggestion for the text, please improve the contents @ChristopherHackett


[tokenizers] Upgrade huggingface tokenizers to 1.14.1

Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Codecov Report
Attention: 1376 lines in your changes are missing coverage. Please review.

Comparison is base (bb5073f) 72.08% compared to head (443775e) 72.05%.
Report is 895 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #2818      +/-   ##
============================================
- Coverage     72.08%   72.05%   -0.04%
- Complexity     5126     7098    +1972
============================================
  Files           473      702     +229
  Lines         21970    31683    +9713
  Branches       2351     3284     +933
============================================
+ Hits          15838    22828    +6990
- Misses         4925     7289    +2364
- Partials       1207     1566     +359

Files
Coverage Δ

...ava/ai/djl/inference/streaming/StreamingBlock.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/metric/Dimension.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/metric/Unit.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/modality/audio/Audio.java
100.00% <100.00%> (ø)

api/src/main/java/ai/djl/modality/cv/Image.java
69.23% <ø> (-4.11%)
:arrow_down:

...rc/main/java/ai/djl/modality/cv/MultiBoxPrior.java
76.00% <ø> (ø)

...ava/ai/djl/modality/cv/output/DetectedObjects.java
96.29% <100.00%> (+1.29%)
:arrow_up:

...rc/main/java/ai/djl/modality/cv/output/Joints.java
71.42% <100.00%> (ø)

.../main/java/ai/djl/modality/cv/output/Landmark.java
100.00% <ø> (ø)

...i/djl/modality/cv/transform/RandomResizedCrop.java
94.11% <100.00%> (+5.22%)
:arrow_up:

... and 225 more

... and 373 files with indirect coverage changes

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


tendermint-proto uses std features in dependencies

This is part of no_std support at informalsystems/ibc-rs#1158. Currently the tendermint-proto crate uses the features subtle-encoding/std and chrono/clock, which depend on std.
When the relevant features are disabled in #980, we would get compile errors like follows:
error[E0599]: no method named `format_with_items` found for reference `&DateTime<Utc>` in the current scope
  --> proto/src/serializers/timestamp.rs:82:20
   |
82 |     let prefix = t.format_with_items(PREFIX.iter());
   |                    ^^^^^^^^^^^^^^^^^ method not found in `&DateTime<Utc>`

error[E0425]: cannot find function `decode_upper` in module `hex`
  --> proto/src/serializers/bytes.rs:15:14
   |
15 |         hex::decode_upper(&string)
   |              ^^^^^^^^^^^^ not found in `hex`

error[E0425]: cannot find function `decode` in module `hex`
  --> proto/src/serializers/bytes.rs:16:31
   |
16 |             .or_else(|_| hex::decode(&string))
   |                               ^^^^^^ not found in `hex`

This has now been fixed.


RAM requirement

Hi there,
Quick sanity check perhaps...
I'm using this pipeline very successfully on a multipass Ubuntu instance . I can afford 4GB RAM since my system has 16GB.
I'm replicating the same instance for someone else, but the only difference is their instance can only be 2GB (since their machine only has 8GB).
We get the same error every time. At the deduplicate stage the pipeline gets killed.
I'm 99% sure that it's not a pipeline issue as the two instances are identical, except for the RAM. I'm using the exact same sequences too.
If it's RAM, is there a workaround for this perhaps?
*apologies if this is more a system requirement question than anything else.

I doubt this pipeline would run with such low memory available.  Many parts of the process require significant amounts of memory.  In routine use we are using 8-core 32GB RAM, and this allows for efficient parallelization.   The amount of memory required for deduplication is correlated to the size of the input file, so perhaps subsampling the input might allow that part to run, but then there would likely be insufficient data to generate a useable output.


move and run webrtc server to aws

after it has been tested in local we can move it to aws.

done and running


[AutoPR containerregistry/resource-manager] add Azure Container Registry policies api and update OperationDefinition

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/3094

(message created by the CI based on PR content)


Update README.md

Hi,
This small PR adds a link to get your app on F-Droid, and put the real link to the app on Google Play (it's always better ;) )
Fixes #59

Looks good 👍


sync upstream main branch to downstream

Sync the upstream changes from csi-addons/kubernetes-csi-addons:main into the
main branch. The most recent changes included are

doc: include badges in the README
vendor: bump github.com/kubernetes-csi/csi-lib-utils

/cc @agarwal-mudit @Madhu-1 @yati1998

/lgtm


#database-issues issue submitter

Map name: bhop_monster_jam
Issue: Short explanation of the issue. Tier {insert number here}, bad zones, cheated time etc.
Screenshot/Video: Optionally attach or link a screenshot/video to help explain the issue.

Create a modal for creating issues for the database-issues channel. Only problem is you can't attach images or videos with modals or slash commands so people will need to use links.

I can work on this

Before I get started on this, just want to check the flow of it.

User runs command in database-issues (can actually restrict permissions for this channel to only using commands and not sending messages I believe, which could be done)
Modal appears with fields for map name, issue, screenshot/video link
Embed is created in channel for a database manager to react to with a tick or a cross
OR
Create message in a database manager chat with embed and confirmation buttons (see #15 )
On button press, send embed to database-issues with details and outcome (potentially with the ability to add reasoning if denied, unsure if this is possible)

The flow should be something like this:

User runs the command and a modal appears with map, issue and screenshot/video url (optional) fields.
When the user presses submit an embed message with all the details is sent to the #database-issues channel. This message can so have two buttons, one for marking it as resolved and one for denying it.

#database-issues channel has been replaced with a "forum channel" so this is not really needed anymore.


Update README.md

Hey @baijunyao,
We still support all Laravel 5 versions (as long as they can run on PHP 7.1 and higher) in the most recent version and we support 5.7 and below in version 0.11.x for PHP versions below 7.1.
We never stopped supporting 5.6 & 5.7.
Would you be willing to update your change to reflect that? Possibly something like:
- Laravel `5.7.x` and below on PHP 7.0 and below is supported in version `0.11.x`
- Laravel `5.x.x` on PHP 7.1 and above is supported in the most recent version

Sorry, I modified.


Option to report source image errors

Apart from reporting unexpected and download errors, it would be useful to have an option to get reports when a source image exceeds for example the "max source resolution".
Would you accept a PR for an additional option for this?

Image format and resolution checks are a part of the downloading flow, so these errors are reported if IMGPROXY_REPORT_DOWNLOADING_ERRORS is set to true.

Hm that's weird, because we're not getting those reported in sentry. The only error we've seen was one for using an invalid path.
I'll check again tomorrow.

To get back at this; what could be a cause for a "Can't download source image: Source image resolution is too big" error not being reported (to Sentry), when other errors are?

Could it be because the resolution error is reported as warning instead of error?
{"client_ip":"x.x.x.x","error":"Can't download source image: Source image resolution is too big","message":"Completed in 55.089129ms /_/plain/tmp-koen/cloud.jpg?","method":"GET","request_id":"_QWMwXkE1T9SmXPld3dTk","severity":"warning","status":422,"time":"2024-05-19T21:11:48Z"}


Integration tests failing on latest build

Describe the bug
Integration tests fail
Installation method
AUR
Distribution
Plain Arch
Version
v1.6.9-4 through v1.6.9-6
Log
Running tests/integration_test.rs (target/debug/deps/integration_test-87ab0dbd66dd9f70)

running 17 tests
test job_continued_after_partial_completion ... FAILED
test job_panic_results_in_main_panic - should panic ... ok
test best_provider_selected ... ok
test downgrade_provider ... FAILED
test next_order_success_after_first_order_failed ... ok
test no_downgrade_if_all_providers_fail ... ok
test no_infinite_loop ... ok
test provider_lowest_score ... ok
test no_new_channel_established ... FAILED
test provider_reused_after_job_completed ... FAILED
test new_channel_established_because_channel_in_use has been running for over 60 seconds
test order_skipped_if_already_in_progress has been running for over 60 seconds
test provider_no_two_simultaneous_jobs has been running for over 60 seconds
test provider_two_simultaneous_jobs_if_required has been running for over 60 seconds
^C
==> ERROR: Aborted by user! Exiting...
==> Cleaning up...

To add more context: only integration tests seem to fail, I have disabled them in 1.6.9-7 package version.
I could not reproduce the integration tests failure, but at least two people had the issue: https://aur.archlinux.org/packages/flexo#comment-944300

@sovanyio can you please run this command and show the full output? From the output you have pasted, I cannot see why exactly the test cases have failed because you've aborted the command before it ran to completion, but the following command should hopefully show more details about why the test has failed:
cargo test job_continued_after_partial_completion

Sure thing, the tests hang indefinitely after the output I posted. Here's the output you requested:
I checked out the last PKGBUILD with the issue and it indeed hung, I opened a new terminal with the hung test still waiting and the command appears to complete successfully despite the makepkg test error in the other tab:
(f0f12a5) [130] % cargo test job_continued_after_partial_completion                     ~/.cache/yay/flexo/src/flexo-1.6.9/flexo
   Compiling autocfg v1.1.0
   Compiling libc v0.2.126
   Compiling pkg-config v0.3.25
   Compiling cc v1.0.73
   Compiling proc-macro2 v1.0.40
   Compiling quote v1.0.20
   Compiling unicode-ident v1.0.1
   Compiling syn v1.0.98
   Compiling crossbeam-utils v0.8.10
   Compiling openssl-sys v0.9.74
   Compiling libz-sys v1.1.8
   Compiling once_cell v1.12.0
   Compiling serde_derive v1.0.138
   Compiling memoffset v0.6.5
   Compiling memchr v2.5.0
   Compiling serde v1.0.138
   Compiling curl-sys v0.4.55+curl-7.83.1
   Compiling getrandom v0.2.7
   Compiling num-traits v0.2.15
   Compiling crossbeam-epoch v0.9.9
   Compiling num-integer v0.1.45
   Compiling scopeguard v1.1.0
   Compiling log v0.4.17
   Compiling crossbeam-queue v0.3.5
   Compiling aho-corasick v0.7.18
   Compiling rand_core v0.6.3
   Compiling serde_json v1.0.82
   Compiling itoa v1.0.2
   Compiling httparse v1.7.1
   Compiling curl v0.4.43
   Compiling ppv-lite86 v0.2.16
   Compiling regex-syntax v0.6.26
   Compiling rand_chacha v0.3.1
   Compiling crossbeam-deque v0.8.1
   Compiling crossbeam-channel v0.5.5
   Compiling atty v0.2.14
   Compiling time v0.1.44
   Compiling socket2 v0.4.4
   Compiling regex v1.5.6
   Compiling openssl-probe v0.1.5
   Compiling termcolor v1.1.3
   Compiling bytes v1.1.0
   Compiling same-file v1.0.6
   Compiling ryu v1.0.10
   Compiling rustc-serialize v0.3.24
   Compiling fnv v1.0.7
   Compiling humantime v2.1.0
   Compiling env_logger v0.9.0
   Compiling http v0.2.8
   Compiling walkdir v2.3.2
   Compiling crossbeam v0.8.1
   Compiling rand v0.8.5
   Compiling toml v0.5.9
   Compiling chrono v0.4.19
   Compiling uuid v0.8.2
   Compiling httpdate v1.0.2
   Compiling glob v0.3.0
   Compiling fastrand v1.7.0
   Compiling remove_dir_all v0.5.3
   Compiling flexo v1.6.9 (/home/brian/.cache/yay/flexo/src/flexo-1.6.9/flexo)
   Compiling tempfile v3.3.0
warning: fields `handle` and `state` are never read
   --> tests/integration_test.rs:252:5
    |
251 | struct DummyChannel {
    |        ------------ fields in this struct
252 |     handle: i32,
    |     ^^^^^^
253 |     collector: JobState<DummyJob>,
254 |     state: DummyChannelState,
    |     ^^^^^
    |
    = note: `DummyChannel` has a derived impl for the trait `Debug`, but this is intentionally ignored during dead code analysis
    = note: `#[warn(dead_code)]` on by default

warning: variable does not need to be mutable
   --> src/mirror_flexo.rs:757:13
    |
757 |         let mut job_resources = self.job_state.job_resources.as_mut().unwrap();
    |             ----^^^^^^^^^^^^^
    |             |
    |             help: remove this `mut`
    |
    = note: `#[warn(unused_mut)]` on by default

warning: `flexo` (test "integration_test") generated 1 warning
warning: `flexo` (bin "flexo" test) generated 1 warning (run `cargo fix --bin "flexo" --tests` to apply 1 suggestion)
warning: `flexo` (bin "flexo") generated 1 warning (1 duplicate)
    Finished test [unoptimized + debuginfo] target(s) in 1m 09s
warning: the following packages contain code that will be rejected by a future version of Rust: rustc-serialize v0.3.24
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
     Running unittests src/lib.rs (target/debug/deps/flexo-fff988cf3b9a49a1)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running unittests src/main.rs (target/debug/deps/flexo-1082c70548b1c681)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 10 filtered out; finished in 0.00s

     Running tests/integration_test.rs (target/debug/deps/integration_test-1d4a87438793122a)

running 1 test
test job_continued_after_partial_completion ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 16 filtered out; finished in 0.00s

For the time being, I'd like to close this and propose to the maintainer of the AUR package to just disable the tests. The tests were never intended to be run during the build process by normal users and don't provide much value there. Anyone who experiences those issues with test cases failing on their machine can provide more information to me if they want to, e.g. if you have some output that shows more than just which test cases have failed, but also why they have failed, please do so. But with the limited information available, and no way of reproducing this issue on my machine, troubleshooting this issue feels like going down a rabbit hole that just consumes much time for little value.


uncompiled files?

I downloaded the .zip of this repository, but I don't see the epub.qlgenerator files. Instead I get folders with .c and .h and .m files. Do I need to compile this somehow? I tried $ make but that didn't work...

Did you choose the source code link from the releases page rather than the epub.qlgenerator.zip?


Feature Request: People Directory - User filter

Category

[ ] Question
[ ] Bug
[x] Enhancement

Expected or Desired Behavior
The People Directory plugin is almost perfect! The challenge would be that i have a thousand or so users who are "guest" or "non staff" and i want to filter those users out. I would like to request a feature where the people directory can be limited to just staff based on some property (OU, metadata on the account, job title, group membership, etc)... really any way to filter them.
Observed Behavior
My entire o365 directory is displayed in this plugin, including users who should not be displayed.
Steps to Reproduce
Install plugin, notice that all users are displayed, irrespective of their employment status.
Submission Guidelines

Hi! Thank you. We can definitely add this as an enhancement if you'd like. You can actually do this yourself on the SharePoint People result source. The Web Part uses this result source to find employees. You should be able to add whatever KQL query you want on that resource source and filter our the results.
Here is a link to some documentation
https://docs.microsoft.com/en-us/sharepoint/manage-result-sources

I just tried to create a query for this but it broke search on the rest of the website :( and it still did not work.
Do you happen to know the syntax? I was trying like:
(contentclass:STS_ListItem OR IsDocument:True) WorkEmail:DOMAIN , which was scoped to the people picker only, as all the users i want are in a specific domain (there are service accounts in there too, but one problem at a time...).
However when i made it default for the site, all other search broke. Your web part does not seem to have a configurable searching scope like in this screen shot:
https://www.sharepointdiary.com/wp-content/uploads/2018/05/search-results-web-part-change-query.png (from https://www.sharepointdiary.com/2018/05/limit-search-results-to-specific-content-source-in-sharepoint-2016.html)
I am not a programmer so the fact that its open source code is irrelevant to me. Would be a nice feature to have in your product.

An active directory group i could do it on.
The users to be filtered out have their own AD group. They have a seperate domain (email domain, user principal domain).
cant do by title, there are too many. Most of the accounts i would filter have numerical usernames while the regular accounts i want to show up do not....

If you are looking for a guide on how you can clean up your people search, you might want to have a look at https://ms365thinking.blogspot.com/2023/05/sharepoint-people-search-how-to-clean.html

Well sure that would be great, if the plugin allowed you to use any sort of filtering. When i click to edit the webpart, all i get is  "no settings to change for this web part", so not sure exactly where i would type in these filter parameters.
I found one item at the following location that may be how i would filter for every query on the site (not the best, but would work for me)
site settings -> manage query rules -> "local people results service" -> "people name in people search"
however you cant edit that query rule, as i assume its built in(read only). Can you define a custom query rule and make it default for this? and the plugin would pick that up? maybe thats what you mean that i should do?

Hi, I am working on added a People Directory into the Starter Kit using the PnP Modern Search web parts. Perhaps you will be able to reuse some or all or this. I intend it to look like this:


Object ID (OID) for OpenWrt SNMP Device Tracker

Hi,
I used below configuration and Object ID (OID) for SNMP device tracker in my OpenWrt router and it seems working.
device_tracker:
  platform: snmp
  host: <IP_ADDRESS>
  community: public
  baseoid: <IP_ADDRESS>.<IP_ADDRESS>.1.2

Tested on Chaos Calmer rc3 and final version firmware.
I simply install snmpd package, made no change on the config file, and it works out of the box.
Hope somebody can also test and confirm whether the above OID is really working or not.
Thanks!

Sorry wrong place, should propose this in the documentation section.


Duplicate URLs with trailing slashes

Google is indexing eg. both /roadmap and /roadmap/

The website is already doing the right thing by redirecting non-trailing-slash URLs to their trailing-slash equivalent. Google will figure it out.


Working on content management

The 1st update is related to the fact that an item can have duplicate version numbers.

Save a published item as a Draft
Discard this Draft through the admin.
Save again this item as a Draft.
You get a duplicate version.

So here, when creating a new draft version, we retrieve the highestVersion which is not necessarily the latest item if a draft has been discarded. Then the new version is assigned to the highestVersion + 1.
The 2nd update is related to the following pattern.

Update an item and do a yesSql session Save().
Do a yesSql session QueryAsync().
Update again the item.
The last update is lost if there is no other session Save().

So, because handlers could do queries and / or updates, here session Save() are done as late as possible, after handlers, explicit queries .... This to prevent, as much as possible, from losing updates.

Just for infos.

This PR fixes an issue where an item get a duplicate version number on Save / Publish if, previously, a draft  has been discarded.

Some session save have been moved but this can be easily reverted if we prefer a more global solution.

That said, in the current code there is already a bad pattern. Even we only call BuildNewVersionAsync() on a Latest item, in the code we assume that this could not be the case. If so, we do a query to retrieve the real Latest item on which we do .Latest = false, but then there is no session save on it.

React to yesSql changes in master branch

See #931 which, for simplicity, only fixes duplicate version numbers.


Transactions appear to be committed before the end of promise chain

Hi there,
Been using knex for a bit and thoroughly appreciate the efforts of everyone involved; it's a great tool.  Recently, an issue was illuminated by an automated test, revealing a race condition.  We tracked the issue down to a transaction. Here's a code sample:
return knex.transaction(function (trx) {
    return functionThatSelectsForUpdate(trx)
        .then(function (dbRows) {
            return functionThatUpdatesRows(dbRows, trx);
        });
});

The above transaction would not necessarily wait for functionThatUpdatesRows to finish before committing the transaction.  Adding an empty .then at the end of the promise chain fixes the issue we were seeing:
return knex.transaction(function (trx) {
    return functionThatSelectsForUpdate(trx)
        .then(function (dbRows) {
            return functionThatUpdatesRows(dbRows, trx);
        })
        .then();
});

I can only assume then that indicating to knex that further work is to be done, and that the further work depends on functionThatUpdatesRows being finished, ensures that the transaction is committed at the proper time.
Please note that I tried using .then(trx.commit) as per the knex documentation, but this presented further issues ("error: transaction already completed") since the trx is implicitly committed by knex.
Please let me know if this is user error on my part, or if you require any further information to help resolve this.  Thanks!

If functionThatUpdatesRows() returns a promise that will get resolved once the DB operation implemented in that function has been completed, then there should be no need for the extra .then() call.
And even if you are returning a knex object representing an SQL query, but not actually running it, it should get run by knex by hooking its own .then() handler to it.
So I can't really see what could be causing it from your description. Can you prepare a simple example reproducing the behaviour you're describing?

I can certainly try.  I'll work on putting something together that reproduces the issue. May take some time. Thanks!

This was actually an alternate issue in the implementation, not the fault of knex whatsoever.  The knex documentation is outdated regarding implicit trx.commit, but that's a separate issue.
Thanks!

@egalpin actually there are two separate examples, where other requires explicit commit and another one relays on implicit commit depending on promise result... I don't know what you mean by document being outdated?

@elhigu Thanks, read the doc wrong.  Your comment prompted me to re-read, during which I found that "... if a promise is not returned within the handler, it is up to you to ensure trx.commit, or trx.rollback are called..." (emphasis mine)


i18n(fr): add install-and-setup.mdx

Description (required)

Translate install-and-setup.mdx (added in #8415) in French

Related issues & labels (optional)

Suggested label: i18n

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

fr
install-and-setup.mdx
Localization added, will be marked as complete.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


Change read activity to a service

According to this answer.

Ended up injecting it in ErbilActivity in 7decc11e1de5f7d6eba3fc56b56b2d9e2b4d9d59, since the NfcVReaderTask needs access to the context.


improve(ci) Report the files with unused lines removed.

Useful in the CI, on failure this would now be reported
total lines removed: 2
Files with unused lines removed: ['src/trace_ng/logfmt.zig', 'src/trace_ng/level.zig']

I think seeing the files is as important (if not more?) as seeing the total lines removed.

It's a funny coincidence that you just posted this pr, because I was working on something similar last night. This script's output could use a lot of improvement. Please take a look at my pr and let me know what you think.

Closing in favour of https://github.com/Syndica/sig/pull/269


Error:make: *** No rule to make target 'build/kernel_mean_field', needed by 'all'.

Hello,
I can run mnist successfully, but met error when i run graph_classificationas follow:

Can anybody help me ? Thanks!

Hi,
If you build the graphnn in CPU mode then this Makefile won't find the library.
I've just fixed the Makefile (remember to config the CPU/GPU mode in the Makefile first). Please pull the latest version.

Hi,
The code can run after update the  Makefile .
But I still meet some issues:

The error means I still use GPU mode?

make sure the 'USE_GPU' flags in Makefile and the make_common are the same.
also try to recompile gnn library, in case of any inconsistency.

I modify the mode to 'CPU mode' and the issues fixed.
Thank you very much!!!


Custom TableComponent is not loading the other components, just TableComponent

Custom TableComponent does not load all the other components. I understand this is not a bug, or an issue with react-table (I'm new to React - started today). I have tried overriding the TableComponent, so the HTML is of a valid table rather than div's (for compatibility with Bootstrap's tables). However, when I override the TableComponent, none of the other components load apart from a "loading" div, and the TableComponent - which obviously suggests that I've missed something in my custom component, I also tried looking at the source but i do not have a sufficient understanding of React yet to fully understand what's going on here to make my custom compoment load the other components like in the source.
https://codepen.io/anon/pen/QvBgJg

The default component originates from here:
https://github.com/tannerlinsley/react-table/blob/master/src/defaultProps.js#L168
Which builds a standard through-put component with a class here:
https://github.com/tannerlinsley/react-table/blob/master/src/utils.js#L122
Which results in this component:
TableComponent: ({children, className, ...rest}) => (
   <div
     className={classnames('rt-table', className)}
     {...rest}
   >
     {children}
   </div>
 )

This is a pretty standard pattern.  Its basically a div component that takes the props given to it, changes a few small things (in this case, the className is decorated with rt-table), then applies any other props (via ...rest). So you will probably want to do something like simply change the div to table:
TableComponent: ({children, className, ...rest}) => (
   <table
     className={classnames('rt-table', className)}
     {...rest}
   >
     {children}
   </div>
 )

You will also need to do the same for any other components you need to override (particularly rows and cells).  Bear in mind though, I don't recommend changing the underlying html components as things will be prone to break (like column flex and column sizing). I'm not familiar enough with bootstrap table styling to know exactly what needs to be done, but give it a try!

@tannerlinsley Cheers, so if I just override every component, they'll automatically be loaded in with each other?

Correct! As long as you render the component with rightclassName and children, the layout will be handled automagically :)

@tannerlinsley Thank you for the example above, but they're still not working for me. Can you take a quick look and my updated codepen to see if you can spot an amateur mistake I've made?
https://codepen.io/anon/pen/Omwjzx
Thanks!

Oh you were so close!  Just needed to use this.props for class syntax. Also, classnames is a module that you'd have to import, so I changed it to use a more simple approach.  This still doesn't work fully, since you still need to replace all of the other html elements.  You'll see an error in the console where React enforces that you don't mix non-table elements inside of table elements. Good job and good luck!  Join the slack org if you have more questions :)


show tag keys returns empty rows

Bug report
System info: InfluxDB 1.5 built from standard docker container, inmem indexes.
Steps to reproduce:
I updated from 1.4 to 1.5 on a large system with multiple databases.
Since the upgrade, I noticed that on some (but not all) of the databases, a "show tag keys from
Looks like a regression from 1.4.
Here is actual output, with names redacted.
> show tag keys from "autogen"."meas"
name: meas
tagKey
------

tag1
tag2
tag3
tag4
tag5
tag6
tag7
tag8
tag9
tag10

@scotloach do you have some test data that can be used to reproduce this issue?

Reproduced with the following:
CREATE DATABASE ""
USE
INSERT cpu,tag0=v\, value=1
SHOW TAG KEYS

Results in:
name: cpu
tagKey
------

tag0

Also, rather than this being a formatting issue, it looks like the index is seeing multiple tag keys:
> SHOW TAG KEY CARDINALITY
name: cpu
count
-----
2
>

Yet:
> SHOW SERIES
key
---
cpu,tag0=v\,
>

It's affecting both inmem and tsi1. I have confirmed it's not in 1.4.


Add checkstyle rule for constants

Summary of the changes / Why this improves CrateDB
Enables the ConstantName  checkstyle rule.
Checklist

[ ] User relevant changes are recorded in CHANGES.txt
[ ] Touched code is covered by tests
[ ] Documentation has been updated if necessary
[x] CLA is signed
[x] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

retest this please


Obj-C import issue

I'm following this apple guidelines still I'm getting Knock import issue in Objective C code
Please guide me how to import in Objective C app delegate

@bytes-mahavirsinh Can you share the error that you are getting?


Add two-input decoder example

I added one of the first examples of a composite gate from a lecture on digital circuits, the decoder. It reads n inputs and asserts exactly one of 2^n outputs, sort of like a switch statement over all input combinations. I built the one with two inputs from Not and And gates.
Are there any tests for examples? I could not find any.

@maurobringolf, just an FYI: I setup an ability to test custom gates when a new example is added in #27. Feel free to add a test for the Decoder in case.


Test thumbv8m.base on Travis CI

This will fail until #155 is resolved

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ithinuel (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Hi, I have approved #167 for merge, when it lands I will merge this too to have base type CIed as well.

bors r+


Add information about the token distribution to InfluxDB

Description
We already have a MongoDB query for retrieving the token distribution. We should also push this information to InfluxDB to make it possible to analyze changes in that distribution over time.

This is one of the slowest queries, one of the worst ones to make incremental, AND a difficult one to display in grafana. Not sure this is worth it.

Yeah, I agree with everything you wrote, but it seems to be something people are interested in (I myself find it quite interesting, too).

Good points @Alexandcoats! I have a good way how to visualize them in mind for Grafana, so that shouldn't be a problem. Regarding the performance, with #949 we can run queries only for certain timestamps, so how about we only compute this distribution on a daily basis? @Alex6323 is right, this metric is very important to the IF.


Py-EVM: Roadmap ideas From Retreat

This is a list of features brainstormed for Py-EVM (some already exist as issues)

JIT
Stepping Debugger
Smart contract coverage metrics
Batch trie updating (performance bottleneck)
EWASM
C-extension and low hanging fruit perf optimizations.
Benchmarking/Profiling suite
Reduce **kwargs usage in APIs
Trace level debugging.
Stateless client support
Remove "pending" block architecture
Standardize base trie

@pipermerriam maybe we could open separate issues for the stuff that is still pending and close this?


How about coffeelint?

I thought that would be great use [CoffeeLint] (http://www.coffeelint.org) for a checking of our code. This tool may prevent a lot of bugs and help to improve code quality. What do you think about it?

nooooooo

@alexbiblyj Why not?

I think, it's a good idea.

Great! Let's use coffeelint.
@vov4yk-bratyk Can you please write about it in our documentation?

no


[FEATURE] Use Python 3.9's Annotated[T, *metadata] (PEP 593) to describe parameters

Is your feature request related to a problem
Not really, the current solution is already great.
The solution you would like
Add an alternative syntax to describe optional parameters, PEP 593's Annotated[T, *metadata]. Now, strictly speaking of syntax, it's not much better, but it's built into python, and thus might help integration with IDEs in the future.
Help for optional parameters could be provided as the second argument of Annotated:
def my_action(a: str, b: Annotated[bool, "description"], c: Annotated[str, "output"] = "~/.config/"):

is equivalent to
def my_action(a: str, b: bool = Argument(..., help="description"), c: str = Option("~/.config/", help="output")):

As a bonus, there's no need to do a weird thing: type = Argument(..., help="description") when you want to specify help without giving a default value, just do thing: Annotated[type, "description"]
Also, it might be a little easier to implement since there's no messing with default values.
An Annotated parameter to the function will resolve to:

Argument if it has no default value
Option else

Describe alternatives you've considered
Making it always resolve to Argument or always to Option, or use something like Annotated[type, "description", form=Argument for arguments and Annotated[type, "description", form=Option] for options. I'm not sure about this.
tbh this is debatable, but I figured I'd throw the idea out there, since this shiny new python 3.9 feature could be useful to Typer, as it seems that the use case described in the PEP is fitting:

This PEP adds an Annotated type to the typing module to decorate existing types with context-specific metadata. Specifically, a type T can be annotated with metadata x via the typehint Annotated[T, x]. This metadata can be used for either static analysis or at runtime. If a library (or tool) encounters a typehint Annotated[T, x] and has no special logic for metadata x, it should ignore it and simply treat the type as T.

— PEP 593, python.org

It would be very useful. Cant wait implementation.

+1 for implementation. Can I help in any way? Is there any option to plug-in typer with this functionality?

Similar PR in FastAPI repo hasn't been merged yet, it's possible this is waiting for Pydantic-Core to be released more broadly (I know Sebastian and Samuel Colvin talk :yum:) to fix this at an even more fundamental level.

Hello there! This was implemented in https://github.com/tiangolo/typer/pull/584, here are the new docs: https://typer.tiangolo.com/tutorial/arguments/optional/#an-alternative-cli-argument-declaration, it's available in Typer 0.9.0, just released :rocket:


Syntax hightlight doesn't work well with multiline template string js

The highlight doesn't work in all htmk if I use the template string, only the first line

indeed...

it's the "data-bind" that is not handled. "databind" would pass (for the color, not the html)


Move security policy to own file

Redo of PR #4, which was accidentally undone by a subsequent commit.
/cc @sachinprasadhs

Copybara import is failing, it needs to be handled internally, I have created a CL with the same changes.
Closing this PR, will update in this thread once the CL is merged.


CSS Building Fails on RHEL 7

On Red Hat Enterprise Linux 7, CSS Building fails in both DEV Environment mode and PROD environment mode. The following is kicked back from the server shell:
Javascript build complete. python build/build_css.py --config-environment Configuration in config.py specified a prod environment. Compiling SCSS in minified mode. CSS build started. Compiling CSS app/static/scss/stylesheet.scss --> app/static/build/css/stylesheet.css Traceback (most recent call last):   File "build/build_css.py", line 79, in <module>     '--style', style,   File "/usr/lib64/python2.7/subprocess.py", line 524, in call     return Popen(*popenargs, **kwargs).wait()   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__     errread, errwrite)   File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child     raise child_exception OSError: [Errno 2] No such file or directory make[1]: *** [default] Error 1 make[1]: Leaving directory/home/REDACTED/public_html/onepaste'
make: *** [all] Error 2
[root@nexus01 onepaste]#
`
I have noticed the instructions for Modern Paste are for Ubuntu and Debian like all other private "pastebin" style scripts. Is this script even compatible with Enterprise Linux? I would think it would be once all the correct tooling is in place (yum groupinstall 'Development Tools'). Other environmental factors you should be aware of is that this is naturally being installed to a web server under its own subdomain.
We're trying to install this script to support our the gathering of log files for our very popular skin developed for the Kodi and Emby projects as most people do not feel comfortable sharing to pastebin.com (with good reason).
We have replicated this on 3 different RHEL 7 servers and a RHEL 7 VMWare vSphere Enterprise Plus VM.

The installation instructions are indeed Debian-oriented as that as the only environment I've tested this on. That said, there should be no reason that it wouldn't run on enterprise Linux provided you have installed all the dependencies as you said.
As for the make failure, it's possible that the sass build step itself is failing because the sass executable isn't in PATH. I would guess this is why the script raises "no such file or directory." Can you try
(sudo) gem install sass
which sass  # should exit 0
sass app/static/scss/stylesheet.scss:app/static/build/css/stylesheet.css --style compressed

In your traceback, it looks like the SCSS source directory is missing scss and has a mispelling of stylesheet. You have
sass app/static/stylesheet.scss:app/static/build/css/styleshee.css --style compressed

Can you try
sass app/static/scss/stylesheet.scss:app/static/build/css/stylesheet.css --style compressed

(This references a SCSS file in the repository tree)
If this succeeds, I'd be happy to accept a PR with notes on getting the make process working on RHEL.

Sorry about that, I do that when having a lot of server connections open to different servers around the world. I did correct it by simply pasting it into PuTTy to prevent the mistake. It seems to succeed when doing it like that but when you run the sudo make process, the build still fails at the same position so I ran a backtrace of the stylesheet build which didn't report anything:
[root@nexus01 onepaste]# sass app/static/scss/stylesheet.scss:app/static/build/css/stylesheet.css --style compressed [root@nexus01 onepaste]#
Likewise, in the build process:
Javascript build complete. python build/build_css.py --config-environment Configuration in config.py specified a prod environment. Compiling SCSS in minified mode. CSS build started. Compiling CSS app/static/scss/stylesheet.scss --> app/static/build/css/stylesheet.css Traceback (most recent call last):   File "build/build_css.py", line 79, in <module>     '--style', style,   File "/usr/lib64/python2.7/subprocess.py", line 524, in call     return Popen(*popenargs, **kwargs).wait()   File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__     errread, errwrite)   File "/usr/lib64/python2.7/subprocess.py", line 1327, in _execute_child     raise child_exception OSError: [Errno 2] No such file or directory make[1]: *** [default] Error 1 make[1]: Leaving directory /home/REDACTED/public_html/onepaste'
make: *** [all] Error 2
[root@nexus01 onepaste]# sass app/static/scss/stylesheet.scss:app/static/build/css/stylesheet.css --style compressed --trace
[root@nexus01 onepaste]#`

@NorthernLights where is your sass? /usr/local/bin?
Add /usr/local/bin to $PATH and try again.

Looks like the issue here is that /usr/local/bin is in $PATH for current user. But it isn't for root. So when you trying "to sudo" something like "sudo make" from installation instruction sass isn't accessible from $PATH.

To fix this issue I did the following:
┌─[✗]─[jfoots@paste]─[~/modern-paste{master}]
└──> sudo which sass
which: no sass in (/sbin:/bin:/usr/sbin:/usr/bin)
┌─[✗]─[jfoots@paste]─[~/modern-paste{master}]
└──> sudo cp /usr/local/bin/sass* /usr/sbin/
┌─[jfoots@paste]─[~/modern-paste{master}]
└──> sudo which sass
/sbin/sass

After that the sudo make command finished accordingly. You could add that to $PATH as suggested above but it would be better to install sass so that it goes to sbin, if you didn't do that (like me) cp into the dir works just as well.


radix sort in c++

i want to take this issue..
radix sort is one of the best sort...

Merged.

@amul123 : Can you move the algorithm to appropriate folder


[iTerm] Binding raw escape sequence not work

Description of the problem or steps to reproduce
When trying to use "Alt-Delete" in iTerm to delete a Word, I added another keybind which would map raw escape sequence "Ctrl-Delete" to Delete Word on Left.
I added in the ~/.config/micro/bindings.json
{
    "\u001bctrlback": "DeleteWordLeft"
}

When I start to use micro it says
`
± |master U:1 ✗| → micro ~/.config/micro/bindings.json
Unknown keybinding:
trlback
Press enter to continue
`
Is there anyway to capture the "escape sequence" sent from iTerm to micro debug. Thanks.
Specifications
You can use micro -version to get the commit hash.
Micro version: 1.3.3
Commit hash:
OS: MacOS High Sierra
Terminal: iTerm v3

And one more thing, when I added custom keybind
{
    "Alt-s": "Save,Quit"
}

In Micro, I run it showed up the symbol "ß" instead, I don't understand how to debug the keybind in micro.

To get Alt-s to work, you should go to iTerm2 Preferences->Profiles->Keys and set the option that says Left option key to +Esc. This way iTerm will send Alt key events to micro instead of doing the default MacOS thing of inserting unicode characters.
Binding raw escape sequences was added after the release of 1.3.3 so if you want that functionality you should download one of the nightly binaries or build from master.

Thank @zyedidia, it worked, I think we should add the note to change the iTerm Profile Keys to use "Left Options as +Esc", so people can face the same problem as me.


vimPlugins: clean up overrides

Description of changes
Since #241328, we are now able to use overrideAttrs with an attrset instead of a function. This utilizes that and simplifies vim overrides

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 241712 run on x86_64-linux 1


aries run can create jobs with the same name when specifying a node list

The commands below effectively creates jobs with the same name:
run -g 0 -n aries-00 jet-dev jetd/basic-cuda12.1 -- bash -c 'sleep infinity'
run -g 0 -n aries-01 jet-dev jetd/basic-cuda12.1 -- bash -c 'sleep infinity'
run -g 0 -n aries-02 jet-dev jetd/basic-cuda12.1 -- bash -c 'sleep infinity'

When not specifying a node list, this will return [error] 14 container of same name already exists! instead (not sure if this behavior is consistent or depending on scheduling).
Another behavior is when you kill jet-dev, all jobs with the name would be killed without warning.
A skim into the client code suggests these behaviors are due to the ws server-side design. Can you clarify if these behaviors are expected?

This is indeed not expected, need to be fixed. I think the check in run is incomplete when specifying node list.

Fixed now. Thank you for the report.


TFLite model maker object detection training is too slow in colab

Click to expand!
Issue Type
Bug
Have you reproduced the bug with TF nightly?
Yes
Source
source
Tensorflow Version
TFlite model maker 0.4.2
Custom Code
No
OS Platform and Distribution
colab
Mobile device
No response
Python version
No response
Bazel version
No response
GCC/Compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current Behaviour?
In colab I have enabled 'fallback runtime version' since with Python 3.10 model maker was not installed successfully.
After enabling this option I am able to install it successfully.
Nut when I started a object detection training with 'efficientnet_lite4', it is showing 35/2122 [..............................] - ETA: 6:08:03 - loss: 0.7095 - accuracy: 0.5509 which is keep increasing.
Please help to solve this issue.
Standalone code to reproduce the issue
My training command is as below-
`model = image_classifier.create(train_data, validation_data=validation_data, model_spec=model_spec.get('efficientnet_lite4'), batch_size=32, epochs=50, train_whole_model=True, use_augmentation=False, use_hub_library=False, model_dir='/content/drive/MyDrive/expi')`

Relevant log output
No response

@pjpratik Have you checked this issue in colab?

Hi @dsbyprateekg
Sorry for the delayed response.
I have tried the object detection tutorial on model maker on colab and found no issue while training. I have used efficientdet_lite0 as the model with 5 epochs.
Please find the gist here and let us know if it helps.
Have you enabled GPU and tried with lighter versions as well?
Thanks.

@pjpratik when I used your shared gist to install, I got following logs-

But when I checked version of tflite model maker, it showed me following error-

My colab env is as below-

Hi @dsbyprateekg
Have you tried enabling fallback runtime option ?
Please check this work around for the installation.
Thanks.

Hi @pjpratik , After enabling the fallback option I am able to install but my issue is the same.
It is taking too much time to complete one epoch.
My current dataset has 42000 images and previously I did the training with 32000 images. That time it took 2-2.5 minutes to complete one epoch.
Do you think it is GDrive+Colab issue due to large size of images?


setRating

when setting a high rating lets say 5 the stars show as 5 but if we then later setRating to a lower rating like 4 the stars UI does not change but stays as the higher rating which is 5

Here you find decsision https://github.com/nashio/star-rating-svg/issues/50#issuecomment-683367989


Backoffice: styles in form and tables

If I wanted to check this out, what is the URL endpoint for backoffice? It is started with the same scripts/run_server.py script, right?

python3 -m scripts.run_server --server=backoffice


Clarify the meaning of declared version for publication

I was thinking that it would be nicer to just explain this clearly in the text directly without a NOTE. Maybe:

Maven and Ivy publications support two strategies for publishing dependencies with versions:

declared versions (default) - This strategy publishes the versions that are defined by the build script author with the dependency declarations in the dependencies { } block.
Any other kind of processing, for example through <<customizing_dependency_resolution_behavior.adoc#,a rule changing the resolved version>>, will not be taken into account for the publication.
resolved versions - This strategy publishes the versions that were resolved during the build, possibly by applying resolution rules and automatic conflict resolution. This has the advantage that the published versions correspond to the ones the published artifact was tested against.

And the I think it is better to add this to the Ivy Publish and Maven Publish chapters as introduction to the Customizing dependencies versions chapter. I think it is too much detail for the (very abstract) What to publish overview. I think I would remove the topic there completely (i.e. remove the sentence In addition, Maven and Ivy publications support publishing resolved versions of dependencies instead of declared ones.).
Wdyt?

@jjohannes I have updated the change, based on your suggestions.