[WIP][SPARK-32492][SQL][FOLLOWUP][test-maven] Fix jenkins maven jobs

What changes were proposed in this pull request?
The newly added test fails Jenkins maven jobs, see https://github.com/apache/spark/pull/29303#discussion_r464729021
The reason is not very clear now. This PR tries to use the jdbc client instead of thrift client to verify that test
Why are the changes needed?

Jenkins recovery
Does this PR introduce any user-facing change?

no
How was this patch tested?

modified uts

Test build #127045 has started for PR 29347 at commit 54f7245.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/31667/
Test PASSed.

cc @cloud-fan @dongjoon-hyun, let's see whether the JDBC client could pass maven jobs or not. thanks very much.

Test build #127045 has finished for PR 29347 at commit 54f7245.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/127045/
Test FAILed.

@yaooqinn . It's still failing. In that case, you had better mark this as WIP.
- check results from get columns operation from thrift server *** FAILED ***
  org.apache.hive.service.cli.HiveSQLException: java.lang.RuntimeException: org.apache.hadoop.hive.ql.metadata.HiveException: java.lang.ClassCastException: org.apache.hadoop.hive.ql.security.HadoopDefaultAuthenticator cannot be cast to

Test build #127057 has started for PR 29347 at commit b4a5fec.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/31679/
Test PASSed.

Test build #127058 has started for PR 29347 at commit f780d8d.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/31680/
Test PASSed.

Seems HiveThriftServer2Test and SharedThriftServer test 2 different ways to connect to the thrift server, but SharedThriftServer has problems to test certain APIs like getColumns.

Test build #127058 has finished for PR 29347 at commit f780d8d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/127058/
Test FAILed.

Test build #127057 has finished for PR 29347 at commit b4a5fec.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/127057/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/31702/
Test PASSed.

retest this please

Test build #127081 has started for PR 29347 at commit 61ba3ce.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/31705/
Test PASSed.

Test build #127081 has finished for PR 29347 at commit 61ba3ce.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/127081/
Test FAILed.

retest this please

Test build #127085 has started for PR 29347 at commit 61ba3ce.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/31709/
Test PASSed.

Test build #127085 has finished for PR 29347 at commit 61ba3ce.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/127085/
Test PASSed.

thanks, merging to master!

Thank you, @yaooqinn and @cloud-fan !


Maintain/env specs names

What?
Environment specs variable names were made consistent and also changed to make more sense
Why?
Environment specs variable names are inconsistent which makes code difficult to understand
How?
Rename variables, correct typing, docstrings. To verify that the PR did not break anything, I ran unit and integration tests and also ran run files in the examples folder to make sure that they still run.
Extra
Updated docstrings, fixed spelling errors
This PR should be merged before https://github.com/instadeepai/Mava/pull/579
Closer https://github.com/instadeepai/Mava/issues/599
Ran examples on TF and JAX side to make sure everything works as before

All integration tests are passing in a local docker container :call_me_hand:


JAVA-764: LWT / CAS Consistency bug on Retry Policy.

This is based on top of #587.
Amend all retry policies and handle serial consistency levels accordingly (rethrow should be the preferred decision).

We're losing some information though, namely the fact that it's the paxos phase, not the mutation phase, that timed out. If we do the switch in the query handler, the retry policy will have no way to differentiate the two cases.
And the default behavior if the paxos phase timed out should probably be to not retry. If a quorum of nodes was not reachable to establish a proposal, it's unlikely that switching to the next host would fix the issue.

Rebased on top of current JAVA-1050. Addressed @olim7t concerns.
Summary of recent changes:

New method ConsistencyLevel.isSerial();
Amended onUnavailable implementations of DefaultRetryPolicyand DowngradingConsistencyRetryPolicy to rethrow on serial consistency levels (see a12838c);
It turns out that onWriteTimeout implementations need not be amended (or so I mistakenly assumed);
Javadoc improvements to clarify the meaning of consistency levels.

New method ConsistencyLevel.isSerial();

Nice, that also takes care of JAVA-982

Now that #587 is merged, can we rebase this on 2.1?

I've rebased on 2.1 and removed the commits related to our initial approach. This will require a bit of cleanup/squashing before merging.

After giving it more thought, I think there is no reason not to retry on the next host when the CL is serial: the "network-isolated coordinator" hypothesis applies as well.
I pushed a commit to try the next host with the statement's original CL.

One more change: retry with the previous CL instead of the original CL. We don't have the case in default policies, but the CL might already have been downgraded in a previous retry.

lgtm :+1:
Small note before we squash commits together: let's try to keep the commit for JAVA-982 separate.

Done.

Opened scassandra/scassandra-server#143 to add the capability to simulate errors returning CL other than what the query specified to help test this.  Created java764tests branch with added tests which pass against this branch that will open PR for when version of scassandra released with this feature.


Upgrade WindowsAzure.Storage to 6.1.0 will break TableController.UpdateAsync

After upgrading the NuGet package for WindowsAzure.Storage from 6.0.0 to 6.1.0 updates to my data result in an error 500. Downgrading fixes the error.
I've switch multiple times between NuGet versions and the error is consistent with version 6.1.0.
The server side exception is:
Method not found: 'Microsoft.WindowsAzure.Storage.Table.TableOperation Microsoft.WindowsAzure.Storage.Table.TableOperation.Retrieve(System.String, System.String)'.

StackTrace:
at Microsoft.Azure.Mobile.Server.StorageDomainManager`1.<GetCurrentItem>d__27.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.Azure.Mobile.Server.StorageDomainManager`1.GetCurrentItem(CompositeTableKey key, Boolean includeDeleted)
   at Microsoft.Azure.Mobile.Server.StorageDomainManager`1.<UpdateAsync>d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.Azure.Mobile.Server.TableController`1.<PatchAsync>d__12.MoveNext()

Acknowledged. Thanks for finding this.

This appears to still be an issue as I'm running into it now (WindowsAzure.Storage v7)


Style issue in Decompile window

Steps to reproduce:

Open any jar.
Navigate to any method in any class.
Right click on method -> Decompile.
Right click anywhere in Decompile window.

Stylesheet none also has this problem.

Also the method recompilation has been unsupported since the 1.0 rewrite. It was buggy before and I haven't gotten around to properly re-adding it.


grid item find by message as well

image for generate html report toolbar button

Pull Request Test Coverage Report for Build 341960006

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

Totals

Change from base Build 339271057:
0.0%

Covered Lines:
20680

Relevant Lines:
48007

💛  - Coveralls


MINOR: Increase default timeout for other wait methods in TestUtils

They are now consistent with waitUntilTrue.

@guozhangwang, can you please review this simple PR? I noticed a transient Jenkins build failure that seems to be caused by a low timeout in one of these methods.

