Cannot read property 'suicide_targets' of null

TypeError: Cannot read property 'suicide_targets' of null
at Object.FeederBot.getCandidateBall (C:\Users\Deezle\Desktop\Deezle\feeder.
js:406:36)
at Object.FeederBot.recalculateTarget (C:\Users\Deezle\Desktop\Deezle\feeder
.js:485:34)
at null._repeat (C:\Users\Deezle\Desktop\Deezle\feeder.js:91:21)
at wrapper [as _onTimeout] (timers.js:275:11)
at Timer.listOnTimeout (timers.js:92:15)
C:\Users\Deezle\Desktop\Deezle>Pause

Yeaa.. New update caused it :(

If you want spam bots change it to default not blind mode

Sjould fix the problem

Mine still work..?

@MasonBurdette can u send me yours? I have edited ogar feeder bot and bots arent Spawn Ing!

*sorry I meant moving

He is not giving/selling to anyone because he used alot of time on them
Sendt fra min iPhone

Den 9. mar. 2016 kl. 14.35 skrev philw1508<EMAIL_ADDRESS>@MasonBurdette can u send me yours? I have edited ogar feeder bot and bots arent Spawn Ing!
—
Reply to this email directly or view it on GitHub.

He is not giving/selling to anyone because he used alot of time on them

Then he has some expiry time?
Do you mean if more people use it he will lost time or what?

I took the time to program a fix.  I don't want Ti to be patched.

default mod is working

@RudaGabriel working how? the bots don't come to you or have mouse control.


Why owner instead of controller?

Is there a specific reason why you call 'controller' property 'owner' in pubkey?
To follow w3c DID spec, I think we should change it to 'controller'

It is a legacy, not intentionally kept like that, and it should be updated.
This resolver was built before the W3C spec was a thing and was not updated for developer bandwidth reasons and because the controller/owner property of keys was not used in any project.
Feel free to submit a PR, especially if you are using this directly.


Cleaner API

This PR introduces a cleaner memory-safe API via the following changes:

Swift side function signature does not need UnsafePointer anymore for its arguments. So now it's func getGreeting(name: SRString)
Rust side now has a .to_swift() function enabled on SR* types, which returns a SwiftRef<Type> (e.g. SwiftRef<SRString>. So long as we pass this from the Rust side, we don't need UnsafePointer on the Swift side. So now, the Rust side looks like unsafe { get_greeting(srstring.to_swift()) }
Swift side now has a .toRust() function on NSObject via an extension, so that we can do a return myString.toRust() instead of return toRust(myString).

The earlier approach still exists, for those who prefer that:

Rust side function signature: unsafe fn get_greeting(name: &SRString)
Swift side function signature: func getGreeting(name: UnsafePointer<SRString>)

This PR also fixes a bunch of fmt and clippy errors. IMHO, it would be a good practice to make sure that anything going into the main branch is naturally clean of these.

I love the toRust change, but I've refactored how SwiftRef works so that there's no transmute_copy or unsafe.
From what I understand, your goal with SwiftRef was to have a copy of the NonNull held by each SRObject. Turns out that NonNull is Copy, which allows for SRObject to be copied and held by SwiftRef, preserving memory layout since it's repr(transparent) all the way down. I've also moved to_swift (now swift_ref) to the types themselves so that a trait doesn't have to be imported.

Please hold on merging this change. I'll need to verify the memory safety of this. I know the tests have passed, but it shouldn't, with these changes. I'll revert shortly.

I've fixed the tests (there was a bug in them), and now they fail.
The reason is that you're using .clone(), which creates a completely new SRObject, leading to its own drop() whenever a SwiftRef expires. But the underlying object behind all of those clones is the same, so this leads to a memory imbalance, and crash.
That's the reason why I had to use transmute, so that no objects get created. That's also the reason why deliberately marked to_swift() as unsafe, because the called needs to be aware that through this function, they can technically retain a copy of references to swift object, even when it has been dropped.

You can also work around this issue by taking a corresponding retainedValue on the swift side, for every rust side .clone(), but the question is, would it be worth it?

Huh, that's a really good catch. Can't it be fixed by making SwiftRef only hold a NonNull like you did before? The tests pass fine on my end with that change.

Yes, that should work as semantically that's identical to the original PR. You'll still need to mark all SR**.swift_ref() functions as unsafe, as technically they can be used to retain references to invalid objects.
Personally, I feel that the above change will take away from the core of what you were trying to achieve (no-unsafe code), with more number of unsafe than before, and more LoC. But still, your discretion on whether to stick with original PR, or make the changes above.
Separately, please do also consider that to_swift() and toRust() have a stronger correspondence (naming convention wise), than .swift_ref() and .toRust()

I'd rather use swift_ref than to_swift since swift_ref directly produces a SwiftRef, whereas toRust just returns the regular data with a side effect. It's not a huge deal anyway, since I'm going to make a macro that conceals the need to use SwiftRef and swift_ref anyway.
Seeing as accessing data via a NonNull is already unsafe, is it really worth making swift_ref unsafe? Especially when it doesn't actually involve any unsafe code.

AFAICT, because swift_ref allows one to retain copies independently of the lifecycle of the object, technically Rust's safety rules require you to expose it as unsafe, even if hidden behind a macro.
Alternatively, you'll need to bind SwiftRef<'a> to the lifetime of the underlying object. In that case, you can avoid the unsafe. I'm guessing that should work from a memory-safety pov.

Seeing as I'm going to macroy this all anyway, I'm gonna do the SwiftRef<'a> approach which will require unsafe. Doesn't really matter if the generics are complex if the end user doesn't need to use them.

Hmm, I think this has been flawed from the start - specifically the use case with test_reflection. Both dd9eaf6 with the $op(); addition and the most recent commit fail to run sometimes because of that test. I'm not quite sure how we should handle it or how the reference counting operates in that case.

Reflection isn't difficult to fix here. Defining the signature something along the lines of
extern "C" {
    fn reflect_string(string: &SRString) -> &SRString;
}

should do it, along with any related ARC issues and with the appropriate changes on the rust side.
But the amount of changes you've made to this PR is already overwhelming, with very little of the original left. I'm spending far more time assisting you with your changes, than the original PR, and that's neither a strong motivation to me, nor IMHO a fair burden to place on a contributor.
It would've been simply easier to just reject the PR, and do the changes you wanted in your own branch. Which is why I'm closing this PR. I'll retain your changes on my fork for another 24 hrs, just in case you don't have a local copy of it for any reason.

There were other issues in this repo I would've liked to contribute to, but clearly you have strong opinions (rightly so, as the owner) about how the code should look like, and I feel it would be easier for those ideas to show up in code before contributors like me barge in in with their own implementations and then face the burden of having to retro-fit the ideas you have for the repo.
A Contribution Guide section in README might be helpful to articulate what you're looking for as well.

I'm really sorry I made you feel that way, I was under the impression we were making good progress but now it's evident that you didn't like this back-and-forth.
Your help over the past couple of weeks has been extremely valuable, and I'm not sure swift-rs would have ever been more developed without your knowledge of Swift. I wish you'd have let me know this was overwhelming earlier so that I could have changed my actions.
If I wanted to reject the PR then I would have, but you proposed some valuable ideas that I wanted you to get the attribution for, instead of me just putting them on my own branch. I probably could have added you as a co-author on my own commits, but that didn't cross my mind.
I'd be very grateful if you changed your mind, but if not then I'll take your changes to a new branch and co-author you, seeing as you don't want this PR merged. I'll add a Contribution Guide as you suggested - I usually require people to open an issue before submitting a PR, but this repo was created before I learned how to properly handle open source and I never got around to updating it.
I hope we can come to an understanding, but regardless I wish you well.

Your clarification is deeply appreciated, thanks. It isn't the back & forth that was the problem, but the scope of the PR. I was specifically targeting doing away with UnsafePointer, since my memory-safety PR had introduced it earlier, and I felt a sense of responsibility to try to minimise its side-effect.
Your changes OTOH were coming from a pov of the full-fledged API you want to see, which is fine by itself, but is of a larger scope, which I unwittingly got pulled into, and ended up spending more time than I wanted, on reviewing the safety aspects of a very different codebase. Something that should've been additive, became substitutive.
I'm sincere in my suggestion that it'd be easier on contributors once you've gotten the skeletal structure in place, as that would relieve them of the burden of retro-fitting new ideas in their PRs at a late stage.
I'll be sticking with my decision for the time being, but I greatly appreciate your closing words here. I'm not bummed about our interaction, just need to stay focussed on my project.


[INFRA] add github issue form

fixes #5
I am using my fork as a demo (switched the default branch to show case it)

submission form rendering: https://github.com/Remi-Gau/global2021/issues/new?assignees=&labels=project&template=project-submission-template.yml&title=[Project]%3A+

example output: https://github.com/Remi-Gau/global2021/issues/2

To do

[x] improve descriptions and place-holders
[x] adapt content to the Google form version

decisions needed

[ ] which items will be "required"?

We need to decide which items need to be filled in for people to be able to click 'submit new issue'. I am tempted to set the bar fairly high (also because sections that are not filled in do not appear in the opened issue).

@jhlegarreta @complexbrains

@Remi-Gau tremendous work. :100: to having considered the label fields and made them drop down menus. Will have a more detailed look tonight, will create the labels and start having a look at how these things can be parsed to get the relevant data.

@Remi-Gau tremendous work.

thanks

100 to having considered the label fields and made them drop down menus. Will have a more detailed look tonight, will create the labels and start having a look at how these things can be parsed to get the relevant data.

Do you think we should add special character before each label in the dropdown menus ? I think the original template used #.
This could make it easier for parsing and should not be too confusing for the users. What do you think?

Do you think we should add special character before each label in the dropdown menus ? I think the original template used #.
This could make it easier for parsing and should not be too confusing for the users. What do you think?

The issue labeler action seems not to require them, so not sure why they were required. I do not see how they should help for the current form.

Actually the # is needed for the issue labeller and not the issue to project parsing:
https://github.com/brainhackorg/global2021/blob/main/.github/labeler.yml

Actually the # is needed for the issue labeller and not the issue to project parsing:
https://github.com/brainhackorg/global2021/blob/main/.github/labeler.yml

I missed the dictionary although I think I opened the file :facepalm: . Labeling the issues was also a requirement last year so that issues could be easily filtered. I guess this is the case this year as well. Adding a heading hashtag to the drop down menus would look weird IMHO. Also, I'm not sure whether the labeler works on the YAML file. I'll create labels tonight and see if if the labeler works for an issue.

Labels created. Just in case we need them again, here they are
bhg_gh_labels.json.txt
.

These two scripts might have things in common, like getting the issues from gh. One is written in Python, the other one is a shell script. IMHO the cost of maintaining the two in non-negligible. Also taking into account #25. So it looks like one way or the other (Python vs shell) needs to be decided. Not sure if @eurunuela happens to have another proposal.

I think we should translate the shell script into Python. IMO that's the easiest way going forward considering #25. Since I wrote the pull_issues.sh script, I will open an issue in the brainmatch repository and will take care of translating it into Python.

I think we should translate the shell script into Python. IMO that's the easiest way going forward considering #25. Since I wrote the pull_issues.sh script, I will open an issue in the brainmatch repository and will take care of translating it into Python.

Agree to use Python as glue for everything.

@Remi-Gau a few thoughts after having had a look:
* To actually see if the labeler is working, we would need this to be merged: I cannot create labels in your repository.

* I think the hashtags last year were used because all list values existed in the issue template: the way to distinguish those required by a project was by adding a hashtag to those elements, and then the labeler had it matches. Not sure what the raw text looks like for an issue with the proposed template, so I cannot tell whether the labeler will get them right.

Opening a bunch of issues here for testing would clutter things IMO, so @Remi-Gau would you upload the labels to your fork (or provide me with rights to add labels) to see if the above works ??
I'm approving so as to get things going forward. Issues with the template can be fixed in separate PRs.

OK so I will merge this here and we test things on my repo once I added the labels.

* see if the `issue to pages` workflow is working with this template, and if not, how to fix it. The repository URL will be one thing to change. The action should be triggered when an issue is opened, so that will cast light on its potential issues.

I guess this can be tested on my side too, no?

I guess this can be tested on my side too, no?

Yep.

By opening an issue in Rémi's fork I've realized that if a file is dropped in one of the fields that is not expected to contain anything other than text, we might run into issues when trying to generate the project data for the workflow.

I ran the script on the repository here
https://api.github.com/repos/Remi-Gau/global2021/
and leaving apart the status:published filtering, got the issue data got parsed without breaking for the existing issue. A few notes, though:

The issue has two titles, one corresponding to the GitHub issue title, the other  one in the body. BHG 2020 had two as well. Might need to be considered at some point/later time if it happens to be misleading. The script only looks at the GitHub issue title.
For the sake of minimizing the effort, being consistent across year and not breaking things:

I would rename the Description field to Project Description in the issue form. If you think that is should not be, the regex should be changed in the script.
Same goes for the Link to the project field: the old template had Link to project repository/sources as title.
Otherwise, the names should be agreed upon once for good.

The issue template title has a default [Project]: text: if not deleted, it will appear in the title field. I would remove it; if not, all project sections on the website will have it.
The labeler is not working (at least in Rémi's repository), and thus the issue is not getting labels, which is relevant for the website project data and brainmatch. If we get the labeler working, the latter would work without requiring changes to the modified script.

The regexes may need to be adjusted to look for ### {field_name} to ensure that the field hit is the desired one. And not sure about


CLI Command for fetching events as pages

This is my PR for #26, at least this is what worked for me.
I think there is room for improvement on many levels, but first wanted to hear your opinion.
Besides adding the functionality, I moved some code from facebook.php to classes/FacebookEvents.php to reuse code in both facebook.php and the new cli/FetchEventsCommand.php.
Usage (after configuring page id and facebook credentials):
[php] bin/plugin facebook fetch-events [user/pages/events]

Best Christian

I am reviewing your pull request and fixing some issues mainly due to the case that event does not necessarily have 'original_end' property. But seems good so far.

Can you tell me what is the purpose of date and unpublish_date in the facebook.event.page.md.twig file ? Why they are just not original_start and original_end ?

Great, haven't thought about the case of original_end date not being set. (Isn't the parsing in the plugin setting it to the start date when it is not present?)
These fields are "special names" for pages in Grav:

date is one way of sorting page collections
unpublish_date will hide the page after that time.

If you want anything added/ documented/ cleared up from my side just tell me!

Since facebook events are no longer working anyways (at least when I last checked, I'll close this PR


readme: add node v6.3+ support

Thanks, wasn't aware of that.
I'm struggling to make it work though (neither v6.3 nor v6.4). It works via chrome-devtools:// but it doesn't using the WebSocket; Node.js just doesn't reply anything (Wireshark can confirm).
Inspecting the DevTools' WebSocket I can see that the first message is {"id":1,"method":"Log.enable"}. Yet if I try with wscat:
$ wscat -c ws://localhost:9229/node
connected (press CTRL+C to quit)
> {"id":1,"method":"Log.enable"}
>

OK I found the issue, maybe obvious but I'm leaving this here for the record. Everything seems to start only after issuing Runtime.run().


Fix typo in batch-transcription.md

"locale to us" should be "locale to use"

@c-w : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Correction confirmed. Thanks.


Sync instance for Task: override definition of Map.

The default implementation of map in terms of point and flatMap incurs the allocation cost of a Lambda expression for any call. For Task, this is easily avoidable.
When profiling a compilation, this was allocating 4 MiB, which was about 1/1000th of total allocated space.

Thanks @diesalbla!


Adding a reference to the dev genai workshop complete with contact form

Referencing this issue: https://github.com/elastic/elasticsearch-labs/issues/193

Comments from @joemcelroy
change my readme to a named sub readme
link to it from the main readme


Support for Malayalam (ml) Language - Hyphenation

This is to request the Malayalam language hyphenation support in Typst.
"Malayalam is one of the main languages spoken (by 40 million people) in South India, with a rich cultural and literary history. It is one of the oldest languages in India with classical language status."
Issue
Malayalam text output by Typst has too much spacing between some words.
Sample in Typst

Sample Text in Latex with Proper hyphenation and justification

References:

https://tex.stackexchange.com/questions/668159/typesetting-malayalam-in-xelatex-lualatex-gives-error
https://thottingal.in/blog/2014/07/20/typesetting-malayalam-using-xetex/
https://github.com/libindic/hyphenation/blob/master/libindic/hyphenation/rules/hyph_ml_IN.dic

We excluded Indic languages because we couldn't find any evidence that hyphenation was actually used with them in practice. Perhaps that wasn't true. Do you have any sources of non-TeX related places where Malayalam is hyphenated?

If you don't speak the language It is hard to find evidence of hyphenation as hyphens are not commonly used. The words are just broken at end of line without any symbol.
Firefox and Chromium have added support for hyphenation in indic languages, see for example here.
Here is a blog that documents that indesign, scribus, libreoffice and so on all support hyphenation for indic languages.
The author of this blog also has a repo with all his hyphenation patterns for indic languages:
https://github.com/santhoshtr/hyphenation


Swap out the handrolled Mempool mock for a mockall implementation

If I remember correctly, the reason I created the hand-rolled Mempool mock was because there were circular dependancies within blockprod pulling in chainstate and mempool. which was one of the reasons why the mocks were moved to /mocks/. However after @ImplOfAnImpl's discussion on Atomics, it made me have another look at the Mempool mock given that there are a lot of Atomics in there.
I have a local change which implements the Mempool mock using mockall, which seems to now work within blockprod. I'm creating the issue as a reminder to update blockprod tests with the mockall Mempool implementation.

Done


[REFACTOR] kubernetes_pv_controller should use the datastore

Currently the kubernetes_pv_controller makes direct calls against a pvLister, instead of going via the shared datastore.
The actual lister might be the same instance as the datastore, but it would be better if all calls are routed through the datastore.
https://github.com/longhorn/longhorn-manager/blob/65afa9947beb518b04230875ec3bde967948f5b7/controller/kubernetes_pv_controller.go#L93-L96

Nevermind, this is necessary for the event subscription.


fix typo that caused a run-on sentence

@wjandrea : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good; thanks.


Implement boolean vectors

I've come around (thanks @hsivonen for being persuasive) and I think it makes sense to implement boolean vectors as part of stdsimd.
I think we could:

[ ] implement boolean vectors like in the simd crate (we don't need to be 1:1 on par in functionality on the initial implementation, we can add more features to boolean vectors later in a backwards compatible way)
[ ] make the comparison operators use them (these won't be stabilized in the first round anyways)
[ ] review all the intrinsics and decide on a case-by-case basis whether to use boolean vectors or not .

I think that none of this must block stabilization (although @hsivonen might disagree). First, IIUC the time-line is as follows: someday somebody will integrate this as part of core and stdsimd will be shipped to nightly users behind some feature flag. We should try hard to not break stuff from then on, but we can technically still break some stuff (like changing the return type of an unstable intrinsic to use boolean vectors). One release cycle later we will want to start stabilizing stuff. For that we are probably having to white-list intrinsics as stable on a case-by-case basis. Once we have done that we need to write an RFC with all those intrinsics inside and submit it to the RFC repo.
If we feel that boolean vectors aren't ready by then we don't stabilize them nor any intrinsic that we think might want to use them in the future. But I'd like to defer that discussion until then. For what we know boolean vectors might turn out to be ready, and we might want to just ship them.
Thoughts?

I don't think we should be adding boolean vectors to the vendor intrinsics. Vendor intrinsics are supposed to be a low level interface to vendor specific APIs, and none of the vendor specific APIs (at least for Intel) have a concept of a boolean vector. One may be implied by the stated contracts on a certain vendor intrinsics, but that means we need to go through all of them and vet them ourselves. We're already trying to improve the state of the world a little bit with more granular integer vector types, but only because others have (for the most part) already done that work for us.
I grant that boolean vectors may be a nice option for the portable API.

A simd PR is probably of interest when implementing this.

I think that none of this must block stabilization (although @hsivonen might disagree).

It seems like a problem if the return type of the comparison methods or vendor operations changes on stable.
Additionally to what the initial comment says, I think it would be good to have API surface for safely bitcasting bNxM to uNxM and iNxM (possibly even fNxM). The reserve should be unsafe, obviously.

none of the vendor specific APIs (at least for Intel) have a concept of a boolean vector

Every operation (including in the Intel case) whose output is defined to set all bits of a given to either zero or one conceptually returns a boolean vector even if the concept isn't a stated part of the Intel C API.
As for inputs, safe and convenient bitcasting from bNxM to uNxM and iNxM is needed so that boolean vectors don't hinder their usage as inputs to operations that don't care about the precondition that each lane is either all-zero or all-one.

@hsivonen

It seems like a problem if the return type of the comparison methods or vendor operations changes on stable.

What I was thinking is not stabilizing those intrinsics where we are unsure if we might want to make them return boolean vectors. That would mean that one must use rust nightly to use those, and the rust nightly code might break if we switch them to boolean vectors.
@BurntSushi

but that means we need to go through all of them and vet them ourselves.

Yes, that is what it would mean.
So I wanted to do this, but before doing so, I wanted to cheat a bit and look at the simd crate for examples of intrinsics in which boolean vector types are used there. The simd crate has following boolean types:

bool8i(i8), bool16i(i16), bool32i(i32), bool32f(i32)
bool32ix2(i32, i32), bool32fx2(i32, i32), bool32fx4(i32, i32, i32, i32), bool32ix4(i32, i32, i32, i32), bool16ix8(i16, ..., i16), bool8ix16(i8, ..., i8)

But... I cannot find a single intrinsic in the whole simd crate that uses them
The simd crate defines them as something extra, and implements some portable operations for them, but doesn't really use them. So... I don't really see the point of adding them if they are not used as the return type of some intrinsics.
@hsivonen is this correct? If so, I don't understand why they can't be provided by a different crate.
If what you wanted is for them to be used as the return type of some intrinsics, then I think you need to make a better case and tells us that a sufficient amount of intrinsics require them (e.g. by reviewing the x86 simd intrinsics and letting us know what you find).

The simd crate defines them as something extra, and implements some portable operations for them, but doesn't really use them. So... I don't really see the point of adding them if they are not used as the return type of some intrinsics.
@hsivonen is this correct?

No. The simd crate uses them as return types for comparisons. The corresponding intrinsics are simd_le, simd_eq, etc.

As for examples of vendor intrinsics that platform-intrinsics (simd_le, simd_eq, etc.) don't abstract over but that logically return boolean vectors, a quick look at the SSE family yields NaN checks: _mm_cmpord_ps.

As for examples of vendor intrinsics that platform-intrinsics (simd_le, simd_eq, etc.) don't abstract over but that logically return boolean vectors, a quick look at the SSE family yields NaN checks: _mm_cmpord_ps.

It would be nice to have a comprehensive list so that we can make an informed decision.

Boolean vectors have been implemented in #338. Only b8xN types are provided (e.g. wider types like b32x4 are not provided).
AFAICT, they don't seem to be required either, at least when taking into account the assembly generated for the SSE2 mm_cmpeq_epi16 intrinsic
// Compares two vectors of packed 16-bit integers
__m128i _mm_cmpeq_epi16 (__m128i a, __m128i b)

which returns an __m128i that, when transmuted into a i16x8, has lanes that only contain either 0x00 (false) or 0xff (true).
First I consider these two cases:
pub unsafe fn foo(x: i16) -> __m128i {
    let a = _mm_setr_epi16(x, 1, 2, 3, 4, 5, 6, 7);
    let b = _mm_setr_epi16(7, x, 2, 4, 3, 2, 1, 0);
    _mm_cmpeq_epi16(a, b)
}

pub unsafe fn bar(x: i16) -> i16x8 {
    let a = i16x8::new(x, 1, 2, 3, 4, 5, 6, 7);
    let b = i16x8::new(7, x, 2, 4, 3, 2, 1, 0);
    _mm_cmpeq_epi16(a.into_bits(), b.into_bits()).into_bits()
}

which produce identical assembly. Then I switched bar to output only whether the third element is true or false, and added another function that does the same using boolean vectors:

pub unsafe fn bar2(x: i16) -> bool {
    let a = i16x8::new(x, 1, 2, 3, 4, 5, 6, 7);
    let b = i16x8::new(7, x, 2, 4, 3, 2, 1, 0);
    let b: i16x8 = _mm_cmpeq_epi16(a.into_bits(), b.into_bits()).into_bits();
    b.extract(3) == 0xffff_i16
}

pub unsafe fn baz(x: i16) -> bool {
    let a = i16x8::new(x, 1, 2, 3, 4, 5, 6, 7);
    let b = i16x8::new(7, x, 2, 4, 3, 2, 1, 0);
    let b = b8x8::from_bits(i8x8::from(i16x8::from_bits(_mm_cmpeq_epi16(a.into_bits(), b.into_bits()))));
    b.extract(3)
}

The functions bar2 and baz produce identical assembly as well. If we switch these functions to return the vectors, then the assembly differs slightly, because the types being returned are different. But they both look equally expensive.
@rkruppe pointed out that LLVM comparisons actually return <i1 x N>, but the best we can do in Rust is probably store them as <i8 x N>. AFAICT the b8xN vectors should be enough, but if we ever need wider boolean vectors we can always add them later.

Boolean vectors have been implemented in #338.

Thank you!

Only b8xN types are provided (e.g. wider types like b32x4 are not provided).

Why? I ported encoding_rs to stdsimd. The performance of the parts that use boolean vectors regressed significantly.
$ cargo benchcmp --threshold 25 --regressions trunk_2018-03-08.txt stdsimd_2018-03-08.txt
 name                                               trunk_2018-03-08.txt ns/iter  stdsimd_2018-03-08.txt ns/iter  diff ns/iter  diff %
 bench_encode_from_utf16_en                         5,730 (11294 MB/s)            7,836 (8259 MB/s)                      2,106  36.75%
 bench_encode_from_utf16_en_windows_1252            6,527 (9925 MB/s)             8,434 (7681 MB/s)                      1,907  29.22%
 bench_encode_from_utf16_jquery                     6,347 (13661 MB/s)            8,866 (9779 MB/s)                      2,519  39.69%
 bench_encode_from_utf16_jquery_windows_1252        5,853 (14814 MB/s)            7,923 (10943 MB/s)                     2,070  35.37%
 bench_mem_check_utf16_for_latin1_and_bidi_de_1000  44,481 (22481 MB/s)           73,276 (13647 MB/s)                   28,795  64.74%
 bench_mem_check_utf16_for_latin1_and_bidi_ja_1000  125,719 (7954 MB/s)           183,051 (5462 MB/s)                   57,332  45.60%
 bench_mem_check_utf16_for_latin1_and_bidi_th_1000  89,725 (11145 MB/s)           162,244 (6163 MB/s)                   72,519  80.82%
 bench_mem_convert_utf16_to_str_ascii_1000          43,173 (23162 MB/s)           59,020 (16943 MB/s)                   15,847  36.71%
 bench_mem_convert_utf16_to_utf8_ascii_1000         40,040 (24975 MB/s)           55,908 (17886 MB/s)                   15,868  39.63%
 bench_mem_copy_basic_latin_to_ascii_1000           34,685 (28830 MB/s)           51,144 (19552 MB/s)                   16,459  47.45%
 bench_mem_copy_basic_latin_to_ascii_16             1,308 (12232 MB/s)            1,669 (9586 MB/s)                        361  27.60%
 bench_mem_ensure_utf16_validity_ascii_1000         49,748 (20101 MB/s)           71,781 (13931 MB/s)                   22,033  44.29%
 bench_mem_ensure_utf16_validity_bmp_1000           49,752 (20099 MB/s)           71,720 (13943 MB/s)                   21,968  44.16%
 bench_mem_ensure_utf16_validity_latin1_1000        49,748 (20101 MB/s)           72,688 (13757 MB/s)                   22,940  46.11%
 bench_mem_is_basic_latin_false_15                  1,333 (11252 MB/s)            1,935 (7751 MB/s)                        602  45.16%
 bench_mem_is_basic_latin_true_1000                 14,957 (66858 MB/s)           23,125 (43243 MB/s)                    8,168  54.61%
 bench_mem_is_str_latin1_true_3                     1,024 (1464 MB/s)             1,936 (774 MB/s)                         912  89.06%
 bench_mem_is_str_latin1_true_30                    3,558 (4215 MB/s)             4,563 (3287 MB/s)                      1,005  28.25%
 bench_mem_is_utf16_bidi_de_1000                    38,694 (25843 MB/s)           71,216 (14041 MB/s)                   32,522  84.05%
 bench_mem_is_utf16_bidi_ja_1000                    125,718 (7954 MB/s)           183,042 (5463 MB/s)                   57,324  45.60%
 bench_mem_is_utf16_bidi_ru_1000                    61,462 (16270 MB/s)           96,280 (10386 MB/s)                   34,818  56.65%
 bench_mem_is_utf16_bidi_th_1000                    89,466 (11177 MB/s)           162,250 (6163 MB/s)                   72,784  81.35%
 bench_mem_is_utf16_latin1_true_1000                14,883 (67190 MB/s)           25,335 (39471 MB/s)                   10,452  70.23%
 bench_mem_is_utf8_latin1_true_15                   4,023 (1864 MB/s)             5,660 (1325 MB/s)                      1,637  40.69%
 bench_mem_utf16_valid_up_to_ascii_1000             49,362 (20258 MB/s)           72,247 (13841 MB/s)                   22,885  46.36%
 bench_mem_utf16_valid_up_to_bmp_1000               49,362 (20258 MB/s)           72,216 (13847 MB/s)                   22,854  46.30%
 bench_mem_utf16_valid_up_to_latin1_1000            49,363 (20258 MB/s)           72,247 (13841 MB/s)                   22,884  46.36%

(The results being compared are merges of the fastest results of four runs with the simd crate and four runs with the stdsimd crate. The numbers are from Intel Core i7-4770 @ 3.40 GHz.)
To have the kind of performance that one would expect, it seems to me that an operation that returns a boolean vector should return a vector of the same bit width as the operands and the any() and all() reductions should be as simple as the ISA allows as seen in the simd crate. (I'll file a different issue about the latter.)

I'll file a different issue about the latter.

Filed #362.

The performance of the parts that use boolean vectors regressed significantly.

Note that these operate on UTF-16, so they compare u16x8 with lt. With simd, the result was bool16ix8. With stdsimd it's b8x8. I believe it needs to be b16x8 in order to not to make portable SIMD too slow to be competitive with architecture-specific code.

@hsivonen

Only b8xN types are provided (e.g. wider types like b32x4 are not provided).

Why?

Because converting from wider types to b8xN should be either be very cheap, or free when done correctly.
In particular, boolean operations always return b8xN right now, so there is nothing to convert if you are doing a.lt(b). When you have a wider type, you would need to do a conversion, and then a boolean reduction. If LLVM doesn't do the reduction directly in the wider type, then that's IMO either an LLVM bug or a bug on our side.

Because converting from wider types to b8xN should be either be very cheap, or free when done correctly.

What does "correctly" mean in this context?

In particular, boolean operations always return b8xN right now, so there is nothing to convert if you are doing a.lt(b).

I don't understand. If a and b are u16x8, lt should compile as _mm_cmplt_epi16, whose output is 128 bits wide and matches the semantics of bool16ix8 from the simd crate. In stdsimd, at the moment, the output is declared as 64 bits wide, so any operation that actually forces LLVM to materialize the 64-bit  representation somewhere involves a conversion.

If LLVM doesn't do the reduction directly in the wider type, then that's IMO either an LLVM bug or a bug on our side.

The pattern I'm using doesn't logically involve LLVM having to materialize the 64-bit type in RAM. Logically, everything should happen in 128-bit registers:
        #[inline(always)]
        pub fn simd_is_basic_latin(s: u16x8) -> bool {
            let above_ascii = u16x8::splat(0x80);
            s.lt(above_ascii).all()
        }

Yet, performance suffers when going from simd to stdsimd.
It seems very brittle to me to define a narrower type (64 bits) and hope that LLVM never needs to actually materialize it as a 64-bit type and operations actually get done in 128-bit registers.
In some sense, part of the problem here is that all types need to have a concrete memory representation. After all, logically in this case there are just 8 bits we care about, not even 64, but it's crucial for performance that the 8 bits are stretched across a 128-bit register. It seems to me that design used in the simd crate where the memory representation is declared as 128 bits wide when we want it to have a 128-bit register representation is the more robust way to go in practice. At least at present, the benchmarks are firmly in support of the design used in the simd crate.

To improve my understanding from a different angle:
What concrete problem (apart from the abstract problem of the number of types proliferating) is solved by having a single boolean vector type for a given lane count (as in stdsimd today) compared to having a boolean vector type for each lane count and lane width combination (is in simd)?
AFAICT, in realistic use cases, one wouldn't typically need to have boolean vectors of the same lane count but different lane widths interact without conversion ceremony.

What does "correctly" mean in this context?

In a way that conveys to LLVM that these vectors are boolean vectors.

If a and b are u16x8, lt should compile as _mm_cmplt_epi16, whose output is 128 bits wide and matches the semantics of bool16ix8 from the simd crate.

It should compile to whatever instruction sequence makes your code run faster. If you don't use the result of that comparison, it should compile to nothing.

Yet, performance suffers when going from simd to stdsimd.

As mentioned in #362 this is currently an expected performance bug that needs to be fixed.

What concrete problem (apart from the abstract problem of the number of types proliferating) is solved by having a single boolean vector type for a given lane count (as in stdsimd today) compared to having a boolean vector type for each lane count and lane width combination (is in simd)?

It makes it easier for LLVM to optimize sequences of SIMD instructions across all ISAs.

What does "correctly" mean in this context?

In a way that conveys to LLVM that these vectors are boolean vectors.

Can we not convey to LLVM that b16x8 is a boolean vector?
Having a type whose declared bit width differs from the bit width that is performant on the machine still scares me. Also, it worries me not to be able to be sure that viewing a boolean vector as a bitmask is a zero-cost transmute.
encoding_rs doesn't have this code yet, but consider this SIMD implementation of converting x-user-defined to UTF-16 using the simd crate:
#[inline(always)]
fn shift_upper(s: u16x8) -> u16x8 {
  let highest_ascii = u16x8::splat(0x7F);
  let offset = u16x8::splat(0xF700);
  let mask = s.gt(highest_ascii).to_repr().to_u16();
  s + (offset & mask)
}

#[inline(always)]
fn decode_x_user_defined_to_utf16(b: u8x16) -> (u16x8, u16x8) {
  let (a, b) = unpack(b); // zero extends one u8x16 into two u16x8s
  (shift_upper(a), shift_upper(b))
}

With the simd crate it's obvious that the .to_repr().to_u16() piece is purely a compile-time type system-level thing that's a no-op for ISA purposes. I don't need to convince myself that the compiler is Sufficiently Smart to make it a no-op. (It would be nicer, though, if I could get the u16x8 view with one method call instead of chain of two.)
With stdsimd, it's not even obvious at the API level how I could turn a b8x8 into a u16x8 whose each lane is 0 or 0xFFFF, so I can't even get to the point of pondering if the compiler is Sufficiently Smart to optimize it all away so that everything that happens on the ISA level is the lane-wise greater-than and the next operation is the bit-wise AND on the register contents obtained from the lane-wise greater-than.
It may look like I'm flipflopping by first complaining that comparisons don't return boolean vectors and then turning around and complaining that I don't get the result as integer lanes, but I have previously emphasized that it's both important that comparisons signal on the type system level that all bits on each lane are either set or unset and that it is important that this type layer can be waived at zero cost to get at the actual bits.

It should compile to whatever instruction sequence makes your code run faster.

Is there a concrete example of this within the bounds of the target having the same register width as the code uses? (I.e. it's a priority for me that u16x8 complied to SSE2 or NEON is fast. It's less important whether u16x8 auto-unrolls to u16x16 when compiling for an AVX-enabled target.)
Superficially, it seems unbelievable that any() and all() could compile to anything faster than the manual implementations that the simd crate provides for SSE2 or aarch64 when targeting SSE2 or aarch64, respectively. (In both cases, a single vector instruction that produces a value in an ALU register followed by an ALU comparison of that value with a constant.)

It makes it easier for LLVM to optimize sequences of SIMD instructions across all ISAs.

Considering that sequences of operations on boolean vectors are bitwise ops on the whole register and the simd crate hand-rolled any() and all() for SSE2 and aarch64 as simple as described above, it's hard to see the optimization opportunity (excluding unrolling to AVX). Is there a concrete example?

As mentioned in #362 this is currently an expected performance bug that needs to be fixed.

It's unclear to me if you mean a performance bug in the sense that you have something simple in mind that makes stdsimd match the speed of simd with LLVM 6 or if you mean in the sense of LLVM needing to become Sufficiently Smart.

If you want to argue for wider boolean vectors here using examples of bad codegen to motivate their need, you should be using examples that do not trigger the codegen bug. Otherwise we can't tell whether the bad codegen is due to the bug, or due to the type not being wide enough.

With the stdsimd API, what's the correct way to go from a b8x8 to a u16x8 bitmask?

From/Into is the right way to do that.

I'm worried that having a type whose memory representation differs from what can be loaded into the efficient register representation using movdqa in the SSE2 case will be bad in cases where the type needs to be materialized in memory.

I understand the worry, but right now it is just that, a worry.

With the stdsimd API, what's the correct way to go from a b8x8 to a u16x8 bitmask?

From/Into is the right way to do that.

I don't see this case implemented. What am I missing?
error[E0277]: the trait bound `stdsimd::simd::u16x8: std::convert::From<stdsimd::simd::b8x8>` is not satisfied
  --> src/x_user_defined.rs:23:58
   |
23 |             let mask: u16x8 = unpacked.gt(highest_ascii).into();
   |                                                          ^^^^ the trait `std::convert::From<stdsimd::simd::b8x8>` is not implemented for `stdsimd::simd::u16x8`
   |
   = help: the following implementations were found:
             <stdsimd::simd::u16x8 as std::convert::From<stdsimd::simd::f64x8>>
             <stdsimd::simd::u16x8 as std::convert::From<stdsimd::simd::u32x8>>
             <stdsimd::simd::u16x8 as std::convert::From<stdsimd::simd::i32x8>>
             <stdsimd::simd::u16x8 as std::convert::From<stdsimd::simd::i16x8>>
           and 5 others
   = note: required because of the requirements on the impl of `std::convert::Into<stdsimd::simd::u16x8>` for `stdsimd::simd::b8x8`

I don't see this case implemented. What am I missing?

Nothing, the error is correct, the implementation is missing.

This has been implemented already.


Redesign the Home Page

I am on it! Can you please assign this task to me?

I can go ahead wid it

I can work on it too!

@aswinikalyan30 Go for it !

please assign this to me

@aswinikalyan30 Go for it !

Hey, you can assign it to someone else! I am working on a few other ones, because of which I won't be able to move forward with this

@SauravMukherjee44 please add description means what to redesign in home page.

I would like to contribute here, please do add proper description on what to redesign

Create a PR.

i can style the dropdown menus and css of the page to make it look better....i would like to work on this issue.
previously i worked on the styling of this project. https://namankhare.github.io/yet-another-tip-calculator/


OSX: Nettle and ZMQ build fail (wrong path)

I've just updated my old Anaconda installation, installed the current Julia (0.5), and from the Julia REPL I run:
Pkg.add("IJulia")

This fails. The error boils down to this:
julia> Pkg.build("Nettle", "ZMQ")
INFO: Building Homebrew
Already up-to-date.
INFO: Building Nettle
=====================[ ERROR: Nettle ]=====================

LoadError: SystemError: unable to read directory
/Users/pi/.julia/v0.5/Homebrew/deps/usr/Library/Taps/staticfloat/homebrew-juliatranslated:
No such file or directory
while loading /Users/pi/.julia/v0.5/Nettle/deps/build.jl, in expression starting on line 39

===========================================================
INFO: Building ZMQ
======================[ ERROR: ZMQ ]=======================

LoadError: SystemError: unable to read directory
/Users/pi/.julia/v0.5/Homebrew/deps/usr/Library/Taps/staticfloat/homebrew-juliatranslated:
No such file or directory
while loading /Users/pi/.julia/v0.5/ZMQ/deps/build.jl, in expression starting on line 38

===========================================================

=====================[ BUILD ERRORS ]======================

WARNING: Nettle and ZMQ had build errors.

 - packages with build errors remain installed in /Users/pi/.julia/v0.5
 - build the package(s) and all dependencies with `Pkg.build("Nettle", "ZMQ")`
 - build a single package by running its `deps/build.jl` script

===========================================================

If I inspect my paths,
<EMAIL_ADDRESS>~ /Users/pi/.julia/v0.5/Homebrew/deps/usr/Library/Taps/staticfloat:
 ⤐  ls
homebrew-juliadeps

<EMAIL_ADDRESS>~ /Users/pi/.julia/v0.5/Homebrew/deps/usr/Library/Taps/staticfloat:
 ⤐  cd homebrew-juliadeps/

<EMAIL_ADDRESS>~ /Users/pi/.julia/v0.5/Homebrew/deps/usr/Library/Taps/staticfloat/homebrew-juliadeps:
 ⤐  ls
LICENSE			fontconfig.rb		openlibm.rb
README.md		glpk452.rb		openspecfun.rb
bonmin.rb		glpk455.rb		optimizationservices.rb
cbc.rb			ipopt.rb		rmath-julia.rb
couenne.rb		libgfortran.rb		scs.rb
ecos.rb			mirror_bottles.sh	zeromq32.rb

.../Taps/staticfloat/homebrew-juliatranslated <-- it expects this
.../Taps/staticfloat/homebrew-juliadeps <-- I have this
What's going wrong? Installation was seamless on my iMac.

Can you file an issue with Homebrew.jl?  This doesn't seem like an IJulia issue per se.


Added an example master-config with github oauth integration

Added master config tested on OCP3.7 with github OAuth2 integration for future testing.

@alexander-demichev, have a look, this is one more example of github oauth from OCPv3.7. We have to decide, whether we want to test against all the OCPv3 minor versions. And if we do - we want to figure out how to keep this in project structure.
CC: @gildub

@alexander-demichev, we might encounter similar difference across the board between ocp 3 versions. For instance node-config, etc. Therefore we could store the difference under example/ocp-3.<x> or something equivalent), for instance example/ocp-3.7/etc/origin/.../

@gildub I agree, we should store it under ocp-3.xdirectories.

@alexander-demichev, is it good to go?


Confusing (possible incorrect) handling of template parts and their stock

If you look at the demo site, you see 1 item out of stock... "Widget Assembly".
But clicking the part you see it has 166 parts in stock (this includes the variants).
So which statement is valid:
A) Templates have their own stock, variants should not be included
B) Templates and all their variants share a common stock count
C) Is there another use case why this correct that I'm missing...
Maybe it is directly coupled to the way you are using a template part (which I'm personally still figuring out).
You can have:
Template
|- Part 1
|- Part 2
Part 1 (as a Template)
|- Variant A
|- Variant B
Any thoughts on this would be appreciated.

@bloemp minimum stock required are per-part. So only for the part itself.

But in that case a template part should not count his variants as its own stock, correct?

I think the current system makes sense, maybe we need to add some docs regarding this.
@SchrodingersGat thoughts?

Personally I think that the "low stock" information should take "variant stock" into account (which is not how the current implementation works). Changing this would require a number of fixes to the underlying API

Having some docs that clear up what the implemented idea behind a template is, could help.
At the moment I see a few use cases that all kind of work, but are conflicting at the stock level...
Use case 1:
A template part (like a screw) and create variants of this part (same size different screw head types).
In this case having low stock on all variants would make sense (in my opinion).
Use case 2:
A template part (like a fuse) and create variants of this part (same rating, different dimensions).
In this case the template part could be is its own part, or it can even be a real template which only exists to easily make new variants. It would make sense to have the template have it's own stock. It seems that this use case is also used in #3338
Would supporting both use cases be an option by adding a "Include variant stock" option to the part?

I like the objective to clear this up - counting variant stock as stock of the template part (as it is done right now) is generally tricky to meet the consistency expectations of a user in my opinion. If at all this would only make actually sense for pure template parts, where it would still be important to mark as variant stock somehow, since a combined stock of different lengths of screws do not have much use as an information regarding stock levels in the warehouse:

There is no way to tell if that variant stock could actually be used as a substitute or variant replacement for build orders: the decision if variants can be used as stock for a BOM item is only a parameter of BOM line items, not of the part itself.
Variant stock is of no informational value for sales orders, because sales order line items refer to specific parts only.

Maybe I am missing something - but I cannot find a good example for where the combined stock level including variant parts would be useful information for a part in lists and such. @SchrodingersGat and @matmair, could you give a fitting example here?
This is how I would suggest to change towards:

Stock always only counts as the direct stock of the part itself, stock level information is then consistent to all other parts (and can be displayed via stock health level badges consistently throughout the interface as well)
The Part detail view could get an additional separate table in the Stock tab that lists Variant Stock for informative purpose

As a general guide to determine how stock levels are calculated/displayed, we should maybe first clearly describe the intended use of that information in the daily business. My personal favorite here would be to "give the user actionable information of the stock level health of a part" --> do we have enough? do I need to order? too low but already ordered? etc. (which is pretty much how the new stock health badges in the search forms are working)

I think it should be left up to the user to ensure that all template parts can be used interchangeably. In the use case they assign them.
I use them in my personal instance to mark parts in different colors and materials. For example: I have different knobs of the make DIN 6336 - all of them are variants of the master DIN part of a given knob size. If I need only a knob of a given size I use the template part. If I need specific colors or strengths I use that variant part. That way I am more flexible in my use.

@simonkuehling it actually comes from the supply chain woes of the last years in my case, it is very much business oriented. Using variants for nested parts sounds like a very maintenance-intensive process.
A setting sounds good. The tag should be located in the STOCK namespace IMO. STOCK_INCLUDE_VARIANTS of similar.

@matmair I see… don‘t even get me started on supply chain nightmares, totally understand to desire any solution to avoid yet another new assembly revision again…
In my use case I have variants of machine assemblies that are used like a configurator - a core setup that has variants which have other modules added for example. This falls apart quickly if you try to have more than one configurable option (like a color and an optional additional module for example) - so that‘s not a super clean use case in itself as well to be honest…
Let‘s assume we introduce a STOCK_INCLUDE_VARIANTS  config setting. Disabling the setting is pretty straight forward for the implementation, that‘s easy.
But how would the logic look like for the enabled setting - as @bloemp mentioned, the minimum stock count values of template parts and their variants interfere with another in the current implementation.


PeriodLoadRule cannot Remove expired segment

Recently, when deploying the cold/hot layered Druid cluster, it was found that a hot node loaded data beyond the time range, resulting in the hot node's storage being full soon. I found the same problem on the Druid forum page, which has not been handled by anyone for a long time. I checked RunRules.java, I feel there is a problem. Periodloadrule will not delete expired data at all, but only delete too many replicants. Does the current implementation of PeriodLoadRule meet expectations?
The following is the current implementation of druid:
//RunRules.run
      for (Rule rule : rules) {
        if (rule.appliesTo(segment, now)) {
          if (
              stats.getGlobalStat(
                  "totalNonPrimaryReplicantsLoaded") >= paramsWithReplicationManager.getCoordinatorDynamicConfig()
                                                                                .getMaxNonPrimaryReplicantsToLoad()
              && !paramsWithReplicationManager.getReplicationManager().isLoadPrimaryReplicantsOnly()
          ) {
            log.info(
                "Maximum number of non-primary replicants [%d] have been loaded for the current RunRules execution. Only loading primary replicants from here on for this coordinator run cycle.",
                paramsWithReplicationManager.getCoordinatorDynamicConfig().getMaxNonPrimaryReplicantsToLoad()
            );
            paramsWithReplicationManager.getReplicationManager().setLoadPrimaryReplicantsOnly(true);
          }
          stats.accumulate(rule.run(coordinator, paramsWithReplicationManager, segment));
          foundMatchingRule = true;
          break;
        }
      }

Now, I have solved this problem by adding dropallExpireSegments to PeriodLoadRule.java, but I don't know what bad effect it will have.
Here is my implementation:
//RunRules.run
      for (Rule rule : rules) {
        if (rule.appliesTo(segment, now)) {
          if (
              stats.getGlobalStat(
                  "totalNonPrimaryReplicantsLoaded") >= paramsWithReplicationManager.getCoordinatorDynamicConfig()
                                                                                .getMaxNonPrimaryReplicantsToLoad()
              && !paramsWithReplicationManager.getReplicationManager().isLoadPrimaryReplicantsOnly()
          ) {
            log.info(
                "Maximum number of non-primary replicants [%d] have been loaded for the current RunRules execution. Only loading primary replicants from here on for this coordinator run cycle.",
                paramsWithReplicationManager.getCoordinatorDynamicConfig().getMaxNonPrimaryReplicantsToLoad()
            );
            paramsWithReplicationManager.getReplicationManager().setLoadPrimaryReplicantsOnly(true);
          }
          stats.accumulate(rule.run(coordinator, paramsWithReplicationManager, segment));
          foundMatchingRule = true;
          break;
        }else{
          //Add Delete Logic,Only implement dropAllExpireSegments in PeriodLoadRule
          rule.dropAllExpireSegments(paramsWithReplicationManager,segment);
        }
      }

Affected Version
0.22.0

I believe @AmatyaAvadhanula and @kfaraz were looking into this area of the code too, working to improve the Coordinator balancing behavior. Perhaps they will have some thoughts.

@599166320 , drop is handled by DropRules like a ForeverDropRule, none of the LoadRules are supposed to have that capability.  The coordinator tries to find the first rule which applies to a given segment at a given time and tries to do what that matched rule suggests. If at any point in the lifetime of a segment, it matches with a DropRule, it gets dropped.
So, I think the problem you are facing can be solved by simply having a ForeverDropRule at the end of your retention rule list (default or datasource-specific). Please let us know if this works for you.

thank  @kfaraz   for your reply. If I want the _defaultTier node to keep the hot data of the last 3 days, and the cold node to keep the cold data of the last 7 days, how should my retention rules be configured?
My retention rules are configured as follows:
loadByPeriod P3D _defaultTier
loadByPeriod P7D cold
dropForever

Will this meet my needs?
According to the current implementation of RunRules, the _defaultTier node will retain data for 7 days, and retain data for 4 more days. I think it is unreasonable, what do you think?

I think @kfaraz 's answer makes sense.
Actually, our doc has pointed out this:

Load rules indicate how many replicas of a segment should exist in a server tier. Please note: If a Load rule is used to retain only data from a certain interval or period, it must be accompanied by a Drop rule. If a Drop rule is not included, data not within the specified interval or period will be retained by the default rule (loadForever).

Although we have doc to state this, I think current default rule(loadForever) is little bit counterintuitive.
Maybe the default rule should be dropForever? But because Druid provides flexible retention rules(both load and drop), chaning the default rule to dropForever might not be so easy.
In constrast to Druid, some other DBs, only provides load rules(not the same concept, but similiar to Druid's load rule), so it makes sense that its default behaviour is a dropForever rule.

@599166320 , for your case, what you need may look like this:
loadByPeriod P3D _defaultTier=1 replica, cold=1 replica
loadByPeriod P7D cold=1 replica
dropForever

Data not more than 3 days old lives on both default and cold tiers
Data more than 3 days old and upto 7 days old lives only on cold tier
older data is dropped
The only thing I added was the cold tier replicas in the first rule. If you don't have that, cold tier will not have data of the past 3 days. Is this what you intended?

@FrankChen021 , maybe there is some middle ground here?
The default rule should be loadForever to allow things to function properly right out the box, without having to configure anything.
But when a user explicitly modifies the rules (for a datasource or global), it's only natural that the last rule be a forever rule, either load or drop. If the user has already given it as so, good, otherwise, we tack on a dropForever rule at the end ourselves. (The user wouldn't mind us doing this as they were particular about loading data only upto a certain period/interval.)
Translated to the code, this simply means that if no rule matches, we drop the segment. This is because no rule matching implies that the retention rules have been explicitly modified by the user, otherwise the default loadForever would have matched.
We already have an alert for segments that don't match any rule but the behaviour should still be reconsidered because it is indeed a little counterintuitive.

@FrankChen021 , maybe there is some middle ground here?
The default rule should be loadForever to allow things to function properly right out the box, without having to configure anything.
But when a user explicitly modifies the rules (for a datasource or global), it's only natural that the last rule be a forever rule, either load or drop. If the user has already given it as so, good, otherwise, we tack on a dropForever rule at the end ourselves. (The user wouldn't mind us doing this as they were particular about loading data only upto a certain period/interval.)
Translated to the code, this simply means that if no rule matches, we drop the segment. This is because no rule matching implies that the retention rules have been explicitly modified by the user, otherwise the default loadForever would have matched.
We already have an alert for segments that don't match any rule but the behaviour should still be reconsidered because it is indeed a little counterintuitive.

@kfaraz I found that default tiers store data for 7 days. Is there a problem with my configuration?

@599166320 , could you please share the json of your rules for this datasource?

@599166320 , could you please share the json of your rules for this datasource?

You can see it in the Druid forum.
In addition, I found a problem with the following code, and I have repaired it. I ran normally for 2 days
	  //RunRules.run
      for (Rule rule : rules) {
        if (rule.appliesTo(segment, now)) {
          //
          if (
              stats.getGlobalStat(
                  "totalNonPrimaryReplicantsLoaded") >= paramsWithReplicationManager.getCoordinatorDynamicConfig()
                                                                                .getMaxNonPrimaryReplicantsToLoad()
              && !paramsWithReplicationManager.getReplicationManager().isLoadPrimaryReplicantsOnly()
          ) {
            log.info(
                "Maximum number of non-primary replicants [%d] have been loaded for the current RunRules execution. Only loading primary replicants from here on for this coordinator run cycle.",
                paramsWithReplicationManager.getCoordinatorDynamicConfig().getMaxNonPrimaryReplicantsToLoad()
            );
            paramsWithReplicationManager.getReplicationManager().setLoadPrimaryReplicantsOnly(true);
          }
          stats.accumulate(rule.run(coordinator, paramsWithReplicationManager, segment));
          foundMatchingRule = true;
          break;
        }
      }

@kfaraz Have you checked retention rules? Will retention rules be improved? Or is there no problem now?

@599166320 , taking a look at the rules now.
Could you also elaborate the fix that you made to the mentioned piece of code?

@599166320 , the configuration seems to be correct for your required behaviour.
It seems that your cold tier needs to have 2 replicas. Do you have enough historicals in the cold tier?
If you don't, then it is possible that the segments are never able to reach the target replication of 2.
Currently, not being at the target replication level can also block the cleanup from the _default_tier.
If you have a metric emitter configured, you can check these metrics emitted by the coordinator to
be certain:
segment/underReplicated/count
segment/dropped/count
Alternatively, you can also take a look at the logs at try to find logs which say something like:
"Loading in progress for segment [<segmentIdhere>], skipping drop from tier [<tierNameHere>] until loading is complete! "

@kfaraz The cold tier of our cluster has enough historicals. The current problem is that we don't want to  _default_tier's storage is full too fast.
I will create a PR and let you review it.

Today, another cluster of ours (without any modification) once again experienced the problem that the expired data of the hot node was not deleted, causing the storage space to be quickly used up.

It looks like the storage space of the hot node is almost full, and the cold node still has enough storage space.

Here are some monitoring:

After this problem occurred, I quickly emitted the monitoring data to promethues. After observing for two hours, I upgraded the master node and applied LoadDropByPeriod, and the cluster quickly returned to normal. Of course, our cluster also found some problems in the process of applying LoadDropByPeriod, such as the need to limit the speed of deletion.
I still have a few hours of monitoring data on my side that I can share with you if you need it. @kfaraz


Upgrade google-auth-library to 8

This was fixed in https://github.com/googleapis/nodejs-common/pull/749 (this library depends on "@google-cloud/common": "^4.0.0", which was released in June 2022 with the google-auth-library upgrade mentioned). Thanks for filing, and apologies for the delay in response!


Doc example update

Wrong variable called in example, query_input -> value_input

@googlebot I signed it!

Please open against master.

@grofte closing this PR. As mentioned by @mihaimaruseac, @qlzh727, please open the PR against the master branch. Thanks!


provide Medium-style email authentication

We should provide Medium-style email authentication.
Old
We should provide password authentication. You should be able to use either your username and/or an email address (which one? only primary? configurable per-address?). This ticket started out being about signing up with email, but the actual important/hard part is the password authentication.
We first discussed email sign-up on #89, but that became more about linking email accounts to existing Gittip accounts rather than using email to sign up in the first place. Here's a ticket about signing up with email in the first place, in response to a request I received in private email:

Is there a way to give money without signing up for Twitter, etc.?

We currently rely on social network profiles to detect fraud. It does limit our reach, however.
Notify:

[ ] https://gratipay.freshdesk.com/helpdesk/tickets/2358
[ ] https://gratipay.freshdesk.com/helpdesk/tickets/2749
[ ] https://gratipay.freshdesk.com/helpdesk/tickets/3213
[ ] https://gratipay.freshdesk.com/helpdesk/tickets/6349

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Some recent thinking on design for this:
http://blog.codinghorror.com/the-god-login/

@whit537 I'd also recommend trying to help break the trend that xkcd 936 illustrates by giving an example using multiple words, and possibly by pushing the term 'passphrase'.
Also, that was a good read :P  Not sure why I hadn't thought of making login attempts progressively slower as more failures occur, since that's something that's been done by Unix and Unix-likes for decades.

+1 and thx for "the God login", very interesting!

+1 https://gratipay.freshdesk.com/helpdesk/tickets/1667

Something to consider when we get around to implementing this:

Attack on Rails apps: sign up as<EMAIL_ADDRESS>copy _app_sess, wait for the victim to set a new password, then use saved session

Hah, did you see my RT of that? :stuck_out_tongue_winking_eye:
The vulnerability being that Rails doesn't invalidate session tokens stored as cookies, and that the most popular authentication library for Rails (Devise) doesn't require email confirmation by default.
That wouldn't be an issue for Gratipay, since we store session tokens in the database (and only one per user). So the moment the owner of the account claims their email address in our system, the attacker's session token would be invalidated. That's assuming we don't require email address confirmation, which of course we should also do.

@seanlinsley Yeah, that's where I got it. Should've mentioned, sorry. :-P

+1 on FJ:

I don't use Gratipay, because you have to log in to Gratipay using Twitter, Google +, Facebook, GitHub, Bitbucket, or OpenStreetMap. I don't use any of those things and I haven't even heard of a few of them. [...] Would FJ accept donations through a different site than Gratipay?

Interesting. Medium has added email authentication, but without passwords. They mail you a new link every time you want to sign in.

I think we should go the Medium route. It's much simpler to implement and reduces our security exposure significantly.

:+1:

+1 for Persona from FD:

Do you plan on providing login methods that are more neutral? I'd like
to use Personna or anything that wouldn't require me to use a
Github/Facebook/any other non free platform.

I think we should make this our only authentication mechanism, and we should phase out account merging.

I'm putting this on "Solve Corporate Sponsorship of Open-Source" because using the company Twitter to login to Gratipay is onerous when you're sitting in one department and marketing owns Twitter and they're way over there.

I'm pretty sure the tokens used to authenticate during email sign-up should be treated as passwords.
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

+1 from @sampablokuper in #4085.

+1 from Freshdesk:

I understand your problem [with fraud detection]. However, a lot of people will have privacy
issues with that. Personally, I won't sign onto anything through a
social site because of the information that it makes available. Email
authentication works for me, but not signing up through Facebook or Twitter.

+1 from Earl at the coffee shop! ☕

+1 from FD. This particular issue is compounded by not showing giving amounts on the chalkboard when the credit card isn't working.

So this really isn't the most helpful e-mail. There's no information here as to what my login is. I tried twitter, facebook, google, and github and none of them show me having any donations. What's the account? Seems pretty basic. I imagine most people just ignore the e-mails and drop off doing donations. Let me know how I can actually login or just remove my account.
On Thu, Feb 2, 2017 at 9:09 AM, Gratipay Support<EMAIL_ADDRESS>wrote:
Gratipay
We tried to charge your credit card $10.74 today, to fund your ongoing support for [redacted] and 5 others, but the charge failed with this message:
Declined
Fix Credit Card
Something not right? Reply to this email for help.
Sent by Gratipay, LLC | 716 Park Road, Ambridge, PA, 15003, USA
To stop receiving emails like this, change your notification preferences.

I found the solution to this issue: https://youtu.be/VgC4b9K-gYU

Would like to see #638 (2FA) as part of this.

Thinking about how we can split this into small pieces:

[ ] Split out dedicated sign-in/sign-up pages. As a side effect, this also helps solve 1) the unfriendly 401 page problem (#4489) 2) Confusion around using the wrong third-party account to sign-in, ends up creating a new account - which requires account merging to fix.
[ ] Allow sign-in via email (under a beta query param) such that any existing verified email address can be used. Things to think about: 1) Rate limiting/Captcha
[ ] Allow sign-up via email (under a beta query param). Things to think about: 1) Rate limiting/Captcha 2) Claim username before email confirmation or after? 3) Participants with zero social logins - make sure no assumptions are left across codebase?
[ ] Remove feature flag for sign-up and sign-up via email

