Introduce extension point for cell rendering.

Closes #5154.
This refactors the existing cell rendering code to make it extensible.
The current method DataTableCellUI._render has a lot of complexity and is already structured into different cases (null value, error value, simple data value and reconciled cell), so I thought it would be helpful to break down those four cases into distinct renderers registered via the newly introduced extension point. This has the benefit of decreasing the complexity of this DataTableCellUI._render method quite a bit.
One thing I am not very happy with is that the reconciled cells rely on a lot of methods of DataTableCellUI, and so the renderer for the reconciled cells must refer back to those methods in the callbacks it binds on the UI. For that to work I had to have DataTableCellUI pass a reference to itself to the render() method of the renderers. This is not very elegant, and I wonder if it would be possible to move those methods to the renderer itself instead.
In #5154 I mentioned that it would be good to add some possibility for extensions to store custom metadata in columns, but I have not done that yet. I think we could potentially do without, leaving extensions to store that metadata in either an overlay model (if they want changes to it to be versioned in the project history) or in the project preferences. For metadata that is actually bound to a column, storing that in those objects could work (by indexing it by the column name) but has the downside of not being resilient to column renames (and there is no extension point to run an action whenever a column is renamed, see #1577 which is superficially related).
I am marking this PR as draft given the unresolved design decisions above and welcome any feedback about the approach.
TODO:

[ ] document the extension point (and perhaps use this opportunity to list the intended extension points of the frontend, whatever that means in a context where you can modify any part of the DOM freely…)

I plan to merge this this week, with the intention of releasing it in 3.7-beta1, unless there are any concerns.

Thanks for having a look!
Concerning performance, I think the overhead is quite minimal here: the only significant change is the introduction of new javascript objects, which need to be explicitly iterated on to call their render methods, instead of having everything inlined in one big code block. The way the DOM is manipulated remains the same (okay, with the exception of an additional <div> wrapper, but that does not feel like a game changer). I could try benchmarking this on large grids, although I am not so familiar with benchmarking tools for frontend code.

Related to that and also your question about the callbacks, it seems like a lot of the stuff which is left in the previous module is reconciliation related and I wonder if it more appropriately should be co-located with the recon renderer.

Agreed.

Going back to the original request (custom thumbnails), it seems like that could be done using a decorator which adds to the existing renderer. Perhaps a getIcon/getThumbnail extension which returns an image to be used by the existing renderer. The ReconCellRenderer is pretty big (and will get bigger if the rest of the recon related stuff is pulled in), which makes me wonder how easy it'll be to extended in an incremental fashion. To implement the thumbnail rendering, you'd basically have to clone the base implementation.

That seems much more specific, it would be basically tailored to the only use case of implementing those thumbnails. I would feel a bit reluctant to introduce an extension point which is just designed for the use case I need right now.
By letting extensions define custom ways of rendering cells, we would allow for many other things:

Custom renderer for cells containing a string matching a given regular expression (for instance, EDTF date ranges could be rendered with a human-readable description of the date underneath them)
A spell-checker ( #3688)? Probably not so easy to look up the words efficiently though
A syntax highlighter for specific markup? (such as JSON?)
Rendering a column of numbers as a histogram (one bar per cell) for easier visualization of the quantities
Rendering booleans as checkboxes that the user can tick/untick to edit the cell (I think @antoine2711 was interested in something like that?)

I have made two moves (in one commit, sorry):

Use string-based identifiers to register renderers, letting extensions register their renderer before another one
Move all recon-related methods out of CellUI into the recon renderer, as suggested above.

I plan to merge this and release 3.7-beta1 soon after unless there are outstanding concerns.

Another use case I thought about while reviewing @tfmorris' Excel importer improvements: we could have conditional formatting support in OpenRefine, and this extension point would be quite suited for that. I am not saying this would necessarily have to be in an extension rather than in OpenRefine's core, but I feel like this adds another example of the suitability of the extension point for reasonably useful applications.

The corresponding documentation change is at: https://github.com/OpenRefine/openrefine.org/pull/163


[Fix] update docx in user guide

In Remove_data_from_cache.md, std::memcpy(handle->getMemory(), itr.first.data(), itr.second.size()); write the content of key to handle wrongly in Line72, we should write the content of value.

I also fix some confusing statements in Write_data_to_cache.md and Read_data_from_cache.md


Better date prompt description

#856  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @alanvardy and the rest of your teammates on  Graphite


Migration to new java-diff-utils organization

A code review due to the licensing issues is still required. (@koppor)

@koppor Due to https://issues.sonatype.org/browse/OSSRH-40817 my request was removed. Starting my request, I was not able to publish. Strange.

I am in contact with @wumpz to resolve this issue.


Upgrade Qt to 5.6

Qt 5.6 was released today http://blog.qt.io/blog/2016/03/16/qt-5-6-released/
Change log: https://wiki.qt.io/New_Features_in_Qt_5.6
This is a stub issue for referencing in future.
Check list:

[x] Linux
[x] OS X
[x] Windows

Cheers!

AFAIK Qt 5.6 removed QtWebkit support and migrated to chromium.

With Qt 5.6 the following modules are no longer part of the release packages, but users can still build them from source:

Qt WebKit

Qt WebEngine

Based on Chromium 45

@Vanuan that's not the problem. Updated WebKit is coming - https://github.com/annulen/webkit

Ah, so phantomjs would use WebKit directly?

@Vanuan kind of. We will maintain our own QtWebkit.

@Vanuan In fact there is a community release of QtWebKit 5.6:
http://download.qt.io/community_releases/5.6/5.6.0/

Am I correct in assuming this would fix the security issue that is blocking package acceptance in Debian?
https://security-tracker.debian.org/tracker/CVE-2013-4549

QXmlSimpleReader is not used in QtWebKit and PhantomJS, so I believe this CVE has no relation to PhantomJS

Does anyone know the process to have it removed from the CVE?

@elachlan Until there's a maintained QtWebkit that is keeping up with Webkit security advisories and PhantomJS can use both that and unmodified system-provided Qt, packaging it for Debian - or any other distro - is inappropriate.  I specifically told them a few months ago that they should drop the package altogether.  Maybe I should try to prod that process along.
Until that time, also, it's probably unsafe to use PhantomJS on untrusted content, especially on Windows.

Windows +

Landed in master

@Vitallium, I've just tried compiling @5d99f2a on Mac OS X (10.11.5) and Qt WebKit build fails with the following error message:
rm -f /Users/astefanu/Development/phantomjs-test/src/qt/qtbase/lib/libQt5WebKit.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar cq /Users/astefanu/Development/phantomjs-test/src/qt/qtbase/lib/libQt5WebKit.a
ar: no archive members specified
usage:  ar -d [-TLsv] archive file ...
	ar -m [-TLsv] archive file ...
	ar -m [-abiTLsv] position archive file ...
	ar -p [-TLsv] archive [file ...]
	ar -q [-cTLsv] archive file ...
	ar -r [-cuTLsv] archive file ...
	ar -r [-abciuTLsv] position archive file ...
	ar -t [-TLsv] archive [file ...]
	ar -x [-ouTLsv] archive [file ...]
make[2]: *** [/Users/astefanu/Development/phantomjs-test/src/qt/qtbase/lib/libQt5WebKit.a] Error 1
make[1]: *** [sub-api-pri-make_first-ordered] Error 2
make: *** [sub-Source-QtWebKit-pro-make_first-ordered] Error 2

ERROR: Failed to build PhantomJS! Building Qt WebKit failed.

I've opened Vitallium/qtwebkit#11 that fixes the issue.

By any chance, https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 will be used in PhantomJS?

@sowani by any chance - PhantomJS 2.5 is based on this fork ;-)

@Vitallium where is V2.5? I don't see it listed in releases?
https://github.com/ariya/phantomjs/releases
I'm suffering from issues with flexbox, blurring and broken webfonts (I believe this is Windows only) and I think this is due to the old Webkit version in V2.1

@phawxby See https://bitbucket.org/ariya/phantomjs/downloads/

What on earth is it doing there?

is there any tags to the source for the 2.5 build?
We have some custome PJS changes we make in-house and it would be good to be able to use a build that has tp5 in it.

https://github.com/Medium/phantomjs/pull/689
You can pull directly from my repo if you want although I would look at the pull conversation.
https://github.com/phawxby/phantomjs/pulls

What I really need is the source code as I have some custom additions I need to add so the binaries are useless for me.


Flex needs to understand baselines

From @abarth on June 14, 2015 17:51
In order to properly align text (e.g., in a horizontal RenderFlex), we need to understand the baseline.  RenderBox needs to understand baselines [hixie] and horizontal RenderFlex needs to use it for layout [jackson].
The test case is that StockRow should be baseline aligned.
@Hixie
Copied from original issue: domokit/mojo#244

From @collinjackson on July 6, 2015 17:29
Hixie finished the first part of this


Update use pages

I wanted to do a major rewrite of the usage pages.
I would like to add the following topics that I think should be here, based on questions I have frequently seen as issues on GitHub and my own experience.

[x] IDEs
[x] GUI
[x] Install R packages
[x] Bind mounts
[x] Proxy

Conversely, I thought it would be better to remove the following page as this is general Docker usage and not R-general specific.

managing_containers

The following page is related to RStudio Server or bind mounts, so the content has been moved to those pages.

managing_users

I would like to merge this and go ahead. Please let me know if there are any problems.


Initial start to reactor archetype

