Needs to stop watchdog in puppet implementation

Is there a way to stop the watchdog in puppet implementation? I want to stop the watchdog in wechaty-puppet-hostie so I can deal with reconnection logic when the server is temporary unavailable.

Of course.
You can make your dog sleep by calling: dog.sleep().
See: https://github.com/huan/watchdog/blob/master/src/watchdog.ts#L238

But watchdog is a private property of wechaty-puppet, it can not be accessed from puppet implementations. Shall we make it protected?

Oh, yes it should be private.
I remembered that there's another way to stop the dog: feed it some poison foods...
Let me try to find it out...

After I reviewed the code, I believe the watchdog should not be stopped, even you are doing a reset operation.
The reason why it should not be stopped is that when you are doing a reset, there's also have a risk of we get out of the control of our code, which should be monitored by our watchdog too.
So my suggestion would be:
When you are doing a reset process, you can create a timer to feed the dog by emitting events that it requires.
Please let me know if you think this solution can be accepted, or we can continue discussing it.
BTW: I'm thinking about to refactor the watchdog system in the past months. So any workaround would be acceptable.

The reason that I raise up this issue is because I was adding the reconnect logic in wechaty-puppet-hostie.
The watchdog is not initially active, for example, during the start phase of wechaty-puppet-hostie, if the grpc client failed to connect, there will be no any heartbeat events, but the watchdog won't complain, I think there is a mechanism that the watchdog won't work until the first food is feed.
But if the puppet is reset from some reason, and the grpc client can not be connected, during the reconnect phase, the reset will be triggered, and there will be double reconnect process, this is why I came up with this issue to discuss if we can stop the watchdog in puppet implementation.

I understand that we need to deal with watchdog related states when enhancing the reconnect logic for our wechaty-puppet-hostie.

The watchdog is not initially active, for example, during the start phase of wechaty-puppet-hostie, if the grpc client failed to connect, there will be no any heartbeat events, but the watchdog won't complain, I think there is a mechanism that the watchdog won't work until the first food is feed.

Yes, your analytics is absolutely right. My suggestion is that we can feed the watchdog inside the start call. The watchdog would be active after it has been feed for the first time.

But if the puppet is reset from some reason, and the grpc client can not be connected, during the reconnect phase, the reset will be triggered, and there will be a double reconnecting process, this is why I came up with this issue to discuss if we can stop the watchdog in puppet implementation.

Yes, that's the problem that I was facing when I was writing the wechaty-puppet-puppeteer.
My solution is to save the reset status in another variable, and when we call reset(), we need to check whether there's another resetting task is running, and if so, the reset should deal this situation right.
I believe the above suggestion would be able to solve your problem, please feel free to let me know if I have missed anything.

I would consider before start, the puppet is in off state, and watchdog is not active in off state. But if we do a reset, which means a stop then a start, we can not bring the puppet back to the off state.

Yes, I understand.
As you suggested before, I believe the most convenient way for you now is to change the watchdog in Puppet from private to protected, am I right?
If so, please go ahead and feel free to submit a PR to change it as you want, I'm OK with it.

Cool, will submit a PR later.

I went through the whole issue again, and I think the best solutions should be that the wechaty-puppet has it's own start and stop implementation, so we can manage the watchdog state in the start and stop method. All puppet implementation could override the implementation or don't have to declare it at all. But this would introduce breaking changes to all puppets.

I think your override solution is great.
And I can not understand why it will introduce breaking changes: they did not exists before so I think there will no breaking changes at all?

And I can not understand why it will introduce breaking changes: they did not exists before so I think there will no breaking changes at all?

Because currently the start and stop is an abstract method. So if we change it to a real method, will this break the current logic?

Could you please explain that why changing a abstract method to real method will introduce a breaking change?

I am not quite sure whether it will introduce breaking change or not, so would like to know your opinion.

I went through the code in wechaty-puppet, came up with a solution below:
Solution
The code below is in the wechaty-puppet constructor() function, I think we should put it into start() function, so we can also clear these resources in the stop() function.
    this.on('heartbeat', payload => this.watchdog.feed(payload))

    this.watchdog.on('reset', lastFood => {
      log.warn('Puppet', 'constructor() watchdog.on(reset) reason: %s', JSON.stringify(lastFood))
      this.emit('reset', lastFood)
    })

    /**
     * 2. Setup `reset` Event via a 1 second Throttle Queue:
     */
    this.resetThrottleQueue = new ThrottleQueue<string>(1000)
    // 2.2. handle all `reset` events via the resetThrottleQueue
    this.on('reset', payload => {
      log.silly('Puppet', 'constructor() this.on(reset) payload: "%s"', JSON.stringify(payload))
      this.resetThrottleQueue.next(payload.data)
    })
    // 2.3. call reset() and then ignore the following `reset` event for 1 second
    this.resetThrottleQueue.subscribe(reason => {
      log.silly('Puppet', 'constructor() resetThrottleQueue.subscribe() reason: "%s"', reason)
      this.reset(reason)
    })

Issue
If we move these code from constructor() to start(), the current puppet implementation will need to add super.start() and super.stop() into their corresponding functions. If they don't have it, some resources won't be initialized. So this will be the breaking change.

I think the above solution is the ideal implementation for our wechaty-puppet, but we need to move to it gradually, so we can do this:

add an implementation for start() and stop() function without moving those initialize code from constructor() to start().
update all current puppets with super.stop() and super.start().
move logic from constructor() to start().

@huan Let me know what do you think about it.

Thanks for your solution proposal, I feel that it's the right direction we should follow.
In order to implement your code movements, I agree with you that we need to add super.start() and super.stop() in our Puppet Provider classes.
In addition, I think we can make the upgrade process to be very easy by just bumping the minor version of our WechatyPuppet class to the next developing version so that the current Puppet Providers classes should not be affected by the new changes at all.
Please feel free to go-ahead to implement your idea when you are comfortable with it.

@huan I just submitted a PR related to the topics we discussed above, and I think we can close this issue after we merge that PR :P

Let's close this issue since we have perfectly solved the problem with #108


Email notifications?

(via a call with Sita today)
Sita said:

Is there way to maybe send a notification to the user when there server times out? Sometimes I forget when I kicked on my server

I think we could do this, though it's not not complex. 😉
(i think) we'd need something (some server space, FH infra or a tiny EC2 VM) to keep track of things and do stuff:

be able to access all users that are using the app
be allowed to send emails to those users
at simplest run a cron job every X hours/days to check if an email should be sent

The title of the issue is broad since I imagine there's more things than the original question which might want an email notification.
FH has pretty aggressive email filtering though, so I wouldn't be surprised if we had some headache getting emails to not get blocked .
cc @sitapriyamoorthi

@vortexing i'm guessing this is a lower priority item in the grand scheme of things. thoughts?

This would be a likely large effort with relatively low adoption/payoff.  Most people likely don't want to get an email, but would rather see when they log into the app, some evidence that they already have a server running.  Given the repairs with the server spin-up and monitoring from SciComp, I'd guess this actually will no longer be needed once you can go to proof.fredhutch.org and see whether your server is still running or if you need a new one.

Sounds right

@sckott this feels like a proofapi issue to me now rather than a shiny-cromwell issue.  No?

As @vortexing mentions above, I think this feature would be too large of an effort with too little of a payoff. It's easy enough to see if your server is still running via the "PROOF Server" tab, and if it's not, starting up another one is a click of a button on the same page. Closing this as "not planned".


Annotate MethodChannel on Android with @UiThread

Today the methods on MethodChannel are the public API often used by plugin developers and advanced users. There is no indication that these methods are supposed to be called from the UI thread even though the mechanisms they rely on in FlutterJNI.java are marked as such.
Let's mark them as @UiThread such that this is less of a surprise for developers.
Tracked internally at: b/132204137

Closed via https://github.com/flutter/engine/pull/8947


Fix Issue 16544 - Add File.reopen

https://issues.dlang.org/show_bug.cgi?id=16544

Current coverage is 89.24% (diff: 94.28%)

Merging #4822 into master will increase coverage by <.01%

@@             master      #4822   diff @@
==========================================
  Files           121        121
  Lines         75908      75943    +35
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits          67744      67777    +33
- Misses         8164       8166     +2
  Partials          0          0

Powered by Codecov. Last update 5813fac...8d87494

LGTM

thx!


refactor: teams v2

fixes: #1013
I just have to add a fix for routing edge cases, apart from this it's good to go. I will do that by tomorrow; gotta sleep now. 😴

Seems like directly accessing the internal docs from the Project Proposal page redirects back to the home page. Is this intended?

@jamessspanggg  It has been moved to Teams > All > Resources. I have removed it from there now.


Provide better logging

by default unless suppress with something like --quiet

compile info
dependency lookup info

debug:

script and jar paths
compile logs

E.g use https://gist.github.com/goodmami/6556701

won't fix


fix NaN(s) error in SH tests

This tries to fix the constant errors on both GPU and CPU CI for shearheating. The tests pass both locally and if re-run on the CI.
Shearheating3D: Error During Test at /var/lib/buildkite-agent/builds/amdgpu1-luraess-com/julialang/justrelax-dot-jl/test/test_shearheating3D.jl:239
  Got exception outside of a @test
  NaN(s)

Current solution to the problem:
try
    iters, thermal = Shearheating3D(igg; nx=nx, ny=ny, nz=nz)
catch e
    @warn e
    try
       iters, thermal = Shearheating3D(igg; nx=nx, ny=ny, nz=nz)
    catch e2
       @warn e2
    end
 end

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Additional details and impacted files

:loudspeaker: Thoughts on this report? Let us know!


Failed to get Gerrit messages: Unauthorized

Failed to get Gerrit messages. Request not successful. Message: Unauthorized. Status-Code: 401. Content unauthorised.
I have no issue with using Gerrit outside of the plugin. I have used password from  Gerrit | HTTP Credentials | Generate new password
Using Gerrit Code Review Version V2.14

@boardtc Have you also tried your "normal" Gerrit credentials? Or are you using some type of single sign on system?


pull in wasi-libc in prep for release 11

WIP: this points at the pause branch, waiting for https://github.com/WebAssembly/wasi-libc/pull/162 to merge to master

#162 is now merged, so this is unblocked.


Move to iojs org?

See iojs/io.js#544 for background.
I think we want to encourage people to switch to nan.  Moving it to https://github.com/iojs gives off a clear signal that it's the blessed approach.  Thoughts?
/cc @kkoopa @rvagg

Sure, that makes sense in a way. But should iojs/io.js then bundle a suitable version of nan? Can we still release  new versions independently?

Congratulations!

:+1:

I agree with blessing nan, but I'm not sure it'd be a good idea for it to be bundled with io.js itself.
One might draw parallels to npm being a separate thing that gets bundled with it. But development of npm moves forward in terms of support, while nan effectively moves backward from each version.
The API surface that native modules have to interact with may change over time to support the same past version due to subtle differences introduced in newer versions.

But should iojs/io.js then bundle a suitable version of nan?

I don't think so.  nan would remain an independent project, evolving at its own pace.  It would be living under the iojs umbrella mainly for messaging reasons (and perhaps better visibility and easier coordination, although that's working pretty well already.)

How to proceed?

I think @rvagg has to initiate the move.

Yeah, been stalling on this to see how the other working groups evolve. TBH, and I know this probably seems silly to some, my biggest beef has been the strong adoption of "codes of conduct" which I don't believe belong in this arena (IMO they are useless at best and toxic at their worst, save them for conferences) and I don't really want to see that forced upon this project.
I think I would interpret the current wording "The WG is free to change these documents through their own governance process," as meaning they can be ditched if desired. I'm just one voice on that anyway and perhaps you all love these things.
Can I get a +1 from active collaborators please?

@bnoordhuis (assumed from this thread)
@kkoopa (assumed from this thread)
@brett19
@agnat

Please review https://github.com/iojs/io.js/blob/v1.x/WORKING_GROUPS.md to see if it's something you can agree to.

+1

I agree with Rod on the code of conduct. I assumed the io.js code of conduct applies to io.js only. The working groups document states that "The WG has final authority over this project including: [...] Conduct guidelines", so that should mean we don't have to adopt them.
I don't, however, care too much for the weekly meeting point. It's worked fine without weekly meetings for the past two years. Enough of us are in meetings already.

agreed on the meetings, we've got a pretty good github workflow going on here

+1 and agreed we can do without the CoC and weekly meetings.

+1

+1

Looks like everyone is OK with it. What's keeps this from moving?

Just had a thought because the io.js Spanish team want to translate my https://github.com/rvagg/node-addon-examples repo--we should just pull that project in with NAN and manage them together as the NAN team, let me know if there are any objections to that but this'd be a perfect role to extend what we're doing here.

I think the examples should be merged with nan and be updated alongside any changes to nan. On top of that, nan should be elevated to be a part of the io.js organisation (and eventually be shipped with io.js).

Spanish team want to translate

I'm curious here, any info about it? What if someone else wants to do the same, but to another language?

@JCMais https://github.com/iojs/iojs-es/issues/78 is the original issue
You should consider joining an io.js language team if you have translation skills. Respond here: https://github.com/iojs/website/issues/125

welcome to iojs/nan and the @iojs/addon-api team folks. @kkoopa, @brett19 and @agnat you should all have invites to join the org, let me know if you have any trouble with it.


NIFI-1874 Added Character Set Detection to IdentifyMimeType

Added mime.charset FlowFile attribute when not null for text MIME types

This is a backport of #8011 for NiFi v1.x.

Summary
NIFI-1874
NIFI-4550
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[x] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[x] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[x] Pull Request based on current revision of the mainsupport/nifi-1.x branch
[x] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[x] Build completed using mvn clean install -P contrib-check

[ ] JDK 21

Licensing

[x] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[x] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[x] Documentation formatting appears as expected in rendered files

Perfect,  thanks @exceptionfactory. 👍🏻


Fix headlines

Coverage remained the same at 100.0% when pulling 14ba7816f130796e00dfb148662b133d19204a07 on feature/headlines into 887d78ad8ebedfeedeb5c6cba5882b6619e07365 on master.


[Synonym] photoreceptors