LGTM. Feel free to merge.

Merged to trunk.


can't access from another device

i can't access from my phone like nodejs

don't know why but now it can load

It already fix thank


Create wallet through descriptors via NFC:

I'm getting this error while scanning via NFC.

Verified this issue on keeper app v 1.1.5(230)


Umd build

This adds the ability to build pixi-tilemap as a UMD module.
It should resolve
https://github.com/pixijs/pixi-tilemap/issues/92

please hold off from reviewing it for a bit. I need to better test this in gdevelop first.

I asked @SukantPal to help with adoption of same build system as in pixi-essentials (https://github.com/SukantPal/pixi-essentials/)

@blurymind I think this is more or less included in #95.

ah thank you, I will give it a try and close this pr

I will close this, as the other pr has the same goal anyway


Bump to 0.5.1

I would expect cargo workspace version to help with this, right?

Well that would republishing everything that changed since the last release, and in this case the last release failed so I don't think that would be accurate.


Incorrect processing $-sign in replacement strings

# cat node_modules/string-format-js/package.json | grep version
  "version": "0.1.2",
# node
> require('string-format-js')
{}
> console.log('%s'.format('pa$$word'))
pa$word
undefined
>

Reason: String.replace():
> 's'.replace('s', 'pa$$word')
'pa$word'

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace
$$	Inserts a "$".
How to fix:
> 's'.replace('s', function () { return 'pa$$word' })
'pa$$word'

@amurchick Thanks for reporting! and sorry for my late reply. I'll fix it in a few days.


boundaries test

add tests for startHour,endHour startMinute,endMinute methods
Code beautification for HTML Document

tnx merged pr


Reformat Manual Testing Section in DG to follow standard formatting

Now these sections are consistent with the overall manual testing
format that we have chosen to follow.
Lets standardize documentation.
sections changed

launch & exit
saving
add
edit
delete
list
deleteShown
importExamScores

Looks Good to Me!


Update config.yml

Summary

Ticket Link

Related Pull Requests

Has server changes (please link here)
Has mobile changes (please link here)

Screenshots

Release Note

The file .circleci/config.yml is in the blocklist for external contributors. Hence, these changes are not tested by the CI pipeline active until the build is re-triggered by a core committer or the PR is merged. Please be careful when reviewing it.
/cc @mattermost/core-security @mattermost/core-build-engineers

Hello @garg47294,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.
Per the Mattermost Contribution Guide, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
Once you have signed the CLA, please comment with /check-cla and confirm that the CLA check is green.
This is a standard procedure for many open source projects.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

E2E tests not automatically triggered, because PR has no approval yet. Please ask a developer to review and then try again to attach the QA label.


hosted_zone_name is needed even with create_dns_record = false

I'm using version 1.0.4 and I got the following error when I tried to use this module with the create_dns_record option set to false:
Error: module.bastion.aws_route53_record.bastion_record_name: zone_id must not be empty
Checking the code I saw that zone_id uses hosted_zone_name

Sorry my bad, It is an int and setting it to 0 worked.


Expose Nightly build links to public

Currently we have nightly builds, which is not opened to public.
After we fully migrated to LF Artifactory, we want to add a "Nightly Builds" section in Download. This section we can either link back directly to Artifactory repository, or see if we can retrieve list automatically and show in the page.
Pre-requirement: migration to LF Artifactory is done.

Part of https://github.com/zowe/zowe-install-packaging/issues/702


Feature/cell editable custom component

Related Issue
Resolves #2559 - using a custom component for cell editables.
Description
Before this change setting an editComponent for cellEditable tables had no effect. Now we just render the component a user passes to us.
Impacted Areas in Application

cell editables

Additional Notes
Thank you so much for this project. It really makes life much easier when it comes to displaying table like data. Especially the tree view is so useful. Keep up the great work :-)****

Eslint now added a lot of changes. Should I revert those?

@klassm thank you for this! It looks like your IDE is changing single quotes to double quotes. I have updated the .eslintignore file.
Would you mind trying once more?

@oze4 Thanks for the review :-) I've done the merge one more time, this time from your latest changes in master. It looks like everything is now single quotes.

Thanks :-)

@klassm v2.2.0 has been published with these changes. Thank you so much for contributing!

@oze4, I need this fix in my project but it seems the last published release is 1.69.2 which not includes this fix

The latest version is 2.3.29. It sounds like you are looking at mbrn/material-table

@oze4 , Thanks a lot. I did not notice that it's a forked branch from mbrn/material-table. Do you plan to merge into mbrn/material-table at some point?

For what feature?
I don't think we are against merging upstream.


Exploring the idea of raster (pixel-perfect) annotations

Hello,
Context
I work on a software called "ilastik", which, amongst other things, does image classification and segmentation. We're experimenting with using neuroglancer as a viewer for the web version of ilastik. The most basic workflow is:
1 - loading you data;
2 - label some parts of your data with different colors in order to train the pixel classifier;
3 - Wait for ilastik to predict which pixels of your image correspond to each label.
Labeling data in the desktop version of ilastik is done using brush strokes, which produce pixel-perfect annotations. The annotations in neuroglancer, on the other hand, are vector data.
I've managed to extend neuroglancer's annotation tools and add a "brush stroke" tool, which produces a sequence of line segments, and that somewhat behaves like a raster brush tool. There are some obvious problems, though, in that:

I need to rasterize those sequences of line segments into integer coordinates;
dealing with brush thickness is tricky;
(de)serializing is very awkward; it doesn't feel right to serialize the very data-dense brush strokes into the URL, though I can keep those in the backend;
An eraser tool would be very hard to accomplish in this scheme;

Question
Would you have any ideas or recommendations on implementing raster annotations with neuroglancer? So far I'm thinking that the best strategy would be to use neuroglancer strictly as a viewer, build a raster annotation tool on top of it, and then serve the brush strokes as a DataSource. On the other hand, as awkward as it was to force a vector-brush into raster pixels, it gave me all the advantages of Neuroglancer's builtin annotation tools, like color picking, snapping to position and deletion, which would be a shame to lose.
Thank you for your time,
Tomaz

This is certainly an often-requested feature and if you implement it I'm sure it will be useful to many people.
I think it would make sense to extend the existing MultiscaleVolumeChunkSource interface to support a new read-write data source, where locally modified chunks would store a boolean mask array in addition to the modified values to indicate which positions have been updated.  Then these modifications could be sent back to the server either automatically or upon an explicit commit action.
Handling multi-resolution and undo would add additional challenges, though.
Alternatively you could try to just handle all brush strokes server side and then just have neuroglancer reload the relevant chunks.  At the moment neuroglancer doesn't really support this sort of low-latency interaction through the python integration or even per-chunk invalidation but maybe it could be made to work.
What representation does ilastik normally use for these brush strokes?

