3.4.0 is not on PyPI?

Describe the bug
I can see version 3.4.0 has been tagged in this repository and CHANGES.rst lists the release date as 2023-08-18, but the release has not made it onto PyPI. Is that deliberate or an oversight?
It would be ideal to have a way to install the latest version which doesn't require us to install it directly from the Git repository.
To Reproduce
Steps to reproduce the behavior:

Run pip install django-simple-history
Observe version 3.3.0 is installed, not 3.4.0

Expected behavior
Version 3.4.0 should be available on PyPI.

The release is still awaiting publishing from the people with permissions to do so, see https://github.com/jazzband/django-simple-history/issues/1238#issuecomment-1696625980 and https://github.com/jazzband/help/issues/344. I'm not sure what else can be done 😕
I'll leave this issue open until the release has been published.

Version 3.4.0 is now on PyPI


(Suggestion) Reflections for the Intro/Retro/Consideration pattern iotas

At the moment, if you want to put Introspection, Retrospection, or Consideration pattern iotas on the stack, you need to use Consideration before them. This is fine for simple hexes, but higher-complexity hexes often involve several layers of Introspection, and each layer requires more and more Considerations. Not only is drawing several Considerations a little annoying, it also means that if you want to put one hex inside another, you have to modify its code to give it additional Considerations, instead of just wrapping it in an Intro/Retro pair and calling it a day.
I suppose I could just start every complex hex with "Consideration: Introspection, Consideration: Retrospection, Consideration: Consideration", and then have deeper layers of the spell copy those iotas from the stack when they need them. But really, it'd be convenient if there were a trio of Reflections to put the appropriate pattern iotas on the stack without so much complexity.

Introspection and/or Retrospection can be done as follows:
{
  {
  }
}

This pushes a list containing one Intro and one Retro to the stack; you can then select whichever one you need, or use Flock's Disintegration to splat both onto your stack.
I do agree that a Consideration reflection would be nice.


Small fix/doc improvement for colour uniform example

Currently the colour uniform example produces
ERROR gfx_backend_vulkan > [Validation]  [ VUID-VkMappedMemoryRange-size-01390 ] Object: 0x6 (Type = 8) | vkFlushMappedMemoryRanges: Size in pMemRanges[0] is 0x84, which is not a multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize (0x40). The spec valid usage text states 'If size is not equal to VK_WHOLE_SIZE, size must either be a multiple of VkPhysicalDeviceLimits::nonCoherentAtomSize, or offset plus size must equal the size of memory.' (https://www.khronos.org/registry/vulkan/specs/1.0/html/vkspec.html#VUID-VkMappedMemoryRange-size-01390)

when creating and updating buffers because it is using calculated sizing instead of received buffer size from memory requirements for creating memory mapped ranges.
In addition, added a note that using CPU visible buffers is not scalable for most uses and especially potentially large/unchanging data like vertex buffers.
PR checklist:

[ ] make succeeds (on *nix)
[ ] make reftests succeeds
[ ] tested examples with the following backends:
[ ] rustfmt run on changed code

bors delegate=ZeGentzy

@ZeGentzy want to review it? :)

@termhn Functions on my computer and changes look good I guess. Can you explain to me why these changes are necessary for colour-uniform but not quad? I'd think they'd be necessary for both, if they are can you add them to quad too?

@ZeGentzy I hadn't checked on quad, I'll do that now, but I suspect it needs the same change as well if it was originally how colour-uniform was laid out.

Yep, same thing was true of both quad and compute examples, fixed there as well.

Thanks, I suspected so, @termhn. Colour uniform was originally written to be for the most part functionally identical.
bors r+


Are different "set of batches" selected at each epoch when using steps_per_epoch ?

This fits the model using 10 batches of 64 samples per epoch:
model.fit(train_data, epochs=5, steps_per_epoch=10)

If the Dataset is .batched with 64 samples, but has more than 640 samples (say 2000), are all those remaining samples used at all ?

Yes @ghsanti -
All remaining samples are used for training at all. Here there is 64 samples means batch size is 64 and steps_per_epoch is 10. This means model iterate through the dataset 10 times in one epoch. So for example in first step first 64 sample will train, then second step next 64 samples and so on upto 2000 samples will use for training.

thanks !


Found a new way to bypass login

I see that you've already worked on this issue before. But I found a new way that will bypass the login screen.
Just by putting #authorized=access_granted after the app URL will bypass the login screen.

Thanks for bringing this to our attention

Issue resolved in latest version: 1.1
Please reopen this issue if you see that it's not resolved. Thanks!


[SE-0039] [SR-3504] Require file literal argument to be a static string

A coordinate change for apple/swift#6503. See that PR for discussion.

Closing this PR because an alternative solution is to be used to resolve SR-3504.


Bot stuck on loading

Hi,
After install I can't login to frontend and stuck on loading page.
In ws I have:

On browser:
{"command":"latest","authToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdXRoZW50aWNhdGVkQXQiOiIyMDIyLTExLTA3VDE3OjMxOjI4LjI1MVoiLCJpYXQiOjE2Njc4NDIyODgsImV4cCI6MTY2Nzg0OTQ4Ok0.OXr3Ke4OKk95zeUF3DDKcem2HaBH_ZFJiqS1D5QK6N4","data":{"page":1,"searchKeyword":"","sortBy":"default","sortByDesc":false}}
On docker:
{"name":"binance-api","version":"0.0.93","hostname":"dd1f1cef3a7c","pid":46,"gitHash":"26a1edc","server":"websocket","payload":{"command":"latest","authToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdXRoZW50aWNhdGVkQXQiOiIyMDIyLTExLTA3VDE5OjAyOjE4LjUwMVoiLCJpYXQiOjE2Njc4NDc3MzgsImV4cCI6MTY2Nzg1NDkzOH0.vENNQ_OEw9Q1Uw0n6EaR2VNA4k_pSqB9vY4kv3OFunc","data":{"page":1,"searchKeyword":"","sortBy":"default","sortByDesc":false},"isAuthenticated":true},"level":50,"err":{"message":"Unexpected token u in JSON at position 0","name":"SyntaxError","stack":"SyntaxError: Unexpected token u in JSON at position 0\n    at JSON.parse ()\n    at Object.handleLatest [as latest] (/srv/dist/server.js:1:119233)\n    at runMicrotasks ()\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n    at async WebSocket. (/srv/dist/server.js:1:114883)"},"msg":"Something wrong with trailing-trade-common cache","time":"2022-11-07T19:05:11.986Z","v":0}

same problem

Same here, using binance testnet key and test mode in the bot env. Stuck on loading after entering the password

same here with latest release

Hi guys,
Sorry for the late reply.
Please refer Troubleshooting wiki page and get the error log.
https://github.com/chrisleekr/binance-trading-bot/wiki/Troubleshooting
Without an error log, I won't be able to find out what is happening.
And please make sure your key and BINANCE_MODE are correct.

The same problem continues

{"name":"binance-api","version":"0.0.94","hostname":"38825bfcaef1","pid":46,"gitHash":"29944c1","server":"websocket","payload":{"command":"latest","authToken":"","data":{"page":1,"searchKeyword":"","sortBy":"buy-difference","sortByDesc":false},"isAuthenticated":true},"level":50,"err":{"message":"Unexpected token u in JSON at position 0","name":"SyntaxError","stack":"SyntaxError: Unexpected token u in JSON at position 0\n    at JSON.parse ()\n    at Object.handleLatest [as latest] (/srv/dist/server.js:1:119454)\n    at runMicrotasks ()\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n    at async WebSocket. (/srv/dist/server.js:1:115058)"},"msg":"Something wrong with trailing-trade-common cache","time":"2022-11-30T09:23:35.176Z","v":0}

{"name":"binance-api","version":"0.0.94","hostname":"fc64d7b7c46a","pid":46,"gitHash":"29944c1","server":"websocket","payload":{"command":"latest","authToken":"","data":{"page":1,"searchKeyword":"","sortBy":"buy-difference","sortByDesc":false},"isAuthenticated":true},"level":50,"err":{"message":"Unexpected token u in JSON at position 0","name":"SyntaxError","stack":"SyntaxError: Unexpected token u in JSON at position 0\n    at JSON.parse ()\n    at Object.handleLatest [as latest] (/srv/dist/server.js:1:119454)\n    at runMicrotasks ()\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n    at async WebSocket. (/srv/dist/server.js:1:115058)"},"msg":"Something wrong with trailing-trade-common cache","time":"2022-11-30T10:19:32.158Z","v":0}

