[BUG]

Describe the bug
If the input is focused, events are not registered by <Hotkey />
How are you using react hotkeys components? (HotKeys, GlobalHotKeys, IgnoreKeys etc)

Expected behavior
If input is focused (<input />, <textarea />), the keyboard handlers should be working.
Platform (please complete the following information):

Version of react-hotkeys: 2.0.0 - pre.4
Browser [e.g. chrome, safari]: Chrome
OS: [e.g. iOS]: Ubuntu

Are you willing and able to create a PR request to fix this issue?
yes
APPLICABLE TO v2.0.0-pre1 AND ABOVE: ======================
yes
Include the smallest log that includes your issue:
HotKeys (F6📘-C2🔷-P0🔺:) Focused.

FocusOnlyKeyEventStrategy.js:215 HotKeys (F6📘-C2🔷-P0🔺:) Component options:
 {
    "actions": {
        "deselectFields": [
            {
                "prefix": "",
                "actionName": "deselectFields",
                "sequenceLength": 1,
                "id": "Escape",
                "keyDictionary": {
                    "Escape": true
                },
                "eventBitmapIndex": 0,
                "size": 1
            }
        ],
        "deleteFields": [
            {
                "prefix": "",
                "actionName": "deleteFields",
                "sequenceLength": 1,
                "id": "Delete",
                "keyDictionary": {
                    "Delete": true
                },
                "eventBitmapIndex": 0,
                "size": 1
            },
            {
                "prefix": "",
                "actionName": "deleteFields",
                "sequenceLength": 1,
                "id": "Backspace",
                "keyDictionary": {
                    "Backspace": true
                },
                "eventBitmapIndex": 0,
                "size": 1
            }
        ],
        "copyFields": [
            {
                "prefix": "",
                "actionName": "copyFields",
                "sequenceLength": 1,
                "id": "Control+c",
                "keyDictionary": {
                    "Control": true,
                    "c": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            },
            {
                "prefix": "",
                "actionName": "copyFields",
                "sequenceLength": 1,
                "id": "Meta+c",
                "keyDictionary": {
                    "Meta": true,
                    "c": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            }
        ],
        "pasteFields": [
            {
                "prefix": "",
                "actionName": "pasteFields",
                "sequenceLength": 1,
                "id": "Control+v",
                "keyDictionary": {
                    "Control": true,
                    "v": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            },
            {
                "prefix": "",
                "actionName": "pasteFields",
                "sequenceLength": 1,
                "id": "Meta+v",
                "keyDictionary": {
                    "Meta": true,
                    "v": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            }
        ],
        "duplicateFields": [
            {
                "prefix": "",
                "actionName": "duplicateFields",
                "sequenceLength": 1,
                "id": "Control+d",
                "keyDictionary": {
                    "Control": true,
                    "d": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            },
            {
                "prefix": "",
                "actionName": "duplicateFields",
                "sequenceLength": 1,
                "id": "Meta+d",
                "keyDictionary": {
                    "Meta": true,
                    "d": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            }
        ],
        "moveFields": [
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowUp",
                "keyDictionary": {
                    "ArrowUp": true
                },
                "eventBitmapIndex": 0,
                "size": 1
            },
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowDown",
                "keyDictionary": {
                    "ArrowDown": true
                },
                "eventBitmapIndex": 0,
                "size": 1
            },
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowLeft",
                "keyDictionary": {
                    "ArrowLeft": true
                },
                "eventBitmapIndex": 0,
                "size": 1
            },
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowRight",
                "keyDictionary": {
                    "ArrowRight": true
                },
                "eventBitmapIndex": 0,
                "size": 1
            },
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowUp+Shift",
                "keyDictionary": {
                    "Shift": true,
                    "ArrowUp": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            },
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowRight+Shift",
                "keyDictionary": {
                    "Shift": true,
                    "ArrowRight": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            },
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowDown+Shift",
                "keyDictionary": {
                    "Shift": true,
                    "ArrowDown": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            },
            {
                "prefix": "",
                "actionName": "moveFields",
                "sequenceLength": 1,
                "id": "ArrowLeft+Shift",
                "keyDictionary": {
                    "Shift": true,
                    "ArrowLeft": true
                },
                "eventBitmapIndex": 0,
                "size": 2
            }
        ]
    },
    "handlers": {
        "deleteFields": "function deleteFields() {\n        return _this.deleteFields();\n      }",
        "deselectFields": "function deselectFields() {\n        return _this.deselectFields();\n      }",
        "copyFields": "function copyFields() {\n        return _this.copyFieldsToClipboard();\n      }",
        "pasteFields": "function pasteFields() {\n        return _this.pasteSelectionBoxFields();\n      }",
        "moveFields": "function moveFields(e) {\n        return _this.moveSelectionBoxFields(e);\n      }",
        "duplicateFields": "function duplicateFields(e) {\n        return _this.duplicateSelectionBoxFields(e);\n      }"
    },
    "componentId": 2,
    "options": {
        "defaultKeyEvent": "keydown"
    }
}
FocusOnlyKeyEventStrategy.js:370 HotKeys (F6📘-E8💙-C2🔷-P0🔺:) Ignored 'Control' keydown event because ignoreEventsFilter rejected it.
FocusOnlyKeyEventStrategy.js:669 HotKeys (F6📘-E8💙-C2🔷-P0🔺:) Stopping further event propagation.
FocusOnlyKeyEventStrategy.js:377 HotKeys (F6📘-E10💜-C2🔷-P0🔺:) New (simulated) 'Control' keypress event.
FocusOnlyKeyEventStrategy.js:796 HotKeys (F6📘-E10💜-C2🔷-P0🔺:) Ignored '' keypress because it doesn't have any keypress handlers.
FocusOnlyKeyEventStrategy.js:370 HotKeys (F6📘-E11🧡-C2🔷-P0🔺:) Ignored 'd' keydown event because ignoreEventsFilter rejected it.
FocusOnlyKeyEventStrategy.js:669 HotKeys (F6📘-E11🧡-C2🔷-P0🔺:) Stopping further event propagation.
FocusOnlyKeyEventStrategy.js:370 HotKeys (F6📘-E12❤-C2🔷-P0🔺:) Ignored 'd' keyup event because ignoreEventsFilter rejected it.
FocusOnlyKeyEventStrategy.js:669 HotKeys (F6📘-E12❤-C2🔷-P0🔺:) Stopping further event propagation.
FocusOnlyKeyEventStrategy.js:370 HotKeys (F6📘-E13💚-C2🔷-P0🔺:) Ignored 'Control' keyup event because ignoreEventsFilter rejected it.
FocusOnlyKeyEventStrategy.js:669 HotKeys (F6📘-E13💚-C2🔷-P0🔺:) Stopping further event propagation.
FocusOnlyKeyEventStrategy.js:280 HotKeys (F6📘-C2🔷-P0🔺:) Lost focus.

repro
https://codesandbox.io/s/wy5qk62528

Hi snaumov,
Thanks for correctly using the issue template to file your issue.
As you are using the latest pre-release, it seems you may have overlooked the Ignoring events section of the Readme.
If that's not the case, or if you would like extra guidance, please let me know. I'm closing this issue for now.

@greena13 thank you so much for your answer, and my apologies I didn't read through the docs carefully, totally missed this part.


pkg/test: allow complex "assert" and "errors" step file names

What this PR does / why we need it:
This PR improves file name matching regexps by adding meta char escapes and non-capturing groups, and permitts assert- and error-type steps to have complex names, ex. "00-assert-test-pod.yaml"
Signed-off-by: Eric Stroczynski<EMAIL_ADDRESS>

nice!  thank you sir!   I like it.   I will review in more detail shortly... but a quick pass looks good!
(shortly being I will complete tonight)

looking to see if @alenkacz is good... thanks Eric!

@kensipe thanks!
@alenkacz the regexps are very similar and can probably be merged into one with a larger refactoring, however I don't think I have time to do one now. I will try when I have more time!


single abseil static library

ndk-pkg abseil produces large number of static libraries (*.a files).  Is there some way to produce a single combined library, e.g. libabsl.a?

I use Cmake to build the abseil, there is no option to merge all static libraries into one, and i have no plan to do this thing too.
rerference:

https://github.com/abseil/abseil-cpp/issues/367-
https://www.wikitechy.com/tutorials/linux/how-to-merge-two-ar-static-libraries-into-one

OK, thanks.


Proposal: Add an option that allows one to not validate mongo query results

Disclaimer
I have used mongo-models in several projects now and I really like it. At this point, I feel (and hope) like I have a pretty good understanding of its intended purpose. As your readme clearly states mongo-models is "A light weight abstraction where we can interact with collections via JavaScript classes and get document results as instances of those classes". So, data passed in via the constructor as well as mongo results are an instance of mongo-models. And thus, they are both subject to validation.
The Problem
Most of my projects have existing or migrated data sets, and as one would expect, my mongo-models schema isn't followed perfectly in this existing data set. This means that even find methods implemented in mongo-models (and all methods that pass results through this.resultFactory) can potentially fail validation and throw a ValidationError. The first time I noticed this happening when doing a find operation, I was very surprised. It wasn't intuitive to me that existing data would be validated (I was used to Mongoose behavior). In these situations, it's usually not very feasible to fix my entire data set to match my schema. So I've avoided using find methods and used direct mongo queries (while still using other features of mongo-models). Of course work arounds in general are not ideal, but also, for other devs who work on the same code later, it is not immediately clear why I avoided using a mongo-models method and did something directly. So I've ended up adding "Here be dragons" comment blocks and documentation.
Proposal
Allow users to turn off validation of all mongo query results. After careful analysis of the current implementation, I think the only way this would work is to have an option that completely removes the result = new this(...) logic in this.resultFactory for all methods (or just don't pass results through this.resultFactory at all). The only time validation would happen is when the developer is instantiating their custom model that extends mongo-models (like the new Customer(...) example in the readme). I do realize that validating the mongo result is sometimes the main or only reason why methods are redefined - so if this is removed, they no longer have a purpose and their presence is a bit awkward.
Is this problem relatable? Thoughts? (@jedireza and anyone else)

Is this problem relatable?

Yes this can be really annoying.
I'm time poor but I'm open to working through a PR that attempts to address this.
One potential escape hatch that already exists is to use the Model.collection() method. That way you interact with the db directly and skip the model entirely.

I agree. The design of when validation gets done seems very odd. It lets you write an invalid model data to the db and then does validation when you read it. I would have expected validation to be done in insertOne() (for example) and not when reading the result.

@jedireza Would it be a major undertaking to move the validation to the write side of things?

I just checked. That does not look very hard to change.
Would you be willing to accept a PR for this, @jedireza?

I'd be happy to review and work through a PR. Ideally this would be an opt-in change.

@jedireza I took a first stab at it and implemented it only for insertOne https://github.com/tcurdt/mongo-models/commit/42a9141ad4a0ddf52cfacb1d0a641c03a5427aef
Do you agree on the approach?
...and maybe you have an idea on how to get lab.expect(blamo).to.not.throw() working with an async funtion?

@tcurdt Thanks for taking the time to work on this. I'm in agreement with the general opinion in this thread, that it makes sense to validate on write only. So let's drop the optionality, which should clean the code around that. We can make this a breaking change and bump to v4.
Please open a PR, it's fine that it's WIP. This way we can comment on specific lines of code going forward.

I'm in agreement with the general opinion in this thread, that it makes sense to validate on write only. So let's drop the optionality, which should clean the code around that. We can make this a breaking change and bump to v4.

Glad you see it that way. I felt the same when looking into it.
I will work on it a bit more on it and then create a PR.

Some progress. I think it comes down to implementing just the two functions now. https://github.com/tcurdt/mongo-models/commit/31686e12593439b7d54cc74ab839dc5e52a98003 The trickiest part (well...) will be to reduce the schema to what is applicable for update queries for a partial validation.
After that re-activate and improvement of some of tests.
I am not sure how to replace the it constructs an instance using the schema though.
Are we otherwise still in agreement on the approach?

Partial updates are actually more of a problem than expected. While not a problem to implement for the $set operator, there are of course quite a few more operators that would required to load the value for validation.
Maybe it's more advisable to use or leverage native mongodb schema validation instead.
Any thoughts?

I guess using the native schema could be done in a similar fashion to https://github.com/yoitsro/joigoose
Basically generating a joi schema from the native mongodb schema - or the other way around.
Then mongo-models would not have to deal with this at all.

The trickiest part (well...) will be to reduce the schema to what is applicable for update queries for a partial validation.

Partial updates are actually more of a problem than expected.

This is bringing back faint memories of how the complexity can balloon pretty quickly. 😅

Maybe it's more advisable to use or leverage native mongodb schema validation instead. Any thoughts?

I don't know much about that functionality, so I have nothing constructive to add.

For the most part, I've moved on from using mongo-models. I only have one project that I maintain that uses it and the annoyance brought up in this issue goes unnoticed.
These days most of my development is done with TypeScript and I've been using TypeORM with Postgres. It doesn't come without it's own issues, but it's been fine.
When I created this project I wanted a thinner/simpler approach than Mongoose. Looking back now, it would've just been better to reach for that instead. If I was going to start a new "plain js" project targeting Node/JavaScript, I'd probably just use Mongoose. But that's a far fetch. I wouldn't use plain JavaScript if I could help it (TS for the win). 🏆
@tcurdt I can make you a contributor to this repo and you can take the lead. The only requirement I have is the next version that gets published to npm be a major version bump.
If you're not interested in that, it might be best for us to just update the readme letting folks know this project isn't going to be maintained and to look at Mongoose and TypeORM instead.
Thanks for getting involved and contributing. Please share your thoughts.

@tcurdt I been working on a successor for mongo-models for use with newer versions of mongodb because I like the pattern.  It happens to support joi style validation, or mondodb validation, or as you request - no  validation.
@enciv/mongo-collections
It's new, I'm just looking for feedback and people who want to try it out.

Interesting approach, @ddfridley
We ended up using a simplified fork where we have joi validation for writes.
If there is a need to switch we certainly will have a look.


Smaller library size with treeshaking or granular imports

Is your feature request related to a problem? Please describe.
Currently, it isn't possible to load specific parts of the system information as the library doesn't support tree-shakeable named imports or granular nested imports.
Moreover, due to the nature of the library, it is perhaps only expected to grow in size as support for more device variants are added. Given this library mentions being small in size as a goal, having granular imports / tree shakeable imports could be quite useful.
Currently, the library pulls in ~250+ KB of minified JS even if I only want to use a single function.
When bundling this library in a yarn plugin, or a CLI tool, can add a lot of cruft.
Would you consider adding support for individual imports e.g. `import cpu from 'systeminformation/lib/cpu' ? That might be the easiest way with the current structure provided TS types are provided for these individual entry points.

@pastelsky ... you are right. Version 6 (working on it already) is a complete rewrite (and all in TS) and will support this as it is much more granular Here you can import just the needed functions and this will reflect in a much smaller size. Hope I can finish this new transition soon.

@pastelsky I currently making good progress with the new version. This version will allow to

just import systeminformation functions for one specific platform
just import specific systeminformation functions for all platforms
just import specific systeminformation functions for specific platforms

So imports can be very specific and granular. Hope to have the first public beta ready in September.


Fix Travis CI by running 11 projects in allow_failures mode

This allows us to make sure that new PRs break tests that currently pass.  This also documents those projects have failing tests so that we can fix them and remove that project from allow_failures: list.

Hi. I made a PR #50 some hours ago, but got a Travis CI build failing.
And I think this PR is related to the failure. Is there any updates about this request?

@dustinvtran Your review please.


Check if current user (token) is teacher or student

This code snipplet will be used literally everywhere. I think a small js function providing this functionality would be good to support seperation by concern. At least, I will provide the code to copy paste it everywhere to do this check.

I might need to store the token in react local store, so that we can access it everywhere. I will have another look at the seba frontend repo.
Also see: https://hptechblogs.com/using-json-web-token-react/


Configure CI

I set up dependabot (to automatically update dependencies), cargo deny (to check dependencies for vulnerabilities and license compatibility), formatting, tests and clippy checks.
Also I fixed discovered warnings and applied formatting to make CI pass.

Hey @Shatur,
thanks for your contributions, I'll have a look at them individually.
Cheers,
Simon

The CI work is really appreciated, I wanted this for a long time but didn't find time to do it. One thing that I'd like to keep (as in the older CI setup) is tests against the baseline version, Rust 1.13. (It's spelled out in dirs, but sadly not in directories as I just found out, apologies for that!)

Would you be willing to have a look at it? Otherwise I can also have a look! It shouldn't block merging the first commit either way, though!

Regarding the formatting, I prefer to not use it on this code; this crate has repetitive lines that really benefit from things being aligned such that inconsistencies are immediately apparent.

I think the changes from clippy are not applicable, neither as_deref nor the struct shhorthand initialization exist in Rust 1.13.

Would you be willing to have a look at it?

Sorry, I found a different crate that suits my needs more :) But it's easy to setup, just use this action.
Regarding other changes - as you wish. Feel free to revert any of my changes.

Sorry, I found a different crate that suits my needs more :) But it's easy to setup, just use this action.

Sure, thanks!


Incorrect result for f1 score

Using _f1 or _f1_parallel for all qrels and run gives incorrect output. But if I use _f1 on individual query case, it gives correct F1 score.
using below 2 functions return 0 for 4 cases. Ideally it should only be 0 for 1 of all the 18 cases in _qrels & _run passed.
from ranx.metrics.f1 import _f1_parallel, _f1

f1(_qrels, _run, 1, 1)
# output
# array([1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 0., 0., 0., 0.])

_f1_parallel(_qrels, _run, 1 , 1)
# output
# array([1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 1., 0., 0., 0., 0.])

But if I call _f1 for each item in qrels, I get correct F1 score for all queries.
scores = []

for i in prange(len(_qrels)):
  try:
      scores.append(_f1(_qrels[i], _run[i], 1 , 1))
  except Exception as error:
    # handle the exception
    print(f" {i} An exception occurred:", error)
    scores.append(0)
    continue

# output
# [1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 0, 1.0, 1.0, 1.0]

Notice, I get only 1 case where the F1 score is 0, which I think is expected for my case.
More context -
I am using f1 metric at k1 =1 for a dataset where each query has only 1 relevant document. There are 18 unique qrels.
Since each query only has 1 relevant document, the score for mrr@1 = recall@1 = 0.9444
also, precision@1 = 0.944 for my case.
Here's the output of my evaluation -
{'mrr@1': 0.9444444444444444, 'mrr@2': 0.9444444444444444, 'recall@1': 0.9444444444444444, 'recall@2': 0.9444444444444444, 'precision@1': 0.9444444444444444, 'f1@1': 0.7777777777777778}
f1@1 seems very low considering precision & recall @ 1 are equal with high value.
Here's the pretty output of scores for each individual query -
I've manually validated the output for all the metrics and all of them seem correct to me except for f1@1 .
Notice that hits score is 0 only for q_id '6', so f1 score 0 for q_id '6' as 0 is expected, but f1 score is also 0 for q_id '7' , '8' and '9' .
{
"mrr": {
"0": 1.0,
"1": 1.0,
"10": 1.0,
"11": 1.0,
"12": 1.0,
"13": 1.0,
"14": 1.0,
"15": 1.0,
"16": 1.0,
"17": 1.0,
"2": 1.0,
"3": 1.0,
"4": 1.0,
"5": 1.0,
"6": 0.3333333333333333,
"7": 1.0,
"8": 1.0,
"9": 1.0
},
"mrr@1": {
"0": 1.0,
"1": 1.0,
"10": 1.0,
"11": 1.0,
"12": 1.0,
"13": 1.0,
"14": 1.0,
"15": 1.0,
"16": 1.0,
"17": 1.0,
"2": 1.0,
"3": 1.0,
"4": 1.0,
"5": 1.0,
"6": 0.0,
"7": 1.0,
"8": 1.0,
"9": 1.0
},
"recall@1": {
"0": 1.0,
"1": 1.0,
"10": 1.0,
"11": 1.0,
"12": 1.0,
"13": 1.0,
"14": 1.0,
"15": 1.0,
"16": 1.0,
"17": 1.0,
"2": 1.0,
"3": 1.0,
"4": 1.0,
"5": 1.0,
"6": 0.0,
"7": 1.0,
"8": 1.0,
"9": 1.0
},
"precision@1": {
"0": 1.0,
"1": 1.0,
"10": 1.0,
"11": 1.0,
"12": 1.0,
"13": 1.0,
"14": 1.0,
"15": 1.0,
"16": 1.0,
"17": 1.0,
"2": 1.0,
"3": 1.0,
"4": 1.0,
"5": 1.0,
"6": 0.0,
"7": 1.0,
"8": 1.0,
"9": 1.0
},
"f1@1": {
"0": 1.0,
"1": 1.0,
"10": 1.0,
"11": 1.0,
"12": 1.0,
"13": 1.0,
"14": 1.0,
"15": 1.0,
"16": 1.0,
"17": 1.0,
"2": 1.0,
"3": 1.0,
"4": 1.0,
"5": 1.0,
"6": 0.0,
"7": 0.0,
"8": 0.0,
"9": 0.0
},
"hits@1": {
"0": 1.0,
"1": 1.0,
"10": 1.0,
"11": 1.0,
"12": 1.0,
"13": 1.0,
"14": 1.0,
"15": 1.0,
"16": 1.0,
"17": 1.0,
"2": 1.0,
"3": 1.0,
"4": 1.0,
"5": 1.0,
"6": 0.0,
"7": 1.0,
"8": 1.0,
"9": 1.0
}
}
Thanks in advance.
Let me me know if I am missing something.

Hi, it is very strange that _f1 called on every query separately and _f1_parallel give different results.
_f1_parallel is just a parallelized loop over _f1 and the queries.
Can you provide me your qrels and run?

Hi,
thanks for the quick response.
Have attached the files here.
qrels_v2.xlsx
run.xlsx

I cannot reproduce your results. F1@1 is correct on my side. 🤷🏻♂

By calling the internal functions instead of using evaluate, I get again the correct results.

Do you have non-alphanumeric document IDs on your side?

No. The document IDs are originally in numeric form when entered in excel.
I have also committed this pipeline here
Could you take a look and try it on your end when you get a chance ?
I am using colab with cpu runtime to run this pipeline where I see this issue.

Once again, thanks for trying to replicate it on your end.

I can replicate on Colab.
There is a zero division not handled, as you noticed.
Unfortunately, numba is not raising it and it probably causes an unreported crash of the numba's threads or something.
The issue arises after the query with no retrieved relevants is evaluated.
I fixed the zero division case on Colab and everything looks fine.
I will do some more testing locally and notify you when the bug is fixed.
Thanks for reporting the issue!

@AmenRa @crux-taaniya how about opening an issue in numba and track it here? this is something serious they might want to fix probably.

@diegoceccarelli I was going to do it this morning, but then I saw that there is already an open issue about it.
numba/numba#6976

I can replicate on Colab. There is a zero division not handled, as you noticed. Unfortunately, numba is not raising it and it probably causes an unreported crash of the numba's threads or something. The issue arises after the query with no retrieved relevants is evaluated. I fixed the zero division case on Colab and everything looks fine. I will do some more testing locally and notify you when the bug is fixed. Thanks for reporting the issue!

Thanks @AmenRa !

Fixed in v0.3.16.


Adds Dmitri as an editor, adds link to Go implementation

Closing this.  We've moved the repo into DIF, so will recreate this PR over there.


Dialog Style

Hi. How i can set Style property to Dialog?

you can override DialogBaseStyle

like that?
<Style x:Key="DialogBaseStyle" TargetType="{x:Type controls:Dialog}" BasedOn="{StaticResource DialogBaseStyle}">

yes


Typo: wrong incident URL in the News page for Netty 4.0.29.Final released

Please use (#3784) instead of (#3794) for [#3784] Support hostname verification when using OpenSSLEngine.
http://netty.io/news/2015/06/23/4-0-29-Final.html

Added both links


Kiwi is not in use?

OCUnit and the SenTestingKit framework are deprecated and  removed from Xcode. So Kiwi is not in use?

Kiwi dropped support for OCUnit some time ago. If you have a specific problem, please feel free to open an issue!


[SPARK-38308][SQL] Eagerly iterate over sequence of window expressions in ExtractWindowExpressions

What changes were proposed in this pull request?
Pass an IndexedSeq (likely a Vector) to ExtractWindowExpressions.extract and ExtractWindowExpressions.addWindow rather than whatever sequence type was specified by the user (in the Dataset.select method).
To accomplish this, we only need to pass an IndexedSeq to ExtractWindowExpressions.extract. ExtractWindowExpressions.extract will then return another IndexedSeq that we will pass on to ExtractWindowExpressions.addWindow
Why are the changes needed?
Consider this query:
val df = spark.range(0, 20).map { x =>
  (x % 4, x + 1, x + 2)
}.toDF("a", "b", "c")

import org.apache.spark.sql.expressions._

val w = Window.partitionBy("a").orderBy("b")
val selectExprs = Stream(
  sum("c").over(w.rowsBetween(Window.unboundedPreceding, Window.currentRow)).as("sumc"),
  avg("c").over(w.rowsBetween(Window.unboundedPreceding, Window.currentRow)).as("avgc")
)

df.select(selectExprs: _*).show(false)

It fails with
org.apache.spark.sql.AnalysisException: Resolved attribute(s) avgc#23 missing from c#16L,a#14L,b#15L,sumc#21L in operator !Project [c#16L, a#14L, b#15L, sumc#21L, sumc#21L, avgc#23].;

If you change Stream to a Seq, it succeeds.
As with SPARK-38221 and SPARK-38528, this is due to the use of this code pattern:
  def someMethod (seq: Seq[xxx]) {
    ...
    val outerDataStructure = <create outer data structure>
    val newSeq = seq.map { x =>
      ...
      code that puts something in outerDataStructure
      ...
    }
    ...
    code that uses outerDataStructure (and expects it to be populated)
    ...
  }

If seq is a Stream, seq.map might be evaluated lazily, in which case outerDataStructure will not be fully populated before it is used.
Both ExtractWindowExpressions.extract and ExtractWindowExpressions.addWindow use this pattern, but the above example failure is due to the pattern's use in ExtractWindowExpressions.addWindow (extractedWindowExprBuffer does not get fully populated, so the Window operator does not produce the output expected by its parent projection).
I chose IndexedSeq not for its efficient indexing, but because map will eagerly iterate over it.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
New unit test.

Gentlest of pings @cloud-fan @HyukjinKwon

Merged to master and branch-3.3.

@bersprockets feel free to backport to branch-3.2 (I didn't cos it has a conflict).


Add rezero option; register ops for APEX AMP training

add rezero option
register ops for APEX AMP training

Make sure the 3.0.0 (dev) branch has all the changes needed for our model training.
I'll test if this branch & version works for ESPNET ASR training.

I wonder if we need tests for apex? Otherwise it will break from time to time, and we wont know about it, until someone complains.

@hpasapp great point. I'll try adding some tests before next Friday.


remove hashCode & equals from HAMT & RBT

fixes #1947

Codecov Report

Merging #2187 into master will increase coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #2187      +/-   ##
============================================
+ Coverage     97.42%   97.47%   +0.04%
  Complexity     5245     5245
============================================
  Files            92       92
  Lines         12062    12029      -33
  Branches       1595     1586       -9
============================================
- Hits          11752    11725      -27
+ Misses          153      150       -3
+ Partials        157      154       -3

Impacted Files
Coverage Δ
Complexity Δ

...src/main/java/io/vavr/collection/RedBlackTree.java
93.39% <ø> (+1.28%)
23 <0> (ø)
:arrow_down:

...n/java/io/vavr/collection/HashArrayMappedTrie.java
98.49% <ø> (+0.22%)
1 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

@danieldietrich knock-knock

Looks great, thank you!
Always a good feeling to delete code :)


default recipe fails when TLS is enabled

Running cookbook with TLS enabled just doesn't work.
================================================================================
Error executing action `create` on resource 'vault_config[/home/vault/.vault.json]'
================================================================================
NoMethodError
-------------
No resource or method named `chef_vault_item' for `VaultCookbook::Resource::VaultConfig (fused) ""'

According to https://github.com/johnbellone/vault-cookbook/blob/master/Berksfile#L5 , vault-cookbook depends on codebase of chef-vault cookbook from master branch. Unfortunately those changes are not in chef-vault 1.3.0 published in chef supermarket.
This needs to be mentioned in documentation.


kubernetes/network-troubleshooting: Stop liquid processing

Ref https://github.com/coreos-inc/coreos-pages/issues/687 https://github.com/coreos-inc/coreos-pages/pull/689

LGTM


[ALLUXIO-2189] Reference webdoc when seeing transport framesize wrong in error message

https://alluxio.atlassian.net/browse/ALLUXIO-2189
before:
$ hadoop fs -libjars core/client/target/alluxio-core-client-1.3.0-SNAPSHOT-jar-with-dependencies.jar  -ls alluxio://localhost:19998/
16/08/15 15:38:25 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
16/08/15 15:38:25 INFO logger.type: initialize(alluxio://localhost:19998/, Configuration: core-default.xml, core-site.xml, mapred-default.xml, mapred-site.xml, yarn-default.xml, yarn-site.xml, hdfs-default.xml, hdfs-site.xml). Connecting to Alluxio: alluxio://localhost:19998/
16/08/15 15:38:25 INFO logger.type: alluxio://localhost:19998 alluxio://localhost:19998
16/08/15 15:38:25 INFO logger.type: Loading Alluxio properties from Hadoop configuration: {}
16/08/15 15:38:25 INFO logger.type: Configuration file /etc/alluxio/alluxio-site.properties loaded.
16/08/15 15:38:25 INFO logger.type: getFileStatus(alluxio://localhost:19998/)
16/08/15 15:38:25 INFO logger.type: Alluxio client (version 1.3.0-SNAPSHOT) is trying to connect with FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998
16/08/15 15:38:25 INFO logger.type: Client registered with FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998
ls: alluxio.org.apache.thrift.transport.TTransportException: Frame size (67108864) larger than max length (16777216)!

after:
$ hadoop fs -libjars core/client/target/alluxio-core-client-1.3.0-SNAPSHOT-jar-with-dependencies.jar  -ls alluxio://localhost:19998/
16/08/15 17:29:13 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
16/08/15 17:29:13 INFO logger.type: initialize(alluxio://localhost:19998/, Configuration: core-default.xml, core-site.xml, mapred-default.xml, mapred-site.xml, yarn-default.xml, yarn-site.xml, hdfs-default.xml, hdfs-site.xml). Connecting to Alluxio: alluxio://localhost:19998/
16/08/15 17:29:13 INFO logger.type: alluxio://localhost:19998 alluxio://localhost:19998
16/08/15 17:29:13 INFO logger.type: Loading Alluxio properties from Hadoop configuration: {}
16/08/15 17:29:13 INFO logger.type: Configuration file /etc/alluxio/alluxio-site.properties loaded.
16/08/15 17:29:13 INFO logger.type: getFileStatus(alluxio://localhost:19998/)
16/08/15 17:29:13 INFO logger.type: Alluxio client (version 1.3.0-SNAPSHOT) is trying to connect with FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998
16/08/15 17:29:13 INFO logger.type: Client registered with FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998
16/08/15 17:29:13 ERROR logger.type: Failed to set up the connection between client and FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998 due to mismatched transport. Please refer to http://www.alluxio.org/docs/master/en/Debugging-Guide.html for the possible reasons and suggestions.
ls: alluxio.org.apache.thrift.transport.TTransportException: Frame size (67108864) larger than max length (16777216)!

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11124/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11125/
Test PASSed.

The link "http://www.alluxio.org/docs/1.3/en/Debugging-Guide.html" doesn't exist.

@gpang  it was linking to http://www.alluxio.org/docs/master/en/Debugging-Guide.html .
the original link with 1.3 was copied from a test run, and it has been updated

@apc999  Thanks, I left a few comments.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11129/
Test PASSed.

Merged build finished. Test PASSed.

@calvinjia  thanks for the comments. PTAL

LGTM

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11136/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11138/
Test PASSed.

@apc999 I took a pass and left a couple comments

@apc999 did a pass and left some comments

@aaudiber @jsimsa  PTAL. here is the new error message looking like
$ hadoop fs -libjars core/client/target/alluxio-core-client-1.3.0-SNAPSHOT-jar-with-dependencies.jar  -ls alluxio://localhost:19998/
16/08/17 12:37:41 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
16/08/17 12:37:41 INFO logger.type: initialize(alluxio://localhost:19998/, Configuration: core-default.xml, core-site.xml, mapred-default.xml, mapred-site.xml, yarn-default.xml, yarn-site.xml, hdfs-default.xml, hdfs-site.xml). Connecting to Alluxio: alluxio://localhost:19998/
16/08/17 12:37:41 INFO logger.type: alluxio://localhost:19998 alluxio://localhost:19998
16/08/17 12:37:41 INFO logger.type: Loading Alluxio properties from Hadoop configuration: {}
16/08/17 12:37:42 INFO logger.type: Configuration file /etc/alluxio/alluxio-site.properties loaded.
16/08/17 12:37:42 INFO logger.type: getFileStatus(alluxio://localhost:19998/)
16/08/17 12:37:42 INFO logger.type: Alluxio client (version 1.3.0-SNAPSHOT) is trying to connect with FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998
16/08/17 12:37:42 INFO logger.type: Client registered with FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998
ls: Failed to connect to FileSystemMasterClient master @ localhost/<IP_ADDRESS>:19998: alluxio.org.apache.thrift.transport.TTransportException: Frame size (67108864) larger than max length (16777216)!. This exception may be caused by wrong network configurations. Please consult http://www.alluxio.org/docs/masteren/Debugging-Guide.html for common solutions to address this problem.

@apc999 http://www.alluxio.org/docs/masteren/Debugging-Guide.html is missing a "/" between master and en

@aaudiber thanks for the catch. Updated.

LGTM

modulo addressing @aaudiber comment this looks good to me

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11146/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11148/
Test PASSed.

+1 LGTM


Make History of Solutions Optional

This PR fixes #10
Each algorithm respects the KeepHistory setting. When false, no solution history is stored. The overall best solution now has its own field in the result structs.

Codecov Report

Merging #12 (b4b3d48) into master (105fb67) will decrease coverage by 3.96%.
The diff coverage is 72.15%.

@@            Coverage Diff             @@
##           master      #12      +/-   ##
==========================================
- Coverage   96.88%   92.91%   -3.97%
==========================================
  Files          13       13
  Lines         546      579      +33
==========================================
+ Hits          529      538       +9
- Misses          8       25      +17
- Partials        9       16       +7

Impacted Files
Coverage Δ

particle_swarm.go
79.51% <35.71%> (-10.10%)
:arrow_down:

evolution_strategies.go
86.76% <40.00%> (-13.24%)
:arrow_down:

tabu_search.go
87.30% <66.66%> (-9.31%)
:arrow_down:

anneal.go
100.00% <100.00%> (ø)

ant_colony.go
100.00% <100.00%> (ø)

genetic.go
96.37% <100.00%> (+0.16%)
:arrow_up:

Continue to review full report at Codecov.

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


Error: undefined method `admin_route_prefix'

When I run rails generate comfy:blog or rails generate comfy:gallery I get this:
/home/austin/.rvm/gems/ruby-2.2.2/gems/comfy_gallery-0.1.3/lib/comfy_gallery/engine.rb:11:in `block (2 levels) in <class:Engine>': undefined method `admin_route_prefix' for #<ComfortableMexicanSofa::Configuration:0x00000004fe2690> (NoMethodError)
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/comfy_gallery-0.1.3/lib/comfy_gallery.rb:14:in `configure'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/comfy_gallery-0.1.3/lib/comfy_gallery/engine.rb:10:in `block in <class:Engine>'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/railties-4.2.1/lib/rails/initializable.rb:30:in `instance_exec'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/railties-4.2.1/lib/rails/initializable.rb:30:in `run'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/railties-4.2.1/lib/rails/initializable.rb:55:in `block in run_initializers'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:226:in `block in tsort_each'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:348:in `block (2 levels) in each_strongly_connected_component'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:429:in `each_strongly_connected_component_from'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:347:in `block in each_strongly_connected_component'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:345:in `each'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:345:in `call'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:345:in `each_strongly_connected_component'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:224:in `tsort_each'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/2.2.0/tsort.rb:203:in `tsort_each'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/railties-4.2.1/lib/rails/initializable.rb:54:in `run_initializers'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/railties-4.2.1/lib/rails/application.rb:352:in `initialize!'
    from /home/austin/cms/config/environment.rb:5:in `<top (required)>'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.1/lib/active_support/dependencies.rb:274:in `require'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.1/lib/active_support/dependencies.rb:274:in `block in require'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.1/lib/active_support/dependencies.rb:240:in `load_dependency'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/activesupport-4.2.1/lib/active_support/dependencies.rb:274:in `require'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/spring-1.3.5/lib/spring/application.rb:92:in `preload'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/spring-1.3.5/lib/spring/application.rb:143:in `serve'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/spring-1.3.5/lib/spring/application.rb:131:in `block in run'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/spring-1.3.5/lib/spring/application.rb:125:in `loop'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/spring-1.3.5/lib/spring/application.rb:125:in `run'
    from /home/austin/.rvm/gems/ruby-2.2.2/gems/spring-1.3.5/lib/spring/application/boot.rb:18:in `<top (required)>'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from /home/austin/.rvm/rubies/ruby-2.2.2/lib/ruby/site_ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
    from -e:1:in `<main>'

Seems like a comfy-gallery is complaining here. Unfortunately that gem is super old and won't work with current cms/blog. I started a full rewrite a while ago, but never finished.

What about blog? Does that work with current version of CMS? I got the same error I believe when I tried to use it

Blog is completely rewritten for CMS v 2.0. This is not an issue anymore


Winit 0.23 support for imgui-winit-support

Of note is that MouseScrollDelta::PixelDelta now returns a PhysicalPosition, and not LogicalPosition. I just converted it using self.scale_factor.
This bumps the crate version, and makes winit 0.23 the default.
The glium examples don't compile anymore, glium needs to update glutin which needs to update winit. I tested with the gfx examples.

Glutin 0.25 uses winit 0.23; should be able to bump it and should just work afaics?

Glium hasn't updated to a new version of Glutin. I suppose I could use glutin directly, and not glium::glutin? Any thoughts?

Can you just send a PR or open an issue there ? Winit changes need to propagate throughout the ecosystem :)

My bad, closer inspection actually shows glium will do a new release soon https://github.com/glium/glium/commit/303f4f95fb4a64acedac0be1732b69b35e2b7b9c

Now that glium updated I went through and tried to get the examples to compile. In test_windows.rs, line 169, I get the error "the trait glium::Vertex is not implemented for imgui::DrawVert". Glium says to use the implement_vertex!() macro, but warns that struct fields must match their names in the shader exactly. However, there are multiple different shaders for different glsl/opengl versions. Any thoughts on what to do?

So what’s the status on this ? Would be really great to get winit 0.23 support, since most crates in the ecosystem have now moved

Actually is it not possible to just add the imgui winit support changes and default to winit-22 feature ? And then publish this crate ? That should allow downstream users to upgrade to winit 0.23 and to continue allow glium deps, etc., to continue compiling ?

@m4b I opened https://github.com/Gekkio/imgui-rs/pull/381#issue-505515187 by accident and it worked for a basic example with wgpu backend for me but pretty sure there will be follow up issues cause that seems too easy :D

Agreed that defaulting to winit 0.22 could be an option, and allow upgrading for those using wgpu or otherwise. @Gekkio, what do you think is the best option?

What exactly still needs to happen to get this PR in? Can't bump my project's winit version cause of imgui-winit-support. If needed, I can of course always help out. :)

What exactly still needs to happen to get this PR in?

Well, passing the tests would be a good start :smile:
I'd greatly prefer upgrading glium and winit at the same time, because glium is supposed to be the most supported renderer in imgui-rs. In fact, I'll almost certainly remove all support for gfx-rs in the near future.
I don't have time to investigate the problems in this pull request, but I noticed that the lock file has two conflicting glium versions. Maybe the upgrade is incomplete?


Add socket activation support for server

Fixes #228

can you add a note on this to the --listen flag and a doc example?

actually meant to but forgot. will add.

LGTM

LGTM although would be nice to have an example in the readme, and the tests

The readme is getting large. We will soon break it up into Documentation/ and then can have a separate document for socket activation with example.


Add documentation on subset to module extraction docs

See https://github.com/EnvironmentOntology/envo/pull/1588#issuecomment-2552318990

I’d be surprised if closures aren’t sufficient…
On Thu, Dec 19, 2024 at 1:05 AM Nico Matentzoglu @.***>
wrote:

@.**** approved this pull request.
Thank you Chris! While i agree with the things you say here, I think the
envo situation might be more convoluted. We probably need some kind of
release variant that cuts the full variant back into using only the
required terms, rather than using subset for modules which might work with
chebi, but certainly not with cL or Uberon, at least if we don't want to
loose gcis etc
—
Reply to this email directly, view it on GitHub
https://github.com/OBOAcademy/obook/pull/526#pullrequestreview-2513762125,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAMMOJK7UHQBDQBKGGHC5D2GKD45AVCNFSM6AAAAABT3UOWLGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMJTG43DEMJSGU
.
You are receiving this because you authored the thread.Message ID:
@.***>


BUG-108343 – Tests for support python shebangs in recipe

BUG-108343 – Tests for support python shebangs in recipe

@biharitomi
> If there are recipe tests for other providers, I would include these tests there instead of creating a new Openstack only for testing a minimal python recipe....
There is no running recipe api e2e test. The classes are there but they're obsoleted/deprecated and not connected to the nightly run. I'll change the content of this PR to extend it to the other providers.

Then Recipe tests on Openstack is fair enough for the first PR.


Add teleporting teams support from issue #242

Please do a deep review to ensure this is all setup correctly... I may have missed something or set something up in a way that you don't like because I'm unfamiliar with your system.
Also I'm not sure how you feel about wild-card imports.. Didn't notice it changed before committing and pushing but my IntelliJ is configured to use them automatically if using all classes inside of the import, which you are. It makes sense to me but I know that some developers don't like using them. Up to you if you wanna keep that.

I implemented nearly all of your requests, but I did leave out using a switch statement for the command arguments because I feel that it makes it somewhat difficult to understand exactly what's going on, but I did optimize the code as much as possible without using it. If you want to change it later, you're welcome to.