Align Listeners with common xUnit pratices

I believe we should review Listeners. Most unit testing frameworks have special methods to be called before a test starts and after a test ends, commonly known as setUp() and tearDown().
Catch provides the same functionality but in the form of Listeners that can only be written in the main file and that use a different syntax than normal test code: tests have TEST_CASE, SECTION and REQUIRE; listeners are normal classes. Also and definitely not least, each Listener requires you to match which test is running before it can execute anything specific to that test.
I propose we replace the current Listener infrastructure with Fixtures similar to what purest provides:

fixtures have explicit names and are activated by declaring their use from test functions, modules, classes or whole projects.

https://docs.pytest.org/en/latest/fixture.html#fixtures
C++ best practices encourage code to be split by files and namespaces by folders and doing the same  that pytest does would bring Catch in line with those practices.  If this cannot be done another good idea would be setUp and tearDown per file, per TEST_CASE and per SECTION. Since Catch supports nested SECTIONs, public code created in the setup of a SECTION should be visible to all other SECTIONs.
C++ tends to be used with large codebases and as things are the main file becomes confusing very quickly.
This issue is to keep a promise I made here.

"Catch provides the same functionality but in the form of Listeners"

that's not quite accurate.
By which I mean: you could use Listeners for that - but that's not what they for - and is certainly not the best way to do it.

Instead "setup" and "teardown" is accomplished in a much more natural (for C++) way!
You just use SECTIONs within a TEST_CASE, and each SECTION will be like a test case in a framework with fixtures. You can then do your setup and teardown (although, typically, less need for the latter in C++) outside the SECTIONs.
If you're prefer the more XUnit style of fixtures, you can still do that, too (see https://github.com/philsquared/Catch/blob/master/docs/test-fixtures.md)

You just use SECTIONs within a TEST_CASE, and each SECTION will be like a test case in a framework with fixtures. You can then do your setup and teardown (although, typically, less need for the latter in C++) outside the SECTIONs.

How is this achieved? So any code I call before and after a section is executed as setup/teardown?

If you prefer the more XUnit style of fixtures [...]

I'm sure I'm missing something but how would you make a fixture fire on setup/teardown?

By which I mean: you could use Listeners for that - but that's not what they're for - and is certainly not the best way to do it.

I remember discussing Fixtures with you and I always had in mind setup/teardown. What should they be used for then?

If we've discussed this before, I apologise. I don't remember that discussion at present (anything else that might jog my memory?). I suspect we're talking a little cross purposes here somewhere - let's try to identify where.
When you talk about Fixtures I'm thinking of a style of unit testing where you have a test class, which has a set of test methods. The class has setup() and teardown() methods and/ or constructor and destructor - either way they are called before and after calling each test method, respectively (with a new instance created for each test). And this is what I was referring to when I said that Catch does support this style of testing (with brief documentation at the link I supplied). Is this different to what you were thinking of?
However, as I've said, that's not the most idiomatic way to achieve a similar result with Catch. In C++ we're used to using stack-based RAII objects to do before/ after operations and this more naturally fits the idea of SECTIONs. So, yes, as you say, "any code I call before and after a section is executed as setup/teardown". In fact the "as setup/teardown" is redundant in this sentence. The whole point of this is to get us away from having to think of setup/ teardown as special things that happen at special times. It's just code that gets used like any other code. The setup/teardown effect is achieved simply by code outside the SECTIONs being called before and/ or after the code within. Each SECTION at the same level is executed by re-executing the test case from the start - so you get the same level of isolation you do with Fixtures. But SECTIONs go further because you can nest them - and so have multiple levels of setup/teardown (see the vector example in the tutorial - https://github.com/philsquared/Catch/blob/master/docs/tutorial.md#test-cases-and-sections).
Is any of this still unclear? Am I still missing what you're asking for?

How is this achieved? So any code I call before and after a section is executed as setup/teardown?

Yes, that is the entire point of SECTIONs
TEST_CASE("foo") {
    std::cout << "setup\n";
    SECTION("bar") {
        std::cout << "bar\n";
    }
    SECTION("baz") {
        std::cout << "baz\n";
    }
    std::cout << "tear down\n";
}

will have output of
setup
bar
tear down
setup
baz
tear down

The same logic applies over arbitrarily nested SECTIONs*
As for listeners, seeing listeners as a way to implement set-up, tear-down is a bit misguided. They can be used that way, sure, but that only makes sense if you have some global state that needs to be cleared/reset with some granularity (these can range from logging singleton, where you presumably want to drop stored logs if everything is OK, to a hardware device that needs restart signal).
You can also use methods of objects as your test cases, in which case the setup/tear down is in constructor/destructor and are run before each test case method is called.
* However, having parallel deeply nested sections tends to make following the test logic a bit hard.

@philsquared I was thinking of this issue I opened where you say I should use Listeners. Listeners are great but they're limited to the main() file and that will get confusing very quickly, at least to me.
I may have misread what you said but I'll try to use TEST_CASEs for now.

@ruipacheco Catch 2 listeners are no longer limited to main file. This won't be backported to Catch Classic, however.
I still think that listener usage should be quite rare though, as they imply a common set of steps that need to be run before each assertion/section/test case/test run. Given how test case + sections already enable reusing common steps for certain set of assertions, this likely also implies a global state.
(And global state is the enemy of unit testing)

I'm happy closing this issue.

Thanks for linking the issue. Of course I remember that one now! :-)
But in there I was suggesting the use of Listeners for cross-cutting, environmental, setup/teardown (you mentioned starting/ stopping/ clearing databases etc), which you might want to do for all tests (either once at the start/ end, or before/ after every test case). In that case Listeners allows you to put that logic in one place.
But if you have to start making that logic conditional on which test is being run, then I don't think Listeners are the right solution - and SECTIONs (or class based fixtures, if you prefer) are a better fit as we've discussed.
So I hope that clarifies things and you get it all working as cleanly as you would like.

This is perfect, thanks!


[ENH] BEP030: Functional Near-Infrared Spectroscopy

BEP030: Functional Near-Infrared Spectroscopy
This PR adds functional near-infrared spectroscopy to BIDS.
Leads: @rob-luke & @lpollonini

validator: https://github.com/bids-standard/bids-validator/pull/952
examples: https://github.com/bids-standard/bids-examples/pull/333
rendered specification draft: https://bids-specification.readthedocs.io/en/bep030/04-modality-specific-files/11-functional-near-infrared-spectroscopy.html

Progress:

[x] Community reviewed proposal (google docs)
[x] Transition google doc to markdown (this PR). View current render here.
[x] Fix language in document. It currently reads as if it was written by many people (as it was), and needs to be reworked to fix sentence structure and grammar.
[x] Extend validator to support this BEP (WIP: GitHub PR link)
[x] Generate open datasets from several labs and ensure they are compliant with specification (e.g. dataset from rob-luke, dataset from robertoostenveld, these are listed in the manuscript)
[x] Add example dataset to bids-examples (dataset 1, dataset 2)
[ ] Resolve remaining issues in this PR as described here
[ ] Preprint of the new extension (manuscript hs been reviewed by half the authors, about to be circulated to remaining authors).
[ ] Press release

NOTE: At all stages in this process we will actively advertise and invite feedback on the proposal. We invite all feedback no matter how minor or major. And we will advertise the draft website to the community for review once it is rendering correctly.
closes #438

Scope of proposal:
This specification applies to the storage of raw fNIRS data and metadata, and does not address data processing or the storage of processed data. This specification aims to deal with data from well established commercial systems, not experimental or DIY systems, although everyone is encouraged to adhere to BIDS-fNIRS to facilitate future data sharing. The specification currently only addresses continuous wave (CW) fNIRS devices, but consideration is taken not to preclude extensions to TD and FD instruments in the future upon contributions from experts in these domains.
Considerations when reviewing this BEP:

It was decided to only include continuous wave (CW) fNIRS in this BEP. However, we have taken effort not to preclude expansion to other techniques such as time or frequency domain fNIRS. We ask that TD and FD experts still review this proposal to ensure nothing in the specification precludes future expansion to other fNIRS types.
This BEP does not specify details about hyper scanning, which is popular in the fNIRS community. This was decided as hyper scanning is not specific to fNIRS and is also performed using other modalities. Thus, hyper scanning should be added to BIDS in a modality agnostic manner. Hyperscanning is an open issue in BIDS (https://github.com/bids-standard/bids-specification/issues/402).
A conscious decision was made not to specify what should be considered a short channel. The specification contains fields to store the number of short channels, as this will be important for searchability. But the definition of what exactly constitutes a short channel (is it less than 8mm, or 10mm, etc) is left to the end user and software packages.

To provide feedback:

Select Files Changed in the tab list at the top of this text box.
Press the Load Diff button for the src/04-modality-specific-files/10-functional-near-infrared-spectroscopy.md file
Hover your mouse over any line that you wish to comment on, this should make a blue cross appear to the right of the line.
Press the blue cross and provide enter your comment

@sappelhoff do you know why the types aren't rendering as hyperlinks in my tables? I think I copied the format from the other BEPs. Thanks

@sappelhoff do you know why the types aren't rendering as hyperlinks in my tables? I think I copied the format from the other BEPs. Thanks

you probably forgot to copy over the link targets, the [this is a link][] syntax only works if you declare [this is a link]: https://www.google.com somewhere in the document (that latter declaration will be invisible in the rendering).
see: https://github.com/bids-standard/bids-specification/blame/master/src/04-modality-specific-files/03-electroencephalography.md#L433-L447

Thanks so much @sappelhoff, that makes total sense now. Appreciate it.

Thanks for the information @sappelhoff. Congratulations on the big PR merge, its great. I will adjust this PR to use the new scheme when I have some time in next weeks.

Thank you for the review @guiomar.

@sappelhoff is there a way to pass additional text to a schema? for example I would prefer this text for CapManufacturer

Name of the cap manufacturer (for example, "Artinis") If a custom-made cap is used then the string “custom” should be used. If no cap was used, such as with optodes that are directly taped to the scalp, then the string “none” should be used and NIRSPlacementScheme field may be used to specify the optode placement scheme.

but currently the schema provides:

Name of the cap manufacturer (for example, "EasyCap").

If not, should I create a new schema yaml called "CapManufacturerNIRS.yaml"? or revert to the hard coded table?

is there a way to pass additional text to a schema?

Take a look at the following line: https://github.com/bids-standard/bids-specification/blame/master/src/04-modality-specific-files/03-electroencephalography.md#L119
That's an example of how the schema "base definition"  can be extended/tweaked slightly to better fit the context. Would that work for you? Else, let's hear @tsalo's opinion.

Here is a brief status update following from https://github.com/bids-standard/bids-specification/pull/802#issuecomment-940562988.

Several issues/implementation inconsistencies were found with the SNIRF file format which was being conflated with problems with the BIDS proposal. The SNIRF file format is the only format supported in this BEP. So while it isn't strictly part of this extension proposal, it was essential to address. This has taken engineering effort away from this BEP. However, there is now an official SNIRF validator (https://github.com/BUNPC/pysnirf2) so this issue should be largely resolved and attention can return to finalising this BEP PR.
An initial draft of the manuscript has been circulated around half the co-authors. Most feedback has been incorporated. Before the draft will be shared with the remaining co-authors we are waiting on an additional two example datasets.
The Homer software team has spent considerable time planning and implementing BIDS support, no significant issues have been raised.
A data-zeroed dataset has been submitted as a PR to the bids-examples repository which will allow testing of the validator. More work is required here.
Suggestion were made on this PR by Helena, Robert, and Remi that need to be implemented.

So things are moving a bit slower than planned, but we are slowly moving forward.

Hi all I am a neuroimaging engineer with expertise in Python and software engineering in science, looking to help move this particular aspect of the BIDS standard along. It is a goal of mine to contribute to BIDS before grad school. If there are any changes I can assist with, please let me know! It will be very beneficial for our lab to have fNIRS / BIDS compatibility, and I look forward to developing tools that take advantage of this consensus.

can we get this rendered as bep-030 on readthedocs (with the version selector in the lower right corner)? There is a bep-009 and bep-028 there. I also propose to remove the wip-derivatives

can we get this rendered as bep-030 on readthedocs (with the version selector in the lower right corner)? There is a bep-009 and bep-028 there. I also propose to remove the wip-derivatives

done, I also removed wip-derivatives (cc @effigies)

@sappelhoff I am unable to understand why the schemacode tests are failing. I have not edited any of the schemacode files, and I can't decipher the error. Could you please point me to the correct person to ask about this?

Ah sorry, just saw it now. I'll look into it, but @tsalo and @effigies are well versed with this.

Also https://github.com/bids-standard/bids-specification/pull/1107 is going to cause issues in this PR. Happy to apply the fix once it's merged.
Also can update your nirs.yaml with the above-mentioned changes directly if you prefer that to me making suggestions and you applying them.

Thanks @effigies! I think @rob-luke will be happy for each of your commits (unless the situation has changed and he suddenly has a lot of time on his hands :wink:)

I think @rob-luke will be happy for each of your commits

@sappelhoff is correct, any direct commits for improvements are greatly appreciated @effigies
I think I managed to fix the current issue and get those green ticks. But any other changes are appreciated too :)

thanks for the changes
I still have a few more to address, but I am working through your great comments. Thanks for your attention to detail. I will finish addressing your comments in the coming two days.

What do you all think?
Great plan

@rob-luke @lpollonini we have scheduled the community review period for the NIRS BEP to be for 14 days from 2022-09-01 until 2022-09-14.
Given that no major problems are still present at the end of the review period, we will:

merge NIRS (spec, validator, examples)
continue directly with a 5-business-day long freeze of the specification
followed by a release of BIDS 1.8.0 :tada:

I hope this suits your schedules! You can read some reasoning in https://github.com/bids-standard/bids-specification/issues/1118#issuecomment-1183074401
The time until the community review period can now best be used to smooth everything out as much as possible (spec, validator, examples, preprint/article), so that during the review period, emerging items can be addressed quickly and efficiently and so that no new blockers arise.
Having seen the progress of this BEP and the involvement of many diverse parties, I am very confident that this will be a great success :-)
Let me know if you have any questions.
cc @bids-standard/steering @bids-standard/maintainers  @bids-standard/bep_leads