Guys,
I've added the error message.
In my experience, most of your issues are caused by using the wrong API key/secret.
This fix will show the possible scenario of errors.

Issue still persists

@chrisleekr json for account-info not parsing
bad json in response
https://github.com/chrisleekr/binance-trading-bot/blob/49271ef5993a2c9c579d54bff1d9d81780b99a2f/app/frontend/websocket/handlers/latest.js#L117


ROX-20318: Move operator lower bound OCP version 4.10 -> 4.11

Description
This change is because OCP 4.10 reached EoL and we don't get new operator versions published downstream for it.
Here's info https://docs.engineering.redhat.com/display/SP/Shipping+Operators+to+EOL+OCP+versions
The similar change will be made downstream as part of the same ticket ROX-20318.
E2E tests were already adjusted for 4.11 instead of 4.10 in https://issues.redhat.com/browse/ROX-20167.
Checklist

[ ] Investigated and inspected CI test results

None of these are needed:

[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

Testing Performed
Here I tell how I validated my change
I won't do any manual testing for this change, rather will run OSCI operator tests for higher and lower OCP bounds.
I will not specifically validate that the new value works as expected because the change should be self-evident and I use benefit of relying that this attribute should work as expected.
Reminder for reviewers
In addition to reviewing code here, reviewers must also review testing and request further testing in case the
performed one does not seem sufficient. As a reviewer, you must not approve the change until you understand the
performed testing and you are satisfied with it.

/test ?

/test ocp-4-14-operator-e2e-tests


Default executor is not using the expected node version

Orb Version: v1.0.1
Describe the bug
Serverless 2.69.0 is requiring Node 16 binaries.
The default executor version is using python 3.8-node which embeds node 14.

Deployment fails to upload the artifacts to S3

This is the error message you can expect

Resource handler returned message: "Uploaded file must be a non-empty zip (Service: Lambda, Status Code: 400, ...)"

To Reproduce
run deploy with default executor version
Expected behavior
deployment succeed
Additional context
N/A
Work around
Set the VERSION environment alongside the executor to set the SLS version to 2.68.x
Possible fix

Allow parameter to chose which version of SLS to install and then use curl -o- -L https://slss.io/install | VERSION=2.21.1 bash
Update default python image version

docker run -it cimg/python:3.8-node bash
...
circleci@6c47c8edc792:~/project$ node --version
v16.14.2

3.10 is the latest version of python available which appears to have the same Node version present. The version parameter has been added and will be available in the next release (due to come out today or tomorrow). Please keep an eye out on the releases/tags for a new version coming shortly.

Hello,
Thank you all for reporting this issue. We have just released version 2.0.0 which should resolve this problem. Please try the latest version of the orb and let us know if you experience any issues.
https://github.com/CircleCI-Public/serverless-framework-orb/releases/tag/v2.0.0
https://circleci.com/developer/orbs/orb/circleci/serverless-framework


Google admob

https://user-images.githubusercontent.com/93048087/153824007-46320376-8308-4428-9007-738c3d0720d1.mp4
https://youtu.be/YnKt6w34I40

 googlereno.web.comUploading - app_open_cold_start_times.mp4 …

@a2425rdl This azure-docs repository deals about feedback related to particular Azure document page (like correcting doc bugs, doc enhancements, product issues related to wrong doc instructions, etc.) so if issue is intended to update / correct / enhance anything in an Azure document then please share Azure document link / URL and share the feedback related to it. If thats not the case then please don't spam.


Broken array test case

This PR adds a failing test case that's supposed to work just fine.

Thanks for spotting this issue and filing this PR! :+1: Unfortunately, the tests contains an error, the changes LGTM otherwise :+1:

For future reference: This PR addresses an actual issue in the server-side inline request parser and adds an unrelated test to the fully working client-side response parser. See also the follow-up PR #13 for the actual issue when parsing multiple inline requests at once.


docs: "Ensure some resource types are always created"

Fix the example in docs/examples as mentioned in #339

Pull Request Test Coverage Report for Build 1228

0 of 0   changed or added relevant lines in 0 files are covered.
6 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.3%) to 57.088%

Files with Coverage Reduction
New Missed Lines
%

terraform_compliance/common/defaults.py
6
85.0%

Totals

Change from base Build 1225:
0.3%

Covered Lines:
1345

Relevant Lines:
2356

💛  - Coveralls

Should there be description for each example or are they clear enough as they are?

I think they are good, but extra explanation is always welcome


WIP: Typed variables

Needs a Cattle release for integration tests to pass.

This conflicts with https://github.com/rancher/rancher-compose-executor/pull/70.  We need to re-evaluate this approach in 2.0


import code to typescript extension webpack config

This is draft of import of existing code base of v0.1.0 branch (the release of extension) to webpack TypeScript extension config that works with crypto dependencies and tries to compile everything.
It is not left to fix TypeScript errors. To that extent, tsc-silent is used to mute some (for time being and for benign ones) and focus on real potential issues with migrating this code base to TypeScript.

having type info will be a big help to the readability of this codebase. there are lots of places where we have various objects flowing through various message passing mechanisms, and historically there have been mistakes on the types of those objects.


Add rich.version

rich should have __version__ property.
AttributeError: module 'rich' has no attribute '__version__'

This is a common python convention to tell package version easily.

I use poetry to do packaging, which recommends pkg_resources to get the version from meta data. They initially recommended dropping __version__ entirely. Fortunately there some to be some movement on that front, and we may get __version__ back.