We keep the strokes in  something like a sparse array. We dynamically create grid-aligned tiles as the user draws, and fill those tiles with the pixels marked by the brush strokes. For our use case, we expect there to be only  few brush strokes, since the classifier doesn't need a lot of samples. This way we can easily support an eraser tool but we don't support undo-redo, though, and that is dearly missed. We also don't handle multi-resolution, and it's hard to tell what would be sensible to do in that case.
The idea of implementing a read/write MultiscaleVolumeChunkSource is pretty interesting. Is there any implementation of a client-side ChunkSource in Neuroglancer? This could potentially help us in another case, which is to allow a user to use ilastik to classify images that are not accessible on the internet, by loading them into the neuroglancer client, though I'd have to think of the consequences of doing something like that.
Serialization would still be weird, though. It seems all annotations serialize to the URL, but that probably wouldn't work for brush strokes, so it would need some special-case to either save the brush strokes to local storage or to a server backend.

I assumed that neuroglancer would be connected to a running ilastik process, which could be responsible for serving the data and storing the annotations.  Is that not correct --- do you want to instead move everything in ilastik into the web browser?
I think serializing to the URL wouldn't work well due to the size of the data.  Local storage might work but I'm not inclined to trust it for anything other than a cache.
The existing annotations interface does actually support read-write server-side annotations on our internal Google brainmaps api data source, and flyem has also added support for the dvid data source which they are working to upstream.  I imagine a similar approach could be used for read-write volumetric data.

Your assumption was correct, there should always be a running ilastik server, and we don't plan to have a js implementation of ilastik any time soon. I was just thinking of some edge cases where a user might want to use web ilastik without having to upload sensitive data to the internet, and it occurred to me that perhaps it would be possible to have the client-side ChunkSource stream the local data to the server, but that's so secondary it doesn't merit a discussion right now =)
I will have a look at the current implementations of read-write server-side annotations and see if I can come up with something sensible

Hello,
I finally had some time to look into this again, and I have a prototype that can draw pixel-perfect (or, rather, voxel-perfect) brush strokes. It's built as an overlay, so that it can be applied to any viewer, but I really would like to validate it with Neuroglancer. Right now I'm having some trouble keeping it in sync with Neuroglancer and its many views; maybe you could point me in the right direction. I'm looking for a position_in_world_coords: vec3 and an orientation: quat that I can programmatically get and apply to my camera every time Viewer.navigationState changes.
I thought Viewer.navigationState.pose would have everything I need, but I'm finding it hard to interpret its meaning. Apparently DisplayPose.position is the camera's position (or, I guess, the "Sections" intersection), expressed in "Voxel coordinates" (as opposed to in "World coordinates"). Is it safe to assume that DsplayPose.orientation is also expressed in the Voxels coordinate system?
I find the coo

Hello,
I finally had some time to look into this again, and I have a prototype that can draw pixel-perfect (or, rather, voxel-perfect) brush strokes. It's built as an overlay, so that it can be applied to any viewer, but I really would like to validate it with Neuroglancer. Right now I'm having some trouble keeping it in sync with Neuroglancer and its many views; maybe you could point me in the right direction. I'm looking for a position_in_world_coords: vec3 and an orientation: quat that I can programmatically get and apply to my camera every time Viewer.navigationState changes.
I thought Viewer.navigationState.pose would have everything I need, but I'm finding it hard to interpret its meaning. Apparently DisplayPose.position is the camera's position (or, I guess, the "Sections" intersection), expressed in "Voxel coordinates" (as opposed to in "World coordinates"). Is it safe to assume that DsplayPose.orientation is also expressed in the Voxels coordinate system?
I find the coo

Exciting progress --- I'd be interested to take a look once you have an integration.
The coordinate transformations in Neuroglancer are unfortunately somewhat complicated.  The actual projection for sliceview (cross-section views) is computed here:
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/sliceview/frontend.ts#L152
For a given sliceview, you can access sliceview.projectionParameters.value to get access to the SliceViewProjectionParameters / ProjectionParameters:
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/sliceview/base.ts#L226
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/projection_parameters.ts#L23
Unfortunately the comments are not great, but "world coordinates" means voxels in the global coordinate space (but only the selected "display dimensions", i.e. the ones shown on the left side of the panel in red/green/blue).
It isn't guaranteed that you can decompose the viewProjectionMat (which maps from global voxel space to OpenGL clip space) into a quaternion, offset, scale --- it would be better to just work with the transform matrices directly.
If you can integrate your overlay by defining a SliceViewPanelRenderLayer (and drawing the overlay in its draw method using WebGL), that would be simplest because then it will automatically be called for each slice view panel with appropriate rendering parameters and WebGL framebuffer provided.
Otherwise, I suppose you can try to hook into sliceview panel creation some other way, and then use the fields of RenderedPanel:
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/display_context.ts#L81
to map from OpenGL clip coordinates to screen coordinates.

Exciting progress --- I'd be interested to take a look once you have an integration.
The coordinate transformations in Neuroglancer are unfortunately somewhat complicated.  The actual projection for sliceview (cross-section views) is computed here:
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/sliceview/frontend.ts#L152
For a given sliceview, you can access sliceview.projectionParameters.value to get access to the SliceViewProjectionParameters / ProjectionParameters:
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/sliceview/base.ts#L226
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/projection_parameters.ts#L23
Unfortunately the comments are not great, but "world coordinates" means voxels in the global coordinate space (but only the selected "display dimensions", i.e. the ones shown on the left side of the panel in red/green/blue).
It isn't guaranteed that you can decompose the viewProjectionMat (which maps from global voxel space to OpenGL clip space) into a quaternion, offset, scale --- it would be better to just work with the transform matrices directly.
If you can integrate your overlay by defining a SliceViewPanelRenderLayer (and drawing the overlay in its draw method using WebGL), that would be simplest because then it will automatically be called for each slice view panel with appropriate rendering parameters and WebGL framebuffer provided.
Otherwise, I suppose you can try to hook into sliceview panel creation some other way, and then use the fields of RenderedPanel:
https://github.com/google/neuroglancer/blob/add6885da32498a1cfd1075a4c19aae8ffb5a6f2/src/neuroglancer/display_context.ts#L81
to map from OpenGL clip coordinates to screen coordinates.

Thanks for the quick response =) Unfortunately it took me a a while to get through it all, but it was great having a clue of where to look for stuff.
In the end I went with something like this:
    let voxel_to_world = mat4.fromScaling(mat4.create(), vec3.fromValues(1, -1, -1))