(NOTE: I'll cross-post this message across several BEP threads)
Hi there, just a quick notification that we have just merged https://github.com/bids-standard/bids-specification/pull/918 and it may be interesting to look at the implications for this BEP.
We are introducing "BIDS URIs", which unify the way we refer to and point to files in BIDS datasets (as opposed to "dataset-relative" or "subject-relative" or "file-relative" links).
If the diff and discussion in the PR is unclear, you can also read the rendered version: https://bids-specification.readthedocs.io/en/latest/02-common-principles.html#bids-uri
Perhaps there are things in the BEP that need adjusting now, but perhaps also not -- in any case it's good to be aware of this new feature!
Let me know if there are any questions, comments, or concerns.

@rob-luke @lpollonini just a note that it'd be a good time to address all currently still unresolved comments on this pull request, because the community review period will start soonish (September 1), and it'd be good to have a clean slate then.
Regarding the current CI failures, @rwblair will push some commits to make the required updates, as far as I understood from the last maintainers meeting notes.

I'm done with my first pass at the schema rules. I still need to update the tables to use the new style macros and confirm that they look good. Maybe more changes next week as we look at how the validator interacts with these schema updates. @effigies any comments on the checks added would be nice.

to do --> nirs is currently not listed as a "datatype" under:
https://bids-specification--802.org.readthedocs.build/en/802/02-common-principles.html#definitions

Should be fixed as of 36202ca

One question is: Why is ACCELChannelCount (etc.) a thing at all? It's presumably redundant with looking at the actual contents of the type column in the channels.tsv file. It's not clear what problem it's solving while it is a place for inconsistency to creep into a dataset that means we need to validate it.

The BEP029 (Motion) introduced something similar (ACCChannelCount) in 1817738f1410eabba966ef62b0e80d1c01bec76e. This was when we still optioned for the nested json structure for multiple tracking systems. This solution is now deprecated. Tbh, I also think it is kind of redundant to have the number of a channel type as an extra field and we will remove it. Additionally, we should keep namings of types consistent (we will check against BEP030 for BEP029).

Tbh, I also think it is kind of redundant to have the number of a channel type as an extra field

As effigies highlights "I see it already exists in EEG, so I guess consistency demands this..."
My opinion is to keep it. There are already several redundant data fields in BIDS but they make life easier and more human readable. And this field matches EEG and consistency is very beneficial when writing code around BIDS.
I think this is a larger issue across BIDS, so I am happy to be guided by the @bids-maintenance group on this.

just a note that it'd be a good time to address all currently still unresolved comments on this pull request, because the community review period will start soonish (September 1), and it'd be good to have a clean slate then.

I think I just closed out all the unresolved comments. Please ping me specifically if anything wasn't sufficiently addressed or I missed anything. Thank you all for the review and direct pushes to the branch.

I just took a read of the BEP029 draft. As @JuliusWelzel points out, there are some conflicts. Specifically, I have noted:

BEP029 proposes ACCChannelCount whereas this PR and current BIDS use ACCELChannelCount . I am not sure if I should change this PR to match BEP029, as ACCELChannelCount is already in the BIDS spec. Any guidance is appreciated.
BEP029 proposes channel types ACC, MAGN, etc. Whereas this PR uses ACCEL, GYRO, MAGN.  One option here is  to change ACCEL in this PR to ACC to match BEP029, leave MAGN as is, and add GYRO to BEP029. The issue with that is then we have slightly different terminolgy with ACC and ACCELChannelCount. Guidance here is also appreciated.

Thank you JuliusWelzel for highlighting the need to align these two PRs. In my opinion BEP029 should be the reference for motion related information, and BEP030 should only include motion fields where absolutely necessary.
@bids-maintenance your help here is appreciated in advance.

Tbh, I also think it is kind of redundant to have the number of a channel type as an extra field

As effigies highlights "I see it already exists in EEG, so I guess consistency demands this..."
My (weak) opinion is to keep it.

Agreed to keep it for consistency. If we ever want to refactor/deprecate this metadata we should do it consistently with all modalities.

From the BEP029 (@sjeung) side let me point to a few minor conflicts which can be easily addressed:
Channel types:

ACC can become ACCEL in BEP029
GYRO is the same as ANGVEL in BEP029. We would like to use ANGVEL as this gives an idea about the content of the channel
--> These naming changes should also be reflected in the [TYPE]ChannelCount fields and be consistent across all BEPs

I think @robertoostenveld proposed to add motion related channels to BEP030. Do you think any motion data be excluded from this BEP as soon as the motion BEP029 is merged? Some mobile EEGs amp also come with IMUs and in the EEG specs motion channels are not specified. In either case, I believe it makes sense to put brain and motion data in different dirs. If people want, they can just specify MISC channels for their individual cases, if they want motion data to be stored in the same directory.

GYRO is the same as ANGVEL in BEP029

I am happy to follow the lead of BEP029 and change to ANGVEL, can someone from the BIDS steering or maintenance provide an opinion on this?
Or is there some way we can say something like "all the types from BEP029 can also be specified here"? But that probably doesn't work because BEP029 won't be merged when BEP030 is.

I am happy to follow the lead of BEP029 and change to ANGVEL, can someone from the BIDS steering or maintenance provide an opinion on this?

Ideally the changes introduced by BEP030 (nirs) will be directly usable by BEP029 (motion), so when @JuliusWelzel and @sjeung are fine with you renaming GYRO to ANGVEL to resolve this potential duplication, that'd be great. The motion team will have to work with what the nirs team introduces here, so please all be vigilant about the changes and find consensus :-)

Or is there some way we can say something like "all the types from BEP029 can also be specified here"? But that probably doesn't work because BEP029 won't be merged when BEP030 is.

That is not possible unless the nirs team wants to completely cut the motion related features and deferring to introducing them later, together with the motion team (in the future BIDS 1.9.0 then).

Tbh we are fine with either naming, let's option what is most convenient for BIDS in general. It is a really minor thing, just needs to be addressed.

Tbh we are fine with either naming

@JuliusWelzel you decide what you want in BEP029 Motion and I will follow your lead, the choice of naming here is motion related and your field of expertise not mine. I appreciate the consideration you have put in to this.
Once you let me know if you prefer GYRO to ANGVEL I will modify this PR and ping you on the change.
Thakns!

My 2 cents regarding GYRO versus ANGVEL: my preference is to name channels to the type of measurement, not to the value that is represented in the channel. For EEG we also don't call it a VOLT channel.

I agree with Sein's point of regarding calling the channel type ANGVEL instead of GYRO.
Some additional remarks when reviewing the specifications:

does the NIRSChannelCount include or exclude the ShortChannelCount? To me, it should include it, though we should describe this better in the documentation.
I remember we had a discussion about on how to describe the CapManufacturerModelName and the NIRSPlacementScheme. If I remember it correctly, our conclusion differs from how it is described in the specification now. However, I cannot find back our conversation on this. @robertoostenveld @rob-luke do you maybe remember where we discussed this or what we decided?

👋 @helenacockx

does the NIRSChannelCount include or exclude the ShortChannelCount? To me, it should include it, though we should describe this better in the documentation.

Good catch! I had always assumed that NIRSChannelCount did include the short channels, but we should make this explicit! I have changed the description from Number of NIRS channels. to Total number of NIRS channels, including short channels. Feel free to suggest additional clarification elsewhere in the document too.

I remember we had a discussion about on how to describe the CapManufacturerModelName and the NIRSPlacementScheme. If I remember it correctly, our conclusion differs from how it is described in the specification now. However, I cannot find back our conversation on this. @robertoostenveld @rob-luke do you maybe remember where we discussed this or what we decided?

The discussion is at  https://github.com/bids-standard/bids-specification/pull/802#discussion_r960215216
If I did not capture the changes correctly, lets fix it! Please suggest specific wording or open a PR to this PR. Thanks Helena :)

Re: NIRSChannelCount, I agree that we should include them all, also because we debated on how people decide what's short and what not and ultimately concluded that that can be done using S-D distance.

Just commenting here that the community review period is officially closed since a couple of days now. This PR is now pending a final review by some maintainers (for example myself) and the issues that were opened during the community review.
Unfortunately I'll only get to do a review in a week from now, because I am temporarily out of office starting tomorrow. I hope this delay is not a major inconvenience for anyone.

I think the discussion of naming GYRO vs ANGVEL is something that we should get input from the wider community on, as it will impact researchers beyond those that just do fNIRS or just do motion. As such, I have started a discussion on the google group at https://groups.google.com/g/bids-discussion/c/JH9t06EA7UQ/m/V5Z0z2xVBgAJ
@sjeung @JuliusWelzel could you please take a read of the google group message and ensure that I have summarised everything correctly? Please ensure that your viewpoint is adequately expressed (I am not a motion expert).

implement channel count checks (perhaps better be done by the schema devs directly?

@sappelhoff @effigies I would greatly appreciate if someone can help with this, I really struggle with the schema and javascript.

Thanks for summarising the remaining issues @sappelhoff  https://github.com/bids-standard/bids-specification/pull/802#pullrequestreview-1121994111
There are three issues remaining. Two could be resolved relatively quickly.
The third issue on GYRO vs ANGVEL may take some time for the wider community to contribute to and come to a consensus. Is there a way we can proceed without this decision? These data types are referenced throughout the PR, so would be difficult to remove. However, it would be good to get this merged so we can start hunting bugs.

Thanks for the code changes and review @effigies

I have made the variable name changes as requested by @tsalo https://github.com/bids-standard/bids-specification/pull/802#pullrequestreview-1126733539

As discussed in yesterday's maintainers meeting I am merging this PR now -- congrats to all who helped and especially to @rob-luke and @lpollonini! :tada: :partying_face:
We can now continue to look for bugs and work on the few remaining issues (mainly NIRS vs fNIRS and Gyro vs AngVel).
Once the remaining issues are resolved we can initiate the release protocol and go forward with BIDS 1.8.0 :rocket:

Thanks @sappelhoff !
I am revising an formatting the manuscript for submission to Scientific Data, and will distribute a could copy to all co-authors/contributors right after the upcoming fNIRS 2022 conference.

WooHoo!!!!!! 🎉
Thank you to everyone who contributed. Now let's knock these last few issues off 🚀

awesome work, the community will thank you ;)

Congrats everyone!!!

Hooray!!! 🥳🥳🥳

We can now continue to look for bugs and work on the few remaining issues (mainly NIRS vs fNIRS and Gyro vs AngVel).