Thanks for the feedback. But why is it closed (it's still unimplemented)? Even though poetry is used, we could add this property with a workaround.

Keeping the version in two places is problematic. But if poetry hasn't got a solution when I release a 1.0 version, that's what I might have to do. In the meantime, the lack of a __version__ isn't going to break anything that I know of, and pkg_resources.get_distribution("rich").version can be used to get the version.

Just a note. For Python 3.8+, importlib.metadata should probably be used instead. And the importlib_metadata backaport exists for other Python 3 versions. It was created to replace pkgresources metadata functionality.
Here's how I use it to deduplicate my package metadata. I use poetry, too, and I couldn't wait any longer. I already had that module and was manually updating it.

I may end up doing something similar...

Thanks for the feedback. But why is it closed (it's still unimplemented)? Even though poetry is used, we could add this property with a workaround.

Still seems to missing __version__, if the intention was for it to be added by v1.0 then perhaps this issue should have been left open...

Don't know where you got that idea from.

I didn't mean to sound adversarial! It was your message above that gave me this impression:

Keeping the version in two places is problematic. But if poetry hasn't got a solution when I release a 1.0 version, that's what I might have to do.

Personally I agree with the OP that it's pretty standard to provide this, but it's up to you of course.

It was a standard of sorts, but now importlib is recommended, and __version__ is a convenience.
Unless poetry has an answer to this that doesn't require a backport of importlib, I'm afraid there is no motivation to change it.


Are there any possibility of putting an event click in slide to redirect to another page?

I want to know if I can put the event click in angular 14.2.0 in slide or know, if already exist some function that do this?
for example, look the picture.

Hey @joolmosd I faced the same problem that you.
I solved on this way

Hi @fonsecapontes I apprecie your help, I'm going to try your solution and I tell you how is it going.
Regards!!


HBASE-24659 Calculate FIXED_OVERHEAD automatically

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 19s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 58s
master passed

+1 :green_heart:
checkstyle
1m 39s
master passed

+1 :green_heart:
spotbugs
2m 50s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 48s
the patch passed

+1 :green_heart:
checkstyle
0m 26s
The patch passed checkstyle in hbase-common

+1 :green_heart:
checkstyle
1m 16s
hbase-server: The patch generated 0 new + 197 unchanged - 9 fixed = 197 total (was 206)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
12m 23s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
3m  8s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 23s
The patch does not generate ASF License warnings.

39m 42s

Subsystem
Report/Notes

Docker
Client=19.03.9 Server=19.03.9 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 60fd4891054b 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / a7a0e1a596

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m  8s
the patch passed

+1 :green_heart:
compile
1m 30s
the patch passed

+1 :green_heart:
javac
1m 30s
the patch passed

+1 :green_heart:
shadedjars
5m 53s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 17s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 43s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 26s
hbase-common in the patch passed.

+1 :green_heart:
unit
129m 50s
hbase-server in the patch passed.

161m 50s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 4b16bbdbf512 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / a7a0e1a596

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/testReport/

Max. process+thread count
4519 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 15s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 46s
master passed

+1 :green_heart:
checkstyle
1m 42s
master passed

+1 :green_heart:
spotbugs
2m 44s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 46s
the patch passed

+1 :green_heart:
checkstyle
0m 23s
The patch passed checkstyle in hbase-common

+1 :green_heart:
checkstyle
1m 17s
hbase-server: The patch generated 0 new + 197 unchanged - 9 fixed = 197 total (was 206)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
12m 18s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
3m  8s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 21s
The patch does not generate ASF License warnings.

38m 55s

Subsystem
Report/Notes

Docker
Client=19.03.9 Server=19.03.9 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 025b92fe8378 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fe2ae809d1

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  1s
the patch passed

+1 :green_heart:
compile
1m 29s
the patch passed

+1 :green_heart:
javac
1m 29s
the patch passed

+1 :green_heart:
shadedjars
5m 44s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 18s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 38s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 24s
hbase-common in the patch passed.

+1 :green_heart:
unit
129m 46s
hbase-server in the patch passed.

159m  5s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 449b58a7ac6e 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fe2ae809d1

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/testReport/

Max. process+thread count
4275 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 35s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m  2s
master passed

+1 :green_heart:
compile
1m 51s
master passed

+1 :green_heart:
shadedjars
7m 32s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 13s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 13s
the patch passed

+1 :green_heart:
compile
2m  2s
the patch passed

+1 :green_heart:
javac
2m  2s
the patch passed

+1 :green_heart:
shadedjars
7m 38s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 18s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 49s
hbase-common in the patch passed.

+1 :green_heart:
unit
223m 31s
hbase-server in the patch passed.

262m 17s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3516ce982d3c 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / fe2ae809d1

Default Java
1.8.0_232

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/testReport/

Max. process+thread count
3502 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

I wonder do we still need the testSizes method in TestHeapSize after this change? And we need a performance test to see if there are any impact on performance(although I believe no)
Yes, this change only affect class loading phase. And the calculation of FIXED_OVERHEAD cost less than 5 milliseconds

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 30s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  7s
master passed

+1 :green_heart:
checkstyle
1m 44s
master passed

+1 :green_heart:
spotbugs
3m  1s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 51s
the patch passed

-0 :warning:
checkstyle
1m 15s
hbase-server: The patch generated 1 new + 197 unchanged - 9 fixed = 198 total (was 206)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
12m 41s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
3m 53s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 26s
The patch does not generate ASF License warnings.

42m 11s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 325d7d6139e8 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 724f0478ed

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Let's run a YCSB or at least a PE to see the performance impact?

Let's run a YCSB or at least a PE to see the performance impact?

yes,it is necessary, Let me do it

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 30s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 31s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m  7s
master passed

+1 :green_heart:
compile
1m 30s
master passed

+1 :green_heart:
shadedjars
5m 45s
branch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 18s
hbase-common in master failed.

-0 :warning:
javadoc
0m 38s
hbase-server in master failed.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  1s
the patch passed

+1 :green_heart:
compile
1m 30s
the patch passed

+1 :green_heart:
javac
1m 30s
the patch passed

+1 :green_heart:
shadedjars
5m 45s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 17s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 39s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 24s
hbase-common in the patch passed.

+1 :green_heart:
unit
131m 31s
hbase-server in the patch passed.

160m 54s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux fcb5d62e8a79 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 724f0478ed

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/testReport/

Max. process+thread count
4397 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 33s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 11s
master passed

+1 :green_heart:
compile
1m 30s
master passed

+1 :green_heart:
shadedjars
6m 25s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 57s
the patch passed

+1 :green_heart:
compile
1m 22s
the patch passed

+1 :green_heart:
javac
1m 22s
the patch passed

+1 :green_heart:
shadedjars
6m  6s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 55s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 30s
hbase-common in the patch passed.

+1 :green_heart:
unit
206m 48s
hbase-server in the patch passed.

237m 51s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux ac959d357f64 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 724f0478ed

Default Java
1.8.0_232

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/testReport/

Max. process+thread count
3826 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 48s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 33s
master passed

+1 :green_heart:
checkstyle
2m  1s
master passed

+1 :green_heart:
spotbugs
3m 39s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 39s
the patch passed

-0 :warning:
checkstyle
1m 35s
hbase-server: The patch generated 1 new + 197 unchanged - 9 fixed = 198 total (was 206)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
15m  9s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
3m 56s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 23s
The patch does not generate ASF License warnings.

48m 27s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 9f622842ffd6 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / af1cc2fc44

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

 Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 44s
the patch passed

+1 :green_heart:
compile
1m 20s
the patch passed

+1 :green_heart:
javac
1m 20s
the patch passed

+1 :green_heart:
shadedjars
6m  0s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 55s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 28s
hbase-common in the patch passed.

+1 :green_heart:
unit
208m 19s
hbase-server in the patch passed.

237m 51s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8689e2fd7a9d 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / af1cc2fc44

Default Java
1.8.0_232

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/testReport/

Max. process+thread count
3675 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m  9s
the patch passed

+1 :green_heart:
compile
1m 57s
the patch passed

+1 :green_heart:
javac
1m 57s
the patch passed

+1 :green_heart:
shadedjars
7m 29s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 19s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 52s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
2m 21s
hbase-common in the patch passed.

+1 :green_heart:
unit
200m 26s
hbase-server in the patch passed.

240m  2s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2018

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux c43be12a39b5 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / af1cc2fc44

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/testReport/

Max. process+thread count
3797 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-2018/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Let's run a YCSB or at least a PE to see the performance impact?

@Apache9 sir,I have done the performance test, and attaches on jira page, please take a look ?

@saintstack PTAL. If no objections, I will push this to master and branch-2.
Thanks.

@saintstack please have a look, thanks

Oh, forgot to merge this one. Since you have pinged @saintstack again, let's wait until tomorrow...

Pardon me for missing your pings @nyl3532016 ... let me look.


no such file or directory, open 'C:\xampp\htdocs\myProject\node_modules\vue-pdf\src\componentFactory.js'

After installing npm install --save vue-pdf, then npm run dev then npm run watch. Run my project then I get this error "no such file or directory, open 'C:\xampp\htdocs\myProject\node_modules\vue-pdf\src\componentFactory.js'"
Is there any way to install vue-pdf that won't error? or is there compatibility issues? I already tried to rebuild node_modules but still the error exist.
I am installing vue-pdf version.

After researching I tried to install worker-loader as suggested by tgbv(commented on Jun 5) from this link: "https://github.com/mozilla/pdf.js/issues/10952", however I encountered some errors, some it is:
Invalid handler for event "error": got undefined
found in
--->  at node_modules/vue-pdf/src/vuePdfNoSss.vue
Please help me :)


Add error logging to BuildDeployTools

Overview
I would like to add additional logging to the build window to get more information about build errors so it's easier to diagnose and solve them.
Expected Behavior
When a build error occurs I am able to read the error message.
Actual Behavior
When trying to build APPX through the Build Window, if there are any build errors you only get a message:
Debug.LogError("MSBuild error (code = " + process.ExitCode + ")");
Usually reads out as "MSBuild error code = 1"
This is a generic failure message and doesn't help us diagnose and solve the problem.
Steps to reproduce
Have any problem in your dev environment that would cause building APPX to fail. In my case I had additional VS Build Tools installed along with my VS environment and it caused build failure.
Unity Editor Version
2017.1.3f1
Mixed Reality Toolkit Release Version
2<IP_ADDRESS>

Closing issues older than 180 days. If this is still an issue, please reactivate with recent information.


SSR not reflecting  in the network tab on page refresh or reload

Dear Team,
Many thanks for this great plugin!!!
I'm facing one issue while refreshing the page.
I'm referring to the Next-13 repo, I cloned it and when I navigate to checkout page and refresh it, I can't see the server response in network tab:

And when I used the next-ssr repo then perform the same steps and reload the checkout page, the server return the response (we can see the in-network tab):

I think it should show in the server response (like in nest-ssr repo) when I refreshed the page.
Please let me know if I missed something while running the above apps or I need some different configuration.

Yeah something looks like it might be wrong, ill test it out on my new v7 branch which fixes several things


initial commit of Get-DbaLastBackup

replaces the previous PR due to completely damaged GIT branch

[ ] Working/useful help content, including link to command on dbatools web site
[ ] All examples work as advertised
[ ] Does not contain template content
[ ] Does not contain excessive/unnecessary amounts of comments
[ ] Works remotely
[ ] Works locally
[ ] Works on lower versions or throws error specifying version not supported
[ ] Works with named instances
[ ] Works with clustered instances
[ ] Handles offline/read only databases
[ ] Supports multiple servers (at the command line or piped from Get-SqlRegisteredServerName)
[ ] No un-handled errors which stop the command working with multiple servers


tf3d: object detection 3d

Hi @HRLTY and @afathi3,
Thanks for releasing tf3d repo.
Got some questions regarding current model architecture for 3d object detection:

The graph layer is missing compared with paper. Why? It seems like interesting concept
Can we expect implementation of LSTM enhancement from the second paper?

Regards,

Hi @soldierofhell,
Thank you for your interest.

In the first released version we tried to have the models be as simple as possible. Graph layer usually improves the results slightly (less than 1%), but on the other hand since at this point computing the adjacencies for building the graph happens on CPU, it could slow down training and eval.
Currently LSTM implementation is not released. One obstacle to releasing that is that the functionality in TFDS that lets us read a sequence of frames is not open sourced yet. Once that becomes open source, we can revisit open sourcing that paper again.

Hi @HRLTY and @afathi3,
Is there any inference file for using your trained weight files?? it would be helpful, if there is.
Regards

Hi @shravanti1,
Unfortunately we didn’t not release a trained model therefore no inference
script.
Thanks!
Sincerely,
Rui
On Wed, Sep 11, 2024 at 6:52 AM shravanti1 @.***> wrote:

Hi @HRLTY https://github.com/HRLTY and @afathi3
https://github.com/afathi3,
Is there any inference file for using your trained weight files?? it would
be helpful, if there is.
Regards
—
Reply to this email directly, view it on GitHub
https://github.com/google-research/google-research/issues/574#issuecomment-2343739498,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3WSIPFV2UDSPCM2TCSGZLZWBDIPAVCNFSM6AAAAABOBA45DSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBTG4ZTSNBZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>


#155269192 setup client side test

What does this PR do?
setup client side test
Description of Task to be completed?

install jest
test actions and reducers with jest

How should this be manually tested?
N /A
Any background context you want to provide?
N/A
What are the relevant pivotal tracker stories?
#155269192 setup client side test
Questions:
N/A

Coverage remained the same at 86.592% when pulling 651056e1931cbf34e00186890b2083c65840d084 on chore/#155269192/setup-client-side-test into e0ed2aa59b082d521065b1091ca1a873d284bb1e on develope.


Question: What are the normalized cosine distance and normalized angular distance?

What are the advantages and disadvantages of using the normalised distance function?

The advantage is improving the search time by reducing the time of distance calculation. The disadvantage is that you cannot use the index as your original vector repository, because vectors  that are extracted from the index are not original ones but normalized ones. There is no other differences from the denormalized distance.


Refactor all Github/Codecov AB3 links to PayMeLah

Closes #63

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@1fa32a2). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master      #64   +/-   ##
=========================================
  Coverage          ?   72.15%
  Complexity        ?      399