https://drive.google.com/file/d/1QRw1s6khVkxRniG_1abDJQwaBarkYp9_/view?usp=sharing

Thanks for the quick response =) Unfortunately it took me a a while to get through it all, but it was great having a clue of where to look for stuff.
In the end I managed to derive a location_w and orientation_w with something like this:
//flip y and x so y points up and -z goes int the screen when the camera is reset
let voxel_to_world = mat4.fromScaling(mat4.create(), vec3.fromValues(1, -1, -1))
let pos_vx = viewer.navigationState.pose.position.value as vec3;
let camera_pos_w = vec3.transformMat4(vec3.create(), pos_vx, voxel_to_world)

let camera_orientation_vx: quat = viewer.navigationState.pose.orientation.orientation
const rotation_axis_vx = vec3.create();
const rotation_rads = quat.getAxisAngle(rotation_axis_vx, camera_orientation_vx)
const rotation_axis_w = vec3.transformMat4(vec3.create(), rotation_axis_vx, voxel_to_world);
const camera_orientation_w = quat.setAxisAngle(quat.create(), rotation_axis_w, rotation_rads)

overlay.snapTo(camera_pos_w, camera_orientation_w)
overlay.setZoom(1 / viewer.navigationState.zoomFactor.value)

And here's a video of how it's looking right now.
The project is a standalone overlay, and is hosted here if you want to take a look. This allows it to be used with arbitrary viewers by providing some glue code like the one above. I plan to integrate it with ilastik soon, but I'll leave the ilastik logic well separated from the brushing logic (maybe in a separate, standalone library).

@Tomaz-Vieira This work is exciting (and so is your general work with ilastik :-)
Is there any hope that your brushing overlay could be somehow integrated with neuroglancer's existing Python API?  If someone wanted to start down that path, do you have any advice for them?


Hosting app: UI related issues

Resolved UI related issues

r? @ustulation
(maidsafe_highfive has picked a reviewer for you, use r? to override)


More meaningful error message on log

Describe the bug
Hello, Team!
I have an apparently flawed .bpmn file which I want to import in Camunda Modeler (attached, change extension to bpmn), but the error messages show no hint on what is missing/broken in the file:
probe.txt
The message is
[C:\Users\machine\Desktop\probe.bpmn] Cannot read properties of undefined (reading 'x') [ warning ]
Steps to reproduce

open Camunda Modeler
open the attached file
I get a few error messages, like:
[C:\Users\machine\Desktop\probe.bpmn] Cannot read properties of undefined (reading 'x') [ warning ]

Expected behavior
The error message should contain more info on what is missing, like what is undefined, the properties of which can not be read.
Environment

OS: Windows 10
Camunda Modeler Version:  5.1.0
Execution Platform: Camunda Community
Installed plug-ins: none

Additional context
No response

Thanks for reporting! Where did you export the diagram from? It seems like some DI is missing (as coordinates where to render the flow elements).

Thanks for reporting! Where did you export the diagram from? It seems like some DI is missing (as coordinates where to render the flow elements).

I created it in one of my projects as a dummy file.

I agree that the error message could be a bit more graceful in this case. Given the example diagram, the BpmnImporer is simply throwing with when a shape's bounds are missing.
It would be nice if the importer checks for missing bounds explicitly and throws accordingly.
<bpmndi:BPMNDiagram id="BPMNDiagram_1">
  <bpmndi:BPMNPlane bpmnElement="dummy-test-job"
                    id="BPMNPlane_1">
    <bpmndi:BPMNShape bpmnElement="StartEvent"
                      id="StartEvent_di"/>
    <bpmndi:BPMNShape bpmnElement="Step_1"
                      id="Step_1_di"/>
    <bpmndi:BPMNEdge bpmnElement="Flow_0"
                      id="Flow_0_di"/>
    <bpmndi:BPMNShape bpmnElement="Step_2"
                      id="Step_2_di"/>
    <bpmndi:BPMNEdge bpmnElement="Flow_1"
                      id="Flow_1_di"/>
    <bpmndi:BPMNShape bpmnElement="Step_3"
                      id="Step_3_di"/>
    <bpmndi:BPMNEdge bpmnElement="Flow_2"
                      id="Flow_2_di"/>
    <bpmndi:BPMNShape bpmnElement="EndEvent"
                      id="EndEvent_di"/>
    <bpmndi:BPMNEdge bpmnElement="Flow_3"
                      id="Flow_3_di"/>
  </bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>

I'm moving this to backlog, thanks for reporting 👍

Thanks for reporting! Where did you export the diagram from? It seems like some DI is missing (as coordinates where to render the flow elements).

I created it in one of my projects as a dummy file.

Which tool are you using for modeling? Where did you export this diagram?

Thanks for reporting! Where did you export the diagram from? It seems like some DI is missing (as coordinates where to render the flow elements).

I created it in one of my projects as a dummy file.

Which tool are you using for modeling? Where did you export this diagram?

I wrote it in Notepad++, as a minimum working example for testing my project which uses Camunda.

I created it in Notepad++, as a minimum working example for testing my project which uses Camunda.

That's good to know. Manually creating BPMN files is pretty error-prone. Your attached diagram is clearly missing the DI bounds, therefore the Modeler is not able to properly render them. There is no autolayouting in place.

I created it in Notepad++, as a minimum working example for testing my project which uses Camunda.

That's good to know. Manually creating BPMN files is pretty error-prone. Your attached diagram is clearly missing the DI bounds, therefore the Modeler is not able to properly render them. There is no autolayouting in place.

I know, I don't intend to create bpmn files manually, I just created this file as a minimal example to illustrate what I mean.


Path element data gets undefined value

Please define your problem or issue as clear as possible.
For a problem, please fill the following:
Vivus version:
Latest
Browser:
Chrome latest
Steps to reproduce it:
Use the attached SVG
bulb_on_azure.zip
Hello, I found an interesting problem. The ground line is not getting drawn. It's the first path element and if you ispect it, it'll have a d="Mundefined value.
I'd love to use it because I'm building an SVG heavy site and it would be awesome to animate these illustrations.

Hallo,
Thanks for your issue (and respecting the guidelines :)
I found out why your SVG is crashing. With this library I learn everyday
about SVG, it's amazing. Your first line is a not valid from my Pathformer
requirements, because the x1 attribute is missing. But by convention,
browsers seems to replace missing position attributes by 0. I'll patch
this. For now, please add x1="0" to your line then it should run smoothly
;-)

Thanks for the quick response.
I'll try it out shortly and report back. It was exported directly from the latest Illustrator CC.


Embed UI templates via go:embed