Regarding these two issues:

NIRS vs fNIRS: We will discuss this on Monday at the fNIRS conference, in the SNIRF meeting at midday. Please attend or contribute your opinion in advance. A decision will be made at this time.

Gyro vs AngVel: I suggest we wait a little longer (another week?) for more contributions to the discussion at https://groups.google.com/g/bids-discussion/c/JH9t06EA7UQ/m/V5Z0z2xVBgAJ before we address this

Thanks for the merge @sappelhoff and extensive contributions from all @bids-maintenance @bids-standard/maintainers  @bids-standard/steering over the last year(s)

Starting testing things on NIRS things with bids-matlab.
Should nirs be mentioned in the modalities of the schema: https://github.com/bids-standard/bids-specification/blob/master/src/schema/objects/modalities.yaml

NIRS vs fNIRS: We will discuss this on Monday at the fNIRS conference, in the SNIRF meeting at midday. Please attend or contribute your opinion in advance. A decision will be made at this time.

one thing to consider is the modality folder names (like "beh" for behavioral, "anat" for anatomical MRI data, etc.) --> if it's fnirs, it'll be longer than nirs. Maybe not a strong argument, but one to keep in mind.

@sappelhoff I think I might be misunderstanding what we are discussing, so let me overcommunicate so we can ensure I am trying to solve the correct problem.
The naming of the modality is currently nirs in the schema and validator. So a file in a BIDS dataset might have the path  /sub-21/nirs/sub-21_task-fingerautodual_nirs.snirf and /sub-21/nirs/sub-21_task-fingerauto_nirs.json. Further, the field names include the prefix NIRS, for example NIRSCoordinateSystem.
Currently, the text in the specification (as rendered on ReadTheDocs) has the title functional Near-Infrared Spectroscopy  and uses the term fNIRS frequently (30 times) in the document.
We are not debating if the schema and file names should be changed from nirs.
We are discussing if the docs page should be reworded to consistently use NIRS, rather than fNIRS (including dropping functional from the title and other places in the text).
Is my above understanding of the problem statement correct? I think the current mixing of fNIRS and NIRS is ok, but I will also be fine with changing everything in the written document from fNIRS to NIRS if thats what the community prefers. I do not think we should change the schema and validator to usefnirs, its longer and not consistent with other modalities.

Okay, thank you for clarifying, Rob. I am fine with your outline of the problem.

There seems to be a consensus for the AngVel vs Gyro discussion now: https://groups.google.com/g/bids-discussion/c/JH9t06EA7UQ

I think GYRO it is

did you finish discussing nirs vs fnirs?

I am not sure if the discussion has concluded, but I am also OK with converting fNIRS to NIRS in the docs, if the mixing with the schema/validator could generate confusion. Also the SNIRF data format does not contain the word "functional", and that's one more reason to drop it from the doc in consistency with everything else.
If we proceed with NIRS only, we should start off the doc with something like "In this doc, the term NIRS refer mostly, if not uniquely, to functional NIRS [...]" to clarify what we are talking about.

I am also OK with converting fNIRS to NIRS in the docs

Agreed, I will make the changes.

@bids-standard/maintainers

Given that these are the last open items before a release, it'd be great to wrap this up :-)

These are done. Please let me know if there is anything else, but I think we are good to wrap this up!!


Resource requests and limits are not applied to init containers

Description
When you have a ResourceQuota applied to a namespace it sets a requirement that every pod must specify the relevant resources, otherwise the pod will not be scheduled.

If quota is enabled in a namespace for compute resources like cpu and memory, users must specify requests or limits for those values; otherwise, the quota system may reject pod creation
https://kubernetes.io/docs/concepts/policy/resource-quotas/

When creating a new mysql database, the spec currently allows users to specify the resource requests which are passed through to the statefulset and configured for the mysql container, but not the init container. Since there are no resource requests or limits specified for the init container the admission controller prevents the pod from being scheduled and pod creation fails.
To reproduce this issue:
Enable ResourceQuotas on a namespace:
apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-request-limits
  namespace: demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: "4Gi"

Create mysql Object
apiVersion: kubedb.com/v1alpha1
kind: MySQL
metadata:
  name: mysqldatabase
  namespace: demo
spec:
  version: "8.0"
  replicas: 1
  storage:
    storageClassName: "standard"
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 5Gi
  doNotPause: true
  resources:
    requests:
      memory: "256Mi"
      cpu: "100m"

Observe no running pods and statefulset not initializing:
kubectl get pods
No resources found.

kubectl get statefulset
NAME            DESIRED   CURRENT   AGE
mysqldatabase   1         0         4m

Observe the events in the namespace, to identify the error
kubectl get events -n demo
LAST SEEN   FIRST SEEN   COUNT     NAME                                    KIND                    SUBOBJECT   TYPE      REASON                  SOURCE                        MESSAGE
2m          2m           1         data-mysqldatabase-0.155bbd5d88cd33bf   PersistentVolumeClaim               Normal    ProvisioningSucceeded   persistentvolume-controller   Successfully provisioned volume pvc-f6266c11-cb3b-11e8-b90a-42010a8e0042 using kubernetes.io/gce-pd
2m          2m           1         mysqldatabase.155bbd5c85a7a450          MySQL                               Normal    Successful              MySQL operator                Successfully created Service
2m          2m           1         mysqldatabase.155bbd5c88de54cd          StatefulSet                         Normal    SuccessfulCreate        statefulset-controller        create Claim data-mysqldatabase-0 Pod mysqldatabase-0 in StatefulSet mysqldatabase success
21s         2m           20        mysqldatabase.155bbd5c891d9336          StatefulSet                         Warning   FailedCreate            statefulset-controller        create Pod mysqldatabase-0 in StatefulSet mysqldatabase failed error: pods "mysqldatabase-0" is forbidden: failed quota: resource-request-limits: must specify requests.cpu,requests.memory

Resolving the issue
Editing the statefulset and adding the resources to the init container immediately causes the pod to be scheduled:
kubectl edit statefulset

initContainers:
- command:
  - rm
  - -rf
  - /var/lib/mysql/lost+found
  image: busybox
  imagePullPolicy: IfNotPresent
  name: remove-lost-found
  resources:
    requests:
      cpu: 100m
      memory: 256Mi

statefulset "mysqldatabase" edited

Observe that the pods are scheduled and run accordingly.
kubectl get statefulset
NAME            DESIRED   CURRENT   AGE
mysqldatabase   1         1         10m

kubectl get pods
NAME              READY     STATUS     RESTARTS   AGE
mysqldatabase-0   0/1       Init:0/1   0          9s

kubectl get pods
NAME              READY     STATUS    RESTARTS   AGE
mysqldatabase-0   1/1       Running   0          3m

Fixed in https://github.com/kubedb/mysql/pull/107


Write Script for CHAOSS Context Working Groups Video

Description:

Write  Script for CHAOSS Context Working Group Video
See guideline

This is complete at: https://docs.google.com/document/d/1zMHxMU28yJeJSoiM_3ieQ5LCA6gVT-oOeJdpbYILjdQ/edit

@peculiaruc


Why is preventDefault not made available on press events?

❔ Question
Why is preventDefault not available in PressEvent?

🔦 Context
I'm replacing the guts our of style system with react-spectrum and ran into an incompatibility with our codebase because preventDefault is not in onPress from useButton (or usePress).

There's a few use cases. First, we have clickable rows in a list that have a delete button inside of them. The delete button needs to prevent the default so the row itself won't navigate away.

💻 Code Sample

🌍 Your Environment

Software
Version(s)

react-spectrum
v3.1

Browser
Chrome Mac

Operating System

🧢 Your Company/Team

Apollo GraphQL 🚀

We preventDefault in many place in usePress https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/interactions/src/usePress.ts#L302
Are we just missing one?
As for why we don't expose preventDefault itself, I'm not 100%, I'll try to get a better answer. In the meantime, there are parts of it here https://react-spectrum.adobe.com/blog/building-a-button-part-1.html

We preventDefault in many place in usePress https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/interactions/src/usePress.ts#L302
Are we just missing one?
As for why we don't expose preventDefault itself, I'm not 100%, I'll try to get a better answer. In the meantime, there are parts of it here react-spectrum.adobe.com/blog/building-a-button-part-1.html