=========================================
  Files             ?       70
  Lines             ?     1232
  Branches          ?      125
=========================================
  Hits              ?      889
  Misses            ?      311
  Partials          ?       32

Impacted Files
Coverage Δ

src/main/java/paymelah/ui/HelpWindow.java
0.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


API Revision for Ease of use and Streaming

It seems to me a base way to use Chevrotain is this:
var chev = require('chevrotain');

var Token1 = chev.extendToken("Token1", /blah/)
  , Token2 = chev.extendToken("Token2", /bleh/)
  , tokens = [ Token1, Token2 ]
  , lexer = new chev.Lexer(tokens, true)
  ;

function MyParser(input) {
  chev.Parser.call(this, input, tokens, { recoveryEnabled: true });

  this.someRule = this.RULE("someRule", function() {
    this.CONSUME(Token1);
  });

  chev.Parser.performSelfAnalysis(this);
}

MyParser.prototype = Object.clone(chev.Parser.prototype);
MyParser.prototype.constructor = MyParser;

var text = getSomeText();

var lexResult = lexer.tokenize(text);
  , parser = new MyParser(lexResult.tokens);

var value = parser.someRule();

This seems like a complicated way to link everything together. How about:

give the Parser the Lexer so it can use it on any input provided to the Parser
receive input in a function call instead of setting it directly and triggering a change from that
allow configuring a default rule to call when provided input to parse(input)
instead of creating a new Parser class and loading the rules in its constructor, create a Parser instance and then add rules to it via function calls (Avoids all that annoying inheritence stuff)
instead of storing the rules on the Parser object itself, store them into an internal rules object so they can be provided as an arg to the function calls
instead of having all the tokens available globally, put them in the Lexer (and then the Lexer is provided to the Parser). They can still be provided to function calls via the object containing them.
The Parser has the Lexer so, for new input, it can provide that to the Lexer's tokenize() function to get the tokens to work with. Also, it could do this asynchronously by having the Parser provide a callback function as the second arg to tokenize(). The Lexer can call that callback with each Token it finds as it lexes the input. The Parser can also return different things from that callback to direct the Lexer what to do.

For example, to make the same as above, it would be like this:
var chev = require('chevrotain')
  , lexer = new chev.Lexer();

// something like this, or addToken()
lexer.token("Token1", /blah/);
lexer.token("Token2", /bleh/);
// or tokens() taking an object
lexer.tokens({
  Token1: /blah/,
  Token2: /bleh/
});

var parser = new chev.Parser(lexer, {
  recoveryEnabled: true, defaultRule:'someRule'
});

parser.addRule("someRule", function(T, R) {
  // `R` is the object containing all the RULEs
  // `T` is the object containing all the tokens
  this.CONSUME(T.Token1);
  // I didn't make another rule... but, here's an example of using one:
  // this.SUBRULE(R.AnotherRule);
});

// require us to do this after all rules are specified.
// Or, when the first rule is run, or parse(input) is called, do this automatically.
parser.performSelfAnalysis();

var text = getSomeText()
  // could have alternate forms to specify different starting rule...
  , value = parser.parse(text)
  // or... specify the starting rule, optionally, if there isn't a `defaultRule`
  , value2 = parser.parse(text, 'someRule')

Syntax at the high level.
I'll admit the base way using Chevrotain with EcmaScript 5 is not the prettiest...
However Chevrotain is based around future versions of JavaScript, mainly because Chevrotain was originally used in a TypeScript project.
This is how it looks like using TypeScript/ES Next.
import {
    Parser,
    Token
} from "chevrotain"
// with ES6 imports it is very convenient to export each token individually and define them in a separate file.
import {
    allTokens,
    LCurly,
    Comma,
    RCurly,
    StringLiteral,
    Colon
} from "./lexer"

export class JsonParser extends Parser {
    constructor(input:Token[]) {
        super(input, allTokens)
        // With ES Next definition of methods as variables (parsing rules) the constructor is much cleaner.
        Parser.performSelfAnalysis(this)
    }

    // Can control rules access using access modifiers
    // there is already a suggestion for private fields: https://github.com/tc39/proposal-private-fields
    public object = this.RULE("object", () => {
        this.CONSUME(LCurly)
        this.MANY_SEP(Comma, () => {
            this.SUBRULE2(this.objectItem)
        })
        this.CONSUME(RCurly)
    })