@rohitpaulk What's the purpose of separating sign-in and sign-up (apart from the side effects)?
I was envisioning a process like Medium's, where email is just another of several options under "Sign in / Sign up."

In terms of user experience (and apart from the side effects), what's the purpose of separating sign-in and sign-up?

By knowing the intent, we'll be able to provide better feedback. Two separate pages is just one way of addressing this, can also be done using better UI feedback on a single page. What I want to solve is "Confusion around using the wrong third-party account to sign-in, ends up creating a new account - which requires account merging to fix.". For example, we shouldn't just 'create' a new account if the user intended to sign-in using a third-party provider but chose the wrong one.
I'll take a look at how Medium handles this, I expect that they'd place an intermediary step between registration (something like "You don't have an account, we're going to create one for you. Are you sure?") to prevent accidentally creating a new account

@rohitpaulk We've talked before about phasing out social logins entirely, and requiring an email for everyone on Gratipay: https://github.com/gratipay/gratipay.com/issues/3837. Do you think we should move in that direction? If so, how does that affect the steps we take here?

We've talked before about phasing out social logins entirely, and requiring an email for everyone on Gratipay: #3837. Do you think we should move in that direction? If so, how does that affect the steps we take here?

That ticket is blocked on this (we can't remove other authentication methods before we introduce email), but I don't think the steps we take here must be affected by that ticket.

A few rough designs I'm experimenting with:
Dedicated Sign-in page - 1

Dedicated Sign-in page - 2

Dedicated Sign-in page - 3

Sign-in modal - 1

Sign-in modal - 2

Sign-in modal - 3

Sign-in modal - 4

(Note: The serif font is not the one we use on production, I couldn't find a downloadable version on our typography.com account)

Sounds good.
Re: font ... if you use localhost:8537 it should work as that is whitelisted. Otherwise you can probably add whatever you're using instead to the whitelist on typography.com?

if you use localhost:8537 it should work as that is whitelisted

These designs are from Adobe XD, not in a browser 😄. Our typography account had Ideal Sans as a downloadable font, but not Typewriter.

Hah! Oh. :-)
Typewriter doesn't sound familiar. Our serif is ... Chronicle, I think?

Typewriter doesn't sound familiar.

Hmm, wonder where I got that from

Our serif is ... Chronicle, I think?

Yes, yes

Sign-in modal is deployed!
https://twitter.com/Gratipay/status/879365201665064961

Moving on to the next step. I'm first going to enable sign-in (not signup) via email, under a feature flag (to test). After that, will look at sign-up via email

+1 from https://github.com/gratipay/gratipay.com/issues/4554#issuecomment-317133698

Closing in light of our decision to shut down Gratipay.
Thank you all for a great run, and I'm sorry it didn't work out! 😞  💃


NetworkAdapter add two properties: GUID, PNPDeviceID

GUID and PNPDeviceID can help determine the adapter is a physical device or not.
Can use informations in registery:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network{4D36E972-E325-11CE-BFC1-08002BE10318}

Please provide more information, some links, a detailed explanation and some example code.


Document some public methods on FileAppenders

In xxFileAppender classes.

Standarise location and order the using statements.
Document GetFileLength, GetFileCreationTimeUtc and GetFileLastWriteTimeUtc methods.

This change is

Current coverage is 82% (diff: 0%)

Merging #1838 into master will increase coverage by <1%

@@             master      #1838   diff @@
==========================================
  Files           276        276
  Lines         18412      18412
  Methods        2850       2850
  Messages          0          0
  Branches       2115       2115
==========================================
+ Hits          15038      15045     +7
+ Misses         2894       2887     -7
  Partials        480        480

Powered by Codecov. Last update 40d067c...3cc4d6c

Thanks again!


Fix #262 to support metaObjectHandler

@wangyi12358
can you check with these changes? I test with your reproducer https://github.com/wangyi12358/quarkus-mybatis-plus-demo and it should work as expected.
The thing I need to change in application,yml is
quarkus:
  http:
    port: 8888
    cors: true
  application:
    name: demo
  live-reload:
    instrumentation: true
  datasource:
    db-kind: mysql
  mybatis:
    initial-sql: example.sql
  mybatis-plus:
    meta-object-handler: com.example.handler.MetaHandler


Linking corresponding vote/ticket for a ticket/vote

For discussion on @McEdward's branch

@McEdward Is this good to go then.  Let me know if I can retest and merge.

@chappjc , yes you can retest and merge


Configurable elimination of FlatMapNode by pushing the flatMap logic into the SourceNode.

Currently we have the FlatMapNode created for a simple flatMap operation. The intent is to let the spout handle the flatMap operation just like the optionMap operation.
We are considering SourceNode aggregation out of scope for this issue, so topologies without any FlatMapNodes will do all of their aggregation in the SummerNode.

I like this project, but it might be a non-negligible change to the design.
We could imagine making all tuples (K, V) pairs but doing a shuffle grouping between mapping nodes. This means you don't have two different input/output formats. In the case of no key, we can put () which is serialized in 0 bytes by chill (but still takes a little space in a tuple by making a longer List to wrap.
That might make things easier since there is not this odd-ball node that has to prepare a special wire format in front of the summer.

FWIW, the complexity will largely mimic what's in FlatMapBoltProvider today:
https://github.com/twitter/summingbird/blob/v0.11.0-RC1/summingbird-storm/src/main/scala/com/twitter/summingbird/storm/FlatMapBoltProvider.scala
Shimming everything into (K, V) is an interesting idea, but it does have the complexity of knowing when to add/discard the (), and possibly handling the (contrived?) case where V actually is Unit.  So maybe its benefit isn't that much overall?

@johnynek : I have made all the changes to the PR considering all the comments. Can you take a look ?


No default sitting animation?

While checking out the mod I have tested it with several furniture mods I had on and noticed this

The sitting animation plays with vanilla vehicles, but does not play during other cases like modded vehicles or modded furniture (but oddly enough works with tanuki decor's furniture)

Also a handy feature would be an option to configure the animations if possible, allowing to disable some specific animations manually for cases like attack animations for better combat etc

also have this issue, kinda sad


installs inotify tools

In reference to #24, this should install inotify-tools to observe changes to the file system during the test runs.

Pull Request Test Coverage Report for Build 1f7d7cae1e7527409f3b2f1568abe234850b159b-PR-44

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

Totals

Change from base Build c7a90939c3c785adee25778f2c9ad8a077cf3613:
0.0%

Covered Lines:
149

Relevant Lines:
208

💛  - Coveralls


Expose request path and method

These functions can be used to extend the client.Request() adding a SendContext() function that can also log the request path and method, including the context (which can contain request ID).
@jhernand @zgalor PTAL

LGTM.
Could also rename the fields Public.

If we want this idiomatic golang - path and method should be public. This would also remove some existing code...

@cben @zgalor I can't rename path to public because there'a already a function called Path (which is actually a set-and-return.
I can change method to be public but that may be inconsistent with the path pattern (and may accidentally lead to someone trying to set the Method?).

@tzvatot I think the Path method should be removed.
However, this is not backward compatible, so should consult with @jhernand regarding that


tsdb (histograms): Handle duplicate histograms properly

We are currently allowing ingesting two different Histograms with the same timestamp. See https://github.com/prometheus/prometheus/blob/7feea8aa894da5f16d41935538d2bf6ffb55050f/tsdb/head_append.go#L355-L360 . Only exact duplicates should be allowed.

What does exact duplicate mean? The spans can change with additional empty buckets while the filled buckets match? Or should the entire thing exactly match, the spans and the buckets and rest of the field?

Hmm, what do we actually do with exact duplicates in the conventional float case? IIRC ingesting them is a no-op (no error message but no state change in the TSDB either).
If that's the case, I think a histogram with just empty buckets added or removed should still count as the same histogram.
Essentially, if you run the Compact method on both, and the returned histograms are equal, then we should consider the original histograms equal (and not ingest the duplicate).
(This is just a random thought. I might be wrong, as usual…)

It would be weird to get empty buckets out of nowhere, and helps keep the code simple if we do not try and take care of empty buckets. Running compact on 2 histograms for every histogram append might be very CPU consuming at ingestion time. So I am thinking of just compacting spans and checking (in-flight check, wont actually call the compact function) while expecting same content for buckets for a start. Based on what we see in practice we can improve the logic I think.

Maybe we should run Compact on all histograms upon ingestion? In that way, we would unify their layout, no matter what targets expose… (In most cases, the Compact call wouldn't do anything, so it shouldn't be too expensive.)

Opened https://github.com/prometheus/prometheus/issues/11321 to track Compact() before appending histogram.


Provide zsh completions

I use afp-cli in a zsh so this would be really neat.

Please provide a pull request. @esc might be interested to collaborate on that.

Solved and merged (for afpv2) with #36 still needs to be shipped via #48 .


Added Video Settings Reset button to Main menu and to pause menu

A little quality of life improvement that allows players to easily reset to the recommended graphics settings. It also will adapt to whether questcraft is running on quest 1 or quest 2!

Looks good!


Setting lambda role with role_arn setting does not work

In the zappa_settings file you can configure manage_roles: true and set role_arn to your role arn. This should work but it does not. It still attempts to use the autogenerated role name which is obviously does not exist as manage_roles is set to true. Using role_name instead of role_arn works. But this means you can't specify a role by arn but only by name.
Expected Behavior
Zappa should use the role specified in role_arn when manage_roles is set to false.
Actual Behavior
Zappa fails to deploy because it looks for the default role by name that it never created as manage_roles is false
Steps to Reproduce

set manage_roles: false
set role_arn: my-desired-lambda-arn
run zappa deploy

Can you try this with the master branch too? I think this may already be fixed.


cache JSON

When responding to a request, the bulk of our time is spent serializing to JSON. This is exacerbated even further for the cases where we serialize first to rippled JSON, then convert to boost JSON.
We should cache the JSON representation of commonly requested objects and transactions. For transactions, this is easy, but for objects, its a bit more difficult, because we don't have an identifier. The object ID is not sufficient, because an object changes over time but it's ID stays the same.
There are a number of ways to go about this. We could just hash the whole blob. We could use uint256 and just invalidate modified entries on ledger update. We could store the ledger sequence with the uin256 and make sure we are getting the right object. etc.

We tried this in #155, but I went ahead and closed it due to a performance hit. We should revisit this branch https://github.com/cjcobb23/clio/tree/json_cache_pr when the time comes to redesign it.

Cache in general is part of our plan moving forward. There is no one true design at the moment. We will spend time investigating possibilities and trade offs. Will take the branch above into account. Closing this one for now.


german language supprot added

Hey @olga-krayevska
I asked ChatGPT and want to confirm the following two points.

'Left' should be 'Links'
'Top' should be 'Oben'

Aren't the above more accurate for the German translation? If you did it intentionally, please tell me the reason.
The rest seems good. I want to merge if the above is confirmed!
Thank you for contributing! I'm happy that users in Germany can use pdfme by your contribution.

hello @hand-dot yes, you are right about Left and Top, I changed it and also changed  'schemas.center': 'Zentriert' (more appropriate translation)

This changes will be published next release.

Thank you for your contribution! We are brightening the future of PDF creation!

@hand-dot thank you for great lib and for reviewing my PR so quickly


fix nodes losing their wires when in an iframe

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)

Proposed changes
Replaced instanceof Array with the recommended alternative Array.isArray, which was breaking RED.nodes.import when Node-RED is embedded in an iframe
Fixes https://github.com/node-red/node-red/issues/3483

Checklist

[x] I have read the contribution guidelines
[x] For non-bugfix PRs, I have discussed this change on the forum/slack team.
[x] I have run grunt to verify the unit tests pass
[x] I have added suitable unit tests to cover the new/changed functionality

Thanks for this. A quick search shows this was the last remaining instance of instanceof Array in the editor.

Coverage increased (+0.04%) to 67.353% when pulling a8579fa68a1272f46cc3be47527d0dc774bb55d1 on zettca:node-wires-array into ac97e8c6136da712a53f6c024a3f7d78d6ba3ec7 on node-red:master.


[SURE-3400 related] Outbound type is restored to LoadBalancer if UserDefinedRouting is selected

If an AKS cluster is created with an outbound type: userdefinedrouting, it is restored to LoadBalancer after the cluster is provisioned successfully. This change appears to be triggered from Azure console, because the change appears in UpstreamSpec first and then in AKSConfig.
The same was reproduced when I provisioned AKS via Terraform, ref: https://github.com/rancher/aks-operator/issues/709.
Rancher version: v2.10-c4944b3ca0b39c474121df9e7ef31f7aff4e4f7a-head.
AKS Operator version: rancher-aks-operator:105.1.0+up1.10.1-rc.2
PR's:

[ ] https://github.com/rancher/aks-operator/pull/776
[ ] https://github.com/rancher/aks-operator/pull/777
[ ] https://github.com/rancher/aks-operator/pull/788

@mantis-toboggan-md Rancher UI needs to be also fixed

Box name where users are selecting LoadBalancer or User Defined Routing needs to be called Outbound Type, currently is DNS Prefix
When User Defined Routing is selected then Virtual Network has to be provided, it can't be empty
When User Defined Routing is selected then Network Plugin Azure CNI has to be selected


Functions with differing phis should not be merged.

What's in this pull request?

Check that the incoming blocks of phi nodes are identical, and block function merging if they are not.
rdar://problem/26387654

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Check that the incoming blocks of phi nodes are identical, and block
function merging if they are not.
rdar://problem/26387654
(cherry picked from commit da9c34644472c80a98cdf2706469735e58ed31e1)

@swift-ci test

@swift-ci test linux


Async Action Example

Hi, i currently have this implementation of the controller:
[MqttController]
[MqttRoute("telemetry")]
public class DeviceTelemetryController: MqttBaseController
{
    public Task NewTelemetry()
    {
        return BadMessage();
    }
}

My question is, how to make the Action async?
Thanks in advance

Please  click
https://github.com/IoTSharp/IoTSharp/blob/master/IoTSharp/Services/MQTTControllers/

Seeing https://github.com/IoTSharp/IoTSharp/blob/64f2dbcc10f95a434b5186b63beffb57dd7b38f7/IoTSharp/Services/MQTTControllers/AttributesController.cs#L168-L250 does that mean we don't actually have to return any of Ok, Accepted, or BadMessage?

I'm struggling with how to return data using methods like Ok().

return Task.CompletedTask;

yes but that is not asynchronous and it doens't make use of Ok() and the others

I think it is possible to do like in the README of #6


some streaming url found this issue in exo player in jet stream

I am unable to reproduce. Could you try restarting your device once and see if it works?


Branches are not being deleted

Even tho the payload has "delete_branch_after_merge": true, and the results claim it was deleted, the branch is remains and the PR remains open.
This was reported by devs implementing on gE. Has not been replicated and confirmed as yet.

@kintsoogi reported to me that this is no longer an issue in gE. Closing.


Support .MOV media type

Hiya 👋
Really like the tool you've made, just wondering why only four extension types are supported?
I get the following error Not a valid JPG (looks more like a MOV)

The error doesn't seem to be coming from google-photos-exif as I've done a search for that message with no results 🤔
What would it take to support more extension types such as .MOV?

Hi @jtsalva.
No reason other than that my photo library happened to only contain those 4 types (JPG, JPEG, GIF, MP4) so I designed it around that to keep it simple - it would definitely be good to update the tool to include more extensions and make that list easier to tweak too.
When it comes to your error, as you've already identified that isn't coming from google-photos-exif, it'll be coming from ExifTool which is used to read/write the metadata.
Do you have a Pixel 2 or similar? From the filename (MVIMG_...), it looks like your file is a "motion photo" which is not a format I'm familiar with, but from some googling it looks like they encode both a photo (e.g. JPEG) and a movie (e.g. MP4) into a single JPG file. I guess this format is what is confusing ExifTool since it is expecting a standard JPEG but finding embedded video.
When it comes to regular .MOV video files I suspect they would work ok if added to the SUPPORTED_MEDIA_FILE_EXTENSIONS array and possibly also added to the doesFileSupportExif function.
For these MVIMG motion photo jpg files, I think it would need some research into the MVIMG format and whether ExifTool can support it since I have relied on that library to do all of the work for reading/writing metadata 🤔

Thanks for the quick response and the research you've done into it already @mattwilson1024, I do have motion photos from my Pixel phone which does seem to be causing the issue. I've raise this issue on the exiftool repo to see if they can provide some insight :)

Update: I've found an app which works for me called meta data fixer. Happy to close :)


Error when changing to language with more cardinal categories

Subject of the issue
Doesn't work when in runtime changing to language with more cardinal categories (http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html). For example from English to Russian. In that case it throws error:
Invalid key `few` for argument `NUMBER`. Valid plural keys for this locale are `one`, `other`, and explicit keys like `=0`.

Your environment
The latest versions, see plnkr.
Steps to reproduce
https://plnkr.co/edit/CmFVg7v5wHVzx7bPHn8r?p=preview

Hi @yusk90
The error is thrown by (your chosen) interpolation adapter for messageformat. Btw: The minified code of messageformat does not help, the actual used version is not readable.
Anyway: I don't seen an issue for angular-translate, and we cannot help. Perhaps I have missed the point, but the problem is because of an unsuitable translation.

Hi @knalli
Ok, sorry for minified code, updated version: https://plnkr.co/edit/CmFVg7v5wHVzx7bPHn8r?p=preview.
I've also added text that doesn't use messageformatting and it translates correctly both ways. I don't sure if it's a problem with angular-translate-interpolation-messageformat or with messageformat itself. For me it looks like for pluralized message plugin somehow doesn't change locale. Hope it helps a little.

The error is produced by messageformat, not by our adapter. Reading the messages it looks like few is illegal used.
You should break down the issue calling messageformat directly with the given locale, text and params.

At the same time if I start app with
$translateProvider.preferredLanguage("ru");

it works as expected for all cardinals, but still messageformat doesn't detect locale change when switching between languages.
Ok, if it's not a problem with angular-translate adapter, I'm sorry for taking your time.
Will try to dig deeper into problem.


Any experiment with Mediapipe?

Have you tried Mediapipe, it returns 3d coordinates directly from camera feed.

Have you tried Mediapipe, it returns 3d coordinates directly from camera feed.

hi，Have you achieved it?


can't customize the LineChart Xaxis width

I'm able to set the chart container width by passing in the width as a property: <LineChart width={width} ... />
but I'm not able to divide the x axis width equally if I'm using just 2 or 3 labels in the x axis, there is too much gap:

I'm facing the same issue @azizChebbi did you find a solution / workaround?

Same issue here any update ?


High risk "example 2"

As per the notes on "friendlyname", it is not guaranteed to be unique. Therefore the example:
PS C:\> $phydisk = (Get-Physicaldisk | Where-Object -FilterScript {$_.HealthStatus -Eq "Unhealthy"}
PS C:\> Reset-PhysicalDisk -FriendlyName $phydisk.FriendlyName

Will reset all disks sharing that friendly name. I have reviewed this in our environment - attempting to reset one unhealthy disk using this command will reset every single SSD in the cluster. This is obviously a dangerous suggestion.
Can I recommend using -UniqueId in the example for a reader who may miss this detail?

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

ID: a8826868-6a17-4641-31a6-5ec04cc5bfdc
Version Independent ID: 5ac34549-8420-f25b-3da9-2ae370c521c3
Content: Reset-PhysicalDisk (storage)
Content Source: docset/windows/storage/reset-physicaldisk.md
Product: w10
GitHub Login: @coreyp-at-msft
Microsoft Alias: coreyp

Interesting report.
First there is a typo in the first line of the 2nd example anyway - so the example is awful!
And looking at the cmdlet, the FriendlyName parameter only takes a String, not a String[] array. So the cmdlet can only affect a single disk. Indeed - if $phydisk ends up with more than one disk, the sample script would generate and exception. Finally, the idea of using UinqueID is a great one- good catch!
The 2nd example would better be:
$BadDisks = (Get-Physicaldisk | Where-Object -FilterScript {$_.HealthStatus -Eq "Unhealthy"}
Foreach ($BadDisk in $BadDisks)
{
  Reset-PhysicalDisk -UniqueId $BadDisk.UniqueId
}

Thanks for that!
I believe that's still not valid, there's still an extra ( on the first line.

Yes - in the above there was an extra (.
That is removed in the PR.

Thanks!


Handling providers with alternate discovery issuer urls

Warning: Novice alert. Just learned what openid connect was today so sorry if I'm missing something.
I am using a gem that wraps this gem using omniauth in an attempt to use intuit's openid connect service. I'm having trouble starting out with this because I believe that intuit may be breaking the discovery spec by using different paths for /.well-known/openid-configuration.

I'm wondering if

There is an existing supported means of overriding the issuer well known path
Whether or not what intuit is doing here is off-spec. If it is off-spec, then should perhaps try and bring it up with them. If it is not off-spec, then perhaps this is actually an issue with this library?

no
its off-spec

I guess you can add static config option to omniauth-openid_connect, so than it won’t access discovery doc.

Inside kubernetes cluster, the discovery endpoint is usually have different host:port than front url.
please make this a config option, more flexible to support more real world use cases.

You can bypass discover validation:
  discover = OpenIDConnect::Discovery::Provider::Config::Resource.new(
    URI('YOUR PROVIDER HERE')
  ).discover!