Thanks for getting back to me @snowystinger . I'm looking forward to hearing more!

Can you tell us which event is is that you need to prevent default on?

Can you tell us which event it is that you need to prevent default on?

@snowystinger I need to prevent on an onPress event. I have a list of graphs that are rendered as  so they will navigate somewhere else in the application. Some of them have a delete button, a button created implementing useButton. When I click that delete button, I need to call event.preventDefault to prevent the navigation resulting from clicking .

Sorry, can you tell if it's the default of the mouse/pointer down, up? there are several events present in the construction of onPress

Also, what is the dom structure for this? I'm envisioning something along these lines and want to double check
This will take you elsewhere <button>Delete</button>

@snowystinger That is exactly the DOM structure we're looking at; a <button> nested under a . As for the events, the call stack is my onPress function called by triggerPressEnd called by onPointerUp.

Ah, that is not valid HTML, so you probably shouldn't be doing that.
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element
Content model:
Transparent, but there must be no interactive content descendant, a element descendant, or descendant with the tabindex attribute specified.

o, and this is probably why we aren't exposing preventDefault on the press events

there are several events present in the construction of onPress

Ah, that is not valid HTML, so you probably shouldn't be doing that.
html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element
Content model:
Transparent, but there must be no interactive content descendant, a element descendant, or descendant with the tabindex attribute specified.

@snowystinger While I know we shouldn't be doing this; the unfortunate fact is we are 😃 I think exposing preventDefault, even if its use is strongly advised against, would make incremental adoption of useButton much easier.

Well you may be in luck, it looks like we're doing something odd here https://github.com/adobe/react-spectrum/blob/main/packages/%40react-aria/interactions/src/usePress.ts#L228
We should probably be consistent with the rest of our events, but this is going to require some serious testing, so not something that will get in this release most likely.
in the meantime, you could use the deprecated onClick prop to handle it yourself until you can get the button out of the link :)  onClick={e => e.preventDefault()} it will result in a console warning, but won't actually break anything
I'll post a link to the branch we're testing on once i have that up

Thank you @snowystinger ! I'll do that for the time being 😃

@snowystinger I think usePress does not support keyboard events for anchor elements. by default, only the enter key triggers the press event, the spacebar is ignored. But if you do onClick={e => e.preventDefault()}  the enter key will stop working too. here the sandbox

I'm not sure I follow your concern @deebov this is the temporary workaround I was suggesting https://codesandbox.io/s/busy-hooks-dhx4u
Is there something in that not working as expected? (minus the invalid html structure)
If you have a concern about something we might break by us default calling preventDefault onClick would you mind commenting on this PR https://github.com/adobe/react-spectrum/pull/904
We're definitely apprehensive about a change like this, so more eyes on it is definitely helpful.
We do have some anchor tag handling in usePress, though we'd optimally like to remove it from there to a more appropriate aria hook(s<EMAIL_ADDRESS>

I have a link button with an onPress, I want the link to be just there but customize what happends when it is clicked.
Is there any way to prevent the default link behavior?

It would be helpful to at least add this to the documentation. preventDefault is very commonly used - being directed to use a deprecated function to solve it is not great but it would be nice to at least have this limitation front and center so it's not a surprise that requires a roundtrip to this issue.
I have a similar use case, an  link with a click handler. The click handler facilitates better in-context UX and the link facilitates opening the feature in a tab. That pattern may not be super common but in the past years I have had to reach for it several times to reach the desired outcome.
Instead of providing the preventDefault to the event handler it could potentially also be an option on the hook, that would allow you to handle it consistently internally, whatever the mix of events is that is required to build onPress.

That's a reasonable suggestion. Should it go on useLink since it's fairly link specific though?

I am pretty disappointed with react-aria tbh. Like if you have a useLink for example and you want to disable it onPress or something, when it's disabled with onPress it disables the href and doesn't move to the next page, this is the only way we can do something like e.preventDefault(), is the use isDisabled and it sucks lol. I had to make a custom prop called isDisable and it goes to the destination and then disables like we would think it would do:
  {...(isDisable && {
    tabIndex: "-1",
    "aria-disabled": "true",
    style: { cursor: "not-allowed" },
  })}


should add $event.preventDefault(); to prevent nested form submit for nested controller;

FileItem.prototype.upload = function($event) {
this.uploader.uploadItem(this);
$event.preventDefault();
};

File selection doesn't have to do with form submission. That would be in your code not the plugin


Please add input fields (hex, r, g, b, a etc) under each color format group so that we can specify colors manually

Sorry, this probably won't happen. You're free to edit the colors in-editor.


helm sometimes fails when creating and using a new namespace in separate template YAML files in a Chart

this doesn't fail every time for me locally; but fails sometimes; so looks timing related.
I've a chart which deploys a bunch of stuff, including creating a new namespace in one template YAML and using that namespace in another YAML file
helm repo add fabric8 https://fabric8.io/helm
helm install fabric8/fabric8-platform

I've seen this totally work once but I've also seen this happen a few times:
$ helm install fabric8/fabric8-platform
Fetched fabric8/fabric8-platform to fabric8-platform-2.2.10-helm.tar.gz
Error: release tufted-badger failed: namespaces "user-secrets-source-admin" not found
$ helm list
$

so am guessing this is an ordering issue of the YAML files inside a Chart.
Historically when applying lots of YAML resources we sorted them in the maven tooling for kubernetes. I wonder if Helm should do the same; load all resources and sort them before applying them? e.g. Namespaces first, then Secrets + ServiceAccounts + Services, then Deployments etc
I guess another workaround is to not have a separate YAML for the namespace and secret; but have a single YAML file for the Namespace and Secret to force ordering.
Whats the best approach to ensure that resources get applied in the correct order so that YAML referencing other resources works reliably?

If you're using Alpha.5, that should be fixed now. I found a bug in the ordering that was resulting in namespace records sometimes being sent too late. Beta.1, which will be out today, should have that fixed.

ah great thanks @technosophos I just tried beta.1 and didn't see this error - but got this instead:
$ helm install fabric8-platform
NAME: insipid-pengui
Error: getting deployed release 'insipid-pengui': release: not found

I'll do a bit more testing to see if this is a one off

@jstrachan Let me know about this one. I'm putting together the next round of Beta issues.


branches cleaning + error: cannot lock ref

Describe the bug
I mirrored this repository in Azure DevOps to use with Microsoft Sentinel Content Management > Repositories (preview).
In deployment pipeline, it fails on multiple "error: cannot lock ref" that should be fixed.
Deleting branches solve the issue. git remote prune origin maybe other option.
Strangely, git fsck --full did not return errors.
As there seems a lot of branch currently and likely that they are not all active, the inactive/merged ones should likely be deleted.
To Reproduce

Clone repository in Azure Devops
Add it to Sentinel repositories
Check Pipeline results in Azure Devops
See error

Expected behavior
ADO deployment should not failed because of local refs errors like below
Screenshots
error: some local refs could not be updated; try running
 'git remote prune origin' to remove any old, conflicting branches
##[warning]Git fetch failed with exit code 1, back off 2.734 seconds before retry.
git -c http.extraheader="AUTHORIZATION: bearer ***" fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin
error: cannot lock ref 'refs/remotes/origin/dev/normalization/dns_entity': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/dns_entity'
From https://dev.azure.com/ORG/PROJECT/_git/Azure-Sentinel
 ! [new branch]          dev/normalization/dns_entity -> origin/dev/normalization/dns_entity  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/dev/normalization/networkYuval': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/networkYuval'
 ! [new branch]          dev/normalization/networkYuval -> origin/dev/normalization/networkYuval  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/dev/normalization/network_v2': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/network_v2'
 ! [new branch]          dev/normalization/network_v2 -> origin/dev/normalization/network_v2  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/dev/normalization/network_yuval': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/network_yuval'
 ! [new branch]          dev/normalization/network_yuval -> origin/dev/normalization/network_yuval  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/dev/normalization/parameters/dns': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/parameters/dns'
 ! [new branch]          dev/normalization/parameters/dns -> origin/dev/normalization/parameters/dns  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/dev/normalization/process': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/process'
 ! [new branch]          dev/normalization/process -> origin/dev/normalization/process  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/dev/normalization/process_analytics': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/process_analytics'
 ! [new branch]          dev/normalization/process_analytics -> origin/dev/normalization/process_analytics  (unable to update local ref)