    // can be private access if we only want to expose a single top level rule.
    private objectItem = this.RULE("objectItem", () => {
        this.CONSUME(StringLiteral)
        this.CONSUME(Colon)
        this.SUBRULE(this.value)
    })
}

Even defining the Tokens is much prettier using ES Next / Typescript given classes (ES6) and Static Properties (ES Next).
export class LCurly extends Token { static PATTERN = /{/}
export class RCurly extends Token { static PATTERN = /}/}
export class Comma extends Token { static PATTERN = /,/}
export class Colon extends Token { static PATTERN = /:/}
export class WhiteSpace extends Token {
    static PATTERN = /\s+/
    static GROUP = Lexer.SKIPPED
}

So Chevrotain is trying "aim" for the future in terms on syntax while staying compatible with the present.  But the main focus is the future.
I'll reply to the other suggestions separably.

// this:
import {Lexer} from 'chevrotain';
let lexer = new Lexer();
export default lexer;
lexer.tokens({
  LCurly: /{/,
  RCurly: /}/,
  Comma: /,/,
  Colon: /:/,
  WhiteSpace: { pattern: /\s+/, group:Lexer.SKIPPED }
});

// in another file, do:
import lexer from './lexer'

// and have:
lexer.tokens.LCurly

// versus this:
export class LCurly extends Token { static PATTERN = /{/}
export class RCurly extends Token { static PATTERN = /}/}
export class Comma extends Token { static PATTERN = /,/}
export class Colon extends Token { static PATTERN = /:/}
export class WhiteSpace extends Token {
    static PATTERN = /\s+/
    static GROUP = Lexer.SKIPPED
}

Why repeatedly write the words "export", "class", "extends", "Token", "static", and "PATTERN" ?
Why extend the Token class without adding any new behaviors? Instead, instantiate a Token instance with the desired pattern and, optionally, group. Do that instantiation internally so the dev only has to write the options.
Same with the Parser. Why extend the class when we're not creating a new class, we're just loading rules into a Parser instance.
import lexer from './json-lexer'
import {Parser} from "chevrotain"

// export a builder function to make the 'JsonParser'.
// accept the Lexer instance which both has the tokens
// and is ready to tokenize input for the Parser.
export default function () {
    // the parser we'll return. use the 'json lexer' we imported.
    // could allow the builder function to accept a different lexer...
    let parser = new Parser(lexer)

    // add the rules by providing an object
    parser.rules({
        // the common case where a rule is just a function.
        // this could mean private or public, up to you.
        object: (R, T) => {
            this.CONSUME(T.LCurly)
            this.MANY_SEP(T.Comma, () => {
                this.SUBRULE2(R.objectItem)
            })
            this.CONSUME(T.RCurly)
        },

        // the less common case where we provide an options object so we can specify
        // public:true or private:true or whatever else, with the function as `fn`
        objectItem: {
            private: true,
            fn: (R, T) => {
                this.CONSUME(T.StringLiteral)
                this.CONSUME(T.Colon)
                this.SUBRULE(R.value)
            }
        }
    })

    Parser.performSelfAnalysis(parser)
    // or: parser.optimize()
    return parser
}

I prefer this because it creates instances instead of classes. And, it avoids carrying all the Token variables in the scope. It's possible to have a lot of tokens and we'd have to type them once in the exporting file and then once in each file importing them all. I suppose there's a way to do export * from tokens and import * from './lexer-tokens'. Anyway, there's no need when they can be contained in the Lexer instance and accessed from there in the parser functions.
Of course, this is all my opinion based on my own preferences. I'm not expecting you to agree :)  I only want to share my thoughts in case you find them useful. Thank you for reading my babble, and making chevrotain.

I'm always  happy to get feedback @elidoran 👍
There are a few reasons why Tokens/ Parsers are created as exported classes.

In some flows the token instances are saved in the parser's output. For example when writing a parser for an IDE and implementing text manipulation capabilities (refactoring / formatting).
In such use cases a naive AST will not have enough information to represent the original text input.
But if the Token instances are used after Chevrotain related flows (Lexing / Parsing) it makes sense to export them as well so other flows can use them.

Chevrotain supports the concept of Token Inheritance which allows for more dynamic grammars.

Chevrotain supports concepts of Grammar inheritance as well, including rules overriding. So once again modeling the simple case as inheritance makes sense to allow supporting the complex cases.

Another thing to note is that the Chevrotain Lexer outputs Chevrotain Tokens, but Chevrotain Tokens can be defined independently of the Lexer to enable support for custom hand built lexers.

On  Syntax
Syntax preferences are subjective. But because Chevrotain is an internal JavaScript DSL
without a code generation phase you should be able to customize the syntax for your needs
in most cases.
So everybody wins 😄
You wanted to write something like this:
import {Lexer} from 'chevrotain';
let lexer = new Lexer();
export default lexer;
lexer.tokens({
  LCurly: /{/,
  RCurly: /}/,
  Comma: /,/,
  Colon: /:/,
  WhiteSpace: { pattern: /\s+/, group:Lexer.SKIPPED }
});

// in another file, do:
import lexer from './lexer'

// and have:
lexer.tokens.LCurly
}

Lets create Tokens from an Object

// utility function created ONCE and used in ALL your grammars
function myCreateTokenSyntax(tokObj) {
    let allTokens = []
   _.forEach(tokObj, (curValue, currKey) => {
        if (_.isRegExp(currValue)) {
           allTokens.push(chevrotain.extendToken(currKey, currValue)
        }
        // handle static props here
        else {
           let currNewToken = extendToken (currKey, currValue.pattern)
           currNewToken.group = currValue.group
           ...
        }
    })

    let lexer = new chevrotain.Lexer(allTokens)
    lexer.tokens = allTokens
    return lexer;
}

// -----------------------------------------
import {myCreateTokenSyntax} from "myChevrotainUtilities";

let lexer = myCreateTokenSyntax({
  LCurly: /{/,
  RCurly: /}/,
  Comma: /,/,
  Colon: /:/,
  WhiteSpace: { pattern: /\s+/, group:Lexer.SKIPPED }
})

// this is both a Lexer instance and also carries the list of Tokens.
export lexer

btw there exists:
import {* as tok} from "......"

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import
And in modern IDEs the import statements will get updated / organized / inserted as you type.
So you normally don't even have to handle those manually.

Well, I think you work in a verbose and inheritance based zone where solutions all look like that. :)  You're obviously very skilled and experienced with it. Chevrotain certainly provides a ton of functionality and works well.
Basically, I disagree with the idea inheritance has those merits. For me, it creates unnecessary complexity which is difficult to maintain, alter, and use. Both dynamism and adaptable functionality are achievable by other means.
Thank you for spending your time writing the utility function to show how to adapt what I was suggesting to work with Chevrotain as it is now. :)

Well, I think you work in a verbose and inheritance based zone where solutions all look like that. :)

I'm usually the one on the side of the anti inheritance debate. so it is interesting to be on the other side 😄
I'd rather think of myself as multidisciplinary rather than following a single paradigm.
Chevrotain itself is a good example of that:

To enable high performance and grammar validations while avoiding code generation a Meta Programing approach was used.
The string representation of the 2nd $.RULE argument (using Function.prototype.toString)
is parsed at runtime to construct a representation of the grammar structure before
any parsing is done. This is effectively a poor man's implementation of read only Macros
Which are highly popular in Lisp style languages (although in Lisp Macros can also "write" code).

        $.object = $.RULE("object",
            // the String representation of this function will be parsed
            // to understand the grammar of this rule is:
            // object:
            //    LCurly (Colon)? RCurly
            () => {
               $.CONSUME(LCurly);
               $.OPTION(() => {
                   $.CONSUME(Colon);
               });
               $.CONSUME(RCurly);
        });

Code where performance is of lower concerns uses functional style immutable series of transformations.

Grammar Validations
Lexer Token's analysis

Code where performance is of the highest concern uses C like Imperative style loops and mutability.

Lexer Engine
Lookahead functions

For internal AST representing the grammar, an Object Oriented Programing Visitor Pattern is used.