By implementing the backend package I discover that the //go:embed directive works when importing external package.
Since the CLI uses the core package to expose a fully working local dev server, it would be nice to embed the templates for the web admin UI.
That way they'd be available from the CLI.
We'd use them like this in the render.go file:
//go:embed templates
var templFS embed.FS

Once this is done, the loadTemplates in render.go line:20 should be changed to use the templFS above. Use the the io/fs instead of os to ReadDir.

Hi @dstpierre. I can work on this issue, if that's ok. Seems pretty straightforward based on your description.

that's great @Conor-Fleming let me know if you have any questions

@Conor-Fleming it would be nice if this change also brings in the CSS and logo image in a "public" directory that would be embeded as well.
For example, at this moment in templates/login.html line 14 there's a  that references the logo from https, same from templates/partials/navbar.html line:5.
And for the CSS it's in templates/login.html line:8 and templates/partials/head.html line:13.
Would be nice to create a public directory, embed it and serve it's content. This involved changing the URL to access those resources in the html file above.
See this go doc part for how to serve content from an embed.FS.
Let me know if you have any questions.

Cool, I'll take a stab and let you know if I need anything. Thanks for the clear direction!

I have created a public directory and added the logo-sb-no-txt.png & sb-app.css files as mentioned above. Would the best place to embed this new public directory and serve these files be in the existing server.go file? Or would you rather create a new file to do this?
Thanks in advance.

@Conor-Fleming yes server.go is a good file to have the embed.FS variable.
sorry for the delay.

@Conor-Fleming I'm doing a friendly follow-up here, I'm planning a new release and would want this issue to be available in the next CLI update.
Can you update on your status, are you still interested in tackling this one?
Please let me know, thanks.

HI @dstpierre,
Apologies, I'm going to have to let this one go for the time being. Again so sorry.

@Conor-Fleming no worries at all, thanks for confirming.


[SPARK-17929] [CORE] Fix deadlock when CoarseGrainedSchedulerBackend reset

What changes were proposed in this pull request?
https://issues.apache.org/jira/browse/SPARK-17929
Now CoarseGrainedSchedulerBackend reset will get the lock,
  protected def reset(): Unit = synchronized {
    numPendingExecutors = 0
    executorsPendingToRemove.clear()

    // Remove all the lingering executors that should be removed but not yet. The reason might be
    // because (1) disconnected event is not yet received; (2) executors die silently.
    executorDataMap.toMap.foreach { case (eid, _) =>
      driverEndpoint.askWithRetry[Boolean](
        RemoveExecutor(eid, SlaveLost("Stale executor after cluster manager re-registered.")))
    }
  }