error: cannot lock ref 'refs/remotes/origin/dev/normalization/sysmon_linux_connector': 'refs/remotes/origin/dev/normalization' exists; cannot create 'refs/remotes/origin/dev/normalization/sysmon_linux_connector'
 ! [new branch]          dev/normalization/sysmon_linux_connector -> origin/dev/normalization/sysmon_linux_connector  (unable to update local ref)
 * [new branch]          testBranch -> origin/testBranch
error: some local refs could not be updated; try running
 'git remote prune origin' to remove any old, conflicting branches
##[warning]Git fetch failed with exit code 1, back off 9.948 seconds before retry.

Desktop (please complete the following information):

OS: N/A
Browser: N/A
Version: N/A

@preetikr - look like we need to clean up again. :)

@juju4 - I did some clean up branches.  We are down to 275 now, having some other folks go thru and clean up based on their areas.

Thanks a lot @shainw !

@juju4  are you still facing the issue?


System froze, screens went black

Microsoft PowerToys version
0.81.0
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce
I was using Excel and when working with a pivot table, the screens went black, there was a beeping tone, and the computer slowed down.  A Power Toys window appeared that something went wrong.
Version: <IP_ADDRESS>
OS Version: Microsoft Windows NT 10.0.19045.0
IntPtr Length: 8
x64: True
Date: 6/27/2024 10:30:38 AM
Exception:
System.Runtime.InteropServices.COMException (0x80263001): {Desktop composition is disabled} The operation could not be completed because desktop composition is disabled. (0x80263001)
at Standard.NativeMethods.DwmExtendFrameIntoClientArea(IntPtr hwnd, MARGINS& pMarInset)
at System.Windows.Shell.WindowChromeWorker._ExtendGlassFrame()
at System.Windows.Shell.WindowChromeWorker._UpdateFrameState(Boolean force)
at System.Windows.Shell.WindowChromeWorker._HandleDwmCompositionChanged(WM uMsg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Shell.WindowChromeWorker._WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.PublicHooksFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
2024-06-27.txt
✔ Expected Behavior
Using pivot tables to filter results.
❌ Actual Behavior
Screen froze, beeping and screens went black.
Other Software
No response

/dup #30507


DRAFT: SPARK: infering of transformationType for column lineage

Problem
OpenLineageSparkListener does not enrich column level lineage with transformType and transformDescription fields...
Closes:
https://github.com/OpenLineage/OpenLineage/issues/2723
Solution
Added logic that infers transformType and transformDescription for column level lineage
It's working draft, I will improve it and add tests, for now will just attach proofs that it works:
Whenever I have some time I will work on it and gradually finish it

Note: All schema changes require discussion. Please link the issue for context.

[ ] Your change modifies the core OpenLineage model
[ ] Your change modifies one or more OpenLineage facets

One-line summary:
Checklist

[ ] You've signed-off your work
[ ] Your pull request title follows our guidelines
[ ] Your changes are accompanied by tests (if relevant)
[ ] Your change contains a small diff and is self-contained
[ ] You've updated any relevant documentation (if relevant)
[ ] Your comment includes a one-liner for the changelog about the specific purpose of the change (not required for changes to tests, docs, or CI config)
[ ] You've versioned the core OpenLineage model or facets according to SchemaVer (if relevant)
[ ] You've added a header to source files (if relevant)

SPDX-License-Identifier: Apache-2.0
Copyright 2018-2024 contributors to the OpenLineage project

Hey @alexs-101, we want to change that mechanism. The description of the changes is in issues https://github.com/OpenLineage/OpenLineage/issues/2186 and https://github.com/OpenLineage/OpenLineage/issues/2187. @tnazarew is working on the implementation right now - there's probably no point in duplicating work.

Hey @alexs-101, we want to change that mechanism. The description of the changes is in issues #2186 and #2187. @tnazarew is working on the implementation right now - there's probably no point in duplicating work.

Cool, I will close mine then, and will wait for the implementation.


Form

is it possible to use this on forms?
I want to obtain the coordinates of a building by searching on google maps then saving it on my database

As far as I know, you still have to create a widget based on InputWidget class. I've created one myself for my personal project.

Thanks, any guidelines on how to do it? I am pretty much new to google maps api.

I did it in the past with Yii1 version: https://github.com/tonydspaniard/egmap/blob/master/EGMapGeocodeTool.php
Maybe you can get some hints


Query Filter Memory Usage

I have a project that only utilizes Filter functionality.  We do this in the ctor when creating the DbContext for multi-tenancy.
After running JetBrains dotMemory, here are the top for instances of the largest retained instances.  Is this by design that it's caching the expressions and dbparameters?  Is there anyway to reduce the memory usage?

Hello @dcomartin ,
Could you provide us a test project with this issue? I will have one of my developers look at it and check why so much memory is required.
You can send it here<EMAIL_ADDRESS>Best Regards,
Jonathan

Yes, I'll try and come up with a sample project to repro that mimics as closely as I can to our usage.

Hello @dcomartin
This issue will be closed since we haven't heard back from you.
Feel free to reopen it if you can provide the information we asked.
Best Regards,
Jonathan


No autoprefix for cursor property

Hi!
I found there are no autoprefixes for cursor: grab.. cursor: grabbing  etc...
We need -webkit- prefix for this.

I check Autoprefixer in online demo and -webkit-grab was added correctly.
Check your browsers list.

This is different repo ? https://github.com/autoprefixer/autoprefixer.github.io


Test vector format

Below is just a proposal open for discussion.
It would make sense to ensure that the whole C2SP project uses the same or at least similar formats for test vectors.
There are a few things that make using the current test vectors in Wycheproof more laborious than necessary:

More than one algorithm in the same test file. Here algorithm means cryptographic primitive together with algorithm parameters such as key size, nonce size etc.  Currently, implementers have to filter test vector files for suitable test vectors, if their implementation is restricted to say AES-GCM with 128 or 256-bit key (but not 192), 12 byte nonces and 16 byte tags.
Having multiple parameter sets in the same file can in the worst case mean that special case implementation (e.g. CCM with 13 byte nonces) are not tested at all if no such vector is available.

the use of TestGroups: TestGroups are typically used to group the test vectors into groups with the same parameters, e.g., they are grouped by key size. They can reduce the size of a test vector file, but more importantly they just add additional complexity to the code handling them. If a new test vector format is added, then the TestGroups should be removed.

the header of a test file should describe the algorithm that is used and briefly explain the test type (e.g. signature verification vs. signature generation). E.g. users not knowing that there are DER and P1363 encoded signatures should at least have a chance to notice that they may be using the wrong file by reading the header information.

The testvector_v1 format did add additional information about the generation of the test vectors, the bug type that the test vector tries to check and potential implications that a failure has. The impact of this information is currently unclear to me.

Another potential change is the format for bigIntegers. Wycheproof currently uses bigendian two's complement representation of bigIntegers in hexadecimal representation. This can lead to confusion because of leading 00 or ff bytes to ensure the correct sign. Alternatives are hexadecimal strings such as ("0x12345", "-0x12345").


(BOLT-1274) Raise validation error when inventory config is invalid

Previously if the config set in inventory was either not defined, or was not a hash a stack trace would be raised when trying to access target['options']&.keys. This commit adds a validation step to ensure there is either no config set or that if it is set that it is a hash. The net effect is to raise a validation error pointing to the offending key instead of a stack trace.

CLA signed by all contributors.


multiserver/fallback option

hi
one of the dns resolvers used often has problems resulting in connectivity loss, requiring to switch to another one.
would be useful if there is an option to list multiple resolvers that checks if current resolver does not return expected result, switches to the next one and restarts service.
or at least an option for a secondary resolver. thanks

You use a cacher like Unbound and you run multiple dnscrypt-proxy processes on different ports.

Properly DNS load balancing / failover is completely different from what dnscrypt-proxy does.
As pointed out by licaon-kter, you should use something like Unbound or even edgedns for this kind of thing.

You can also run multiple instances of the proxy on different IP addresses, and use these different IPs in your operating system configuration.


[FR] Automatically capture reports from ./gradlew --profile on CI

Running ./gradlew --profile <task> locally is a super helpful way to diagnose slowness, but it seems to always output the nice HTML report to the build/reports/profile directory.
I'd like to add --profile to all my tasks on CI because profiling is pretty cheap and it's interesting to be able to click through and see whether there's low-hanging fruit.  Currently, I'd need to add a bunch of nasty lines of bash to copy these reports into the $CIRCLE_ARTIFACTS directory.
As an alternative, what do you think about making this gradle plugin detect the --profile flag and add it's own version of the ReportGeneratingProfileListener which writes to the $CIRCLE_ARTIFACTS directory?

Sounds cheap and smart. Definitely within the scope of this plugin. Only problem is develop is stuck on a blocked feature. Base your PR off the 1.x branch and I'll fix that independently.

Cool, can't promise a PR soon but glad you think this repo could be a good home for this feature :)

I would expect you to be able to configure the target directory with a single line of Gradle by the way, definitely check to see if that's possible before sinking time into the listener route (assuming you haven't already search and hit a blank).