Visitor

Also consider that certain API related decisions (Tokens as Classes for example) were not made in a vacuum or without constraints. For example:
In the project where Chevrotain was first used, it was not as a separate library but as part of the project source itself. That project used TypeScript and already had Tokens as classes in a previous Parser implementations, so it was not so much that a decision was made, rather that what seemed like common sense for the current specific use case was done.
At the end of the day I'm pleased with the results, even if the base API may be opinionated
It is compatible with future versions of JavaScript. And if different API is required, Chevrotain
is malleable enough to allow that as well.

This is what I've been using to mess around.
I made a LexerParser class which extends your Parser:
# in 'LexerParser.coffee'
{extendToken, Lexer, Parser} = require 'chevrotain'

class LexerParser extends Parser

  @SKIPPED = Lexer.SKIPPED

  constructor: (options = {}) ->
    super [], []

    # store the constructor options for later use
    @_buildOptions = options

    # store Token classes, by name, on this Lexer/Parser
    @T = {}

    # store token array for Parser constructor call
    @tokenArray = []

    @defaultRule = options.defaultRule

    if options.addTokens? then @addTokens options.addTokens
    if options.addRules? then @addRules options.addRules

  _prepare: ->

    if @__needPrepare is false then return

    @__needPrepare = false

    @lexer = new Lexer @tokenArray, true

    Parser.performSelfAnalysis this

  _addToken: (name, options) ->
    pattern = options.pattern ? options
    @T[name] = token = extendToken name, pattern
    if options.group? then token.GROUP = options.group
    @tokenArray.push token

  addTokens: (tokens) ->
    @_addToken name, options, false for own name, options of tokens
    # Parser needs tokens to constructor so it's ready for adding rules
    Parser.call this, [], @tokenArray, @_buildOptions

  addRules: (rules) -> @RULE name, fn for own name,fn of rules

  parse: (input, options) ->

    @_prepare input

    results = @lexer.tokenize input
    @input = results.tokens

    rule = options?.start ? @defaultRule

    value      : @[rule]()
    lexErrors  : results.errors
    parseErrors: @errors