but on removeExecutor also need the lock "CoarseGrainedSchedulerBackend.this.synchronized", this will cause deadlock.
   private def removeExecutor(executorId: String, reason: ExecutorLossReason): Unit = {
      logDebug(s"Asked to remove executor $executorId with reason $reason")
      executorDataMap.get(executorId) match {
        case Some(executorInfo) =>
          // This must be synchronized because variables mutated
          // in this block are read when requesting executors
          val killed = CoarseGrainedSchedulerBackend.this.synchronized {
            addressToExecutorId -= executorInfo.executorAddress
            executorDataMap -= executorId
            executorsPendingLossReason -= executorId
            executorsPendingToRemove.remove(executorId).getOrElse(false)
          }
     ...

## How was this patch tested?

manual test.

Test build #66957 has started for PR 15481 at commit 3681fae.

Test build #66957 has finished for PR 15481 at commit 3681fae.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/66957/
Test PASSed.

@zsxwing or @andrewor14 might know best on this one.

Would be cleaner to simply copy executorDataMap.keys and works off that to ensure there is no coupling between actor thread and invoker.

Test build #67054 has started for PR 15481 at commit 2997ccb.

LGTM, sorry to bring in deadlock issue.

Test build #67054 has finished for PR 15481 at commit 2997ccb.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/67054/
Test FAILed.

retest this please.

Test build #67067 has started for PR 15481 at commit 2997ccb.

Test build #67067 has finished for PR 15481 at commit 2997ccb.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/67067/
Test FAILed.

retest this please.

Test build #67105 has started for PR 15481 at commit 2997ccb.

Test build #67105 has finished for PR 15481 at commit 2997ccb.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/67105/
Test PASSed.

@scwf I think the initial fix with a small change might be sufficient.
What I meant was something like this :
protected def reset(): Unit = {
  val executors = synchronized {
    Set() ++ executorDataMap.keys
  }

  executors.foreach ( eid => driverEndpoint.askWithRetry[Boolean](
    RemoveExecutor(eid, SlaveLost("Stale executor after cluster manager re-registered.")))
}

This will keep the synchronized block restricted to copying the executor keys, and leave the rest as-is removing the deadlock. Thoughts ?

reset is called in YarnSchedulerEndpoint which ideally should not be a blocking action.

I'm wondering if we can also fix this.

@zsxwing Ah, then simply making it send() instead of askWithRetry() should do, no ?
That was actually in the initial PR - I was not sure if we want to change the behavior from askWithRetry to send ...

Seems it could be changed to send instead.

ok, i will revert to the initial commit.

Test build #67155 has started for PR 15481 at commit af6072a.

Test build #67155 has finished for PR 15481 at commit af6072a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/67155/
Test FAILed.

Merged build finished. Test FAILed.

Updated, can you review again?

Test build #67173 has started for PR 15481 at commit 7d86054.

LGTM, @zsxwing any comments ?

BTW, it was interesting that the earlier change did not trigger a test failure (the issue @viirya pointed out - about needing to move RemoveExecutor to receive)

@mridulm I checked #9963 and looks like we don't test against CoarseGrainedSchedulerBackend.reset.

Test build #67173 has finished for PR 15481 at commit 7d86054.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/67173/
Test PASSed.

Sorry that my comment was unclear. I meant:
  protected def reset(): Unit = synchronized {
    numPendingExecutors = 0
    executorsPendingToRemove.clear()

    // Remove all the lingering executors that should be removed but not yet. The reason might be
    // because (1) disconnected event is not yet received; (2) executors die silently.
    executorDataMap.toMap.foreach { case (eid, _) =>
      removeExecutor(eid, SlaveLost("Stale executor after cluster manager re-registered."))
    }
  }

@zsxwing To minimize scope of synchronized block.
The way @scwf has now, the synchronized block is limited to duplicating key and setting some state.
Remaining can happen outside of the lock.

@mridulm ask is very cheap. It just puts the serialized message into a buffer. The current codes now need to duplicate the codes and as @viirya pointed out, it misses executorDataMap.get(executorId).foreach(_.executorEndpoint.send(StopExecutor)).
How about just the following changes? I agreed that removeExecutor doesn't need to be in the synchronized block.
  protected def reset(): Unit = {
    val executors = synchronized {
      numPendingExecutors = 0
      executorsPendingToRemove.clear()
      Set() ++ executorDataMap.keys
    }

    // Remove all the lingering executors that should be removed but not yet. The reason might be
    // because (1) disconnected event is not yet received; (2) executors die silently.
    executors.foreach { eid =>
      removeExecutor(eid, SlaveLost("Stale executor after cluster manager re-registered."))
    }
  }

@zsxwing I think the issue is that case RemoveExecutor() is not identical to what exists in receiveAndReply
Any reason 'executorDataMap.get(executorId).foreach(_.executorEndpoint.send(StopExecutor))' is missing from case RemoveExecutor(executorId, reason) in receive ?
If we add that in there, will it not be sufficient ?
I dont want to call removeExecutor from outside the event loop.

I meant CoarseGrainedSchedulerBackend.removeExecutor not DriverEndpoint.removeExecutor. It's confusing that we have two methods having the same name :(

Ah ! Apologies, I got confused. Yes, I agree, that is a better approach.
It also means we can get rid of the RemoveExecutor pattern match from receive right ? As it stands now, that looks buggy.

It also means we can get rid of the RemoveExecutor pattern match from receive right ?

yep

CoarseGrainedSchedulerBackend.removeExecutor also use ask,  but it does not matter right?  because it just send msg once and log the error if failure

Test build #67312 has started for PR 15481 at commit 7bf3bf8.

Test build #67312 has finished for PR 15481 at commit 7bf3bf8.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/67312/
Test FAILed.

retest this please

Test build #67322 has started for PR 15481 at commit 7bf3bf8.

Test build #67322 has finished for PR 15481 at commit 7bf3bf8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/67322/
Test PASSed.

LGTM now.

LGTM. Merging to master and 2.0. Thanks!


az image copy to multiple locations not working

I'm trying to copy an image to multiple locations using the following command:
Command
az image copy --source-resource-group infinity-images \
  --source-object-name infinity-25-3-0-59550-0-0-cnf  \
  --target-location eastus2 southeastasia australiaeast westus \
  --target-resource-group infinity-images

I don't get any errors, but I do get the following output:
Getting OS disk ID of the source VM/image
Creating source snapshot
Getting sas url for the source snapshot with timeout: 3600 seconds
Creating resource group: image-copy-rg
Target location count: 4
Starting async process for all locations
Deleting transient resources

However, the resource group image-copy-rg is created, but it is empty and no new images are created.
Expected Behavior
I was expecting to see the newly created images in the target resource group.
Environment Summary
macOS-10.16-x86_64-i386-64bit
Python 3.8.7
Installer: HOMEBREW

azure-cli 2.24.0

Extensions:
image-copy-extension 0.2.8

Additional Context

compute

@yonzhan isn't this feature supposed to already exist? I'm wondering why it has the feature-request label.

Please upgrade to latest version of az cli 2.39.0


Fix lexing of integer literals

This reverts a change introduced in 34417ce55 by @mmicko that caused #1364. It also adds support for uppercase S as signedness indicator.

@cliffordwolf Well now originally fixed issue is broken again https://github.com/YosysHQ/yosys/issues/1022
Plain unsized  works :  assign b = 'b0;
But unsized and "untyped" still does not : assign b = '0;

But unsized and "untyped" still does not : assign b = '0;

Ah! I see.. It should have been ? instead of *. I think now it should be fine.


IStringBuilder and StringBuilder usage

In JavaScript usually there is no need for a StringBuilder. Are you sure it helps the performance? AFAIK += for strings is fast in every browser, it's only necessary if you implement batch operations, eg. a batchAppend(string[]) method.

Hmm... you might be right.  I had not gotten around to tuning perf yet.  The main idea was to abstract the string building, so that if some technique is found to be faster, we only need to change one place.
Looks like the TypeScript compiler has a EmitTextWriter abstraction, but its inner loop just uses +=.


Moving service mesh image sanitization attributes from JobDescriptor to Container attributes

Description of the Change
Downstream services are expecting the image sanitizer to read and populate the specific attributes as part of container and not JobDescriptor. This PR moves the reading and populating the attributes to the container attributes section.

@joshi-keyur You should cancel this PR and rebase your commit on top of master. This one because of you did merge contains far too many changes from other commits.


Targeting Sdk version 31 on android

Hello ! I'm trying to install this package. But when adding it to my project.
I'm getting this error on compilation :
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:checkStagingDebugAarMetadata'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.CheckAarMetadataWorkAction
   > The minCompileSdk (31) specified in a
     dependency's AAR metadata (META-INF/com/android/build/gradle/aar-metadata.properties)
     is greater than this module's compileSdkVersion (android-30).
     Dependency: androidx.appcompat:appcompat:1.4.1.
     AAR metadata file: C:\Users\maximedev\.gradle\caches\transforms-3\65490f590e300e64121b2eb11f167879\transformed\appcompat-1.4.1\META-INF\com\android\build\gradle\aar-metadata.properties.

Not sure from where it come, the project don't seems to target sdk 31.
The only thing I found is that the android sdk sample is targeting 31...
Is anybody got the same issue or has a solution ?

Not sure from where it come, the project don't seems to target sdk 31.
The only thing I found is that the android sdk sample is targeting 31...
Is anybody got the same issue or has a solution ?

@maximewim I had the same issue, by adding the following to android/build.gradle it make to work:
        compileSdkVersion = 31
        targetSdkVersion = 31

Not sure from where it come, the project don't seems to target sdk 31.
The only thing I found is that the android sdk sample is targeting 31...
Is anybody got the same issue or has a solution ?

@maximewim I had the same issue, by adding the following to android/build.gradle it make to work:
        compileSdkVersion = 31
        targetSdkVersion = 31

I would prefer not to have to update the build version. This creates other issues related to my project. Is there no other solution?

Not sure from where it come, the project don't seems to target sdk 31.
The only thing I found is that the android sdk sample is targeting 31...
Is anybody got the same issue or has a solution ?

@maximewim I had the same issue, by adding the following to android/build.gradle it make to work:
        compileSdkVersion = 31
        targetSdkVersion = 31

I would prefer not to have to update the build version. This creates other issues related to my project. Is there no other solution?

@maximewim you can force the module appcompat of group  androidx.appcompat to use 1.3.0 instead of 1.4.1,  I could make it work to my project, can share with you the configuration later.

Hi,
I integrated Crisp chat on my React website and would like to implement it on my React Native app.
My React Native app is using the following versions:
 "react-native": "0.70.8",
"expo": "~47.0.12",

I followed the installation steps by running yarn add react-native-crisp-chat-sdk and configuring the app.json file with the plugin as follows:
yarn add react-native-crisp-chat-sdk
 {
  "expo": {
    "plugins": [
      [
        "expo-build-properties",
        {
          "ios": {
            "deploymentTarget": "13.0"
          }
        }
      ],
      [
        "react-native-crisp-chat-sdk",
        {
          "websiteId": "YOUR_WEBSITE_ID"
        }
      ]
    ]
  }
}

However, I encountered the same issue as mentioned in a previous answer in this topic with the SDK version.
1.  Dependency 'androidx.appcompat:appcompat-resources:1.5.1' requires libraries and applications that
           depend on it to compile against version 32 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Recommended action: Update this project to use a newer compileSdkVersion
           of at least 32, for example 32.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       2.  Dependency 'androidx.appcompat:appcompat:1.5.1' requires libraries and applications that
           depend on it to compile against version 32 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Recommended action: Update this project to use a newer compileSdkVersion
           of at least 32, for example 32.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       3.  Dependency 'com.google.android.exoplayer:exoplayer:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       4.  Dependency 'androidx.emoji2:emoji2-views-helper:1.2.0' requires libraries and applications that
           depend on it to compile against version 32 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Recommended action: Update this project to use a newer compileSdkVersion
           of at least 32, for example 32.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       5.  Dependency 'androidx.emoji2:emoji2:1.2.0' requires libraries and applications that
           depend on it to compile against version 32 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Recommended action: Update this project to use a newer compileSdkVersion
           of at least 32, for example 32.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       6.  Dependency 'com.google.android.exoplayer:exoplayer-dash:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       7.  Dependency 'com.google.android.exoplayer:exoplayer-hls:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       8.  Dependency 'com.google.android.exoplayer:exoplayer-rtsp:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

       9.  Dependency 'com.google.android.exoplayer:exoplayer-smoothstreaming:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

      10.  Dependency 'com.google.android.exoplayer:exoplayer-core:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

      11.  Dependency 'com.google.android.exoplayer:exoplayer-ui:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

      12.  Dependency 'com.google.android.exoplayer:exoplayer-datasource:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

      13.  Dependency 'com.google.android.exoplayer:exoplayer-database:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

      14.  Dependency 'com.google.android.exoplayer:exoplayer-extractor:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

      15.  Dependency 'com.google.android.exoplayer:exoplayer-decoder:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

      16.  Dependency 'com.google.android.exoplayer:exoplayer-common:2.18.2' requires libraries and applications that
           depend on it to compile against version 33 or later of the
           Android APIs.

           :app is currently compiled against android-31.

           Also, the maximum recommended compile SDK version for Android Gradle
           plugin 7.2.1 is 32.

           Recommended action: Update this project's version of the Android Gradle
           plugin to one that supports 33, then update this project to use
           compileSdkVerion of at least 33.

           Note that updating a library or application's compileSdkVersion (which
           allows newer APIs to be used) can be done separately from updating
           targetSdkVersion (which opts the app in to new runtime behavior) and
           minSdkVersion (which determines which devices the app can be installed
           on).

When I checked my android/app/build.gradle file, I found the following lines:
minSdkVersion rootProject.ext.minSdkVersion
argetSdkVersion rootProject.ext.targetSdkVersion

I replaced these lines with versions 32 and 33, respectively, but the issue persisted. I also tried using the following commands:
npx expo prebuild -p android --clean
npx expo run:android

Do you have any suggestions on how to resolve this issue?


Add personal tasks

As a student, I can add personal tasks, so that I can keep up to date with the different tasks to complete.

Looks good to me!

Looks great! Would be good to include a task name for the task.


chore: make no-unused-vars eslint rule error

Summary
Noticed the lint warning on CI (it's set to warn for some reason in the underlying fb config: https://github.com/facebook/fbjs/blob/4369c7dfeb1ab0de27feb3e9245f599c8edd6a5c/packages/eslint-config-fbjs/index.js#L264). Any reason not to error here?

Test plan
No lint errors

Codecov Report

Merging #5598 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5598      +/-   ##
==========================================
- Coverage   60.63%   60.62%   -0.01%
==========================================
  Files         213      213
  Lines        7313     7312       -1
  Branches        3        4       +1
==========================================
- Hits         4434     4433       -1
  Misses       2878     2878
  Partials        1        1

Impacted Files
Coverage Δ

packages/jest-cli/src/search_source.js
45.07% <ø> (-0.77%)
:arrow_down:

Continue to review full report at Codecov.

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


[DC-1349] Update registered tier to use questionnaire_response_id remapping cleaning rule.

Added a REGISTERED_TIER_DEID_CLEANING_CLASSES list
Added QRIDtoRID cleaning rule to the
REGISTERED_TIER_DEID_CLEANING_CLASSES list
Added the registered tier DataStage element
Added the registered tier rules to the DATA_STAGE_RULES_MAPPING
dictionary
Added the REGISTERED_TIER_DEID constant
Updated to run registered tier cleaning rules before running deid

Everything looks good to me. Approved!

Thanks!! I'll merge once the integration test check passes!


maintainers-list: create a field isActive

Default true; should be set to false when the maintainer is not active.
The most immediate use of this Boolean attribute is to mark maintainers that are not contributing to Nixpkgs from a long amount of time. Nonetheless it can be used to mark any long term inactivity, including but not limited to:

Sabbatical leave
Retirement
Intimate issues
Force majeure

In principle, a third person can set this attribute; nonetheless, for the sake of a good etiquette, at least one contact attempt must be issued and carried out before effectively committing it.
This attribute can be employed to many useful activities, including but not limited to:

Treewide automation

Removal of inactive maintainers from packages
Orphaning alerts

Filter automatic notifications

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Why?

In this way we can indeed trace other people's active status easily. But self mark as inactive and by others/bot have different meanings. If they are marked passively, they may not want to be disturbed, but this behavior may lead to more inactivity. It's good to use this to remind the maintainer or help remove inactive ones, but it also deserves more consideration.

Why?

Routinely I am bumping on code maintained by inactive people. https://github.com/NixOS/nixpkgs/issues/290642
Recently I am refactoring SDL and Guile libraries, and it is not hard to find people that are at least two years away from Nixpkgs.
It would be easier to have some help from Nixpkgs machinery to detect them.

If they are marked passively, they may not want to be disturbed, but this behavior may lead to more inactivity.

The idea is to mark cases of long term inactivity.
Also they are also free to return, just by updating the field.

It's good to use this to remind the maintainer or help remove inactive ones, but it also deserves more consideration.

Agreed.

Related issues:

https://github.com/NixOS/nixpkgs/issues/88867
https://github.com/NixOS/nixpkgs/issues/290642

Hello, @abbradar!
Apologies for marking you without previous advice, but I have read what you wrote at the RFC55 comment.
What do you think about marking yourself as inactive for the time being?

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/4096

The idea is to mark cases of long term inactivity.
Also they are also free to return, just by updating the field.

They would still receive PR review requests and the like. What would more align with the current tooling and not requiring further changes, would be to just drop those entries and maybe together packages they maintain which are broken for a longer time.

They would still receive PR review requests and the like.

the tooling can be updated to reflect this...

just drop those entries

I am accumulating days cleaning up SDL-related packages is a state of abandonment...

Aleksana said

But self mark as inactive and by others/bot have different meanings.

Rather than a boolean field, what if we make it nullOr str, where the string states the reason? Any string indicates inactivity. The field would also then need to be renamed.

whyInactive? I will test this.

Done. What do you think,  @pbsds

The tooling can be updated to reflect this.

But until that is done, this doesn't change things and from a reviewer perspective, this is completely intransparent. It would be way easier to review things, if the packages didn't have a maintainer, then we also wouldn't start a discussion with every PR that picks up an abandon package.

The tooling can be updated to reflect this.

But until that is done,

This is not the hardest thing on this planet.

this doesn't change things and from a reviewer perspective, this is completely intransparent.

Asking a dormant reviewer is not what I call transparency.

This pr seems to be stuck in a limbo

The [test] commit makes this un-mergeable as-is
My request for some release note entry or documentation is unadressed
We need more people to look at this and determine whether this is the direction we want to go or not since i don't consider myself influential enough to make that call. Should we advertise it on matrix?

This pr seems to be stuck in a limbo
* The `[test]` commit makes this un-mergeable as-is

It was a test and a proof of concept, I did it to catch errors.
I can delete it right now if you like.

* My [request for some release note entry or documentation](https://github.com/NixOS/nixpkgs/pull/310759#pullrequestreview-2129153331) is unadressed

Apologies, I did not notice this part.
Where should I  write such documentation?

* We need more people to look at this and determine whether this is the direction we want to go or not since i don't consider myself influential enough to make that call. Should we advertise it on matrix?

Matrix and Discourse. I will open a post on Discourse.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/nano-annoucement-create-a-field-inactivityreason-for-maintainers/48618/1

For someone to have write access to another repo in the NixOS org they have to be in the org. Adding oneself to the maintainer-list.nix triggers some automatic process that invites the person to the org. I only know this because it's a step I had to do when @infinisil gave me write access to nixpkgs-check-by-name. Any pruning of maintainer-list.nix should take this into account.

Some other random thoughts / questions:

Seems unlikely that anyone would have the foresight or time (when asked) to note a reason.
Would a bot / GitHub action eventually stomp on the reason anyway?
How long before the reason is stale?

I will close this. It is not the suitable time to ponder about.


[Bug]: What's new and error pages don't work.

Steps to reproduce the issue?
(Probably only a mac-specific issue)
Open catalyst, click the button beside the settings button, then click whatsnew.htm or err.htm.
https://github.com/CatalystDevOrg/Catalyst/assets/66514999/043e1c00-731d-46c1-88dd-daacfd0b387f
What happened?
I would see what the new features were
Your environment (if applicable)
OS: macOS 11.7.6
CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Memory: 553.99 MB / 16.00 GB
Shell: 5.8 - /bin/zsh
Version
3.5.0 (Release version)

You are loading these pages from bookmarks made prior to the release that removed both of those pages. These pages are no longer part of the browser.


Allow running as either cargo benchcmp or cargo-benchcmp

Fixes #20.
Had to change the docopt usage string. Unsure if there is a better way.

Had to change the docopt usage string. Unsure if there is a better way.

I suppose another way would be to see if the first argument ends with "cargo-benchcmp" and the second argument is not "benchcmp" and then automatically insert "benchcmp" as the second argument.

I would prefer a method that doesn't change the usage string. I find the docs confusing without mentioning cargo in there, given that the usage should be cargo benchcmp or cargo-benchcmp...

Ok, consider me blind. I missed your second comment completely. That way, adding in benchcmp, sounds like a nicer approach to me.

@BurntSushi have an opinion about the above?

I'd like for the usage string to reflect how the user should use the tool, which is cargo benchcmp. However, cargo-benchcmp should also work. I think this means we should look at argv[0], and if it's basename is cargo-benchcmp, insert benchcmp at argv[1] (and move all other arguments down). I think that solves this without changing the usage string, right?

I think this means we should look at argv[0], and if it's basename is cargo-benchcmp, insert benchcmp at argv[1] (and move all other arguments down). I think that solves this without changing the usage string, right?

Yep, this is what I was trying to suggest as an alternative in https://github.com/BurntSushi/cargo-benchcmp/pull/21#issuecomment-251000816
I'll implement this and then comment again once I've updated the PR.

@BurntSushi I've force pushed a new version that adds "benchcmp" when invoked as "cargo-benchcmp" rather than removing "benchcmp" when invoked as "cargo benchcmp", which lets us keep the original USAGE string.

Hmm... Looks like Windows build is failing, but it appears unrelated to this PR.
@fitzgen Thanks so much! :-)

Thank you!

My apologies, but I had to back this change out because of #26.
I'm not necessarily opposed to merging another fix for this, but I'll have to insist that it be well tested.

No problem -- not sure if this is really worth jumping through hoops for.


Store arbitrary context in Flow AsyncLocalStorage

Because tools and flows are defined independently but are often interrelated in practice, it would be great to be able to set and retrieve arbitrary values from ALS. Something like:
import { setFlowContext, getFlowContext, defineFlow, defineTool, generate } from "genkit";

const findRestaurant = defineTool({
  name: 'findRestaurant',
  inputSchema: z.object({query: z.string()}),
  async ({query}) => {
    const userInfo = getFlowContext('userInfo');
    return searchRestaurants(query, zipcode: userInfo.zipcode);
  }
});

defineFlow({
  name: 'chatbotFlow',
  inputSchema: z.object({userInfo: UserInfoSchema}),
}, ({userInfo}) => {
  setFlowContext('userInfo', userInfo);
  generate({
    // ...
    tools: [findRestaurant],
  });
});

This is just a simple function wrapper around ALS right? Is this worth baking in?


Program for are of square

GDSC RAIT

Already been done by other users.Try using different branch name/programming language


mia website outdated

I noticed that mia homepage is on version 1.9.10 although the current mia version is higher (1.9.11 as of now). This indicates that something in the automated GHA build has failed although I do not see such failure in actions.
-> Check whether the automated build of website works in mia package or if not, how to fix.
The site can be locally build for testing purposes with:
pkgdown::build_site("./")
That also seems to fail. Perhaps the explanation lies there?

It looks like it has updated already!

Everything's good