Yeah I was really hoping there would be a one-liner to do that too, but my googling skills are apparently not good enough (and as far as I can tell, the build/reports/profile directory isn't configurable)

You just catapulted past the bar for becoming an admin on this repository, holy cow.


Refactor paging options

Refactor paging options to allow a literal object or a boolean. Basically going from a flat prefix based structure to a more structured one.

Codecov Report

Merging #464 into master will not change coverage.
The diff coverage is 82%.

@@           Coverage Diff           @@
##           master     #464   +/-   ##
=======================================
  Coverage   87.24%   87.24%
=======================================
  Files          37       37
  Lines        4381     4381
  Branches      353      353
=======================================
  Hits         3822     3822
  Misses        536      536
  Partials       23       23

Impacted Files
Coverage Δ

src/modules/rowsCounter.js
89.74% <100%> (ø)
:arrow_up:

src/tablefilter.js
91.83% <100%> (ø)
:arrow_up:

src/modules/paging.js
82.05% <81.63%> (ø)
: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 05f1c62...9858ac8. Read the comment docs.

Ignoring codecov patch 👍


Add FTP server as alternative for fuse

Original issue title: Add WebDAV server as alternative for fuse
Important: This is not about an WebDAV Backend.
I think the idea of using fuse to examine the backuped snapshots is great, but as some OS do not support fuse and somebody might not have enough rights to use fuse, it would be great to have an alternative.
My idea was to add a command to restic that instead of mounting the snapshots via fuse opens a local WebDAV server. As all major OS have a options to mount a WebDAV server, everybody would be able to mount the snapshots.
As I guess that it is easy to find a WebDAV serverlib for Go and you would use the same directory structure the fuse mount, it should not be too complicated to add this feature.

Good idea, although we need to investigate if it's really necessary to implement WebDAV, as opposed to e.g. ftp or plain HTTP.

Thanks. I also thought about HTTP and FTP, but the advantage of WebDAV would be, that you can mount it easily.

You can easily mount an ftp server on a recent Windows: http://www.thewindowsclub.com/map-an-ftp-drive-windows

Oh cool, I did not know that. Then a FTP server is the better solution.

Just my humble €0.02: Please don't use FTP. It's not a simple protocol. It's an old, legacy protocol that needs to die. Even if this is only for localhost connections - FTP doesn't even define how directory listings should look. And look, there is a nice WebDAV server library for Go right here: https://godoc.org/golang.org/x/net/webdav - Using WebDAV instead of plain HTTP gives instant integration into most file managers: Windows Explorer, Apple Finder, KDE, GNOME.

interesting, thanks for the comment

argh, wrong button, sorry.

I don't get the point.
Which major OS doesn't support FUSE?
BSDs, OS X, Linux, Windows... all of them have a FUSE driver..
(Windows for example https://github.com/dokan-dev/dokany)

Dokan is not the same as FUSE, it's a compatibility layer around libfuse (which we do not use), I've explained it here: https://github.com/restic/restic/issues/361#issuecomment-192162082

WebDAV on Windows is finicky but it does work (in a way which is compatible with everyone else too).  More important is that WebDAV gives a super-easy way to allow users to restore single files from snapshots with low setup overhead (i.e. rustic web --port :8080 and then collect the repository password per-session on a local network).

Please, take into account that WSL requires Hyper-V to work, but it cannot coexist with any other hypervisor software the user may already be using (like VirtualBox, etc). So, if someone is already using VirtualBox (or any another hypervisor), they will not be able to use WSL.
In summary, I think that WSL should not be taken for granted for every Windows user.

It might be worth looking at how Kopia does its mounting on Windows.  Looks like it does use webdav.

Having a second way to access the contents of the repo in a way similar to a file system becomes more important as the [source code for osxfuse is not available any more and the library we're using for fuse dropped support for macOS entirely.

I'm super keen for this – is there a way I can contribute monetarily and/or might someone be able to give me some mentoring for me to attempt adding this feature? :smile:

Well. Fuse works but in Windows it requires winfsp, that requires admin to install. Also there is the MacOS question that the library dropped support and the limitations of using WSL2 to workaround this.
Just for viewing stuff, WebDAV, or even plain HTTP, can solve this issue for people that are using Windows or MacOS. Maybe a route in the restic server?

I'd would really, really like to get this feature. It should rather be simple to somebody who knows Go, as there are webdav-server-implementation as libraries and there is already the mount command. It should nearly as simple as connecting these two code parts and write a command for it. I even tried to learn go to build this myself, but I did not get used to it.
Here are some things I could offer to give an incentive to somebody to write this feature: I would be willing to give 100 EUR to someone who builds this feature, or instead as I am a senior developer in Java and Kotlin and my NodeJS and Docker skills are also not bad, I would offer an developer exchange, so in exchange I would work twice the time you needed for this issue on your project, or the project of your choise.

I've banged together and locally tested another prototype of adding WebDAV support to the restic (as restic serve) as a fun exercise today. There's already another PR up which takes a similar approach but it looks like it hasn't made any progress for a while: https://github.com/wrouesnel/restic/tree/wrouesnel/add_support_for_webdav

https://github.com/wrouesnel/restic/tree/wrouesnel/add_support_for_webdav

I found a very old PR from you but none for this new prototype, is there any reason why you (seemingly) abandoned it? Because your new code seems straightforward and more importantly self-contained, so it has a decent chance of being accepted.
I have a pull request open (#4276) that allows to browse repositories in a web browser but there hasn't been much interest from maintainers. So I'd be interested in maybe finishing your work because perhaps WebDAV would gather more interest!

@ducalex It's open source so go for it! My use-case for WebDAV. I ran the build locally for a while but the system I was using it with no longer exists.


Add DCO documentation

Add DCO documentation

@jeffmaury i think I don't have rights to remove the existing DCO bot or i don't know where to find it. All yours :laughing:

@jeffmaury i think I don't have rights to remove the existing DCO bot or i don't know where to find it. All yours 😆

Done


Someone here password cursor state

@Julesssss  @eVoloshchak
Details

Added a checkbox native file that takes care of the events onMouseDown and onPress which seem to be causing this issue.
Fixed Issues

$ https://github.com/Expensify/App/issues/12018
PROPOSAL: https://github.com/Expensify/App/issues/12018#issuecomment-1314225656
Tests

Click on the password text input to bring it into focus
Enter some text
Press the show/hide button
The cursor stays in the same place
Repeat step 4 with the cursor in a few different places (beginning and middle of password)

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Click on the password text input to bring it into focus
Enter some text
Press the show/hide button
The cursor stays in the same place
Repeat step 4 with the cursor in a few different places (beginning and middle of password)

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The reviewer will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for expected offline behavior are in the Offline steps section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[ ] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] I verified that if a function's arguments changed that all usages have also been updated correctly
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://user-images.githubusercontent.com/77237602/204382808-cb89d361-1351-43b0-80e3-af41e1be1687.mov

Mobile Web - Chrome

https://user-images.githubusercontent.com/77237602/204382848-31a9d01c-d002-41ab-bc9b-3d4786861a77.mp4

Web - Safari

https://user-images.githubusercontent.com/77237602/204382997-d2e49e41-d809-4fe8-88be-7feb3d5e2cc9.mov

Desktop

https://user-images.githubusercontent.com/77237602/204383485-cf4b787b-d643-4329-9b0d-6372ac2bcfa5.mov

iOS

https://user-images.githubusercontent.com/77237602/204382973-d9b7d1a8-3cc6-409d-bdbb-f2c11d74e1d2.mov

Android

https://user-images.githubusercontent.com/77237602/204383161-c377747f-b805-406b-aa9d-afb93eba4ca0.mov

I think it went away because now we are no longer using inline functions...

Fixed the formatting now. 0 lint errors

Is this working as expected?

Now, finally it is fixed but I had to disable the eslint warning that forced me to make the breaking change before....

When testing for mWeb, please make sure that chrome it updated to the latest version 107 because there might be some internal issues in versions below 102/103

https://user-images.githubusercontent.com/9059945/205083817-38144e68-b13c-45de-a33e-1497c842b21f.mov
Bug in Chrome mWeb

Please check the chrome version https://github.com/Expensify/App/pull/13187#issuecomment-1332630654

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://user-images.githubusercontent.com/9059945/205088127-58d457f6-551d-473d-bc8d-46b1c5175f8a.mov

Mobile Web - Chrome

https://user-images.githubusercontent.com/9059945/205088330-7a309098-288b-48ff-ac9b-cafad355c116.mp4

Mobile Web - Safari
https://user-images.githubusercontent.com/9059945/205088163-a9af8343-0d94-488c-ba06-0b0789af519e.mov

Desktop
https://user-images.githubusercontent.com/9059945/205088211-9f3e29d5-d5df-4c43-a054-2ad65594876f.mov

iOS
https://user-images.githubusercontent.com/9059945/205088186-4e6289c7-7d31-4f42-aea0-be2a65984916.mov

Android
https://user-images.githubusercontent.com/9059945/205088289-c4ec7bdc-e09d-46c8-adaf-73351ce5cd9b.mp4

Is this PR now ready to merge?

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

@Julesssss and @eVoloshchak I want to thank you for being patient with me as I am new to this and you really helped me learn a lot about open-source and best practices for contributing.

@Julesssss and @eVoloshchak I want to thank you for being patient with me as I am new to this and you really helped me learn a lot about open-source and best practices for contributing.

Thank you for saying this!
And thank you for contributing and making the app better :)

And for this job, where can I apply to the upwork posting?

And for this job, where can I apply to the upwork posting?

https://www.upwork.com/jobs/~017777eb694223c27d

Oh, this is the same one as before. I have already sent a proposal to this job and updated the price as well.

Can we please fix the PR title to indicate the solved issue or summary of code changes?
@eVoloshchak Please make sure you check that.
cc: @Julesssss

🚀 Deployed to production by @francoisl in version: 1.2.36-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Fix "sides" option if using Duplex in lpoptions file

Remove Duplex option read from lpoptions file if "sides" is
specified on command line. Otherwise both options would be
present and "sides" would not override Duplex.
Test case:
Have a ~/.cups/lpoptions file containing a Duplex option like this:
$ cat ~/.cups/lpoptions
Default myprinter Duplex=None PageSize=A4
Print a document with more than one page on a printer supporting
duplex:
$ lpr -P myprinter -o sides=two-sided-long-edge test.pdf
Without this patch the document is not printed two-sided,
with this patch applied it is printed two-sided.

This isn't strictly the correct fix, as there are many PPD options that map to sides... Will consider for a future update.

Please report this to the OpenPrinting CUPS project.


Run timeout for Engine.Razor.Run[Compile]

I didn't found Timeout option for RunCompile/Run methods. Not present in configurator either. So Im a little bit in a pinch when it comes to running untrusted code, for example:
while(true){};
It will run forever.

Where exactly are you seeing this?

I see this when executing compiled (by razor) dll. For now Im just running it in separated thread and Abort() it to prevent further execution if it times out after one minute.

Do you have an example?

Create file example.cshtml with this content:
@
{
    while(true){};
}

And RunCompile it.

Yeh that'll break.
I'm not sure if the MS razor engine offers a timeout option.
But, surely all the code should be "trusted" you wouldn't be putting in random views into your code would you?

I stated, that this code will be untrusted - it means I give users rights to modify it. It is used for report generation, and I try not to protect code against hacker or malicious behaviors but from accidents when user made a bug and template will be stuck/overflowed/execute something bad, etc.

With a lack of anything here (or in the MS version).
You could write your own, using cancellation tokens? Or set your own timeout


Nested layouts not lockable

It is not possible to lock nested layouts with the w2layout.lock(...) command.
Demo: http://jsfiddle.net/3qys3wL2/

Seems to be a timing issue. It works if you lock the panel with a setTimeout().
I have also updated your fiddle to use the latest 1.5 sources.
http://jsfiddle.net/3qys3wL2/2/

If your issue is resolved, please close the thread.


Fix bug in polars parquet decoding handler

TL;DR
When trying to use flytekitplugins-polars I would get the error:
Message:
    Could not open Parquet input source '<Buffer>': Parquet file size is 0 bytes
User error.

Checking out the code, the PolarsDataFrameToParquetEncodingHandler actually places the parquet file at '{location}/00000', but it tries to read it at '{location}'
I think this is the easy solution, but maybe PolarsDataFrameToParquetEncodingHandler should be returning the '{location}/00000' instead of the parent directory?
Type

[x] Bug Fix
[ ] Feature
[ ] Plugin

Are all requirements met?

[ ] Code completed
[ ] Smoke tested
[ ] Unit tests added
[ ] Code documentation added
[ ] Any pending items have an associated Issue

could you update this test? To test the decoder, we should have a task that produces structured dataset, and pass it to the download stream task.

@pingsutw I'm not exactly sure what you mean by this.  But I added a very basic roundtrip style test, and I merged with master.
After looking at the code more closely, I believe that this current implementation is more in line with what was intended.  I also suspect that using pandas in the tests was unintentional (but i could be wrong), so I changed that (but it works either way)
Also, for the html representation of the data, I wonder if pl.DataFrame.repr_html might be a better fit?

thank you @danpf


Fixed #40646 - Duplicate Line Down is now Multi-Cursor Aware

This PR fixes https://github.com/Microsoft/vscode/issues/40646.
Having multiple cursors on the same line and copying them down will now result in a single line instead of multiple lines.
Copying Up:

Copying Down:

Thanks for considering this request.

Thanks for the response, I didn't think about those cases.
I'll look into making it work in all of those cases.

Closing for now. Please reopen if further work is done.


It's weird, I got (projectReflection instanceof Reflection) === false?

Search terms

serializer plugin
Expected Behavior

projectReflection instanceof Reflection to be true.
Actual Behavior

Steps to reproduce the bug

Environment

Typedoc version: latest
TypeScript version: 4.6
Node.js version: 16.8.0
OS: Windows

This is unactionable without a reproduction. However, I suspect the root cause is that you have multiple installations of TypeDoc.


Support rendering a cached JSON object at the top-level of a return

An easy way to test this is to add a method to Toolbox NewsController -
def first() {
  renderJSON(newsService.newsItems.first())
}

I just pushed an update to set cacheJSON to true on NewsItem.


Add rbpf/drand-tests. Move/Sui sha256

This includes a call to Sui implemented sha256.
Test is a part of rbpf tests, it is executed on VM and the results are compared with expected.

Closing this since it is superseded by #59


Provide full naming for VDB in "DataVirt: Create VDB" command name

What means VDB? Virtual Database?
[Here](This snapshot is in the form of a Virtual Database definition, or VDB.) I understand Virtual Database definition but it doesn't match the acronyms. So it is only a Virtual DataBase? and in our case we are creating a Virtual Database Definition?, so a VDB definition?
@lhein @rareddy ?

@apupier yes, it is "Virtual Database" a.k.a "VDB". Although it a definition of it we do not call "VDB Definition" it is just VDB.

UI naming proposals:

DataVirt: Create a VDB (Virtual Database definition)
DataVirt: Create a Virtual Database definition (VDB)

side note: maybe the prefix should not be DataVirt but Teiidfor all commands?

we should do prefix as just dv since we are not using the community name in the naming.

see #65


Enhance Code Usability

Change adding new Debug message behavior to only use a function to be easy to change the functionality of adding debug messages .

@hbattat Please Review the pr.


Everything with new badge should come to the top except instructor page

Wontfix because changes might degrade performance.