This PR includes some basic components to set up for a new facility archetype and an install script for the repository. I have modeled these off of the information on the Cyclus website (https://fuelcycle.org/arche/hello_world_py.html) and the d3ploy repository (https://github.com/arfc/d3ploy). The only functionality of the archetype right now is to print "Hello" and "world" at the beginning and each of each time step.
Additionally, I have included an example Cyclus input file to demonstrate how to call this library and archetype, and the functionality of the existing archetype.
If any name changes are requested, that just requires changing file names or class names.

@yardasol @munkm @nsryan2 bumping this PR.

@yardasol @samgdotson I have updated some of the documentation in the README to reflect the conversations. Let me know your thoughts.

Looks good to me


Does Official Build for C Work with CUDA 10?

Hi, I notice that there are options to use CUDA 10 or CUDA 9 when I build from source, so I was wondering if the official GPU build for C will work with CUDA 10?

YES.

I see. So the prebuilt binary is still with CUDA 9, is that correct?
If this is the case, it's there a future plan to also provide prebuilt binary with CUDA 10? Thanks.

Official binaries are built with cuda 9.1. See here https://github.com/Microsoft/onnxruntime#system-requirements.


Avoid MLIR default enablement in ROCm 5.0

On behalf of @junliume, @JehandadKhan and @jerryyin :
Proposed actions:

[x] (1) Promote develop to amd-develop (as usual), but do NOT send email about promotion of MIOpen Staging to CQE et al. yet
[x] (2) Then, immediately: Rebase "[MLIR] Removing MLIR dependency requirement until ROCm 5.1" #1298 to amd-develop, and commit.

(2.1) Actually done by merging of 95b58f72f "Removing MLIR dependency requirement until ROCm 5.1" into amd-develop directly.

(2.1.1) Side effect: Dependency on MLIR library will persist in 5.0 in spite of that it is not really needed.

[x] (3) Now send notification mail about promotion of MIOpen Staging

(3.1) Done, amd-develop 95b58f72f
...

[ ] Immediately after 5.0 release branch is cut: Revert #1298 in amd-develop.

Due to (2.1) should be done done by reverting the 95b58f72f in amd-develop.

Reasoning and discussion: See the "MLIR default enablement in ROCm 5.0" mail thread.

95b58f7 reverted in amd-develop by ebaaf3ebd Revert "Removing MLIR dependency requirement until ROCm 5.1"


Allow Manual Additions to a Imported List

generic case of #15/similar to #4, allow manual input to supplement a pre-populated list from an import

fixed by #24


⚠ Samsung has degraded performance

In 585e7ef, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 6715 ms

Resolved: Samsung performance has improved in e2259cf.


iox-#1103 Add discovery monitoring examples

Signed-off-by: Matthias Killat<EMAIL_ADDRESS>Pre-Review Checklist for the PR Author

[ ] Code follows the coding style of CONTRIBUTING.md
[ ] Tests follow the best practice for testing
[ ] Changelog updated in the unreleased section including API breaking changes
[ ] Branch follows the naming format (iox-#123-this-is-a-branch)
[ ] Commits messages are according to this guideline

[ ] Commit messages have the issue ID (iox-#123 commit text)
[ ] Commit messages are signed (git commit -s)
[ ] Commit author matches Eclipse Contributor Agreement (and ECA is signed)

[ ] Update the PR title

Follow the same conventions as for commit messages
Link to the relevant issue

[ ] Relevant issues are linked
[ ] Add sensible notes for the reviewer
[ ] All checks have passed (except task-list-completed)
[ ] Assign PR to reviewer

Notes for Reviewer

Checklist for the PR Reviewer

[ ] Commits are properly organized and messages are according to the guideline
[ ] Code according to our coding style and naming conventions
[ ] Unit tests have been written for new behavior

[ ] Each unit test case has a unique UUID

[ ] Public API changes are documented via doxygen
[ ] Copyright owner are updated in the changed files
[ ] PR title describes the changes

Post-review Checklist for the PR Author

[ ] All open points are addressed and tracked via issues

References

Closes TBD

This is a proposal for a possible service discovery API usage with listener and waitset. The user can basically build her own discovery but there are certain limitations.
API comments and use case suggestions are welcome but it is too early for coding style remarks as it is WIP.

This example needs to be added to the Readme.

@elfenpiff Can be reviewed, readme will be written when the code is agreed upon.

Please check if we have to remove code examples for the removed findService method from the `iceoryx-v2-0-0.md as mentioned here.

@FerdinandSpitzschnueffler @dkroenke Ready for review


Fix script permissions

Description

Release required?

[ ] No release
[x] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

When merging, use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author. The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).
Merge by using "Squash and merge".

/run pipeline

:tada: This PR is included in version 1.21.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Enhancement] modify mv maintenance interface

What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Modify the state of binlog scan range of StartEpochTask and ReportEpochTask
Update the binlog consumption state in reportEpoch interface

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto backported to target branch

[ ] 2.5
[ ] 2.4
[ ] 2.3
[ ] 2.2

@Mergifyio rebase

run starrocks_admit_test

[FE PR Coverage Check]
:disappointed: fail : 0 / 43 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/scheduler/mv/MVManager.java
0
11
00.00%
[187, 188, 189, 190, 192, 193, 194, 196, 197, 198, 199]

:large_blue_circle:
com/starrocks/scheduler/mv/MVMaintenanceJob.java
0
2
00.00%
[293, 404]

:large_blue_circle:
com/starrocks/scheduler/mv/TxnBasedEpochCoordinator.java
0
1
00.00%
[163]

:large_blue_circle:
com/starrocks/scheduler/mv/MVMaintenanceTask.java
0
29
00.00%
[55, 129, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 154, 155, 156, 157, 159, 160, 161, 163, 164]

@Mergifyio rebase

[FE PR Coverage Check]
:disappointed: fail : 0 / 43 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/scheduler/mv/MVManager.java
0
11
00.00%
[187, 188, 189, 190, 192, 193, 194, 196, 197, 198, 199]

:large_blue_circle:
com/starrocks/scheduler/mv/MVMaintenanceJob.java
0
2
00.00%
[293, 404]

:large_blue_circle:
com/starrocks/scheduler/mv/TxnBasedEpochCoordinator.java
0
1
00.00%
[163]

:large_blue_circle:
com/starrocks/scheduler/mv/MVMaintenanceTask.java
0
29
00.00%
[55, 129, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 154, 155, 156, 157, 159, 160, 161, 163, 164]

run starrocks_admit_test

run starrocks_admit_test

run starrocks_admit_test

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 0 / 47 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/scheduler/mv/MVManager.java
0
11
00.00%
[187, 188, 189, 190, 192, 193, 194, 196, 197, 198, 199]

:large_blue_circle:
com/starrocks/scheduler/mv/MVMaintenanceJob.java
0
4
00.00%
[286, 329, 397, 409]

:large_blue_circle:
com/starrocks/scheduler/mv/TxnBasedEpochCoordinator.java
0
2
00.00%
[157, 164]

:large_blue_circle:
com/starrocks/scheduler/mv/MVMaintenanceTask.java
0
30
00.00%
[55, 72, 130, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 155, 156, 157, 158, 160, 161, 162, 164, 165]

run starrocks_admit_test

run starrocks_admit_test


update istio and remove kfserving

Description of your changes:

Upstream is using istio 1-14 and kfserving has been removed
Verified that cognito/rds-s3/sanity-check and manifests installation all pass

Testing:

[ ] Unit tests pass
[ ] e2e tests pass
Details about new tests (If this PR adds a new feature)
Details about any manual tests performed

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Changes look ok but could you please add some details on tests run.

Didn't save the test logs, but have verified that they are passing. This pr in particular is mostly concerned with getting our kustomization files to point to the correct paths upstream.

Also change the version in main readme badge, test constant, prerequisites to point to the right upstream versions

updatd the test constants. Not sure what you mean by main readme badge. Waiting on pointing pre-reqs to upstream since they are still tagged as rc version and we don't have an aws release either.


PoC for activation manager

This can activate extensions using the custom x-onAzNodeTypeFetch and x-onAzNodeTypeResolve activation events.
This can support having multiple extensions listening to the same type, and also handles extension enable/disable/install/uninstall gracefully.

Closing in favor of #117


Attached xlsx file cannot be opened by Excel

Expected behavior
Attached xlsx file should be opened by Excel
Actual behavior
Excel refuse to open the file and tells the user that the file is invalid.
Workaround
Either use another email client (GMail for example) or save the file on the device storage and open it later with Excel
Steps to reproduce

Open the mail
Display attached file
Download complete message
Open the attached xlsx file

Environment
K-9 Mail version: 5.010
Android version:
Android 6.01
Samsung S6+ Edge / Sony Z3
Account type (IMAP, POP3, WebDAV/Exchange):
IMAP (Kerio Connect server)

Is this reproducible with different XSLX files or is it only a specific file. I don't have Excel right now so I can't test it. It seems very odd that it would only occur with a specific file extension.

Probably fixed by #1769 ?

Nope actually, since this was reported for version 5.010

I tested this and it works for me. Since the file could be opened after download with another client: could this be a wrongly declared mime-type?
@stephanewierzbicki Can you reproduce this with other XLSX files? And can you attach a minimal example of a not-working file? What client was used to send the file? Are you able to post the mime-type from the source code of the not-working email?
Mine was sent as
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;

I have the same issue and can reproduce this with many file types including PDF. The affected PDF is attached (it is a public random pick) and the email source is also attached.
I am using the current alpha release. File comes via IMAP.
I can specify the problem as follows: Opening the attachment in K9 fails (invalid PDF file, with every receiving app). Saving it with K9 and then clicking on the download notification and opening it, also fails with the same error. BUT:
Opening the same file with ES file explorer from the download folder succeeds.
I further verified, that the file is not broken. Therefore I downloaded the from the same IMAP source with thunderbird. Then compared both of them with checksums. They are the same.
So the file attachment is healthy but the sharing with another intent, seems to indicate a wrong mimetype or anything else like that.
failingpdfatttachment.zip

New alpha out today, please check if the issue persists. Also, what pdf reader do you use? Adobe worked fine for me

Problem fixed in latest alpha release. Thanks.
Of course it would be good to know, what the problem was (eg. which commit actually fixed it).
I used many different readers including adobe and the one from google drive. All with the same result.

It was fixed in #1769

Problems occurs again.
Now I can't open any office documents : word or excel application are telling me that "file cannot be opened".
I don't have this issue if I use the bundled email client (in my case Samsung mail reader).

Still applies in the last published version from Play Store.

The issue always occurs when attachment is identified as application/octet-stream mime type and as result file cannot be determined using Uri for example, having:
content://com.fsck.k9.tempfileprovider/temp/3ac760f5a0812097540d90237f3dffb9b715f2d2?mime_type=application%2Foctet-stream
it is impossible to get file name using OpenableColumns.
Are there any plans to solve this bug ?

Thanks for looking into why this happens @tomgozdek.
If we were/are losing the MIME type which is provided in the attachment then that would be a bug obviously.
Given we have the file extension we could guess what the mime-type should be and set it properly.
Making K-9 try to do best-effort file-extension/MIME-type decoding itself is somewhat annoying.


Upgrade PicketBox to 4.9.0.Final

Linux Build 1809 is now running using a merge of da976bed9cad8f560d5f11eaaf82fe39e94717f1

Core - Full Integration Build 958 is now running using a merge of da976bed9cad8f560d5f11eaaf82fe39e94717f1

Windows Build 1364 is now running using a merge of da976bed9cad8f560d5f11eaaf82fe39e94717f1

Windows Build 1364 outcome was SUCCESS using a merge of da976bed9cad8f560d5f11eaaf82fe39e94717f1
Summary: Tests passed: 3105, ignored: 69 Build time: 0:21:04

Linux Build 1809 outcome was SUCCESS using a merge of da976bed9cad8f560d5f11eaaf82fe39e94717f1
Summary: Tests passed: 3105, ignored: 69 Build time: 0:22:51

Core - Full Integration Build 958 outcome was FAILURE using a merge of da976bed9cad8f560d5f11eaaf82fe39e94717f1
Summary: Tests failed: 1 (1 new), passed: 2843, ignored: 375, muted: 1 Build time: 0:50:51
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.integration.ejb.remote.distinctname.JarDeploymentDistinctNameTestCase.testRemoteSLSBInvocation: <no details avaliable>


MSVC 22: 'Bit' Undefined in Codec_Choose.c Line 222  with HAVE_AVX512 defined

I am getting the following error when compiling with AVX512 support enabled. I have tested this under an i9-10920X and Intel Xeon 8272CL processor. If I disable AVX512 the project will compile.
Severity	Code	Description	Project	File	Line	Suppression State	Details
Error	C4013	'bit' undefined; assuming extern returning int	base64	C:\source\libs\base64\lib\codec_choose.c	222

Fixed by #145.


Inline request migration defaults name

When migrating to inline request we should default the name to something like <PLACEHOLDER_NAME_CHANGE_ME>. This makes it obvious where name should go whereas currently it is hard to figure out.
fern check should still fail on the placeholder names because we don't want anyone to run fern generate and use the place holders in their SDKs/docs.

makes sense, easy thing is to make the placeholder invalid so we don't have to hardcode the placeholder in the validator

this migration is pretty old now, no longer relevant


feat: Add storage delete command

Proposed changes
Add storage delete command.
❯ saucectl storage delete -h
Delete a file from Sauce Storage.

Usage:
  saucectl storage delete <fileID> [flags]

Flags:
  -h, --help   help for delete

Global Flags:
      --disable-usage-metrics   Disable usage metrics collection.
      --no-color                disable colorized output
  -r, --region string           The Sauce Labs region. Options: us-west-1, eu-central-1. (default "us-west-1")
      --verbose                 turn on verbose logging

Oops. Triggered some keyboard shortcuts and assigned myself 😂


Hey folks,

Can we have any apps to refer the video feed in video calls? Is there any available apps that has used the feature?
Cheers,
Upulie.

Duplicate of this
closing this.


Visualise provisioned Agents cost

Dependencies

Feature Request

As a user, I want a way to visualize the cost of Agents provisioned:

By type (Cloud, SSH, JNLP, ...)
By Cloud provider
By Cloud VM type
By job
By job+build

related to https://github.com/jenkinsci/opentelemetry-plugin/issues/57


Call NoSleep from within a user input event handler

noSleep.enable() "must be wrapped in a user input event handler e.g. a mouse or touch handler" in order to work.
It was not working properly on some older Android 4.1 devices because it was called inside on onLoad().
This will fix it

Thank you!


Add range queries

Add range queries to Db and DbInner. I'm thinking we'll copy RocksDB's interface, which has a db.iter() and iter.seek() API.
At a high level, I think this work involves a few things:

Creating a snapshot manager that creates, updates, and deletes snapshots from the manifest.
Cloning the current DB state, including the memtables and wal data structures. This will be needed for the iterator, so it has a consistent point in time to iterate over all data (both in-memory and on disk/obj storage). I'm thinking this might be included as part of the snapshot manager (i.e. each snapshot in the manager will be a full Db with a state at a point in time).
Creating a user-facing DbIterator that merges the wal, memtable, and L0+ SSTs into a single iterator similar to MergeIterator. We might be able to use MergeIterator directly, I need to check. This iterator interface should have a seek() method.
Update the Db object to have a .iterator() method that returns a DbIterator.

For (3), I suspect if we use MergeIterator, we'll need a DbMergeIterator (similar to TwoMergeIterator) that takes iterators for wals, memtables, and SSTs (because of the Rust typing issue mentioned here
I don't plan to tackle prev() in this issue.

@paulgb Pulled you from this one since it's been a few months. LMK if you want to pick it back up.

At a high level, I think this work involves a few things:

Creating a snapshot manager that creates, updates, and deletes snapshots from the manifest.
Cloning the current DB state, including the memtables and wal data structures. This will be needed for the iterator, so it has a consistent point in time to iterate over all data (both in-memory and on disk/obj storage).
Creating a user-facing DbIterator that merges the wal, memtable, and L0+ SSTs into a single iterator similar to MergeIterator. We might be able to use MergeIterator directly, I need to check. This iterator interface should have a seek() method.
Update the Db object to have a .iterator() method that returns a DbIterator.

For (3), I suspect if we use MergeIterator, we'll need a DbMergeIterator (similar to TwoMergeIterator) that takes iterators for wals, memtables, and SSTs (because of the Rust typing issue mentioned here
I don't plan to tackle prev() in this issue.

DoubleEndedIterator would be nice so you can iterate through the range in either direction!

Fixed in:
https://github.com/slatedb/slatedb/pull/342

Closing since #342 is merged.


Handle missing default branch better in owner/repo/branches page

This PR more nicely handles a missing default branch in owner/repo/branches
Fix #18265
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@4d0a72a). Click here to learn what that means.
The diff coverage is 59.25%.

@@           Coverage Diff           @@
##             main   #18290   +/-   ##
=======================================
  Coverage        ?   45.76%
=======================================
  Files           ?      831
  Lines           ?    92181
  Branches        ?        0
=======================================
  Hits            ?    42186
  Misses          ?    43238
  Partials        ?     6757

Impacted Files
Coverage Δ

routers/web/repo/branch.go
57.91% <59.25%> (ø)

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 4d0a72a...8febb4b. Read the comment docs.


warn against automatically using nightly features

See https://github.com/tkaitchuck/aHash/issues/200 for an issue caused by using version_check::supports_feature without considering the consequences.
IMO supports_feature should be removed entirely, but maybe there are ways to use it that are not as fragile?

is_feature_flaggable is harmful as well. Though it's probably more useful to not delete it but keep it and deprecate it saying "DONT DO THIS, use a feature flag". That will be more effective at deterring people.

@Nilstrieb A feature flag does not solve the same problem and hence is not a viable replacement.

Using supports_feature is also not a viable replacement for anything. Rustc devs are actively discouraging this pattern since it can and will cause wide-spread build breakage. This breakage will incorrectly be blamed on rustc (when it's really crates using nightly detection that are to blame). We'd strongly prefer if we didn't have to try and use technical means to prevent such issues.

Perhaps a feature could have a version. If that could be accessed through cfg conditionals, there would not need to be any features or risk of incompatibility .

I agree that we should include more verbiage with respect to how this crate can be used in a less error-prone fashion.
On the broader subject, I believe there are two threads to consider:

The responsibility of a crate author using nightly features (the dependency).
The responsibility of a user depending on a crate that may or may not use nightly features (the dependent).

The argument pushed forward by this PR and by the comment in https://github.com/tkaitchuck/aHash/issues/200#issuecomment-1928961077 is that the dependent should be responsible for opting-in to potential nightly breakage via a feature flag or similar. While I believe this is a fair recommendation, I also believe that this "opting-in" is already happening as a result of a nightly compiler being used, and that a second opting-in should be viewed as redundant.
By their very nature, nightly compilers are expected to break. It shouldn't be seen as catastrophic when something does break. We shouldn't normalize using a nightly compiler or try to make it seem as stable as stable. I fear that this PR and the aforementioned recommendation perpetuates that sentiment, however.
Finally, I believe the dependency should have the responsibility of staying on top of nightly releases, should they wish to use nightly features, and by doing so, decrease significantly or entirely eliminate any kind of breakage. This is the approach we took with Rocket early on and one we continue to take. It's a large responsibility, but it's attenuated by 1) the ability for users to roll-back to a "good" nightly release, and 2) the fact that not everyone updates their nightly toolchain immediately. In some ideal word, rustc and/or cargo would alleviate this burden, but alas that is not the current world.
To summarize, I agree that we should add a word of warning to this crate's documentation, but my feeling is that that wording should be a bit more conservative that the proposed.

As someone who uses nightly compilers a lot, I generally expect that cargo +stable build and cargo +nightly build will build the same code, just with slightly different compilers. That is an extremely viable property, e.g. when determining whether there was a regression in the compiler
So I must disagree here, using nightly is not an opt-in using potentially breaking features. If that were true, we wouldn't bother with all these feature attributes, we'd just enable them all automatically on nightly!
I also think historically this is pretty clear: the opt-in to a potential breakage is the #[feature] attribute. Furthermore, that opt-in is only available on nightly. But using nightly itself doesn't opt-in to anything, it merely provides the ability to opt-in.
Interpreting the use of nightly as opt-in is a risk for nightly rustc development since we can no longer easily test how a crate will behave when this compiler turns stable. That's exactly why rustc developers are so concerned, and why https://github.com/rust-lang/rust/issues/120804 exists.

As someone who uses nightly compilers a lot, I generally expect that cargo +stable build and cargo +nightly build will build the same code, just with slightly different compilers. That is an extremely viable property, e.g. when determining whether there was a regression in the compiler.

I also use nightly almost exclusively and yet I don't have the same expectation. I generally expect that the compilers will build the same code, but I expect nearly 100% reliability from a stable compiler whereas I don't have the same expectation from a nightly compiler. Unfortunately it doesn't seem that any documentation anywhere defines what the user's expectations of each channel should be. I base my expectations on my own experience: ICEs and random compilation bugs happen with nightly with significant more frequency than stable. As a result, I don't trust it nearly as much.

So I must disagree here, using nightly is not an opt-in inviting rustc to just use potentially breaking features in whatever way it pleases. If that were true, we wouldn't bother with all these feature attributes, we'd just enable them all automatically on nightly!
I also think historically this is pretty clear: the opt-in to a potential breakage is the #[feature] attribute. Furthermore, that opt-in is only available on nightly. But using nightly itself doesn't opt-in to anything, it merely provides the ability to opt-in. It is only when crates started to become too clever in what they do in their build scripts, that this stopped working.

I think this is a good argument, and I think it would be an even stronger argument if feature was infectious in some sense, any sense. That would also absolve crate author's of the burden of abusing Cargo features for this purpose.
It should also be mentioned that there are numerous differences in nightly that, for one reason or another, aren't or can't be behind feature flags. These represent core differences between the channels that have no further means to opting in. Ultimately, this leads to work-arounds of this nature which would otherwise have no utility.

Interpreting the use of nightly as opt-in is a risk for nightly rustc development since we can no longer easily test how a crate will behave when this compiler turns stable, and we can no longer change nightly features without risking making some crates that work fine on stable entirely impossible to build on nightly, thus severely impacting the usability of nightly compilers.

The beta channel seems to have been forgotten here as it was at least initially suggested for exactly this use-case.

If a crate wouldn't build on stable at all, then obviously none of this matters, but we're talking about crates that are ostensibly relying only on stable Rust, but then when I switch to nightly e.g. to use some -Z flag, suddenly they enable more functionality, thus changing their behavior (always fun during debugging) or they even fail to build -- that's bad. That's exactly why rustc developers are so concerned, and why rust-lang/rust#120804 exists.

I understand, but as we've covered, I feel that you're absolving the user from any responsibility involved with the switch to nightly. Their code could well stop building as a result of a change in the nightly compiler that has nothing to do with unstable features. In fact, there are dozens of issues reporting such breakage in the last couple of weeks. What is the analogous argument but to suggest that one shouldn't use the nightly channel, or minimally, the affected nightly version?
I should clarify that I am not against adding a word of caution to this crate's documentation, and I am in the process of doing so, only that it shouldn't bias so much in any one direction.

Pushed a variant of this in https://github.com/SergioBenitez/version_check/commit/f4284aff45d7e128aa5d9f3483ef5ec1cd575a75.

I also use nightly almost exclusively and yet I don't have the same expectation. I generally expect that the compilers will build the same code, but I expect nearly 100% reliability from a stable compiler whereas I don't have the same expectation from a nightly compiler. Unfortunately it doesn't seem that any documentation anywhere defines what the user's expectations of each channel should be. I base my expectations on my own experience: ICEs and random compilation bugs happen with nightly with significant more frequency than stable. As a result, I don't trust it nearly as much.

Yes, nightly has more compiler bugs. It exists as a testbed for the compiler. But it was never intended to be a testbed for ostensibly stable crates to silently enable more functionality. This is something crate authors started doing, and some individuals on the compiler team are not happy about that since it interferes with the original role of nightly.
Incidents like the one with ahash make it noticeably harder to find and weed out these bugs in nightly before they hit beta and then stable. That's why we should push back hard against crates doing things like that. Some crates use a more sophisticated approach where they actually build a bit of demo code that uses the feature, and then only enable the feature if the demo code builds -- that has the big advantage that if the feature changes in ways that break the demo code, the crate keeps building. It is still problematic IMO, but it is much better than a crate just blindly enabling a nightly feature without any check whether that feature works the way it should. The latter is something that IMO should never be done.

It should also be mentioned that there are numerous differences in nightly that, for one reason or another, aren't or can't be behind feature flags. These represent core differences between the channels that have no further means to opting in. Ultimately, this leads to work-arounds of https://github.com/rust-lang/rust/issues/120804#issuecomment-1936604648 which would otherwise have no utility.

I think you misunderstood the work-around proposed there -- that proposal is intended to deal with code that uses functions like version_check::supports_features, by forcing it to always return "no, not supported". It is the hammer we wouldn't need if boot scripts wouldn't try to be more clever than is good for the ecosystem. I'd rather not enter a game of whack-a-mole with crate authors where the compiler gets increasingly clever at tricking crates into not realizing that they are running on nightly, and then crate authors find creative ways to detect the presence of nightly anyway.

The beta channel seems to have been forgotten here as it was at least initially suggested for exactly this use-case.

The beta channel is great, but when working on compiler features, if it takes 6 weeks until I can even test whether my code breaks anything that works on stable, that's really bad.

I understand, but as we've covered, I feel that you're absolving the user from any responsibility involved with the switch to nightly. Their code could well stop building as a result of a change in the nightly compiler that has nothing to do with unstable features. In fact, there are dozens of issues reporting such breakage in the last couple of weeks. What is the analogous argument but to suggest that one shouldn't use the nightly channel, or minimally, the affected nightly version?

Crates that use version_check::supports_features make it harder for compiler devs to find and fix these issues. This isn't about the responsibility of users, it is about compiler dev's ability to develop the compiler.
I don't understand what kind of analogy you are trying to make here. It should be the case that if a crate builds on stable and doesn't build on nightly, that's a compiler bug (or an expected breakage, which is rare but happens). Bugs happen, obviously. They are not the user's responsibility. But crates that use version_check::supports_features make it so that if a crate builds on stable and doesn't build on nightly, that's now sometimes not a compiler bug, throwing a wrench into Rust's nightly feature development story.
Just look at the amount of backlinks in https://github.com/tkaitchuck/aHash/issues/200. If that amount of fallout can arise from a nightly-only change not observable on stable, then something is wrong. This is not healthy. And the root of the problem is crates automatically enabling nightly features without even testing whether they work. That should be considered an anti-pattern and not acceptable to occur in any crate. Whether build probes are acceptable is still somewhat open, the compiler team is of split mind here.
Thank you for adding some cautionary wording. I worry it might not be strong enough to dissuade people from using these functions, given that the crate provides no build probe functionality, so it's much harder to do that. Maybe it'd be worth linking to https://github.com/cuviper/autocfg which provides a way to fairly easily write such build probes?


empty

Codecov Report

Merging #168 (5a1aad7) into main (3630ebd) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main     #168   +/-   ##
=========================================
  Coverage     90.40%   90.40%
  Complexity      542      542
=========================================
  Files            94       94
  Lines          1657     1657
  Branches        111      111
=========================================
  Hits           1498     1498
  Misses          143      143
  Partials         16       16

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 9891db7...5a1aad7. Read the comment docs.


[ENH] Improve proba metrics

Reference Issues/PRs
Continues #2153.
What does this implement/fix? Explain your changes.
Fixes functionality and general tidyup of changes made in #2153.
Does your contribution introduce a new dependency? If yes, which one?
No

@fkiraly I still need to improve the tests for the proba metrics. Are there any forecasters that implement predict_quantile or predict_interval for a multioutput case?

@fkiraly I still need to improve the tests for the proba metrics. Are there any forecasters that implement predict_quantile or predict_interval for a multioutput case?

Currently none, I think.


Handle file touched events

Description
This PR makes the search provider listen and react to FileTouched events.
Related Issue

Fixes https://github.com/owncloud/ocis/issues/3154

:boom: Acceptance test Core-API-Tests-ocis-storage-1 failed. Further test are cancelled...


Currencies - SEK, NOK

User has requested following

Swedish Krona https://en.wikipedia.org/wiki/Swedish_krona
Norwegian Krone https://en.wikipedia.org/wiki/Norwegian_krone

Config
These are the settings I'm adding:

{ code: "NOK", symbol: "kr", name: "Norwegian krone", flag: "🇳🇴" }
{ code: "SEK", symbol: "kr", name: "Swedish krona", flag: "🇸🇪" }

Rates
Sample rates from today (Nov 3) to show consistency we will have
NOK

free-currency-rates-usd: 11.17113765
https://github.com/fawazahmed0/currency-api/blob/1/latest/currencies/usd/nok.json
currency-beacon: 11.07383276
https://api.currencybeacon.com/v1/latest?base=USD&symbols=NOK&api_key=

SEK

free-currency-rates-usd: 11.06999857
https://github.com/fawazahmed0/currency-api/blob/1/latest/currencies/usd/sek.json
currency-beacon: 10.92210246
https://api.currencybeacon.com/v1/latest?base=USD&symbols=SEK&api_key=


Add a comparison between j5, existing APIs and ROS

Fixes #271

Overriding so I can post this to people after yesterday's meeting


Add Apache v2.0 license

https://github.com/ansible/awx is Apache 2 licensed as well as the python client. The ruby client is MIT licensed.

I think the copyright header is a good thing. I remember that, long time ago, when I did some Fedora packaging work, one of the things I had to do for each source file of each package was check the license statement. The presence of that copyright header simplified that a lot: if the file doesn't have a copyright header then you have to go and guess what is the license of that source, which is error prone.
In addition the copyright date doesn't need to change. If you say Copyright 2018 then you don't need to update it to Copyright 2019 next year: it is understood that the copyright applies since 2018 on.
But, I am not a lawyer.

OK will add headers, thanks.

I see all the files already have headers. I think this one is ready to go.

@jhernand we merge this right?

Yes, please.


Error: listen tcp <IP_ADDRESS>:11434 in windows

I get this error in Windows  ollama preview when I try to run "ollama serve."
Error: listen tcp <IP_ADDRESS>:11434: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Ok, I think I got it.
Ollama is already running in the background as a server in Windows at: http://localhost:11434.
Just put that address in your browser, and you'll see

Thanks,brother

Thanks,brother

I got this problem. How do you exit Ollama?

So I exited Ollama from the taskbar, and "http://localhost:11434/" was no longer reachable with the message: "Ollama is running". So it's off. Then I opened it with my command prompt with "C:\Users\hinso>ollama serve", and I got this output:
time=2024-04-05T07:13:53.844-05:00 level=INFO source=images.go:804 msg="total blobs: 6"
time=2024-04-05T07:13:53.851-05:00 level=INFO source=images.go:811 msg="total unused blobs removed: 0"
time=2024-04-05T07:13:53.852-05:00 level=INFO source=routes.go:1118 msg="Listening on <IP_ADDRESS>:11434 (version 0.1.30)"
time=2024-04-05T07:13:53.881-05:00 level=INFO source=payload_common.go:113 msg="Extracting dynamic libraries to C:\Users\hinso\AppData\Local\Temp\ollama1623166627\runners ..."
time=2024-04-05T07:13:54.024-05:00 level=INFO source=payload_common.go:140 msg="Dynamic LLM libraries [cpu_avx cpu rocm_v5.7 cpu_avx2 cuda_v11.3]"
[GIN] 2024/04/05 - 07:14:08 | 200 |            0s |       <IP_ADDRESS> | GET      "/"
I checked the taskbar. Ollama isn't open there, but "http://localhost:11434/" is available again saying, "Ollama is running". I just want to get back to where I was chatting with it in my command prompt. I can't seem to get back there. I closed the command prompt because I thought that I could reopen it without a model loaded. I was trying to install something for Comyui.


FIX - broken links in the README

This updates the links pointing to documentation, after #619.
Also, it fixes the format
Checks before merging PR

[ ] ~added documentation for any new feature~
[ ] ~added unit test~
[ ] ~edited the what's new (if applicable)~

Codecov Report

Merging #628 (70d3aea) into main (b15dc03) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #628   +/-   ##
=======================================
  Coverage   55.09%   55.09%
=======================================
  Files          44       44
  Lines        2855     2855
  Branches      525      525
=======================================
  Hits         1573     1573
  Misses       1165     1165
  Partials      117      117


Allow passing severityLevel in trackException

#170

Do you have autocollected exceptions? If yes, do you want to set SeverityLevel for them?..
:shipit:

:shipit:

@abaranch Good point, but I don't want to change the current behavior.

@kamilszostak but that would be consistent with Web SDK where we set it...


Could Lucene's default Directory (FSDirectory.open) somehow preload .vec files?

Description
This is really a "discussion" issue.  I'm not sure at all that the idea is feasible:
I've been testing luceneutil with heavy KNN indexing (Cohere wikipedia en 768 dimension vectors) and one dismal part of the experience is the swap storm caused by HNSW's random access to the raw vectors stored in the .vec files for each segment on "cold start" searching.
Even when the box has plenty of RAM to hold all .vec files, the swap storm takes minutes on the nightly benchy box, even with a fast NVMe SSD holding the index.  Even if the index is freshly built, the OS doesn't seem to cache the .vec files since they appear to be "write once", until the searching starts up, and then the swap storm begins.  This was with FLOAT32 vectors ... I suspect the problem is less severe with int4 or int8 compressed vectors (haven't tested).
At Amazon (customer facing product search) we also see this swap storm when cold starting the searching process even after NRT segment replication has just copied the files locally: they don't stay "hot" in the OS in that case either (looks like "write once" to the OS).
Lucene already has an awesome feature to "fix" this:MMapDirectory.setPreload.  It will pre-touch all pages associated with that file on open, so the OS caches them "once" on startup, much more efficiently than the random access HNSW.  But this only makes sense for applications/users that know they have enough RAM (we will test this at Amazon to see if it helps our cold start problems).  For my luceneutil tests, simply cat /path/to/index/*.vec >> /dev/null (basically the same as .setPreload I think) fixed/sidestepped the swap storm.
(The Linux kernel's less aggressive default readahead for memory-mapped IO vs traditional NIO is likely not helping either?  Is this really a thing?  I have not tested NIOFSDirectory to see if the swap storm is lessened).
Longer term we have discussed using AKNN algorithms that are more disk-friendly (e.g. DiskANN), but shorter t erm, I'm wondering if we could somehow help users with a default Directory (from FSDirectory.open) that somehow / sometimes preloads .vec files?  It's not easy to do -- you wouldn't know up front that the application will do KNN searching at all.  And, maybe only certain vectors in the .vec will ever be accessed and so you need to pay that long random access price to find and cache just those ones.

It wouldn't solve the issue, only mitigate it, but hopefully cold start performance gets better when we start leveraging IndexInput#prefetch to load multiple vectors from disk concurrently (https://github.com/apache/lucene/issues/13179).

The Linux kernel's less aggressive default readahead for memory-mapped IO vs traditional NIO

FWIW, it's not that the read-ahead is less agressive for mmap than traditional I/O, it's that since recently MMapDirectory explicitly tells the OS to not perform readahead for vectors by passing MADV_RANDOM to madvise.

Oh sorry I used the wrong term (thank you @rmuir for clarifying!): it's not a swap storm I'm seeing, it's a page storm.  The OS has plenty of free ram (reported by free), and that goes down and buff/cache goes up as the OS pulls and caches pages in for the .vec file.  I don't think I'm running too many ram hogging crapplications ;)

it should be a one-liner using setPreload to preload "*.vec" if we wanted to do it either from FSDirectory.open or by default in MMapDirectory

+1 -- it would be a simple change.  But I worry if it would do more harm than good in some cases, e.g. if there are truly cold HNSW cases where the application plans to suffer through paging to identify the subset of hot vectors?  I don't know if that is even a thing -- a bunch of dark matter vectors that never get visited?  I guess we do know that HNSW can and does sometimes produce disconnected graphs, but I think those dark matter islands are "typically" smallish.

if the application isn't doing KNN searching then they won't have .vec? I struggle to imagine someone indexing a ton of "extra" vectors that isnt "using" them and hasn't noticed big performance impact

+1!  Especially because indexing them is quite costly!

It wouldn't solve the issue, only mitigate it, but hopefully cold start performance gets better when we start leveraging IndexInput#prefetch to load multiple vectors from disk concurrently (#13179).

+1 -- that would be a big help especially when paging in from fast SSDs since these devices have high IO concurrency.

The Linux kernel's less aggressive default readahead for memory-mapped IO vs traditional NIO

FWIW, it's not that the read-ahead is less agressive for mmap than traditional I/O, it's that since recently MMapDirectory explicitly tells the OS to not perform readahead for vectors by passing MADV_RANDOM to madvise.

Ahhh, that makes sense!  And I think it is still correct to madvise in this way for our .vec files: it really likely (is there any locality to HNSW's access patterns?) is a random access pattern from HNSW.  It does make me wonder if the scalar compression will actually help or not.  I guess it might still help if that compression means multiple vectors fit into a single IO page.

I don't think we should change anything here in MMapDirectory. It is all available and easy to do for one that wants to do this. Elasticserach is doing this for some files, but we have no default on preloading anything.
For preloading you can pass MMapDirectory#setPreload and give it a lamda expression to select on which file extensions you want preloading: https://lucene.apache.org/core/9_11_0/core/org/apache/lucene/store/MMapDirectory.html#setPreload(java.util.function.BiPredicate)
The default is: https://lucene.apache.org/core/9_11_0/core/org/apache/lucene/store/MMapDirectory.html#NO_FILES

it should be a one-liner using setPreload to preload "*.vec" if we wanted to do it either from FSDirectory.open or by default in MMapDirectory

It is trivial:
mmapDir.setPreload(name -> name.endsWith(".vec"));

So no change needed in the API or behaviour of Lucene.

...but later realized that this would not work for compound files that have vector data in them eg .cfs?

Tracing MMapDirectory.openInput in main, it does this:
    return PROVIDER.openInput(
        path,
        context,
        chunkSizePower,
        preload.test(name, context),
        groupingFunction.apply(name),
        attachment);

So it looks like it applies the preload predicate to the .cfs named file... and then passes the resulting boolean to the JDK-version-specific impl.  Opening further slices within this IndexInput (what CFS filels do) no longer do any preloading, since the whole .cfs file was either preloaded or not.
@gautamworah96 -- maybe open a spinoff issue exploring whether we could offer preloading of just slices within a CFS file?

Opened https://github.com/apache/lucene/issues/13967

Late to the party!!!
I want to dig a little further on the distinction between the implementation of preload and prefetch, at least with the mmap implementation. The former touches every page (effectively forcing into the cache), while the latter simply advises of the access pattern.
For sequential access, a combination of sequential advice and prefetch works really well, but not so well for random access. Random access, at least for the HNSW graph and the related vector data (be it quantised or not), really needs to be resident in memory. Preload gives us that, at least at the time of opening. Prefect does not.
For optimized vector search use cases, assuming enough RAM, I was thinking that a separate IndexInput::load could be useful. This would be similar to preload (touches every page), but can be called after opening. It may or may not be super helpful, it mostly depends on how things get setup, etc, and whether or not preload is good enough for your use case.
For optimized vector search use cases, assuming enough RAM, I was thinking that a separate IndexInput::lock could be useful. Basically a wrapper around mlock. The idea being that Vector search perf sucks when there is not enough RAM to keep the graph and vector data resident in memory, so allow to load and lock it, then leave the tradeoff to the user to decide if they want this "fail fast" rather then "search slowly" behaviour (at least for pure vector search).


added docs for Zed 2i Camera

Could you add Headers to keep everything organized? Will accept merge after :)

Added the headers🙏


Preparing for release 1.0.0

adding tests
closes #113
refactor code outside of main

CI passed 🚀


Eclipse keymap CTRL-H from Explorer regression

Does this issue occur when all extensions are disabled?: Eclipse keymap is required

VS Code Version: 1.76.0
OS Version: Ubuntu 22.04

Steps to Reproduce:

Press CTRL-H from explorer
«files to include» still contains the path from last search
Expectation: «files to include» contains the path from selected folder in Explorer
Workaround: Right-click folder and select «Find in folder...»

Can you try insiders and let me know if you still see this issue
https://code.visualstudio.com/insiders/

I just installed the latest version 1.76.1 and retried. Issue is stll present

Insiders is 1.77.0. Contains all the latest fixes. Did you move your explorer at all?

I also installed Insiders 1.77.0. Issue is still present.

Please try CTRL + SHIFT + P  -> Reset all view locations

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Write date directly on input

It is possible to write the date directly in the input besides choose in the datepicker? I followed the instructions on how to use and can't find nothing related

No this is not possible by design.


Migrated ESLint config to flat config

#502  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @CatChen and the rest of your teammates on  Graphite


Initial karoake feature

Merge karaoke into main.

Wow this looks interesting, let's analyze this.


Update magixTx_chain_config.js

Updated Agoric explorer URL to 'https://agoric.explorers.guru/transaction/ following Big Dipper's drop of support, referenced Agoric's tweet: https://twitter.com/bigdipperlive/status/1766162059690119486.

@Priyanshu1710


DEV: Update dependencies and build number

Update dependencies and build number
New dependency SimpleITK

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender


Unable to select a folder using window.openFileDialog with a remote File System (using local workspace)

Version: 1.51.0-insider
Commit: 7a3bdf4ee9588755d447aa1c3b5db4a123fc11a9
Date: 2020-10-23T07:32:22.213Z
Electron: 9.3.2
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0

Steps to Reproduce:

Create an extension and register a remote file system
Use the command window.showOpenDialog with defaultUri pointing to a directory on the remote file system.
VS Code will now select the remote file system folder picker (as expected).
Selecting a folder from the list results in the display of the message The path does not exist..

VS Code seems to convert the remote path to a local path & perform some local FS operations on the path (to determine its validity, things fall over as the file doesn't exist, hence we get the incorrect message).
Expected behavior

VS Code will return the selected remote folder.
Looking at the code,

Note:

Not using any of the Remote extensions for VSCode
I am on the local machine
I have a local workspace folder opened
I have registered a remote file system,

See below screenshot:

Screenshots of the stack trace (hope this helps)

Does this issue occur when all extensions are disabled?: No

Checked the existing issues, and they do not apply

What is your defaultUri? I'm wondering if it has the correct scheme.

Default uri is localhost888:/ and this is correct and that's why the folders are listed in the drop-down (ie it is display remote folders).

Is it possible your files system provider is implemented incorrectly? It should be called as part of that call stack.

Is it possible your files system provider

To my knowledge this is implemented correctly.
Agreed it should be cashed, but not, and that's why I posted that stack.

Can you share the exact way you call window.showOpenDialog? You must also specify the availableFileSystems for the file picker to understand what to do. availableFileSystems is just an array of uri schemes.

Here's the code
        const remoteFolders = await window.showOpenDialog({
            canSelectFiles: false,
            canSelectFolders: true,
            canSelectMany: false,
            defaultUri: fileSystem.rootFolder,
            openLabel: 'Folder to create notebook',
            title: `Select folder on Remote Server (${server.label})`
        });

FYI - I am an extension author, hence do not have access to internal VSCode API. availableFileSystem is not in the exposed API (https://github.com/microsoft/vscode/blob/master/src/vs/vscode.d.ts).

That makes sense. Do you have a repo I could clone to try it out? I think I see the problem, but it would be good to confirm.

Thats good news, unfortunately the code is private, hence nothing I can share.
Should be easy to repro though (whipping up using a sample fs provider).

@alexr00 Do u still need some information (asking because of the current label needs more info)
Thanks

@DonJayamanne no further info needed, thank you!

@DonJayamanne does the fix work for you?

@alexr00 @DonJayamanne's steps don't look too hard but I'm wondering if you know what "register a remote file system" refers to? Is that part of the VS Code API, or does that mean setting up a remote file system on the side?

Using the below sample code (npm i => f5 => memFS: Open memFS) I'm still seeing the "path does not exist error".
fsprovider-sample.zip

does the fix work for you?

Will check, I didn't see a new insider build. Will double check

Since this isn't a regression (it never worked), moving the fix to November.
To verify, use sample project here: https://github.com/microsoft/vscode/issues/109345#issuecomment-721451698

npm i
F5
Run the command  memFS: Open memFS
Verify that you can navigate into folders in the file dialog. (the sample doesn't actually open any files, just shows the dialog).

/closedWith 8145e9f

Tested and confirm it does not work.
Version: 1.52.0-insider
Commit: 24b28f57be22fe3029cb17a1dd72d8d9c2d6468b
Date: 2020-11-06T05:39:23.276Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.6.0

@DonJayamanne thanks for trying to verify! Are you still seeing the exact same bad behavior? With the sample project I can no longer repro the issue.

Odd, I can still repro this. However using the VSCode extensions examples I can no longer repro this.
Will have to check why its not working in my extension.
Lets assume this is closed for now, I'll need to debug my extension separately.

Thanks @DonJayamanne. Feel free to ping again if you discover that the issue is still present.


About updating slate in development environment

Question/Feature request
Would be nice to have some words about "updating slate" inside the documention.
As far as I see, I shall update slate that I use on my computer with "npm install -g @shopify/slate", I did and it shows me the new version of slate. Fine. But the theme that I am working on is not changed at all, so e.g. no change inside the package.json.
Does my theme development now still work as expected? Is there no conflict between global slate and the slate used to build that theme, is there a second slate now somewhere? The node modules that I find inside the theme, are defined by the package.json or by the global slate? So the "global slate" has now a differnet slate-tools set than the theme for example?
I found the related question #154 but beside the hint, that you have to copy files manually it does not really help me understand what to do, when I want to use a current state of slate with an envolving theme, that will be contious developed over the next months…
Can I have some more hints, or maybe a link, where I can find information about that?
Thanks!

Hey @AlphaHasi -- we've been working on our versioning setup and one discussion that came up was about the Slate upgrade path.
I agree with your request! I think two things can be done:

General docs on how to upgrade slate-cli and slate-tools on your computer
Version specific upgrade docs included in the CHANGELOG.md and the release notes

Please note that slate-theme (the boilerplate files and directory structure for a slate theme) is not expected to be upgradable. This is pretty typically of boilerplates since they are a starting point that is immediately customized to your needs.


Benchmark?

Is there a benchmark, comparing standard Go vs CNG on Windows?

We don't publish benchmarks for now. You can generate your own by using the Microsoft Go toolchain to benchmark whatever crypto package you are interested on with an without the CNG backend.


Create LICENSE

There are links to the various licenses in the README.md file.
Is this not sufficient?
https://github.com/nathansmith/unsemantic/blob/master/README.md

The LICENSE files make it explicit so others can use the GitHub API to access it: https://developer.github.com/v3/licenses/#get-a-repositorys-license
Not sure how you'll want to dual-license though.

Ah, gotcha. Cool. Thanks for the clarification. :)


clarify when the ProvisionStopped condition would be set

It is meant to indicate that at least one cluster provision was
attempted.

Pretty sure this will need a make update to regenerate the CRDs etc.
Should we also say that ProvisionStopped means we've run out of retries?

While the Conditions are part of the API in a roundabout way, they aren't part of the CRD. At least that's what I'm telling myself why there were no other changes after running 'make update'. I've added additional text that hopefully makes things more clear.

While the Conditions are part of the API in a roundabout way, they aren't part of the CRD

Oh, duh, right.

/lgtm
/test images


Securing Bower

I'd like to begin a discussion about adding some security features to Bower. Note that I'm not currently engaged with the Bower-Next development, so I'm not aware of what features have been discussed and implemented there, however I've searched through the code and the issues and nothing jumped out at me. Either way, pardon me if I'm rehashing some things.
Signing, Validation, Key Registration
The first is to teach bower to recognize cryptographically-signed tags and commits. Signed tags have been around for a while, however signed commits are relatively new (via the git commit -S option). In both cases, I would like bower to be able to check its dependencies and determine whetner a specific library version is signed or not (whether you're linking a version or a direct commit sha).
The second feature is a little more nuanced: I would like to enable a 'verified' run mode for bower where it only resolves versions that are cryptographically signed. In other words, if you run bower install --verified, it will only resolve versions which have been signed.
The last feature, and most important one, is that I would like to add the GPG public key id for a package maintainer into the bower registry (not into the package.json file, that's considered compromised). Combined with the above two, the 'verified' mode would only resolve versions which have been signed by the gpg public key available in the bower registry.
But why do we care?
Well, most of this is driven by the linux enterprise community (I myself am involved with OpenStack), who have well established signing and trust-chain standards. While we recognize that client javascript libraries - such as registered by bower - are executed in a compromised environment, and are thus inherently untrustworthy, the least we can do is ensure that the bits that are installed on and hosted by our servers can be trusted.
It's not just a code problem though.
Ultimately this is more of a social problem than a code problem. Yes, having the features is all well and good, however without broad adoption of PGP-signing we'll have a library full of empty books. With that in mind, I want to gauge how people feel about modifying the log output of bower install to highlight which packages are signed and which are not. Either via color, or a [signed] prefix, or something else.
So who's going to do the work?
Me. No, really, I'm serious... that is, unless one of you wants to help :). It's my job to make OpenStack better at JavaScript, and that encompasses the entire technical field. I've tried to reach out to the #bower channel on FreeNode, but nobody seems to be doing anything there, so I figured the design discussion could take place here.

With the above in mind, where should this work happen? I can put effort into bower-next, but without a release schedule I can't judge whether that'll be fast enough. I could clone it into both.... but... well, I don't like duplicating effort. Any suggestions?

Hello @krotscheck. @kodypeterson is already working on "lockfile" feature in #1748 that would enable GPG verifying. To enable GPG verifying we'd only need to include it inside the bower.lock.
It's something that bower misses for almost 2 years. We need helping hand.
Could you contact him and work on it together? Please read #1592 for specs.
Let me know if I can help you in any way achieving it. e.g. I can make you a contributor to this repo.

Thanks, @sheerun - I'll dig into the spec and the lockfile work on monday and see where I can get involved. I'll leave this topic open as a discussion point, and reference bits as work progresses.

Google's Polymer and Angular projects are heavily reliant upon Bower.  If they are using Bower to manage code for their front-end software, then a vulnerability in Bower's infrastructure could lead to a vulnerability in their deployed code.  Maybe someone at Google would be interested in helping make this happen?

@krotscheck Let me know how I can help! :smile:

@kodypeterson Thanks! I'm on paternity leave for another week, but I'll dive into this as soon as I get back.

@krotscheck An issue that is older than your child. Ha ha! I think it is fair to close it.


Windows installer requires execution policy

When trying the installer script for uv on windows 11 in powershell, i get an error:
PS > powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
Error: PowerShell requires an execution policy in [Unrestricted, RemoteSigned, ByPass] to run uv. For example, to set the execution policy to 'RemoteSigned' please run:

    Set-ExecutionPolicy RemoteSigned -scope CurrentUser

Running that command doesn't help instead i need to
powershell -ExecutionPolicy Bypass -c "irm https://astral.sh/uv/install.ps1 | iex"

@konstin - thanks for filing- looks like Restricted is the default setting for clients and RemoteSigned is the default setting for servers, and that using Bypass would work on both to ensure that the script successfully runs. what is not 100% clear to me is that all users attempting to install uv have permissions to update/set the execution policy. i would definitely take a PR for this and then we'd probably want to do some testing to make sure it fully works. i am actually somewhat surprised we haven't gotten any issues filed for this which makes me think that execution policy is also varied across the average dev platform. if you have any further info on this it'd be helpful- but yeah i think adding this and then doing a bunch of testing on a pre-release would be a good idea.

This is on a recent acer laptop with an OEM windows relatively close to factory settings on a non-admin terminal; I didn't have this happen on my older windows, i assume it's something i had turned off before there. I unfortunately don't have a windows server to test there.

For what it's worth, this works fine on this Windows Server 2022 box: https://app.vagrantup.com/jborean93/boxes/WindowsServer2022


Failed to connect, please try again

Since yesterday? I get failed to connect.
Tried to reinstall , no success
No errors in log.
Same with HA Melcloud version.
The iPhone Melcloud app has no problem connecting
Also tried guest account.

I am getting this as well but my android cannot connect

At the moment it is working again.  If it was indeed a SSL certificate problem, then it can be closed.


feat: eetq gemv optimization when batch_size <= 4

What does this PR do?

Add TensorRT-LLM weight-only GEMV kernel support. We extract GEMV kernel from TensorRT-LLM to accelerate the decode speed of EETQ when batch_size is smaller or equal to 4.

Features

There is almost no loss of quantization accuracy.
The speed of decoding is 13% - 27% faster than original EETQ which utilizes GEMM kernel.

Test
Below is our test on 3090. Environment: torch=2.0.1, cuda=11.8, nvidia driver: 525.78.01
prompt=1024, max_new_tokens=50

Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you read the contributor guideline,
Pull Request section?
[ ] Was this discussed/approved via a Github issue or the forum? Please add a link
to it if that's the case.
[ ] Did you make sure to update the documentation with your changes? Here are the
documentation guidelines, and
here are tips on formatting docstrings.
[ ] Did you write any new necessary tests?

Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@Narsil

Good job!


Properly escape url params

Uri.EscapeUriString is weird. It basically ignores / and & and probably others too.

@thingylab any chance of a test?

@jonnii just for you


The website Github icon need to be changed

I hope it can be modified to be the same as this website:
https://eventmesh.apache.org/

#342 This PR has solved this problem.

https://github.com/apache/incubator-linkis-website/pull/342 This PR has solved this problem.


removing 'users' route causes missing module error in webpack skeletons

I'm submitting a question/bug report

Aurelia Skeleton Version
skeleton-esnext-webpack
skeleton-typescript-webpack

Please tell us about your environment:

Operating System:
Windows [10]

Node Version:
8.1.3

NPM Version:
5.0.3

JSPM OR Webpack AND Version
webpack 3.0.0

Browser:
Chrome

Language:
all

Current behavior:
Removing route 'users' from app.ts/js causes following error:
Error: Unable to find module with ID: aurelia-logging-console.
This happens in updated skeletons, and not in previous ones (2.x.x)

Have you tested removing only the users route and leaving the child-router route in place? It seems to work for me as long as at least one of the routes provided by the skeleton remain in place.
If this is the situation you find yourself in then I can confirm the environment found at the bottom of this comment also manifests the issue, if not then a similar issue is present in the aforementioned environment.
A bit of further detail, this doesn't appear to be mitigated by adding new routes as I have tried adding my own routes to see if it was perhaps expecting multiple routes (admittedly this seemed unlikely). Redirecting the route also manifests the issue.
Adding routes in addition to those provided by the skeleton does not seem to cause any issue.
I managed to work around this issue by adding either of the following code snippets in one of the typescript files that I have added. This appears to be the minimal code that fixes it.
import {lazy} from 'aurelia-framework';
import {HttpClient} from 'aurelia-fetch-client';

export class ClassName {
  constructor(@lazy(HttpClient) private getHttpClient: () => HttpClient) {}
}

or
import { Router, RouterConfiguration } from 'aurelia-router';
import { PLATFORM } from 'aurelia-pal';

export class ClassName {
  router: Router;

  configureRouter(config: RouterConfiguration, router: Router) {
    config.map([
      { route: ['', 'welcome'], name: 'welcome',      moduleId: PLATFORM.moduleName('./welcome'),      nav: true, title: 'Welcome' },
      { route: 'users',         name: 'users',        moduleId: PLATFORM.moduleName('./users'),        nav: true, title: 'Github Users' },
      { route: 'child-router',  name: 'child-router', moduleId: PLATFORM.moduleName('./child-router'), nav: true, title: 'Child Router' }
    ]);

    this.router = router;
  }
}

Obviously, this is still not exactly an ideal workaround - especially if you don't need either of those code behind files. Just hoping it might be of some assistance in tracking down what the issue is.

Operating System:
macOS Sierra (10.12.5)

Node Version:
8.2.1

NPM Version:
5.3.0

JSPM OR Webpack AND Version
webpack 3.3.0

Browser:
Chrome

Language:
Typescript

Thanks,
Dan

Hi @EisenbergEffect, this is still happening, must keep this minimal users.ts file as a route or the app hangs on loading spinner with:
Error: Unable to find module with ID: aurelia-logging-console
import {lazy} from 'aurelia-framework';
import {HttpClient} from 'aurelia-fetch-client';

export class Users {
  constructor(@lazy(HttpClient) private getHttpClient: () => HttpClient) {}
}

Aurelia Skeleton Version
skeleton-typescript-webpack
Please tell us about your environment:
Operating System:
Ubuntu
Node Version:
8.9.1
NPM Version:
5.5.1
JSPM OR Webpack AND Version
webpack 3.3.0
Browser:
Chrome
Language:
all
Current behavior:
Removing route 'users' from app.ts/js causes following error:
Error: Unable to find module with ID: aurelia-logging-console.


Make the Qt signal/slot mechanism easier to use

Adding a "signal_done" function and corresponding signal to the Qt
widget classes makes it much more convenient to request a Qt callback
when a camera operation completes.
There's a new version of app_capture.py, app_capture2.py, that uses
this mechanism to re-enable the push button once the capture operation
is done.
Signed-off-by: David Plowman<EMAIL_ADDRESS>

Yep, I'll fix the conflict. Actually I seem to have got some logic slightly wrong here. I'll re-post it tomorrow. Thanks!


Update CONTRIBUTORS.md

my first open source project

@jay-jpj Hi Jay, thanks for your PR. Have approved it.
Congratulations on your first open source project contribution 🎉!
Please kindly follow me or this organization on GitHub to stay tuned to this project for future updates.
Thanks and have a good day ahead 😊


Update pod spec for version 2.0.1

Would you mind updating the pod spec for tag 2.0.1?

Done! Sorry for missing that during the release!
(for reference: The pod spec was updated, but I neglected to pod trunk push)


Event on cell changes

I need to get an event when a cell changes . Is this currently supported ?

Sorry, this library doesn't support this feature currently.

thanks. I can probably add it.
Can you give me some info about how changes are tracked ?

https://github.com/qax-os/excelize/blob/master/cell.go#L118 looks like the entry point...

Could you describe the scenario of using listen to cell change event? If you can tell the cell to change listener (handler) when setting cell value in your program, that is not required to modify the library.

My use case of that I am using the excel file as a quasi database .
Mutations to cells and formula happen from my code via your API.
when mutations happen to a cell I need to react to those changes in higher lever code.
if this is out of scope or too ambitious please let me know and I will drop support for excel files in my system and I stress revert to just supports csv.

When will mutations happen to a cell? I think if you know who will modify the cell value, if which also using this library to change the cell value, could you comminute with them each that other? That's not required to modify the library. If the cell value modifies via the Office application user interface, this library is unable to recognize which part of the workbook file has been changed.


WIP:  kit2fiff support for UMD

Adding support for University of Maryland, cc @teonlamont
I am still trying to improve the usability by having more extensive tooltips. I wonder if it would even make sense to have the help text itself in a separate text/xml/... file and read it when constructing the kit2fiff-GUI ...

@teonlamont in case you're wondering, one of the major modification concerns the way stim channels are read, they use the stim-channel number as trigger value, i.e. if the event happens in stim channel 181 the trigger value is 181. They have more than 8 channels.

I put the help text into a json file. Let me know what you think, if you agree I will put the remaining tooltips in it too.

Otherwise LGTM

Thanks @Eric89GXL and @teonlamont , appveyor seems to be a traits-internal problem
NotImplementedError: the tvtk.pyface.ui.null. pyface backend doesn't implement SceneEditor
Does the ci error mean something is wrong?

Ignore CircleCI for now. The AppVeyor error we should fix. Do you think your tests use some functionality that is triggering this error? I wonder if we need to install PyQt4 on AppVeyor or something, since the problem is that pyface backend doesn't implement SceneEditor. @christianbrodbeck what backend are you running locally? Hopefully it's sufficient to install it on AppVeyor.

@Eric89GXL I am using whatever is the default backend locally. For the bash commands $ mne coreg etc. we explicitly set it to QT4 because that seemed to be the only one reliably supported by traits, so yes maybe installing qt would help (I think the WX backend used to initialize it too, although the GUI was not displayed correctly, but I think that was pre-3.0). If I am not mistaken SceneEditor is the basic display for Mayavi scenes, so I am curious why this error does not happen on all other PRs? Also, the coregistration test seems to trigger the same error, and it was not modified in this PR. If we can't install the GUI backend, can we selectively skip those tests?

We could come up with some decorator that allows us to skip the tests, but the cleanest thing would be to make AppVeyor run the tests properly, so let's exhaust that possibility first.

I there  a way I can tell it to install qt or does that have to be done in the configuration?

https://github.com/mne-tools/mne-python/blob/master/appveyor.yml#L25

That seems to have done the trick

ok, I think I'm done. thanks @christianbrodbeck!

besides the pyside thing I don't understand
@teonlamont @christianbrodbeck merge when you're happy

thanks @christianbrodbeck


CMake for .Net5 & above

How to use CMake with .Net 5+

Thanks for adding this @joeloftusdev! I'm going to assume that this works and merge it without testing. ;)

All works! cheers :)


chore: fix upgrade check error

Coverage remained the same at 75.281% when pulling 3afe855b80729eca7eb2a347fa3c875655ba80f1 on Rory-Z:chore/fix-upgrade into 15e98c277dc72cebe6f27ee25a67b8934440b00a on emqx:main.


Feature Request : Add Heading to tags!

Giving Heading to Tags under resource section might be helpful to newcomers to understand the UI.
P.S : I can add this functionality!

Can you elaborate it a bit, what kind of heading and where ?

I tried explaining here with this edited image!

Hey @rahulnegi20 , that is self understandable, it is the part of UX, no need of adding a heading. Thanks for the suggestion, looking forward to more from you.


DDL syntax to revert changes to some schema object.

There are situations where reverting some changes to the schema is desirable. Consider the following examples:
Annotations
We start off with a schema like this:
abstract inheritable annotation my_anno;

type Foo {
  annotation my_anno := 'forever';
}
type Bar extending Foo {
  annotation my_anno := 'nope';
}

Then we decide that actually it wasn't a great idea overriding the inherited annotation my_anno in Bar, so we want to migrate to:
abstract inheritable annotation my_anno;

type Foo {
  annotation my_anno := 'forever';
}
type Bar extending Foo;

But how will this be implemented? How to do this in DDL? Currently the only way is to first DROP ANNOTATION my_anno from Foo, then add it back. This is somewhat round-about way of doing this especially if the inheritance hierarchy is deeper and contains more places where the inherited annotation is overridden which we don't want to change.
Links
We start with the following:
type Foo {
  link stuff -> Object;
}
type Bar extending Foo {
  overloaded link stuff -> Foo;
}

Once we've added some data we decide that in retrospect we don't want Bar.stuff to link exclusively to Foo, but the base class approach was just fine.
type Foo {
  link stuff -> Object;
}
type Bar extending Foo;

So the question is how is this migration done? Ideally we expect the data to be preserved and there's nothing particularly ambiguous about the intent here, but we can't just drop the link and re-create it like with annotations since that will discard data. So the question is: what's the correct DDL to use here? (Incidentally, SDL migration works fine preserving the data)
The obvious user choice for DDL is ALTER TYPE Bar {ALTER LINK stuff {SET TYPE std::Object}};, but that makes the link overloaded rather than actually inheriting without alterations. There are some system fields that are used by the SDL migration that user-DDL simply cannot use, like is_local. This has little functional difference, but it does result in a different schema ultimately.

This was implemented in c6cc25da9c46d and 529da2d4f8ada.


Issues in High Sierra

As seen above, the transparency is not aligned and with the transparency on you can click through the actual window, making for unsightly interaction.

Here the Electron issue: https://github.com/electron/electron/issues/10521
There doesn't seem to be a fix yet.
Temporary workarounds

A temporary workaround noted here is to go full-screen and then back to normal. Of course that's pretty annoying if it has to be done for every new window. Even automatically in Init Script.. probably feels too jarring.

Another option is to add back a background to the title bar:

@import "syntax-variables";
.one-vibrancy .title-bar {
  background-color: @syntax-background-color;
}

There are no rounded corners and doesn't really work with Title Bar: hidden tough.

Election carried out a fix, and seems it's taking effect in current Atom (1.26.1). The issue still presents on cold start, but if you fullscreen the window and switch back it will recover.


Docker issues

I'm trying to run this in docker. I've tried just docker and docker-compose with the same result.
Sorry if I'm doing something obviously wrong. Thanks in advance. Let me know if I can provide any other details.
I'll run something like this:
docker run -e USERNAME="username" -e PASSWORD="password" -v "/data:/data" -p "3000:3000" bropat/eufy-security-ws:latest
and I get invalid credentials everytime
2021-08-14 23:39:39.948  INFO Eufy Security server listening on port 3000
2021-08-14 23:39:40.818  ERROR Response code not ok
{
  code: 26006,
  msg: 'Email address or password incorrect.'
}
2021-08-14 23:39:40.832  ERROR Token error

What's interesting is that if I use the library straight like this:
eufy-security-server
I don't get an authentication error but something else.
2021-08-14 23:44:49.456  INFO Eufy Security server listening on port 3000
2021-08-14 23:44:55.041  ERROR Station T8510Q10202703D0 - Response code not ok
{
  code: 20028,
  msg: 'Failed to request.'
}
buffer.js:207
    throw new ERR_INVALID_ARG_TYPE(
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type undefined
    at Function.from (buffer.js:207:11)
    at stringWithLength (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/utils.js:23:35)
    at p2pDidToBuffer (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/utils.js:32:18)
    at Object.buildLookupWithKeyPayload (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/utils.js:36:26)
    at P2PClientProtocol.lookupByAddress (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:188:33)
    at cloudAddresses.map (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:172:51)
    at Array.map (<anonymous>)
    at P2PClientProtocol.lookup (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:172:29)
    at Socket.socket.bind (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:247:26)
    at Object.onceWrapper (events.js:286:20)

I know that it is getting past authentication in this case because if I change the password in my config.json file, then I get this result:
eufy-security-server
2021-08-14 23:46:41.568  INFO Authentication properties changed, invalidate saved cloud token.
2021-08-14 23:46:41.701  INFO Eufy Security server listening on port 3000
2021-08-14 23:46:42.505  ERROR Response code not ok
{
  code: 26006,
  msg: 'Email address or password incorrect.'
}
2021-08-14 23:46:42.532  ERROR Token error

here's my docker compose, if it's helping ...

services:
eufy-security-ws:
image: bropat/eufy-security-ws:latest
environment:
- TZ=Europe/Paris
- USERNAME=eufyaccount
- PASSWORD=eufypassword!
ports:
- "3000:3000"
volumes:
- /root/eufy/data:/data
restart: always

Thanks! I figured my issue was that I had an & in my password.
That all being said, I'm still get this error once past authentication:
2021-08-14 23:44:49.456  INFO Eufy Security server listening on port 3000
2021-08-14 23:44:55.041  ERROR Station T8510Q10202703D0 - Response code not ok
{
  code: 20028,
  msg: 'Failed to request.'
}
buffer.js:207
    throw new ERR_INVALID_ARG_TYPE(
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The first argument must be one of type string, Buffer, ArrayBuffer, Array, or Array-like Object. Received type undefined
    at Function.from (buffer.js:207:11)
    at stringWithLength (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/utils.js:23:35)
    at p2pDidToBuffer (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/utils.js:32:18)
    at Object.buildLookupWithKeyPayload (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/utils.js:36:26)
    at P2PClientProtocol.lookupByAddress (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:188:33)
    at cloudAddresses.map (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:172:51)
    at Array.map (<anonymous>)
    at P2PClientProtocol.lookup (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:172:29)
    at Socket.socket.bind (/usr/lib/node_modules/eufy-security-ws/node_modules/eufy-security-client/build/p2p/session.js:247:26)
    at Object.onceWrapper (events.js:286:20)

Seems to be an issue with trying to get the dsk keys for a door lock that is blue tooth only. Going to close this and open an issue in the eufy-security-client project


Roadmap for BIDS Schema Tools docs

Your idea
Thanks to @bendhouseart, we are now pushing documentation for the schema tooling to https://bidsschematools.readthedocs.io/en/latest/. This issue is intended to track tasks for improving this site to make it more useful. Please add/edit freely, or comment below.
Appearance

[x] Update theme. Furo is a good, clean theme with dark/light support.
[x] Logo. We should have BIDS logos for dark and light themes.

Content

[x] Description of project on landing page. Single-sourcing README for PyPI (https://pypi.org/project/bidsschematools/) and the docs seems like a good idea.
[x] Links to other major sites in BIDS.
[ ] Flesh out API docs. Aim for 100% docstrings of public functions/methods/classes.
[ ] Add examples, run doctests (if we aren't already)
[x] Move/link schema readme into docs

Should the documentation for the macros be also moved into the official schema doc?
I mean this document
https://github.com/bids-standard/bids-specification/blob/master/macros_doc.md
At least we could symlink it.
WDYT?


worklog: start_data typo, should be start_date

jiraSOAP / lib / jiraSOAP / entities / worklog.rb
The start_date is called start_data here.

@FDj sorry about that, hopefully that's all that's broken


[stable/kube2iam] adds Prometheus ServiceMonitor resource to kube2iam

What this PR does / why we need it:
Adds the ability to create a prometheus operator ServiceMonitor resource that configures prometheus to scrape kube2iam's /metrics endpoint.
Special notes for your reviewer:
Since kube2iam itself handles defaulting the --metrics-port parameter to the value of --app-port, I wasn't sure how best to handle the config of it. I didn't want to specify 8181 in the included values.yaml so I documented the parameter but left it commented out. Let me know if you'd prefer a different approach here.
CC @jmcarp / @icereval / @mgoodness
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @paulczar

@paulczar @scottrigby @lachie83 bump? This is quite a small change to add some optional monitoring config that would be greatly helpful :D
Also please let me know if you guys were incorrectly assigned and this would be better with someone else?

/unassign @paulczar
/assign @davidkarlsen
@davidkarlsen I spotted you reviewed some other ServiceMonitor-related PRs recently - hope you can help but apologies if you're not the right person. I'm a little confused as to how the auto-suggested assignee was generated.

bump

/assign mgoodness
:pray:

/assign
/ok-to-test

/lgtm