CL term
CL:0003050 'S cone cell'
Synonyms to be added
(exact, PMID:32555229) S cone
(exact, PMID:32555229) S-cone
(exact, https://doi.org/10.7554/eLife.39166) S-cone photoreceptor
(exact, https://doi.org/10.7554/eLife.39166) short- (S) wavelength-sensitive cone

CL term
CL:0003049 'M cone cell'
Synonyms to be added
(exact, PMID:32555229) M cone
(exact, PMID:29603924) M-cone
(exact, https://doi.org/10.7554/eLife.39166)) middle- (M) wavelength-sensitive cone

CL term
CL:0003048 'L cone cell'
Synonyms to be added
(exact, PMID:32555229) L cone
(exact, PMID:29603924) L-cone
(exact, https://doi.org/10.7554/eLife.39166)) long- (L) wavelength-sensitive cone

Additional synonyms after another cursory review:
short wavelength sensitive cone
short-wavelength sensitive cone
S-(short-wavelength sensitive) cone
middle wavelength sensitive cone
middle-wavelength sensitive cone
long wavelength sensitive cone
PMID:31117170
short-wavelength-sensitive (S) cone
middle-wavelength-sensitive (M) cone
https://opg.optica.org/josaa/abstract.cfm?URI=josaa-6-1-153
long-wavelength cone
https://doi.org/10.1038/323623a0


Improve idle holding behavior through the use of a channel-based interface

This addresses #562 by creating a channel interface where user code can register channels as semaphores and hold IJulia from firing the 'idle' message.  Also sets the timeout to 0 by default.  Interact.jl compatibility as discussed in #491 is also checked for and naively waited on so that it works until Interact.jl updates to use the channel interface to hold until necessary.  Hope this helps.
If a new type or something is needed, that works for me, I just used the most basic level-trigger that Julia has in the base docs.
Also could use assistance with an error path in case one of the semaphores times out (aka some way to indicate to the user which semaphore was causing issues and where that semaphore came from)

@yuyichao @JobJob @stevengj

I looked at the errors on the appveyor tests, they don't appear to be related to my code, but rather something about ZMQ not being installed correctly.  Take a look and let me know if that's indeed the case or if I need to change something to play more nicely.

Yeah, the appveyor tests have been broken for a while and I haven't gotten around to fixing them.

Apart from the error paths, a future issue that I would be willing to work on (but also could use assistance with) is that I don't have a solid testing scheme for this yet, so I would like to add some test cases to /tests to ensure continuing functionality.

Notwithstanding the hyperbole in the original issue, which I could only laugh at, this seems good!
Comments:

IJulia will process more execute_request messages (and the frontend will send them, e.g. if you run multiple cells) even if the status:idle hasn't been sent for a previous cell, so actual performance in the notebook, i.e. the vast majority of usage (~= all use cases besides yours 😄 ), isn't degraded by the existing behaviour. You can test this out by setting the idle delay really high, to say 10 seconds, and running multiple cells in a notebook.
#491 is a workaround for what I think can be fairly regarded as a bug in the frontend. We would happily send the idle asap, but if we do, output can get lost if there's an intervening comm_msg. Having the delay is a super simple solution that may help other packages that also use custom comm_msgs without them having to make any changes, with no real downside, or so it seemed. Nonetheless, this PR, whilst more complex, seems to be a neater and more powerful solution, so thanks!

I'll hopefully get a chance to look at it in more detail (and try it out) over the weekend. I'll probably make the necessary changes to Interact myself.

I will admit I was probably a little more annoyed than was really warranted in the original issue, but to me it was just that a large portion of the reason Julia exists is for performance concerns, so to me when I asked myself "which should be the fastest Jupyter kernel?" I immediately thought of IJulia.  So then to learn it was two orders of magnitude slower than it really had to be, it was quite a letdown considering pretty much everything in Julia is by default orders of magnitude faster than a language like Python.

@stevengj How do you feel about the modifications thus far?  Are any other revisions in order?

These are my thoughts after taking a closer look at this.
I see the cases this PR might touch are:

Regular case: normal synchronous code execution and output
Long running asynchronous tasks where comm/other messages are sent as well as output
@JMurph2015's case: wants to receive the idle as soon as possible
Interact case: output truncation in "slightly asynchronous" cases (output happens from an asynchronous task which runs very soon after the cell code is run), where other messages are also sent, such as the comm messages of Interact*

* when a new, e.g. comm, message is sent after the idle is received, Jupyter's javascript in the browser removes the output display handlers, so stdout/stderr stream messages aren't displayed.
How this PR affects these cases:

No effect AFAICT
I was hoping it would help here, and that this would be the payoff, but it doesn't at present, because of the hold_channels_timeout_default
Helps, although currently case 3 is fine as long as you call IJulia.set_idle_delay(0.0)

Regarding case 4, this is currently handled with the default 0.5s delay. Handling all the code paths required to correctly use the channels in this PR seems like it might get complicated.
To me it seems like just calling IJulia.set_idle_delay(0.0) to handle case 3, is going to be simpler than manually working out where Interact/Reactive (and possibly other packages) need to hold and release the semaphores, to handle case 4 (e.g. PlotlyJS uses it's own custom comm channel and may possibly run into it). To me it seems case 4 affects more people, and might be difficult to get right using the mechanism in this PR, and case 3 has a fairly simple workaround.
@JMurph2015 - is there a reason why you're so averse to using IJulia.set_idle_delay(0.0), what if we set it up to use an environment variable - would that make your life easier? e.g. put "IJULIA_IDLE_DELAY" in keys(ENV) && IJulia.set_idle_delay(ENV["IJULIA_IDLE_DELAY"]) in kernel.jl ?
However, if this PR could be be adapted so that the default delay was left at 0.5s, but provided a reliable mechanism in case 2, for indefinitely delaying the status:idle from being sent, then I'd be on board.
Overall, even though this PR is neat work, it may put a burden of effort on other packages, and I guess I still don't really see a major downside to delaying the idle by 0.5s by default. Nonetheless, a mechanism to indefinitely delay the idle would probably be useful for some cases. But I completely understand if you don't feel like continuing down that path if it doesn't serve your aims.
Having said all that, it is just, like, my opinion 😄 and I'm open to counter points.

@JobJob I'm mostly opposed to the IJulia.set_idle_delay() on principle.  Sure one could work around it without a ridiculous burden, but every other Jupyter kernel behaves as if IJulia.set_idle_delay(0.0) was the default (or if this PR was accepted).  Furthermore, Julia being a language that functionality just doesn't get implemented if it compromises speed, it would make sense that as much as possible we would push possible slowdowns as far down the stack as possible ( remember IJulia is installed on pretty every Julia install ).
Therefore, if Interact or Reactive need to have some funky delay mechanism, I have no problems making a hook for them to do that, but I do have a problem with IJulia doing it for them.  In fact this new interface could use a hook for IJulia to signal a 'idle' message sent event, so that Interact could just set up an async routine that waited for that signal, then waited 0.5s, then released IJulia, wash-rinse-repeat.
Secondarily, I'm opposed on principle to delay mechanisms anywhere in code where it is just trying to approximate the runtime of an async routine.  There is definitely something that you are waiting on, so the rub is just finding it and being able to put essentially a callback on it.  Interact should have some "comm-signal" pipeline, and the trick is to just register the semaphore somewhere in the setup process, clear it at the beginning of the pipeline, then trigger it at the end of that "comm-signal" pipeline.  Now, I did take a look at the Interact code, and I will say this looks tricky without being able to hook into some of the code outside of the ijulia.jl file there.
MIT has a hacking rule "Brute force is the last resort of the incompetent", and I generally apply that to code as well. http://mitadmissions.org/blogs/entry/practice_safe_hacking, which leads us to...
Three takeaways from my side here:

It may be somewhat harder (and in some cases legitimately difficult) to implement semaphores, and it should be made serviceable to just fire off a delay async routine. These async routines would live in other packages' code, and Interact could use something like this until we find the exact points where the semaphore can be effectively used.
The semaphore system, while more complex, is the best at keeping IJulia fast and elegant, which is somewhat more important than keeping Interact's and React's hands clean.
Considering the pains taken to make other parts of the Julia ecosystem as fast as possible, the speedup and elegance of this is well worth our effort even if we have to rewrite a couple files or add some callbacks to some functions.

PS Interact and React could've actually implemented stuff on their end in the first place that would make sure that their main threads waited for side-jobs to finish in IJulia contexts which would have eliminated this issue before the days of the IJulia.set_idle_delay()

Also I just processed what you meant about use case (2).  Yeah, so I wouldn't mind some way to indefinitely hold IJulia, but it's just that it would really mess things up if someone abused it, because then things go very badly.  I'm open to suggestions on how long that hold_channels_timeout_default should be, and also could be convinced to open up an interface to changing that value.

I appreciate, and share, your aim to improve code quality across the Julia ecosystem. I guess this issue comes down to the trade-offs that are acceptable to people doing the work. My view is IJulia is fast - it just doesn't send the idle fast and I don't see that as a major problem (c.f. https://github.com/jupyter/notebook/issues/518).

"Brute force is the last resort of the incompetent"

I also think there are other maxims of programming that apply:

premature optimisation is the root of all evil (in this case I see it as more unnecessary than premature)
done is better than perfect
real artists ship

😄
Anyway, I personally am ok with the status quo, but if you want to finish this up and make a PR to Interact - I think probably just adding a hold, then async release of the semaphore after, e.g., a 0.5s delay, in all the handle_msg methods in https://github.com/JuliaGizmos/Interact.jl/blob/master/src/IJulia/handle_msg.jl should (inelegantly but simply) work - then great!

I wouldn't mind some way to indefinitely hold IJulia, but it's just that it would really mess things up if someone abused it, because then things go very badly

I actually don't think it would be that bad - not sending idles is not a big deal is it? If someone is using this system then it's up to them to get it right IMO. I.e. I don't think there should be a timeout at all, which would enable people with arbitrarily long running processes (and other intervening messages) to avoid losing their output.

I'll add a hook so that packages can listen in on when IJulia is sending 'idle' signals.  Then I'll just add an @async task to Interact.  I think that is the simplest right now, and makes it possible for other packages architect around channels in the future (it's simpler to include this sort of thing on the ground floor of a package.)
Secondarily, has anyone seen the Summer of Code project on Interact https://summerofcode.withgoogle.com/projects/#5415076583440384?  Could we have them consider this from the get-go on that project?

I'll add a hook so that packages can listen in on when IJulia is sending 'idle' signals. Then I'll just add an @async task to Interact.

Sounds good!

Secondarily, has anyone seen the Summer of Code project on Interact https://summerofcode.withgoogle.com/projects/#5415076583440384? Could we have them consider this from the get-go on that project?

Yep, I'm intimately familiar that work 😉 All the IJulia related stuff is happening in WebIO now.

I feel like there should be a single semaphore that user code can increment when it wants Julia to wait before idling, and decrement when they are ready to idle.  Why do we need multiple channels?

Uh, so oops on my git skills, I had some stuff I was testing, forgot it would push to this PR when I pushed to my fork, and here we are (after some squashing that didn't really even help).
I can also look into the Reentrant lock business.  I'm kinda partial to my Event type, for obvious reasons, but my favorite reason is because I solved a race condition of code listening for an IJulia "ready to send" signal and IJulia starting the waiting process on their hold (possibly before it was cleared), so I tossed a "persistent" field on the type to designate which should be cleared on every loop (by IJulia) and which should be left alone.  That way people can either hold in reaction to IJulia being ready or just hold whenever they want, like at the start and end of an async routine.

Also, I'm not too averse to dropping the timeout, that was mainly in the principle of isolating potential bugs from say an imported package from holding up functionality of the rest of the running code (via this feature at least).  Although overall, the odds of that seem low, and it's not the end of the world.

Putting aside the timeout, can't we use a simpler semaphore-like implementation?  A task increments an idle counter when it is not idle, and decrements it when it is, and the main task waits for the idle counter to hit zero before sending the idle message.  i.e. something like:
const busycount = Ref(0)
const idlecond = Condition()
function busy()
    busycount[] += 1
end
function idle()
    busycount[] -= 1
    notify(idlecond)
end
function waitidle()
    while busycount[] > 0
        wait(idlecond)
    end
end

Then tasks that want IJulia to wait before idling would call IJulia.busy() and then IJulia.idle() when they are done.

The only problem I have with a straight counter is that it doesn't distinguish by "user".  For example
Task 1:
IJulia.busy()
...
IJulia.idle()
Task 2:
IJulia.busy()
...
IJulia.idle()

is equivalent to
Task 1:
IJulia.busy()
IJulia.idle()
IJulia.idle()
Task 2:
IJulia.busy()

So maybe some registered increment/decrement would be good?

If task 1 calls busy once and idle twice, that is a bug; I'm not sure we need to protect against this.   As long as tasks correctly match the count of busy and idle calls, we don't need to distinguish the count by user.

(This is a low level interface that relatively few packages, possibly only Interact, will be using; it's not like this is an API for end users.

Okay, that's fair, I'll do some refactoring tonight.

So I took it a touch more complicated than your example, just so that I could overload the Base.wait function and use that.  It's just a type with some barebones functions defined for it, namely Base.+, Base.-, wait, and notify.  I think it adds a nice layer of abstraction where, in the loop, in busy(), and in idle(), you use it just like a counter, but in the loop's wait() call and in the wait_for_ready() it behaves like a Condition.

Defining a type and overloading + etcetera seems like overkill to me for a type that is used in literally one place.
My suggestion requires exactly 15 lines of code (14 lines of definitions and one call to waitidle()), whereas you are adding more than double that.

I just liked using the Base.wait function. :/
I can either pull the overrides on + and -, and make them custom methods, or pull out that type entirely...
Also I did miss that your wait_idle probably doesn't actually block anything except the current green thread.  (Sorry, I've been using Python 3.6 too much recently, and its native async is substantially more verbose)
We still have to accomodate a hook for listening in on the loop so that this sort of workaround is tractable
@async begin
    while true
        IJulia.wait_for_idle_ready()
        IJulia.busy()
        sleep(0.5)
        IJulia.idle()
    end
end

This was the proposed short term solution for Interact.jl-side compatibility, and having two semaphores kinda justified the type in my head, even if it wasn't going to save many lines.

I don't see that it's worth implementing a timeout.  Just accept that if a package is buggy and calls busy but never calls idle that it will hang IJulia.   There's no point in protecting against this, since if a package just calls sleep(1e10) it will also hang IJulia.
I think IJulia's execute function should just replace sleep(idle_delay[]) with
sleep(idle_delay[])
wait_idle()

and then at some point after Interact is updated we remove the sleep line

So the "quick fix" @JobJob and I were talking about is that Interact should just have an async process that would hold IJulia for some arbitrary amount of time, every time IJulia is otherwise ready to send an "idle" message.  Therefore, that means one needs some way of knowing that IJulia is ready for this rigamarole so that they can start something like a half second timer, after which they release IJulia.
This exactly mimics current behavior (at least from Interact's point of view), but moves the burden of deciding how long to wait to Interact.  That is why there needs to be some facility for processes to "listen in on the loop" (IJulia's eventloop) so that they know when to start timers (or other things potentially).
The timeout functionality has been entirely removed at this point.

Thanks @JMurph2015 for your good work on this and keeping Interact's workload in mind. I actually had a chance to look into where Interact could use the semaphore today.
It would need to call IJulia.busy() the line above here: https://github.com/JuliaGizmos/Interact.jl/blob/master/src/IJulia/setup.jl#L54
And then run this:
@async begin
    sleep(1.0) # 1.0 to be safe
    IJulia.idle()
end

the line below here: https://github.com/JuliaGizmos/Interact.jl/blob/master/src/IJulia/setup.jl#L61
The cases for Interact are surprisingly hairy, without the above (or the current delay) the following code sometimes truncates the error message:
p = Signal(0.0)
push!(p, "1") #error because "1" is a String and p is a Float64 Signal
p

If we don't use the async sleep, we could handle this case by putting the IJulia.idle() call in the Reactive event loop along with a test to see if there are more Reactive events to process, but that might not handle some other cases too well...
Anyway, @JMurph2015, your solution addressed our previous concerns more thoroughly, and if I hadn't spent a while looking into it today (which I probably shouldn't have, got a lot on my plate), the listening in on the idle workaround would have been very helpful as a stop-gap for Interact, so thank you, and sorry I have been a little too busy to look into this more.
I guess the above changes to Interact will work with both of the above solutions (I presume - just quickly tested with @stevengj's and it seemed to work). So regardless of which is decided, I'm happy if any Interact specific code is removed. I'll be able to get the required changes into Interact by mid next week.
I do think the simple option for other packages offered by the code in this comment is a nice pro. Whether it justifies the extra complexity (given that maybe no-one will ever use it), I'm not sure. Happy to defer to the acuity of @stevengj's judgement.
Just FYI to you both, probably no need to address it in this PR, but as it stands the code will send multiple idle messages when the triggering IJulia.idle is called, which isn't a problem afaict, just thought to let you both know.
Ok, thanks again for your efforts to improve things and reduce the burden on Interact to conform @JMurph2015. Could be nice to put your LevelTrigger stuff into a package.

@JobJob, if Interact does sleep(1); IJulia.idle() then doesn't it defeat the whole purpose of this PR by imposing a fixed delay on every idle status when Interact is loaded?
I thought that the point of this PR is that Interact knows when it is safe to idle.

So the idea, was that Interact should know when it is safe, but it was going to take some work to make sure.
There were two short term fixes that would move IJulia from just arbitrary delays that we have come up with.  The first was to just check if Interact was loaded and wait, and the second was to change Interact to use a delay itself (via the new interface).  However Interact can't do anything until IJulia changes its interface, and even then it will take a similar process of discussing and such to get a final solution done.  Not to mention it is getting completely restructured this summer.
Thus, both the short-short term*, the short term, and the long term solutions are all in there.  It's not my favorite thing either, but generally breaking things isn't good for a PR's chances to get approved.
short-short term:  Before Interact has an PR and update to support using semaphores at all
short term: Before we find the best way to make sure Interact holds IJulia properly
long term: IJulia doesn't have arbitrary delays (at least in our code) and Interact knows how to properly trigger the semaphores.

Oops, I didn't read @JobJob 's last comment, so I deleted my last comment saying pretty much what he said.

Briefly reading Interact's code, I thought it would be safest to overload a method or two on their base types (like Comm?) such that pushing to them etc. was automatically padded with IJulia hold and release code.  But I could be totally wrong there.  But, I didn't see any automatic showstoppers that would lead to Interact not knowing where to release.

@shashi, can you comment on this?

@JobJob, if Interact does sleep(1); IJulia.idle() then doesn't it defeat the whole purpose of this PR by imposing a fixed delay on every idle status when Interact is loaded?

No, the init_comm method where we'd put the idle delay (links to code in previous comment) only gets called when a Signal is displayed, either through a call to display or as a result of a cell. So the sleep before idle will only happen in those cases, certainly not on every cell execution once Interact is loaded.
tl;dr of the below: very boring information about the intricacies of Interact and Jupyter stream messages. I guess we should merge a simple version of this PR, since it might help, and shouldn't harm.
Some more info about the scenario: when this code runs
p = Signal(0.0)
push!(p, "1") #error because "1" is a String and p is a Float64 Signal
p

Here's some notes on how it plays out:

javascript(js): send execute_msg
Julia(JL): IJulia: run the code, note the Reactive.push!(p,"1") is async, and that error message originates from Reactive.
JL: metadata(x::Signal) (defined here) called as part of displaying the Signal as result of cell

calls JL:init_comm(x::Signal)

JL: IJulia sends result of cell
JL: send idle (exec req)

js: receipt of idle after an exec request means Jupyter will no longer append stream (STDOUT/ERR) messages to the cell when the stream message explicitly specifies the parent_header associated with that cell's last execute request.

Subsequent stream messages would normally still be displayed under the last cell executed, but this mechanism is interrupted by the interceding comm message - details below.

js: Signal value being displayed causes Interact/setup/ijulia.js to send a "subscribe_mime" custom comm message: tells the Julia side of Interact which mimetype Jupyter chose to display the value with, so it knows which mimetype to send to update the value with when it changes.

js: the sending of comm message causes Jupyter to overwrite its last sent message (the execute_request), and it stores a mapping between the last sent message and the display area to append output to, essentially stopping any future comm messages from being displayed. Annoying, but true.

JL: receive the "subscribe_mime" msg, processed by handle_subscriptions (sub)
JL: send idle (subscribe_mime req)
JL: possibly still sending the error message as a stderr stream message

After this PR Julia can delay the idle by calling IJulia.busy() at step 3.i, delaying the idle of step 5, and call IJulia.idle() with a delay after step 7, so that 8 happens after  9.
I personally don't see where Interact can decide it's ok to (immediately) send the idle. You can look at it as Interact (or any package that initiates comm messages in the browser after the execute message) "breaking" IO in Jupyter (thanks to Jupyter's annoying behaviour) in step 6, so we need to find a workaround.
The global delay was a perfectly fine solution, and part of me feels this whole PR was an over-engineered solution to a problem that barely existed that has taken up a lot of time for little immediate gain. But we're here now and I think this PR can actually help Interact under certain timings of the above (certainly increasing the delay in that particular case to 1.0s may help - though I suppose we could've done that with set_idle_delay). It may also prove useful for other packages in future that wish to get their stream messages under the correct cell by explicitly setting the parent_header and delaying the idle.

note the Reactive.push!(p,"1") is async, and that error message originates from Reactive.

I don't see why the error message would have to be async.  Why doesn't push! throw an error message?  i.e. why isn't push! defined something like:
push!{T}(s::Signal{T}, x::T) = .... whatever ...
push!{T}(s::Signal{T}, x) = push!(s, convert(T, x)::T)

in which case convert will throw an exception immediately?

In that case, yes the error could be sync, but it's just a toy example. There can be many errors that result from the value propagating through the signal graph. e.g.
using Interact
s = Signal(1)
m = map(sqrt, s)
push!(s, -1)
s

Maybe Interact should catch the exception and send a Jupyter error message instead of writing to STDERR?

The exception is caught in Reactive here, asynchronously, and the error message is written to STDERR by the default error handling function here. What happens in the front end when you send this message?
If you define a custom error handling function to push!(s, -1; onerror=custom_err_fn) - you can see the details with ?push! so you could easily try sending the error.
I'm now thinking possibly a better solution is for Interact to assume Jupyter is going to use the richest mimetype, i.e. guess the mimetype, and have Interact's ijulia.js only send that "subscribe_mime" comm if it got its guess wrong, I bet that would be rare.

What happens in the front end when you send the error message?

It does exactly what you want.  Because the error message includes the triggering execute_msg in its header, then the error gets printed in whatever cell that execute_msg came from.
For example, I tried running the following code in IJulia, which waits for 5 seconds and then sends an error message.
cur_execute_msg = IJulia.execute_msg
@async begin
    sleep(5)
    try
        error("foo")
    catch e
        IJulia.send_ipython(IJulia.publish[], IJulia.msg_pub(cur_execute_msg, "error", IJulia.error_content(e)))
    end
end

Even if I execute another cell before the error message is sent, the error message is still attached to the original cell:

I found if I add an IJulia.set_idle_delay(0.0) at the top, it doesn't work on second and subsequent runs. It does work though if you leave the idle at the default 0.5 - probably because by the time Jupyter receives the idle (after the 0.5 sec delay), the next cell has executed so it associated that idle with the second cell, and cleans up its output area handling rather than the first cell's.
I also found the behaviour to be the same replacing that error sending with:
IJulia.set_cur_msg(cur_execute_msg)
println(STDERR, "he's not the messiah, he's a very naughty boy...")

Strange that it works on the first run, but I didn't expect any output to show after the idle is sent, maybe there's a delay while the async idle sending block gets compiled on first run.
I'm going to have to leave this issue alone until Tuesday, very busy till then. Cheers.

I was just going to put it out there that I'll just be kinda listening from here until we get back around to how the IJulia-side interface should be structured, just because I don't know enough about Interact.jl and Reactive.jl internals to be useful currently.  If anyone has changes on the code here, just tag me and I'll be along asap.

It sounds to me like we may be able to just ditch the delay entirely in IJulia and not worry about any idle-synchronization methods.
If the only point of #491 was to avoid truncation of STDERR messages from Interact, I think the right solution is for Interact not to use STDERR at all but rather to send an error message directly.

Hi, sorry for the delay, busy week.

If the only point of #491 was to avoid truncation of STDERR messages from Interact, I think the right solution is for Interact not to use STDERR at all but rather to send an error message directly.

It mostly was, but the delay in sending the idle can help output to appear under the right cell, in some circumstances. It's not particularly elegant or reliable though. Something like what we have in this PR would be good, in general, since it would make it possible to have output from long running processes appear under the correct cell. You would need to define e.g.:
function cellprintln(exec_msg, args...; name="STDOUT")
    send_ipython(publish[],
             msg_pub(exec_msg, "stream",
                     Dict("name" => name, "text" => string(args...))))
end

and then in a cell you could have
IJulia.busy()
cell_exec_msg = IJulia.execute_msg
@async begin
    sleep(10.0) # simulation of long running process
    cellprintln(cell_exec_msg, "important information")
    IJulia.idle()
end

If you then run other cells while that cell is doing its thing, the output ("important information") would correctly appear under the cell above.
Without holding the idle, the output wouldn't appear with the cellprintln above (since the idle disables output addressed by the cell's most recent execute_msg), though it would appear with a regular println, only it would be below the most recently executed cell. So if you ran other cells in between, it would appear below them.
This won't fix the Interact issue directly, but I'm pretty sure the solution I mentioned in the last paragraph of this comment above will fix that problem more neatly, and more generally - not just for errors that are caught by Reactive.
So, in short, I recommend we merge a simple form of this PR, like that proposed above in this comment and remove the idle_delay[] completely.

I'm still not sure I see the point, since calling busy/idle is effectively equivalent to just blocking until the task is done:
t = @async begin
    sleep(10.0) # simulation of long running process
    println("important information")
end
# do other stuff here
wait(t)

Because you can run other cells in the meantime, assuming you put the waitidle in an async block at the end of the eventloop as per the idle_delay currently.

Does Jupyter allow you to execute other cells if a given cell hasn't sent an idle message yet?  If so, then I'm fine with the simplified version of this PR as suggested above.

Yes, try setting the current idle delay to 10.0, you'll still get the results of multiple cells.

Sounds good then; a lock is definitely better than an idle delay.

Hi all,
So I was reading through and it sounds like the solution from this comment is pretty popular, is that to say that it should be exactly that implementation or are my most recent commits sufficiently far down that road?

Do you mean the solution from this comment, i.e. the busy/idle/waitidle() functions I proposed?  That's what I would prefer.

Oops, yeah, copied the wrong link there.  The one problem I have with that is that there is no quick way to implement that on a package.  You need to either build it in from the start or track all of your asynchronicity in from the start.

Why is it hard for a package to add busy and idle calls?

I think that knowing that something should have places to put locks is different than actually finding the correct locations to make sure it catches all of the asynchronous parts.  If you are writing something from scratch its easy to plan accordingly.  But similar to the case of Interact, an existing project could be challenging to refactor to enable that sort of flow.

@JMurph2015 as I understand it, this PR currently enables the type of workaround mentioned in your comment above: https://github.com/JuliaLang/IJulia.jl/pull/563#issuecomment-314825206
Just to rehash that comment, a package could implement, say, a 0.5 sec delay before sending the idle on every request, by running something like this:
@async begin
    while true
        IJulia.wait_for_ready()
        IJulia.busy()
        sleep(0.5)
        IJulia.idle()
    end
end

It's implemented with two separate level triggers:
idle_hold_cond controlled by busy() and idle(), which IJulia waits on before sending the idle (as per stevengj's simple version) and an additional
idle_ready_event which a package can wait on to do something.
I mean, maybe no one's ever going to use it, but I suppose it doesn't hurt. Maybe we just add the above example to the docstring of wait_for_ready()?
Also you get rid of all the Interact specific stuff, I'll sort Interact out once something is merged here.

Honestly, I'm very reluctant to merge this at all, since the need for it seems purely hypothetical, and I definitely don't want to merge a complicated PR that implements its own LevelTrigger type unless there is a clear need.  The only packages that would need this would be IJulia-specific, and such packages seem mostly likely to be better off sending display or error messages directly.  And it's hard to reason about what functionality might be necessary here without a concrete use-case.
I'd rather just fix Interact to send error messages (rather than STDERR) and eliminate the idle delay.

If there weren't a delay at all, I wouldn't mind, but I don't I'm not involved with any packages taking advantage of these sort of features.  I can probably clean up the code some more to make it simpler, but the only reason I didn't use any of the dozen or so packages that export a level-triggered type was to avoid adding a dependency.

We don't need a level triggered type; see my proposed simpler code.
I suggest that we fix Interact, then remove the delay, then return to the possible feature discussed in this PR if a real need arises.

Not asking to merge right now, but I thought it was useful to try to show in code what I meant about there being a use case I've been saying was missing from @stevengj 's solution.  Also this way, if this PR ever gets resurrected, it'll have this already done.

The use case for wait_for_ready() seems even more hypothetical than busy().

The problem with implementing features based on hypothetical needs is twofold.  First, you may be unnecessarily complicating the code.  Second, even if a real version of the need arises, it may be different from what you guessed and may require different semantics.

I think the use case for wait_for_ready() is pretty un-hypothetical, it would be used to immediately fix Interact's bugs until better analysis was done on code paths that could lead to clipped output.  But beyond that, yes I do agree that it has "pretty niche" use cases, none of which are super obvious to me.  To me it just makes sense considering we are exposing a pseudo-async interaction with IJulia already, so might as well allow it to go the other way.

As I explained, this is the wrong way to fix Interact.  A quick fix is pretty easy: don't use STDERR for error messages.

So then where does that leave us?  Should we just start another PR to remove the idle_delay[]?  Do we make no changes to IJulia?  Or do we go forward with some further simplified version?

As I said above, my feeling is that we should leave IJulia as-is, fix Interact, remove the delay from IJulia, and return to this PR if and when a real need arises.

Don't use STDERR for error messages

Not sure if it was clear from the above - https://github.com/JuliaLang/IJulia.jl/pull/563#issuecomment-315391648 - but it seems the display of a Jupyter "error" message has the same problems as displaying stream messages. If you send a stream message instead of an error message in your code in https://github.com/JuliaLang/IJulia.jl/pull/563#issuecomment-315377812, I'm pretty sure the results are the same.
You may get some advantage in that you send the message synchronously, but it is not generally reliable for getting output to appear below a particular cell - if the idle has been sent, it won't display.
As I mentioned above (last paragraph), the most general workaround for Interact's problem is to not send the comm message that interferes with displaying output below the last executed cell. I think it's probably avoidable.

In summary, if we want to enable the possibility of addressing output to a particular cell, we need something like this PR to delay sending the idle.
If not, and we're happy with the status quo of output usually displaying below the last executed cell (which mirrors IPython), then we can do as Steven has said in the comment immediately above.
Unfortunately I may not have much time to try this alternate workaround for Interact for the next month or so. If people are desperate to remove the idle delay asap, I'd be fine with having the default be 0.0, and having Interact set it to 0.5.

@JobJob, I can't reproduce your problem.  Even if I set IJulia.idle_delay[] = 0, and sleep for 10 seconds, and execute several other cells in the meantime, my example code from above where I send an "error" message still works (the error output goes to the correct cell).

That's interesting, I still can. What Jupyter you using? I'm on 4.2.3

I have Jupyter 4.3.0

Sending a stream message also works for me.  Maybe they fixed this?

You're running the exact code from your comment above? Just with setting the idle_delay before that?

Sending a stream message also works for me. Maybe they fixed this?

Nice, was just going to ask. Mayyybeee...
Anyway, I'm outta here for now. Very interesting development 😄

Yes.  The exact code with the sleep increased to sleep(10), first setting IJulia.idle_delay[] = 0.

Also, does this mean we can get rid of the delay by default?  I'll open another PR for that if so.

More than just setting the default delay to zero, I would get rid of the delay code entirely once Interact is fixed, since it was only added for Interact.  If the need ever arises again, we can return to a version of this PR.


Add option runsettings

Hello!
Please add to the project the ability to specify with which .runsettings to run tests.
thanks!

Great, thank you


feat: Support for custom JSON icon sets

Description
Added support for custom JSON icon sets.
Linked Issues
#12
Additional context
I use JSON icon set for fontawesome pro.
https://docs.iconify.design/tools/tools2/examples/import-fa-pro.html

I was just looking for this; great work!  @antfu what do you think?

Thanks!


Trouble using Canaries. LIveness probe failure

Kubernetes version
1.15.4
Flagger version
1.0.0-rc3
Helm version
3.0.1
Istio version
1.5.1
Canary file as a template in the Helm chart
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: {{ .Values.serviceName }}
spec:
  # deployment reference
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: {{ .Values.serviceName }}
  # the maximum time in seconds for the canary deployment
  # to make progress before it is rollback (default 600s)
  progressDeadlineSeconds: 600
  # HPA reference (optional)
{{ if .Values.hpa.enabled }}
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: {{ .Values.serviceName }}
{{ end }}
  service:
    # container port
    port: {{ .Values.service.port }}
    portName: http
    portDiscovery: true
    tls:
    - match:
      - port: 443
        sniHosts:
          - {{ .Values.allowedHosts }}
    match:
    - uri:
        prefix: '/'
    trafficPolicy:
      tls:
        # use ISTIO_MUTUAL when mTLS is enabled
        mode: ISTIO_MUTUAL
    gateways:
    - ingress-gateway
    # Istio virtual service host names (optional)
    hosts:
    - {{ .Values.allowedHosts }}
  # promote the canary without analysing it (default false)
  skipAnalysis: false
  analysis:
    # schedule interval (default 60s)
    interval: 15s
    # max number of failed metric checks before rollback
    threshold: 10
    # number of checks to run before rollback
    iterations: 100
    # max traffic percentage routed to canary
    # percentage (0-100)
    # maxWeight: 50
    # canary increment step
    # percentage (0-100)
    # stepWeight: 5
    # Istio Prometheus checks
    metrics:
      - name: error-rate
        templateRef:
          name: error-rate
          namespace: istio-system
        thresholdRange:
          max: 1
        interval: 30s
      - name: latency
        templateRef:
          name: latency
          namespace: istio-system
        thresholdRange:
          max: 500
        interval: 30s

After the chart has installed, the service-primary comes up as expected. Eventually the deployment fails and rolls back to the old Deployment. This of course removes the Istio virtual service and destination rules making the service inaccessible. Digging in, i found that its failing its health check.
Then i noticed that it's different than what i was expecting.
From the Helm chart:
 livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /readiness
            port: http
            scheme: HTTP
          initialDelaySeconds: 5
          periodSeconds: 5
          successThreshold: 1
          timeoutSeconds: 1

But when i look at the pods being spun up via the canary i see
livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /app-health/<name of service>/livez
        port: 15020
        scheme: HTTP
      initialDelaySeconds: 5
      periodSeconds: 5
      successThreshold: 1
      timeoutSeconds: 1

It looks like it's trying to hit the istio-proxy, but thats on port 15090.

Istio rewrites the http probes since they don’t work with mTLS

Here is how Flagger probes work https://github.com/weaveworks/flagger/blob/master/kustomize/base/flagger/deployment.yaml#L28

I guess i'm unsure where that port is supposed to be open.

This service has been running fine with Istio for months, but i'm just now bringing Flagger into the mix. The value for ISTIO_KUBE_APP_PROBERS hasn't changed, so I'm wondering if something is missing in my setup

ok - i think i got this worked out. turns out the application wasn't allowing alive checks from certain hosts.


Auto-sizing of WASM memory (investigate)

Around block 540,612 -
2018-08-25 11:57:59          CLIENT: Idle (0 peers), #540612, 0x4314d6…dfe240

Allocation fails -
2018-08-25 12:05:28            SYNC: Requesting blocks from QmUMQn..Ye3eRe, #540613 -
2018-08-25 12:05:35          CLIENT: Idle (6 peers), #540612, 0x4314d6…dfe240
2018-08-25 12:05:42            SYNC: Requesting blocks from QmY33G..y4HvAB, #540613 -
2018-08-25 12:05:42            SYNC: Requesting blocks from QmWCnX..2P9fGn, #540613 -
2018-08-25 12:05:42            SYNC: Requesting blocks from QmWzYU..5XGWG7, #540613 -
2018-08-25 12:05:42            SYNC: Requesting blocks from QmRMGc..TChmrd, #540613 -
2018-08-25 12:05:42            SYNC: Requesting blocks from QmSz8q..jvqcvW, #540613 -
2018-08-25 12:05:44            SYNC: Queued 64 blocks from QmSz8q..jvqcvW
allocate(460842) failed, consider increasing the default runtime memory size
2018-08-25 12:05:44         RUNTIME: Runtime memory exhausted. Aborting

auto-size or
increase defaults (currently set at default 512k, see below for increased sizes)

That seems like the large-proposal-block (i.e. where Rust had issues as well)
In the above, this is failing
--wasm-heap-size 1024
--wasm-heap-size 2048
--wasm-heap-size 4096

This passes -
--wasm-heap-size 8192

Also on
2018-08-25 15:47:05            SYNC: Requesting blocks from QmUMQn..Ye3eRe, #604800 -
2018-08-25 15:47:13          CLIENT: Idle (6 peers), #604799, 0x8a5b56…4e5bac
2018-08-25 15:47:14            SYNC: Queued 64 blocks from QmWzYU..5XGWG7
allocate(921690) failed, consider increasing the default runtime memory size
2018-08-25 15:47:15         RUNTIME: Runtime memory exhausted. Aborting
wasm://wasm/000e5c2e:79

In this case tweaked 1M offsets, --wasm-heap-size 6000 worked

And
2018-08-25 17:44:36          CLIENT: Sync (5 peers), #645079, 0x77a28c…70469a
2018-08-25 17:44:36            SYNC: Queued 64 blocks from QmY33G..y4HvAB
allocate(458592) failed, consider increasing the default runtime memory size
2018-08-25 17:44:43         RUNTIME: Runtime memory exhausted. Aborting
wasm://wasm/000e5c2e:79


RPaaS work item field data value is not always accurate

I was looking at all of the active work items for APEX to make sure we had contacted all of teams with launches before build.  I noticed that there were quite a few work items that had FALSE for the value of the RPaaS field but I remember from my interactions with the service team that the RP is RPaaS.

How is the RPaaS field updated for the ADO work items?  Is it only updated when a service team uses the release planner to onboard?
If so, then these could be work items that were generated with the survey. I can ask Siva to go look at the PRs for all the work items that have a value of FALSE for RPaaS because the PRs do have the label RPaaS if the RP is RPaaS.  Does anyone know of another way to confirm RPaaS or non-RPaaS?  This data is not in service tree.

Here is the query I am using -  https://dev.azure.com/azure-sdk/Release/_queries?tempQueryId=537c0b0e-27d3-4be3-9ed9-22d5898ab46e.

How is the RPaaS field updated for the ADO work items? Is it only updated when a service team uses the release planner to onboard?

It looks like the Release Planner only updates that field when a team fills the Onboarding questionnarie (notice that they can overwrite previous values). The RPaaS value comes from their answer on:

How is the RPaaS field updated for the ADO work items? Is it only updated when a service team uses the release planner to onboard?

It looks like the Release Planner only updates that field when a team fills the Onboarding questionnarie (notice that they can overwrite previous values). The RPaaS value comes from their answer on:

Thanks @maririos!  I am going to keep this issue open as I explore if there are any other options that we can use to confirm RPaaS.  I have inquiries out to the ARM team.

This has been modified as part of the UX/UI work done https://github.com/Azure/azure-sdk-tools/issues/5631


Random plugin restarts: Cannot read properties of undefined (reading "length")

Describe the bug
Randomly child bridge running this Tuya platform plugin restarts with errors as in screenshot. Got connected 1 camera (no other Tuya devices) and everything works as expected (video stream etc.).  Configurated using the guide in plugin description. Is it possible to do something to stop this happening OR decrease the log level? Plugin is quite flooding my homebridge log. Anyway thanks for the great plugin!
Screenshots

Seems the plugin is crashing, can you enable homebridge debug log and upload the full logs? It can help me solving this issue, no more restart then. from the non debug log I can locate the issue but I want to know why it happens.

Seems the plugin is crashing, can you enable homebridge debug log and upload the full logs? It can help me solving this issue, no more restart then. from the non debug log I can locate the issue but I want to know why it happens.

Can you please advise me how to do that? I have never done that before. Thanks!

Guides are here: https://github.com/0x5e/homebridge-tuya-platform#troubleshooting

I am also experiencing the same issue with 3 x ANKO (KMART) cameras. I'll send you the log with debug directly as it contains tokens.
Cheers, and good luck! best, Drew

I am also experiencing the same issue with 3 x ANKO (KMART) cameras. I'll send you the log with debug directly as it contains tokens.
Cheers, and good luck! best, Drew

Thanks, I got the email and I will fix this today :)

Fixed in beta.16.

Fixed in beta.16.

I have also collected the debug log if you need it, where can I send it when it contains sensitive tokens etc.? Or you do not need it anymore? Thaks!

Fixed in beta.16.

I have also collected the debug log if you need it, where can I send it when it contains sensitive tokens etc.? Or you do not need it anymore? Thaks!

Yes no need anymore, please upgrade the plugin and confirm if it has been fixed, thanks :)

Fixed in beta.16.

I have also collected the debug log if you need it, where can I send it when it contains sensitive tokens etc.? Or you do not need it anymore? Thaks!

Yes no need anymore, please upgrade the plugin and confirm if it has been fixed, thanks :)

Upgraded and still when I open the stream, plugin gets restarted:

Weird... can you go to the tuya website and the device debugging page, take some photos about the standard instruct sets? can doorbell_pic been found there?

Looks as though it’s working for me now, awesome work buddy thank you!Generally the cam performance isn’t great but I think that’s the hardware. To save power they don’t return images often (even in the Tuya app). This seems to be persistent in HomeBridge. Essentially I think the camera stream sleeps until it’s needed or detects motion.Sent from my iPhoneOn 27 Dec 2022, at 19:37, gaosen @.***> wrote:
Weird... can you go to the tuya website and the device debugging page, take some photos about the standard instruct sets? can doorbell_pic been found there?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

Weird... can you upload the /var/lib/homebridge/persist/TuyaDeviceList.*.json(manually remove the sensitive data, ip, token, localkey) or just send me email?

Here is the complete Standard Instruction Set from my device from Tuya website and how can I download that TyuaDeviceList.*.json files? I can login to shell of RPi where HB is running, but dont know the commands. Thanks.

Meanwhile I have sent you to you email directly homebridge debug log part where that error happens with plugin restarts (it is from previous version beta 15), but with beta 16 it does the same error.

can you send the beta 16 logs? as @dmckillican has been fixed, I want to confirm if the upgrade is success.

@dmckillican the preview of the camera in homekit app homepage is a snapshot, apple will fetch it every 15s.

can you send the beta 16 logs? as @dmckillican has been fixed, I want to confirm if the upgrade is success.

OK, so I have rebooted whole HB server and it seems the plugin is not crashing now - was not able to replicate it in -D mode. But when I try to open the stream in Home app, I get very often those error, but I suppose it is just a communication issue through the Tuya servers, right? Camera is near WiFi AP with excellent signal.

yes, upgrade plugin need to restart the homebridge.
do you have the latest firmware of the camera? mine didn't get snapshot until I uprgade the firmware (but my error is different with you).

Confirming everything is now working fine and consistently.Delays and slow responses were resolved by adjusting the setting within the camera itself via the Tuya App. I had PIR set to off on the camera subject to performance issues.After turning on PIR the camera became responsive.Thanks again for your help and fast turn around. The PIR “quirk” may be something worth noting.Sent from my iPhoneOn 27 Dec 2022, at 20:19, gaosen @.***> wrote:
can you send the beta 16 logs? as @dmckillican has been fixed, I want to confirm if the upgrade is success.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Yes, I can also confirm, that my camera is now working without any issues or plugin reboots. It would be great to have a Homekit switch for night IR toggle, because I have turned it off to extend battery life of camera and would like only to switch it on when I need, I suppose it is not possible to have that? Thanks!

OK, switches will be added later.


Device function declaration order error message

Hi,
I've discovered a surprising behavior from numba when writing device functions that are going to be called inside CUDA kernels: the device functions have to appear before (e.g. be written above) the kernel, or Numba will produce this not-so-useful error message:
  File "/home/anaconda3/envs/tmol/lib/python3.6/site-packages/numba/typeinfer.py", line 1119, in typeof_global
    typ = self.resolve_value_type(inst, gvar.value)
  File "/home/anaconda3/envs/tmol/lib/python3.6/site-packages/numba/typeinfer.py", line 1042, in resolve_value_type
    raise TypingError(msg, loc=inst.loc)
numba.errors.TypingError: Failed at nopython (nopython frontend)
Untyped global name 'identity_ht': cannot determine Numba type of <class 'object'>

(where identity_ht was the name of the function I was trying to call, but was declared later in the file)
This will only happen when trying to run on a GPU.
I am opening an issue here, as google does not turn up anything useful when you search with the error message.
It would be helpful if perhaps this deviation from how python handles function declaration order were highlighted more clearly somewhere in the documentation, or if the error message gave you some hint as to what is wrong with your code.
I am using version 0.37 from anaconda.

Thanks for the report. This is a minimal reproducer:
import numpy as np
from numba import cuda, types

@cuda.jit(argtypes=(types.double[:], types.double[:], types.double[:]))
def foo(res, x, y):
    i = cuda.threadIdx.x + cuda.blockIdx.x * cuda.blockDim.x
    if i >= res.shape[0]:
        return

    res[i] = dev_bar(x[i], y[i])

@cuda.jit(device=True)
def dev_bar(a, b):
    return a + b

g = np.arange(256.)
h = np.arange(256.)
ret = np.zeros_like(g)

threadsperblock = 32
blockspergrid = (g.size + (threadsperblock - 1)) // threadsperblock
foo[blockspergrid, threadsperblock](ret, g, h)

print(ret)

which works under the simulator but not on hardware. I expect it's because on the CPU Thread running with target foo can see dev_bar.
I've added https://github.com/numba/numba/issues/2965 RE the error message.

Closing this as it is known and valid behaviour, @sklam offers the reason for this.


Documentation on macaroons is wrong

Background
Macaroons are created after wallet creation. However, the documentation in the main installation (https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md) states the following:

Running lnd for the first time will by default generate the admin.macaroon, read_only.macaroon, and macaroons.db files that are used to authenticate into lnd.

As a first-time LND user, I was bitten by this today because I first wanted to run lncli getinfo; it took some searching to realize I had to first run lncli create in order to create the macaroon files.
As you can see, this has confused users for a long time: this old closed issue https://github.com/lightningnetwork/lnd/issues/1190 which is reflective of the same wrong documentation, had a user post as recently as late 2020.
Your environment

version of lnd: v0.13.0-beta
Linux hostname 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
bitcoin-0.18.0

Steps to reproduce

Run lnd for the first time, connecting via RPC to bitcoind
Run lncli getinfo

Expected behaviour
Should not fail with macaroon error
Actual behaviour
Macaroons do not yet exist, which is in direct conflict with the documentation

Yes, the doc could be improved here. PRs are welcome.

Hi @guggero can I send a quick pr for this?

@guggero this is fixed with #6348, right?

Yes, thanks for the reminder, @tvolk131!
Fixed by https://github.com/lightningnetwork/lnd/pull/6348.


Microsoft safety scanner

[Enter feedback here]
Look at the scan result: unknown malware was detected but not deleted. I am a genuine Win10 Home Edition computer, We hope to delete the unknown malware detected.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f5bb1ce3-9128-5385-4417-d22eb5f8cb77
Version Independent ID: cb6ba731-a2c2-e9b9-7c3e-db781b1b5222
Content: Microsoft Safety Scanner Download - Windows security
Content Source: windows/security/threat-protection/intelligence/safety-scanner-download.md
Product: w10
GitHub Login: @levinec
Microsoft Alias: ellevin

@dyd1947, Zip all the detected malware files  and sumbit  to micrsosoft antivirus  analysis lab server .
Sign in with microsoft account on below site ,send the samples
https://www.microsoft.com/en-us/wdsi/filesubmission/
For better security purposes and Real time protection , use builtin microsoft defender antivirus  , enable it enable windows firwall, with enable controlled folder access, enable block at firstsight.


offset list support return latest offset

Codecov Report

Merging #24 (ddf318b) into main (b194018) will decrease coverage by 0.23%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
- Coverage   33.33%   33.09%   -0.24%
==========================================
  Files           8        8
  Lines         564      568       +4
==========================================
  Hits          188      188
- Misses        357      361       +4
  Partials       19       19

Impacted Files
Coverage Δ

pkg/kafsar/kafka_impl.go
0.00% <0.00%> (ø)

pkg/kafsar/offset_helper.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Safari Error

The first time a swagger set loads in Safari on OSX, it's invisible to the user. This can be seen in the demo:
http://www.sipple.io/ember-stagger-swagger-demo/#/homepage
Issue affects Safari Desktop and Chrome on iPhone.

Created a pull request #8 that appears to correct the issue. Would love feedback.


Dialogs fail when shown from "single page" apps

Steps to Reproduce

Create app with the following in main.dart:

import 'package:flutter/material.dart';

void main() => runApp(new MyApp());

class MyApp extends StatefulWidget {
  const MyApp({Key key}) : super(key: key);

  @override
  MyAppState createState() => new MyAppState();
}

class MyAppState extends State<MyApp> {
  @override
  Widget build(BuildContext context) {
    return new MaterialApp(
      home: new Scaffold(
        appBar: new AppBar(
          title: new Text('Test app'),
        ),
        body: new Center(
          child: new RaisedButton(
            child: new Text('Click me'),
            onPressed: () {
              showDialog(
                context: context,
                child: new AlertDialog(
                  title: new Text("My dialog"),
                  content: new Text("Hi from dialog"),
                ),
              );
            },
          ),
        ),
      ),
    );
  }
}

Run it, and click the button

=>
I/flutter ( 1170): ══╡ EXCEPTION CAUGHT BY GESTURE ╞═══════════════════════════════════════════════════════════════════
I/flutter ( 1170): The following assertion was thrown while handling a gesture:
I/flutter ( 1170): Navigator operation requested with a context that does not include a Navigator.
I/flutter ( 1170): The context used to push or pop routes from the Navigator must be that of a widget that is a
I/flutter ( 1170): descendant of a Navigator widget.
I/flutter ( 1170):

I feel like there is something very basic I'm missing here?

I think I'm getting the same issue.
General Layout
FirebaseAnimatedList > ListTile > onTap > showDialog
When I click on show dialog it is displayed, but when I try to pop it throws this exception.
 ] I/flutter (32665): ══╡ EXCEPTION CAUGHT BY GESTURE ╞═══════════════════════════════════════════════════════════════════
[   +4 ms] W/zygote  (32665): Attempt to remove non-JNI local reference, dumping thread
[  +12 ms] I/chatty  (32665): uid=10083(u0_a83) com.wrightwaycs.economy identical 1 line
[        ] W/zygote  (32665): Attempt to remove non-JNI local reference, dumping thread
[        ] I/flutter (32665): The following assertion was thrown while handling a gesture:
[        ] I/flutter (32665): Looking up a deactivated widget's ancestor is unsafe.
[        ] I/flutter (32665): At this point the state of the widget's element tree is no longer stable. To safely refer to a
[        ] I/flutter (32665): widget's ancestor in its dispose() method, save a reference to the ancestor by calling
[        ] I/flutter (32665): inheritFromWidgetOfExactType() in the widget's didChangeDependencies() method.
[  +13 ms] I/flutter (32665):
[        ] I/flutter (32665): When the exception was thrown, this was the stack:
[   +3 ms] I/flutter (32665): #0      Element._debugCheckStateIsActiveForAncestorLookup.<anonymous closure> (package:flutter/src/widgets/framework.dart:3181:9)
[   +6 ms] I/flutter (32665): #1      Element._debugCheckStateIsActiveForAncestorLookup (package:flutter/src/widgets/framework.dart:3190:6)
[        ] I/flutter (32665): #2      Element.ancestorStateOfType (package:flutter/src/widgets/framework.dart:3232:12)
[        ] I/flutter (32665): #3      Navigator.of (package:flutter/src/widgets/navigator.dart:722:19)
[        ] I/flutter (32665): #4      allowInviteDialog.<anonymous closure> (package:economy/main.dart:417:23)
[        ] I/flutter (32665): #5      _InkResponseState._handleTap (package:flutter/src/material/ink_well.dart:478:14)
[        ] I/flutter (32665): #6      _InkResponseState.build.<anonymous closure> (package:flutter/src/material/ink_well.dart:530:30)
[        ] I/flutter (32665): #7      GestureRecognizer.invokeCallback (package:flutter/src/gestures/recognizer.dart:102:24)
[        ] I/flutter (32665): #8      TapGestureRecognizer._checkUp (package:flutter/src/gestures/tap.dart:161:9)
[        ] I/flutter (32665): #9      TapGestureRecognizer.handlePrimaryPointer (package:flutter/src/gestures/tap.dart:94:7)
[        ] I/flutter (32665): #10     PrimaryPointerGestureRecognizer.handleEvent (package:flutter/src/gestures/recognizer.dart:315:9)
[        ] I/flutter (32665): #11     PointerRouter._dispatch (package:flutter/src/gestures/pointer_router.dart:73:12)
[        ] I/flutter (32665): #12     PointerRouter.route (package:flutter/src/gestures/pointer_router.dart:101:11)
[        ] I/flutter (32665): #13     BindingBase&GestureBinding.handleEvent (package:flutter/src/gestures/binding.dart:143:19)
[        ] I/flutter (32665): #14     BindingBase&GestureBinding.dispatchEvent (package:flutter/src/gestures/binding.dart:121:22)
[        ] I/flutter (32665): #15     BindingBase&GestureBinding._handlePointerEvent (package:flutter/src/gestures/binding.dart:101:7)
[        ] W/zygote  (32665): Attempt to remove non-JNI local reference, dumping thread
[        ] I/flutter (32665): #16     BindingBase&GestureBinding._flushPointerEventQueue (package:flutter/src/gestures/binding.dart:64:7)
[        ] I/flutter (32665): #17     BindingBase&GestureBinding._handlePointerDataPacket (package:flutter/src/gestures/binding.dart:48:7)
[        ] I/flutter (32665): #18     _invoke1 (file:///b/build/slave/Linux_Engine/build/src/flutter/lib/ui/hooks.dart:134)
[        ] I/flutter (32665): #19     _dispatchPointerDataPacket (file:///b/build/slave/Linux_Engine/build/src/flutter/lib/ui/hooks.dart:91)
[        ] I/flutter (32665):
[        ] I/flutter (32665): Handler: onTap
[        ] I/flutter (32665): Recognizer:
[        ] I/flutter (32665):   TapGestureRecognizer#1d033(debugOwner: GestureDetector, state: possible, won arena, finalPosition:
[        ] I/flutter (32665):   Offset(125.1, 393.7), sent tap down)
[        ] I/flutter (32665): ════════════════════════════════════════════════════════════════════════════════════════════════════
[   +1 ms] W/zygote  (32665): Attempt to remove non-JNI local reference, dumping thread

// called from the list tile on tap
Future<Null> allowInviteDialog(BuildContext context, String inviteCode,
    String userName, String asUserName) async {

  bool selected = await showDialog<bool>(
    context: context,
    child: new SimpleDialog(
      title: new Text(
          "$userName has accepted invite to sign in as $asUserName. Allow them to sign in?"),
      children: <Widget>[
        new SimpleDialogOption(
          child: const Text('Yes, I approve'),
          onPressed: () {
            // ~~~ broken!!!
            Navigator.of(context).pop(true);
          },
        ),
        new SizedBox(height: 15.0,),
        new SimpleDialogOption(
          child: const Text("No, I don't approve"),
          onPressed: () {
            // ~~~ broken!!!
            Navigator.of(context).pop(false);
          },
        ),
      ],
    ),
  );

  // ...
  }
}

@mit-mit Any suggestions on what change we could make that would address your concern?

Sorry, I don't know this well enough to suggest any concrete changes


Markers in Slider

Feature request
Overview
Markers in Slider
Examples in other libraries
https://reach.tech/slider SliderMarker
Who does this impact? Who is this for?
Currently migrating from Reach UI to Radix and marker in slider is something very useful in highlighting important positions in the slider to user.

Example usage: Media player seek bar


Added new methods for comparing float and double arrays with delta - F…

Fixes #1803
Closes #1803
Did you remember to?

[x] Add test case(s)
[x] Update CHANGES.txt

We encourage pull requests that:

Add new features to TestNG (or)
Fix bugs in TestNG

If your pull request involves fixing SonarQube issues then we would suggest that you please discuss this with the
TestNG-dev before you spend time working on it.

@juherr - I have done the changes. Pls check.


Adding conditional dependencies to our data model

Pulled this table from the visualize/attributes endpoint of the schematic API with help from FAIR. I currently have it stored in data-models, allowing us to integrate this information directly into the portal for documentation purposes.
@adamjtaylor lmk if there is a better spot for this

As agreed with @aditigopalan, to rename as HTAN.dependencies.csv or HTAN.conditionals.csv or similar to keep the naming pattern.


NIAD-1132: Apply consistent autoformatting rules

Description
Starting with IntelliJ defaults:

Never use '*' imports (999 threshold)
Always wrap if long
Binary operation signs on next line

Gradle uses an old version of checkstyle by
default – this is upgraded to 8.41.
A couple of places then still violated checkstyle
because they couldn't be fixed automatically.
Jira Ticket
https://gpitbjss.atlassian.net/browse/NIAD-1132
Checklist
These are items (excluding GitHub Checks) which should be confirmed before a branch is ready to merge.

[ ] Acceptance Criteria met
[ ] Commit messages are meaningful
[ ] Manually tested
[ ] Self-reviewed your code
[ ] Code reviewed from two other developers
[ ] If your pull request depends on any other, please link them in the description
[ ] main branch is passing/green on CI
[ ] Add/update any relevant documentation

We will address the issue here incrementally rather than in one big PR. Everyone applies the same IntelliJ code formatting configuration and applies it to the files relevant to their work. Over time, the code base will be cleaned up.


PostgreSql array column $nin

Describe the bug
if entity has an member like

and i use an repository to query by an array it does not add {} to the array value

Please dont ignore the issue template.


CRYPTO-66: Fix compiling warning

Fixing: https://issues.apache.org/jira/browse/CRYPTO-66

Thank you for your contribution. LGTM+1

Committed to master


Results with filtered children?

Hi,
So if we have an array of objects and search for them, Fuse returns the objects that match the criteria.
But if said objects have an array of children which we want to search, is it possible to filter those to the search criteria as well?
Examples:
[
	{
		label: 'parent123',
	},
	{
		label: 'parent321',
	}.
]

If we search for parent123 we will get:
[
	{
		label: 'parent123',
	}
]

But if it's a group with children:
[
	{
		label: 'parent123',
		children: [
			{
				label: 'child1'
			},
			{
				label: 'child2'
			},
			{
				label: 'child3'
			},
		]
	},
...

Is it possible for a search of parent123 to return back that object (as usual) but for a search of child2 to get back:
[
	{
		label: 'parent123',
		children: [
			{
				label: 'child2'
			},
		]
	}
]

? :)

Hi ,
I also want same behavior in my project. My array as below
var test= [
{
"title": "Floor A",
"id": "55fea689216b519578bc1b3a",
"units": [
{
"unitTitle": "A.0.1",
"unitID": "55fea689216b519578bc1b6e"
},
{
"unitTitle": "A.0.2 - EG",
"unitID": "55fea689216b519578bc1b6f"
}
]
},
{
"title": "Floor B",
"id": "55fea689216b519578bc1b3b",
"units": [
{
"unitTitle": "B.0.1",
"unitID": "55fea689216b519578bc1b98"
},
{
"unitTitle": "B.0.2 - EG",
"unitID": "55fea689216b519578bc1b99",
},
]
}
]
suppose I want to search "Floor" then it should return all the record that matches with it. If I search "B.0.2" then my expected result will be:
{
"unitTitle": "B.0.2 - EG",
"unitID": "55fea689216b519578bc1b99",
}
But I get the result as mentioned below:
{
"title": "Floor B",
"id": "55fea689216b519578bc1b3b",
"units": [
{
"unitTitle": "B.0.1",
"unitID": "55fea689216b519578bc1b98"
},
{
"unitTitle": "B.0.2 - EG",
"unitID": "55fea689216b519578bc1b99",
},
]
}
can you please provide any solution for it. I am waiting for your response.

@ashusdn you may want to consider formatting your response using triple-backticks to render code blocks. That'll make it easier to read and allow others to help you out quicker.

@iamvitali If you have solved the problem, can you help me?

Any luck here;
I'll add my usecase here;
List =>
[
	{
		id: 1,
		title: this is my title-ABC,
		items: [
			{
				title: this is my subitem-ABC,
				description: this is my descriptionA,
			},
			{
				title: this is my subitem-QQQ,
				description: this is my description-ABC,
			},
			{
				title: this is my subitem-WWW,
				description: this is my description,
			}
		]
	},
	{
		id: 1,
		title: this is my title,
		items: [
			{
				title: this is my subitem,
				description: this is my descriptionA,
			},
			{
				title: this is my subitem,
				description: this is my description-ABC,
			},
			{
				title: this is my subitem,
				description: this is my description,
			}
		]
	},
	{
		id: 1,
		title: this is my title,
		items: [
			{
				title: this is my subitem,
				description: this is my descriptionA,
			},
			{
				title: this is my subitem,
				description: this is my description,
			},
			{
				title: this is my subitem-WWW,
				description: this is my description,
			}
		]
	}
]

var options = {
  ...
  keys: [
    "title",
    "items.title",
    "items.description"
]
};
var fuse = new Fuse(list, options); // "list" is the item array
var result = fuse.search("ABC");

Expected search result;
[
	{
		id: 1,
		title: this is my title-ABC,
		items: [
			{
				title: this is my subitem-ABC,
				description: this is my descriptionA,
			},
			{
				title: this is my subitem-QQQ,
				description: this is my description-ABC,
			}
		]
	},
	{
		id: 1,
		title: this is my title,
		items: [
			{
				title: this is my subitem,
				description: this is my description-ABC,
			},
		]
	}
]

Hi, I could not solve this problem with fuse, but I think that I can solve my own problem, maybe it helps you. I put the values I need to search into another array. And I did the search here.
You can find the demo here.
I also share the codes here github.
const list = [{
    id: 1,
    title: "this is my title-ABC",
    items: [{
        title: "this is my subitem-ABC",
        description: "this is my descriptionA",
      },
      {
        title: "this is my subitem-QQQ",
        description: "this is my description-ABC",
      },
      {
        title: "this is my subitem-WWW",
        description: "this is my description",
      }
    ]
  },
  {
    id: 1,
    title: "this is my title",
    items: [{
        title: "this is my subitem",
        description: "this is my descriptionA",
      },
      {
        title: "this is my subitem",
        description: "this is my description-ABC",
      },
      {
        title: "this is my subitem",
        description: "this is my description",
      }
    ]
  },
  {
    id: 1,
    title: "this is my title",
    items: [{
        title: "this is my subitem",
        description: "this is my descriptionA",
      },
      {
        title: "this is my subitem",
        description: "this is my description",
      },
      {
        title: "this is my subitem-WWW",
        description: "this is my description",
      }
    ]
  }
];

const subItems = _.flatMap(list, data => data.items);

var options = {
  shouldSort: true,
  threshold: 0.1,
  location: 0,
  distance: 100,
  maxPatternLength: 32,
  minMatchCharLength: 1,
  keys: [
    "title",
    "description"
  ]
};

var fuse = new Fuse(subItems, options);
var result = fuse.search("this is my subitem-ABC");

console.log(result);

The solution provided by @ccoeder is kind of close but different. Thanks @ccoeder for it
It strips off the hierarchy.
But does anyone has a closer solution to this problem? Please share.


Menu Save - Request Times Out After Repeated Cache Purges

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the plugin and it is still present.

WordPress version
6.1
Cloudflare-WordPress version
4.11.0
PHP version
8.1
Expected result
When saving a Menu, I expect it to save quickly and possibly trigger a site-wide purge (see https://github.com/cloudflare/Cloudflare-WordPress/issues/478). However, instead, it is repeatedly calling purgeCacheByRelevantURLs for the pages contained in the menu, which results in the Menu page crashing/timing out if the menu is large.
I would expect Cloudflare to keep a log of URLs and/or Page IDs it has purged in any one request. Each time purgeCacheByRelevantURLs is called, it should check this list and abort early if it's already handled that page in that request. This could be as simple as an array in a global variable or object property.
With updating Menus, it triggers the hooks many times over with the same Page IDs, so many requests are sent to Cloudflare. This causes the page load to time out.
Actual result
Upon saving a large Menu, WordPress's request will timeout. This is because purgeCacheByRelevantURLs is being called dozens or hundreds of times by the WordPress hooks. Each time, it is making the same Cache Clear requests to Cloudflare over and over again.
Steps to reproduce

Enable Cloudflare plugin with APO
Setup a large menu (dozens of menu items)
Save the Menu
Wait for the timeout

If you run a debugger, you can see how many times purgeCacheByRelevantURLs is called in one request for saving a menu.
Additional factoids
No response
References
No response

As a very quick and dirty workaround for the moment without modifying the plugin itself, I present this awful code:
add_filter('is_post_type_viewable', function($is_viewable, $post_type) {
// Prevent menu items from triggering a cache purge
// Workaround due to https://github.com/cloudflare/Cloudflare-WordPress/issues/498

// Only impact calls from the Appearance > Menu page.
if(!isset($_SERVER['SCRIPT_NAME']) || pathinfo($_SERVER["SCRIPT_FILENAME"], PATHINFO_BASENAME) != 'nav-menus.php') {
    return $is_viewable;
}

// If this is being called from Cloudflare, return $is_viewable=false, always on this page
$backtrace = debug_backtrace();
foreach($backtrace as $entry) {
    if(isset($entry['file']) && strpos($entry['file'], 'cloudflare') !== false) {
        return false;
    }
}

return $is_viewable;
}, 10, 2);

I know this was closed as stale, but I'm just not certain if it has been dealt with? Can anyone comment?


Add missing contributors to list

Closes #74
I simply added myself to the lit of contributors of the ontology.

[x] @Bachibouzouk

[ ] @solar-c

[ ] @Izzet91

[x] @Ludee

I suggest that the people add their information (if they want to) by making suggestion in the section "Files changed" (github help). Here is a screenshot of the button you have to press once you selected the line where you would like to add your information :

Can this be closed? Didn't we decide to use teams instead?

Can this be closed? Didn't we decide to use teams instead?

This is for the contributors inside the oeo.omn file for citations purposes, this was already there. You are probably confusing this with the additional file I had proposed to create with more details as just the names. However, this proposition was rejected during hackathon and it was decided to use teams instead of an additional file. Nevertheless, the dc:contributor still need to be filled with the names of the people contributing as it was the case before the proposal :)

Yes, I did confuse this. Thanks for clarifying.

Would you also add me to the list please? Thanks

@stap-m Could you try doing it yourself following my explanations? (the purpose was to let you know how to make suggestions and commit them on github :))


mat-mdc-button : Button Custom background color and text color are overriding in angular material 15

Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
14
Description
I have migrated angular from ver 14 to 15, In angular ver 14 all things are working good, after migrating to angular material 15 buttons are not picking the custom text color and background color.
button theme:
@use '../_variables' as vars;
@mixin theme() {
.blue-button {
background-color: vars.$primary-default;
color: white;
}
}
this class is overriding the font-color of the button :
mat-mdc-button:not(:disabled) {
color: var(--mdc-text-button-label-text-color, inherit);
}
this class is overriding my background color:
.mdc-button {
background: rgba(0, 0, 0, 0);
}
html file implementation of button:

Test

Note:
I dont want to solve this issue using the !important keyword so is there any work-around to fix this issue.
Reproduction
StackBlitz link:
Steps to reproduce:
1.
2.
Expected Behavior
The buttons are not picking the custom styling eg blue color as a background and white font color.
Actual Behavior
The buttons should pick the custom styling eg blue color as a background and white font color.
Environment

Angular: 15.2.10
CDK/Material: 15.2.9
Browser(s): Chrome
Operating System (e.g. Windows, macOS, Ubuntu):Windows

Closing since we don't officially support overrides like this. You can work around it by setting the CSS variables instead.

@crisbeto I haven't override any thing I have created a mat-button and then gave this css(blue-button) class which I define in theme mixin.
@mixin theme() {
.blue-button {
background-color: vars.$primary-default;
color: white;
}
The problem I am facing is my custom css (background color and color ) is overriding by these two classes (mat-mdc-button:not(:disabled , .mdc-button  ) which i defined in the description.I am not facing this problem in angular ver 14 but facing in angular version 15.
By giving !important property to the properties of my custom (blue button) class I can see my color applying on the button but without that its not picking the color.

The example you posted is overriding the built in styles.

@crisbeto  So here in this attachment my custom CSS is with yellow color highlighted and with the blue color highlighted is the built in styles of mdc-mat-button, so from these built in classes added in angular ver 15 my custom class (blue-button) is not working.