With that class I can create an instance and then add both tokens and rules via convenience functions. Then have it parse text via parse().
It doesn't allow all the varied functionality of the base Lexer and Parser classes, but, it allows the single mode basic tokens stuff I'm doing.
Here's the JSON parser example using it:
jsonParser = new LexerParser

  defaultRule: 'json'

  addTokens:
    WhiteSpace:
      pattern: /\s+/
      group  : LexerParser.SKIPPED
    NumberLiteral: /-?(0|[1-9]\d*)(\.\d+)?([eE][+-]?\d+)?/
    StringLiteral: /"(?:[^\\"]+|\\(?:[bfnrtv"\\/]|u[0-9a-fA-F]{4}))*"/
    LCurly : /{/
    RCurly : /}/
    LSquare: /\[/
    RSquare: /]/
    Comma  : /,/
    Colon  : /:/
    True   : /true/
    False  : /false/
    Null   : /null/

  addRules:
   json: ->
      @OR [
        { ALT: -> @SUBRULE @object }
        { ALT: -> @SUBRULE @array }
      ]

    object: ->
      @CONSUME @T.LCurly
      @MANY_SEP @T.Comma, -> @SUBRULE2 @objectItem
      @CONSUME @T.RCurly
      return

    objectItem: ->
      @CONSUME @T.StringLiteral
      @CONSUME @T.Colon
      @SUBRULE @value
      return

    array: ->
      @CONSUME @T.LSquare
      @MANY_SEP @T.Comma, -> @SUBRULE @value
      @CONSUME @T.RSquare
      return

    value: ->
      @OR [
        { ALT: -> @CONSUME @T.StringLiteral }
        { ALT: -> @CONSUME @T.NumberLiteral }
        { ALT: -> @SUBRULE @object }
        { ALT: -> @SUBRULE @array }
        { ALT: -> @CONSUME @T.True }
        { ALT: -> @CONSUME @T.False }
        { ALT: -> @CONSUME @T.Null }
      ]

# or could return the `jsonParser` itself and let them call its `parse()`.
module.exports = (text) -> jsonParser.parse text

Note, I added explicit "return" statements to some of the rules because CoffeeScript returns the last value by default, so, it was returning the result of the last CONSUME or SUBRULE call.
This stuff is just for fun. I'm sharing it so you can see how I'm messing with things compared to the CoffeeScript example you made recently. It allows doing things the way I was babbling about on top of the current implementation.

This looks very good.
Particularity the terse Token definitions.
I'm wondering if such API should be a part of Chevrotain.
The problem is that because it wraps the basic Chevrotain API it hides away many capabilities.
These capabilities may only be relevant some of the time... but it would be strange if someone using
Chevrotain would have to perform a large refactor just to add a small built in capability.
Perhaps if you ever have a productive use case for Chevrotain and implement these wrappers for yourself. They have a place as a separate npm package.

Sorry to revive an old issue, but is the class X extends Token with static fields paradigm supported in recent versions of chevrotain or is it something that was just planned for the future? Trying to import Token with TypeScript results in an error.

That syntax was deprecated as Tokens support multiple inheritance (categories) so modeling these
as ECMAScript classes was not appropriate.

https://sap.github.io/chevrotain/docs/changes/BREAKING_CHANGES.html#_2-0-0

Here is an example of a Chevrotain Parser written in TypeScript:

https://github.com/SAP/chevrotain/blob/master/examples/implementation_languages/typescript/typescript_json.ts

I see, thank you for the prompt response. It may be worth updating the documentation here removing the bit about static fields to avoid confusion.

You mean?

We will use the createToken API in the rest of tutorial because ES2015 has no support for static fields.

This looks like a legacy reference... or did you mean anything else?

Yeah that's what I meant, the language of it makes it seem like static fields are the preferred method (or at least a non-deprecated method) for doing this if you're using a language version that supports them.


plot_alignment should show transparent brain when using sEEG electrodes

Describe the new feature or enhancement
Using plot_alignment to see where sEEG electrodes are located in the brain.  So it would be best to give the brain a bit of transparency when you have sEEG electrodes embedded in the brain.
Describe your proposed implementation
As far as I can tell, this is a single line change. I have already created a feature branch in my fork which changes the setting of opacity depending on whether there are sEEG electrodes present for plotting.
https://github.com/kdoelling1919/mne-python/blob/5b039cdfb3da64c89947f09a0bfd83481955f29c/mne/viz/_3d.py#L840
Describe possible alternatives
Another option might be to set transparency generally any time there are sensors to be plotted that are inside the brain volume. Sounds like a bit more work (and more knowledge about the surfaces than I currently have) but it would be more general.
Additional comments
Here is what the plot_alignment looks like in current master version of plot_alignment

Here is what it looks like in my branch.

If people agree this is useful beyond just for myself. I'll make the pull request.
Thank you!

@GuillaumeFavelier thoughts? any way to expose such options?

Yeah, I prefer the result with transparency

any way to expose such options?

plot_alignment has so many parameters already, I would rather not add another one. I prefer the auto-detection approach. I think computing the bounds of the brain surface is enough as a compromise between precision and computational cost.

Currently we make the innermost surface opaque (alpha=1). It's probably fine instead just to always make the innermost surface translucent (alpha=0.75 or something). That way you can see stuff behind it anyway, which is nice. Would that work for your sEEG example?
These are the examples where plot_alignment is used:
https://mne.tools/dev/generated/mne.viz.plot_alignment.html#examples-using-mne-viz-plot-alignment
@kdoelling1919 if you want to make a pull request with this change, if you could make minor improvements to wording if possible (otherwise just add an extra PEP8-compatible newline somewhere) to some of them, it will cause CircleCI to render them so we can see the outputs. Ideally you could pick examples that cover the various uses of surfaces that we have. I'd guess there would be 4 or 5 different ways we use surfaces in our examples.
In a worst case we can make surfaces be a dict mapping surface names to alpha values, but I'd rather avoid that API change if possible.

That's wonderful! That's what I want!

OK. So i'm not totally clear where we've landed. Seems like options are:

leave the change as I have it (reducing alpha when using seeg)
set the innermost to always be 0.75
auto-detect surfaces with electrodes inside of them and reduce alpha for these surfaces

I'm happy with any of them. Though I can imagine that if we changed everything to .75 (option 2), some one else will be writing an issue soon enough complaining that they really NEED it to be fully opaque. so I'm inclined to make a more specific change like option 1 or 3.
Once there is consensus, I'll make the PR along with the tutorial changes as @larsoner suggested.

That's wonderful! That's what I want!

Describe the new feature or enhancement
Using plot_alignment to see where sEEG electrodes are located in the brain.  So it would be best to give the brain a bit of transparency when you have sEEG electrodes embedded in the brain.
Describe your proposed implementation
As far as I can tell, this is a single line change. I have already created a feature branch in my fork which changes the setting of opacity depending on whether there are sEEG electrodes present for plotting.
https://github.com/kdoelling1919/mne-python/blob/5b039cdfb3da64c89947f09a0bfd83481955f29c/mne/viz/_3d.py#L840
Describe possible alternatives
Another option might be to set transparency generally any time there are sensors to be plotted that are inside the brain volume. Sounds like a bit more work (and more knowledge about the surfaces than I currently have) but it would be more general.
Additional comments
Here is what the plot_alignment looks like in current master version of plot_alignment

Here is what it looks like in my branch.

If people agree this is useful beyond just for myself. I'll make the pull request.
Thank you!

Hi, where is this brain come from. In the tutorial working_ewth_seeg, it's just a skin or a skull? No brain in it.

Though I can imagine that if we changed everything to .75 (option 2), some one else will be writing an issue soon enough complaining that they really NEED it to be fully opaque.

It's possible but really I think the transparent was probably always a better choice. We make aesthetic/functional judgments like this often for our plotting functions. This is why I wanted to make sure that, in your PR, you make some tiny change to each plot_alignment surfaces use "type" so that we can verify things got better in them, not worse.
So I say we try (2) and look at the results. If they look bad, I'd prefer (3) to (1). Making it contingent on sEEG/ECoG does not solve the problem -- for example if you plot EEG+scalp and your dig point is off by a couple of mm it will be inside. In that case should the scalp be transparent? So now the transparency of the surface depends on the locations of the electrodes, etc. It's cleaner to have a standard behavior in all electrode + surface combinations if possible.

@BarryLiu-97 by adding surfaces=["pial", "head"] or just surfaces=["pial"] (for only brain and no skull) as a parameter to plot_alignment should look like this
plot_alignment(raw.info, subject=subject, subjects_dir=subjects_dir,
               trans=trans, show_axes=True, surfaces=["pial", "head"])

o

I agree with you. Why not set this para Customizable?  So people can choose whether  transparent or not?

@BarryLiu-97 by adding surfaces=["pial", "head"] or just surfaces=["pial"] (for only brain and no skull) as a parameter to plot_alignment should look like this
plot_alignment(raw.info, subject=subject, subjects_dir=subjects_dir,
               trans=trans, show_axes=True, surfaces=["pial", "head"])

Thank you so much!

I'm skeptical that option 2 will work, but I'm willing to be proven wrong.
I routinely use plot_alignment to check my coreg results by plotting scalp
surfaces and dig points. I know from various problems in mne_coreg that
being able to see the dig and FID points on both sides of the head through
the scalp surface is not helpful and is generally confusing. Hence my
concern.
Like i said I'm happy to be proven wrong but please consider use cases like
https://mne.tools/stable/auto_examples/visualization/plot_eeg_on_scalp.html#sphx-glr-auto-examples-visualization-plot-eeg-on-scalp-py
when evaluating the change.
Thanks
Luke
On Wed, Oct 28, 2020 at 9:54 AM Keith Doelling<EMAIL_ADDRESS>wrote:

@BarryLiu-97 https://github.com/BarryLiu-97 by adding surfaces=["pial",
"head"] or just surfaces=["pial"] (for only brain and no skull) as a
parameter to plot_alignment should look like this
plot_alignment(raw.info, subject=subject, subjects_dir=subjects_dir,
trans=trans, show_axes=True, surfaces=["pial", "head"])
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/issues/8445#issuecomment-717949040,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABKTXHOUH4CQYXVAYHAHGRTSNAPCPANCNFSM4TCHJWIA
.

Like i said I'm happy to be proven wrong but please consider use cases like

I'm thinking/hoping that this example will look better with alpha=0.75 because you'll get more information -- you'll see the 50%+ of the electrodes not currently visible from that view.
So perhaps we should take a hybrid approach -- implement 2 and 3, so that in the (hopefully rare) cases where things do look worse, people have a way to get back to the old behavior. This is the approach we've been trying to take with topomap plotting and it has seemed to work well so far.
Concretely @kdoelling1919 I would implement this by:

Changing our surface logic so that the innermost surface has alpha=0.75 by default instead of 1.
Make minor changes to a set of examples from the link I pasted above that captures all the use cases of plot_alignment with surfaces  (I'd expect this to be 4 or 5 examples)
Open PR, let CircleCI build, and then we evaluate the results. This tells us if 0.75 is actually better (in the vast majority of cases) or not.
Add surfaces=dict(...) support.
Add tests.

Does that sound like a reasonable plan?

Why not set this para Customizable? So people can choose whether transparent or not?

FYI @BarryLiu-97 the reason I was trying to avoid this is that every time you add more options for people it increases code complexity and maintenance burden at our end, and also makes it harder for people to understand (more options = more complicated interface). But I agree it's probably safer to allow it...

Why not set this para Customizable? So people can choose whether transparent or not?

FYI @BarryLiu-97 the reason I was trying to avoid this is that every time you add more options for people it increases code complexity and maintenance burden at our end, and also makes it harder for people to understand (more options = more complicated interface). But I agree it's probably safer to allow it...

I couldn't agree more.

I'm thinking/hoping that this example will look better with alpha=0.75 because you'll get more information

here is the output of mne coreg with 0.75 head opacity..
mne coreg -s fsaverage -f ~/mne_data/MNE-sample-data/MEG/sample/sample_audvis_raw.fif -d ~/mne_data/MNE-sample-data/subjects/ --head-opacity=0.75

I don't think that additional information is helpful in this case. Which points are inside the head vs on the opposing side of the head?

I don't think that additional information is helpful in this case. Which points are inside the head vs on the opposing side of the head?

Yes I agree this looks confusing in this specific case.

Yes I'm in agreement with @bloyl. Running these tutorials locally, I found that just making everything by default more transparent will make some other use cases harder to read. The reason I liked using only sEEG as a special case for transparency is because it's the only case we have (that I can think of) where you would purposefully have sensors inside the surface of interest, so I think it really is a special case that should be treated differently. Even in the scenario @larsoner mentioned, where one digitized point is accidentally inside the head, I'm not sure I would catch it from a plot like @bloyl just presented.

Yes I'm in agreement with @bloyl. Running these tutorials locally, I found that just making everything by default more transparent will make some other use cases harder to read. The reason I liked using only sEEG as a special case for transparency is because it's the only case we have (that I can think of) where you would purposefully have sensors inside the surface of interest, so I think it really is a special case that should be treated differently. Even in the scenario @larsoner mentioned, where one digitized point is accidentally inside the head, I'm not sure I would catch it from a plot like @bloyl just presented.

I found a para seeg(bool) in plot_alignment, what if set aplha=0.75 when seeg=True?

here is the output of mne coreg with 0.75 head opacity..

I think you get this because of your (unfortunately persistent) graphics problems. It looks better with a modern graphics setup / advanced rendering. But we still do block the points on the far side (that are not inside the head) intentionally in that case actually.

Running these tutorials locally, I found that just making everything by default more transparent will make some other use cases harder to read.

It turns out that hacking in a head_alpha=0.75 instead of 1.0 in plot_alignment is not enough -- you need to also enable depth peeling (we'll need to talk to @GuillaumeFavelier about enabling this properly; for now you can test by changing this line to True) this plot:

Becomes this:

To me this is nicer, but probably still not good enough for sEEG. And adding depth peeling things become more challenging (and restrictive in terms of which graphics cards actually work). So I can live with leaving the default at 1.0 and just having surfaces=dict support.

I found a para seeg(bool) in plot_alignment, what if set aplha=0.75 when seeg=True?

My proposal is to make it so you can do surfaces=dict(head=0.1, dict(pial=0.5) or whatever you want to set the surface alpha(s).

Here's what sEEG looks like with depth peeling enabled. I would be fine with this. Particularly since the skull is unnecessary anyway.

Alternatively, if we do go with adding surfaces=dict(...) functionality. I would still recommend that the default be some transparency when seeg electrodes are involved. Using dict for alpha settings will already be unwieldy so I'd rather the defaults be as sensible to the case as possible.

I would still recommend that the default be some transparency when seeg electrodes are involved.

Fair enough. I think this line:
    alphas = (4 - np.arange(len(skull) + 1)) * (0.5 / 4.)

Is just a really convoluted np.linspace call of some sort. I would first convert this to the equivalent np.linspace call, then set the upper bound to 1. or 0.75 (or whatever looks good) if seeg electrodes are pleasant.

I like the last figures @larsoner and @kdoelling1919 produced.

This issue is fixed by #8446


⚠ Bofrost.fr has degraded performance

In 30fe55b, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1145 ms

Resolved: Bofrost.fr performance has improved in 0054e33 after 7 minutes.


Error when reorder marking scheme criteria

As a result, I can't change the order of the criteria. Errror dump from Chrome's console below. Source code reference column should be shifted down by 1.
Uncaught ReferenceError: ajaxRequest is not defined
rubrics:44
jQuery.sortable.update   application.js:16399
e.Widget._trigger   application.js:16399
e.widget._trigger   application.js:16399
(anonymous function)   application.js:16399
(anonymous function)   application.js:16399
e.widget._clear   application.js:16399
(anonymous function)   application.js:16399
e.widget._mouseStop   application.js:16399
(anonymous function)   application.js:16399
e.widget._mouseUp   application.js:16399
(anonymous function)   application.js:16399 n._mouseCapture._mouseDistanceMet._mouseDelayMet._mouseUpDelegate   application.js:10725 jQuery.event.dispatch   application.js:10393
elemData.handle

Also, the order doesn't stick.  On refreshing the page it goes back to the original order.

Thanks @david-yz-liu !


[BUG] trace-agent: a time.Timer leak in HttpReceiver.handleTraces

Upon a successful semaphore acquisition, the resources associated with the time.After call are left behind here.
This code is run once on every spans-accepting endpoint call, so up to apm_config.decoder_timeout (default: 1 second) times the endpoint-call-rate active time.Timer instances are retained. That leads to inflated heap data structures backing time.Timer (slower addition of new timers) and CPU time + context switches wasted on the timer firing logic.
Stopping the timer before continuing is the way to go. E.g. like so:
	decoderTimeout := time.NewTimer(time.Duration(r.conf.DecoderTimeout) * time.Millisecond)
	select {
	case r.recvsem <- struct{}{}:
		_ = decoderTimeout.Stop()
	case <-decoderTimeout.C:
        ...
        }

I opened https://help.datadoghq.com/hc/en-us/requests/1969667 to get attention to this ticket.

Hello! Thanks for opening an issue here, this does seem like an area where we might be able to make a small improvement. Before doing that I'll need to implement a benchmark to be sure of the performance improvement as I have never seen these timers show up in any of our internal heap or cpu profiles on very busy trace-agents. 🤔  Did you discover this change from seeing issues in your trace agent and this area appeared in your profiles?

Hey @ajgajg1134,
I spotted the issue statically while reading the code to troubleshoot something unrelated.
When this grabbed my attention I wondered if anything would be affected and I found this change by @ahmed-mez (https://github.com/DataDog/datadog-agent/pull/18868) - increasing DecoderTimeout may well have resulted in no timers firing until after all tests complete, which "fixed" flakiness :)
Starting with Go 1.23, this is a non-issue. Calling Stop as I suggested above is not needed because of this awesome new feature: https://github.com/golang/go/commit/508bb17edd04479622fad263cd702deac1c49157

👍 That's good news then since the agent is currently built / released with 1.23 https://github.com/DataDog/datadog-agent/blob/main/go.mod#L3
I also ran a quick benchmark internally with this change and there wasn't a measurable difference in cpu / memory compared to  the pre-release version of 7.61.
Given that, I'm going to mark this issue as closed. Thanks for pointing this out regardless! If you have additional comments or data feel free to re-open or bring it up in your support ticket.


Use build operations instead of progress logger in persistent caches

The PR replaces the dependency between :persistent-cache and :enterprise-logging by :build-operations. This is needed to simplify using the build cache library (which relies on :persistent-cache) in non-Gradle clients. It also means we don't need to publish :enterprise-logging, :logging-api and :logging to be part of the build cache library.
This is also a step towards replacing ProgressLogger with BuildOperationRunner in general.
The PR separates BuildOperationRunner and BuildOperationExecutor more clearly. The latter used to extend the former, but this is not the case anymore:

BuildOperationRunner is responsible for running individual build operations, and is part of the build cache library, and has few dependencies.
BuildOperationExecutor is about parallel execution of several operations using a BuildOperationQueue. It has many more dependencies, and is not part of the published build cache library.
Note: For now, the type still provides the same method signatures as BuildOperationRunner to keep compatible with existing code. We should follow up and replace these usages with BuildOperationRunner and remove the delegating methods from BuildOperationExecutor. We should probably rename the executor to something like ParallelBuildOperationExecutor or something to signal that it is only about parallelism.

As part of the changes I now moved BuildOperationRunner, BuildOperationListenerManager and CurrentBuildOperationRef to the WorkerSharedGlobalScopeServices from GlobalScopeServices, so CacheFactory has access to them.
Since both the build operation executor and runner are used in a number of unit tests (some more integration-test-like than the others), I've added some test fixtures to easily create these in tests.

@bot-gradle test QF please.

I've triggered the following builds for you. Click here to see all build failures.

QuickFeedback build

The merge queue build has started. Click here to see all failures if any.

The merge queue build has failed. Click here to see all failures.

The merge queue build has started. Click here to see all failures if any.


Optional identity tokens

It seems that currently, the OidcClient always requires the token response to include an identity token. When logging in using the authorization code flow, ProcessCodeFlowResponseAsync() will call ValidateTokenResponseAsync() with the default true value for requireIdentityToken.
This means you can't use OidcClient for just acquiring access tokens from an authorization server that does not provide id tokens. Is that right or am I missing a setting?

you know what OIDC stands for?

I do, I just thought this library could also support a basic OAuth2 flow without requiring identity tokens, as the readme states it is an 'an implemenation of the OIDC/OAuth 2 for native apps specification'.
Anyway, from your response I understand that this is not the case :)
I'll see if I can find another OAuth2 library.

Yes id_token is required.

Why is it required with OidcClientOptions.AuthenticationFlow.AuthorizationCode?
Using this flow the client is not even asking server for id_token and then of course response does not include it and the validation mentioned above fails.
This makes using this library impossible for me also. Please fix this


Convert terminal and immediate to booleans

Converts terminal and immediate to booleans. Currently both are
represented as strings in the provider.
Ref: LOG-8179
Semver: patch

with this change existing configurations would no longer be valid, correct? if so this is a breaking change, and so would require a major version bump (not patch)

I think this can be closed now as the change has been made on the API to be compatible.

I think this can be closed now as the change has been made on the API to be compatible.


Direct mode Agent Support

A question came up about support for direct mode.
There are two main use cases for  direct mode.
1- direct mode on both ends
2- direct mode on one end and indirect mode on the other end
Currently direct mode support involves a dedicated tcp connection with direct mode both ends.
One way to expand direct mode support is to leverage the current indirect mode agent code.
Each witness in indirect mode also has an agent API with a mailbox.  We could modify the agent api to represent just the direct mode controller (i.e. a controller with no witnesses). Instead of a witness OOBI to find the endpoint, one just publishes a controller OOBI.
Anyone wanting to get the KEL of the controller just hits the endpoint published by the controller OOBI.  Exchange messages use the SSE + push interface of the Agent API.

Agent removed from KERIpy for WebOfTrust/KERIA