[Windows10] Dark age of Camelot directx9 32 bit game

Hello i tested latest versione and 1.10 version, the game run super bad whit both version. Heavy swapping and the game is unplayable. The game is using Directx9 32bit. I usually play on this server since is free ( https://www2.uthgard.net ) that use the base game patched from them.
The reason i tested this Vulkan api system is casue even on normal the game run super bad whit this graphic card even disabling ULPS ( ultra low power settings ), basicly it will not use the gpu at all and constantly downclocking. Was hoping Vulkan can solve this problem
Software information
Dark Age of camelot base settings bordeless windows at monitor resolution 1440p
System information

GPU: Amd Rx6700XT
Driver: 23.8.2
Wine version:
DXVK version: 2.3 and 1.10 tested

Do you mean the game have low fps in general with dxvk or that there is alot of stuttering?
I tried the game on the main servers quickly and both with my 7900xtx dGPU and weak zen4 iGPU my fps seems to always be at 125 fps in the starting area i choose.
The game does have quite alot of shaders and they will get compiled when you move and look around in the game which will introduce alot of stutter (should get better over time),b ut dxvk can't do much about that. That part should improve once AMD's driver supports the VK_EXT_graphics_pipeline_library Vulkan extension which is utilized to help such issues. The radv driver on Linux (not AMD's own) already support this, though even without it fares better in regards to shader compilation.
Though i also see game always loads them in at draw time and not up front.

Yes stuttering i also get 120 fps but is the cap, the problem lies in the shader. I found a discussione on reddit some minute ago ( https://www.reddit.com/r/Amd/comments/9mpzvj/is_there_anyway_to_switch_global_shader_cache_to/ ) enabling shader cache to on greatly improved in dx9. Ill try use vulkan again to see if it goes even better. Btw im having a Ryzen 5700G Cpu and whit that integrated gpu the game was working no problem even on dx9 so i guess its something wrong whit just the dedicated graphic card even if they use the same driver ...

Please make an apitrace so I can look into this.

Native Windows trace https://drive.proton.me/urls/G78R3YVEKM#LjY0TLIVAteu

@Filters83 I use dxvk to play on the Dark Age of Camelot freeshard because using the normal 'gl' renderer causes a massive memory leak (in libMesa somewhere). I switched renderer=vulkan and the game plays fine. Once in a while I do get a crash to desktop but it seems stable to me.
How did you manage to get Uthgard freeshard to run? When I try, I see game.dll running and connecting to the server, but there is no graphics.


Unable to Open another sheet over existing sheet in ios

i m facing problem in ios device, when i click on any item of rbsheet, i need to open another rbsheet. This works fine in android device, but not in ios device. pls help.

@rahul121010989kumar RBSheet is implemented on top of react native Modal and this is currently not possible #3445. Anyway, you are able to nest components to achieve this behaviour.
<View>
  <Button title="OPEN BOTTOM SHEET 1" onPress={() => { this.RBSheet1.open(); }} />
  <RBSheet ref={ref => { this.RBSheet1 = ref; }}>
    <YourOwnComponentOne onPress={() => { this.RBSheet2.open(); }}  />
    <RBSheet ref={ref => { this.RBSheet2 = ref; }}>
      <YourOwnComponentTwo />
    </RBSheet>
  </RBSheet>
</View>

Hope this could help.

I also couldn't open multiple sheets on each other in iOS. I tried to close the first sheet and open the second one immediately, but it also didn't work. The solution my colleague and I came up with was a timeout of 2 seconds between closing the first sheet and automatically opening the second one.


solved bug in automatic deployment

Fixes issue #38
Changes: Fixed bug in automatic deployment

@saurabhjn76 @Manveer695 @dynamitechetan kindly review this PR Thanks.


Include preprints

Preprinting (as opposed to open access, #9) seems like an omission from the current topic suggestions.

Here the wikipedia page on journals by preprint policy would be a great resource to link to, along with more rhetorically persuasive pages.

That's a good idea, thanks @ctb.
Other nice resources are also:
http://www.sherpa.ac.uk/romeo/search.php
https://rchive.it/ (a wrapper for SHERPA/ROMEO)

More generally, the list of resources in this paper:
https://figshare.com/articles/The_open_research_value_proposition_How_sharing_can_help_researchers_succeed/1619902
is reasonably recent and might be a good starting point for many things.

Thanks for your input, @ctb! I personally would count this still as part of open access (#9). In the open access topic the different paths (golden, green (i.e. preprints and instistitutional repositories) and diamond open access) should be described. But independent if this will be a distinct topic or part of open access (#9) it is good to have this explicitly mentioned as something to that needs to be addressed.

The reason I would suggest classifying it separately is that many people are
afraid to publish in open access journals b/c of stigma. With preprints, you
can make your work open (and citable), while also targeting the journals
that your co-authors think are important.

Okay, just a question of "marketing" :) Good point.

Would be great to list benefits for each group. For example,
Authors:

Fixing issues by suggestions.
Citing growth.

Publishers:

Gems early discovery.

Companies and Funding bodies:

Faster proof of the topic viability

What are the other benefits?

I don't think authors always view the opportunity to have more people review their work as a positive ;).
There's a more complete list in the figshare preprint I link to above, but in addition to citations and finding out about major problems BEFORE the peer reviewers, I also see:

authors benefit by getting the work out there and citable during the (sometimes lengthy) peer review process; in many physics fields, peer review can take years, but in the meantime everyone has read the paper.

preprints establish priority of publication.


Ability show sources via node-inspector

...that doesn't show the source map though, does it?!

This pr add ability to require *.ls with sourcemaps for correct representation in node-inspector or maybe other debugging tools.

thanks


Why no v3-sdk repo

Can't see a v3-sdk repo anywhere? Why is that?

It's in the "frontend" repo. Not very well named, just throwing that out there


Initial addition of emails

Feel free to make any changes you see fit. Fixes #25.

Includes inviteEmail
Includes welcomeEmail
Note that you do need to export MANDRILL_API_KEY="YOURKEYGOESHERE"

[EDIT]

default link value just use ENV=production on deploy
Adds default link value. Added MailConfig. Might be overkill if we never need any other config stuff but feel free to modify to your liking.

Just realized I hard coded localhost for the inviteEmail I can change that.

Cool, can't wait to test it out!


Update selectStakeCredentialWitness to return all possible Credentials

Changelog
- description: |
   Update `selectStakeCredentialWitness` to return all possible Credentials.
   This allows us to use Plutus script witnesses for any certificate involving a script stake credential.

  type:
  - bugfix         # fixes a defect
  - compatible     # the API has changed but is non-breaking

Context
Additional context for the PR goes here. If the PR fixes a particular issue please provide a link to the issue.
How to trust this PR
Highlight important bits of the PR that will make the review faster. If there are commands the reviewer can run to observe the new behavior, describe them.
Checklist

[ ] Commit sequence broadly makes sense and commits have useful messages
[ ] New tests are added if needed and existing tests are updated. See Running tests for more details
[ ] Self-reviewed the diff

This PR appears to be reverting fix for ExtraRedeemers error: https://github.com/IntersectMBO/cardano-cli/issues/297#issuecomment-1747536111 , meaning this PR: https://github.com/IntersectMBO/cardano-api/pull/383/files . However, that was for babbage era but this PR is in Conway. It would be worth running a similar regression test but for Conway.
Can you check with @mkoura if it's not breaking test suites in https://github.com/IntersectMBO/cardano-node-tests ?

It caused a regression like the one described in https://github.com/IntersectMBO/cardano-cli/issues/297#issue-1904885972

Command failed: transaction submit  Error: Error while submitting tx: ShelleyTxValidationError ShelleyBasedEraConway (ApplyTxError [ConwayUtxowFailure (AlonzoInBabbageUtxowPredFailure (MissingRedeemers [(ConwayCertifying (ConwayTxCertDeleg (ConwayRegCert (ScriptHashObj (ScriptHash "f52e522c0d4cd59704c883c330f781134c5f00d8152db3eca3860154")) (SJust (Coin 400000)))),ScriptHash "f52e522c0d4cd59704c883c330f781134c5f00d8152db3eca3860154")])),ConwayUtxowFailure (UtxoFailure (AlonzoInBabbageUtxoPredFailure (UtxosFailure (CollectErrors [NoRedeemer (ConwayCertifying (ConwayTxCertDeleg (ConwayRegCert (ScriptHashObj (ScriptHash "f52e522c0d4cd59704c883c330f781134c5f00d8152db3eca3860154")) (SJust (Coin 400000)))))]))))])


Improve Browser UI after logging

Currently. After you login, you have a message to get back to the Explorer that is plain text with white background.
Improve it to match the other UIs

https://github.com/leanmendoza/decentraland-auth/pull/3


Add Ability to manage the WSUS Service

We should add the ability for the user to manage the wsus service.

puppet resource service wsusservice

service { 'wsusservice':
  ensure => 'running',
  enable => 'true',
}


(Bug) DuckDB integer division need to be rewritten with '//' symbol

Describe the bug
In DuckDB, integer division is done with symbol //, for example a // b. Currently there's no way to specify an integer division when sending queries to DuckDB connector / accelerator. An implementation to detect and rewrite integer division from a/b into a//b in unparser DuckDB dialect is needed to support queries containing divisions and sent to DuckDB
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Runtime Details
Spicepod
Add the relevant spicepod.yml section.
Output of the describe table
Add any relevant describe table output here.
Output of explain query
Add any relevant explain query output here.
E.g. explain select 1
+---------------+--------------------------------------+
| plan_type     | plan                                 |
+---------------+--------------------------------------+
| logical_plan  | Projection: Int64(1)                 |
|               |   EmptyRelation                      |
| physical_plan | ProjectionExec: expr=[1 as Int64(1)] |
|               |   PlaceholderRowExec                 |
|               |                                      |
+---------------+--------------------------------------+

spice, spiced, OS info

spice version: spice version
spiced version: spiced --version
OS info: uname -a

Have you tried this on the latest trunk branch?

[ ] Yes
[ ] No

If possible, run spiced with DEBUG log level
By setting the environment variable SPICED_LOG="task_history=DEBUG,spiced=DEBUG,runtime=DEBUG,secrets=DEBUG,data_components=DEBUG,cache=DEBUG,extensions=DEBUG,spice_cloud=DEBUG"
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Closed by https://github.com/spiceai/datafusion/pull/64


rename: Declarations diff

Yes, looks better indeed!
maintainer merge

bors merge

bors r-

bors d+

bors merge


Fixes umbrella

Apart from fixing the design guideline violations, I believe the added spike on top more clearly communicates the icon's umbrella-ness.

@karsa-mistmere I like how you rethink of the icon and make it better looking. Thanks for that!


Spring Boot Guide: Versions section needs link to RN component versions table for Spring Boot tested starters

Here is the production RN URL: [https://access.redhat.com/documentation/en-us/red_hat_openshift_application_runtimes/1/html-single/red_hat_openshift_application_runtimes_release_notes/]
This issue is for [https://issues.jboss.org/browse/OBST-500].

Added link to RN in SB runtime guide.

@ccopelloRH changse incorporated and merged.


Output dictionary keys hardcoded in model.py should be in DefaultDataKeys

https://github.com/PyTorchLightning/lightning-flash/blob/143112d01542083214d8d6b1bfba54688ac9cf3e/flash/core/model.py#L353-L355
It seems to me that hardcoding "loss" "y_hat" and "y" in here isn't the best practice and encourages everyone who needs those values in callbacks to either hardcode or store the key values in their own variables. For whatever reason, if the keys were to change, custom callbacks would break easily.
I propose moving the output keys into the DefaultDataKeys for this use case. Naming them something with a prefix so as not to be confused with other input data keys. Alternatively, make a different enum class for these to go in and be used.

@dlangerm Thanks for the suggestion! Definitely good to get rid of those magic strings. I think either of your proposed solutions would be fine. Perhaps a new enum is best as it could reside in the same file as the strings for readability. Would you be interested in making a PR to do that?
Thanks :smiley:

@ethanwharris  https://github.com/PyTorchLightning/lightning-flash/pull/765


Explore how to best extract intelligence from the OpenTelemetry

Exploration of an easy solutions/integration, which gives insights into the OTel data recorded.

Done here https://www.notion.so/expanso/How-Should-We-Collect-Telemetry-About-Our-Users-54493a30964343e2ac1b632a19ff8e73


Better multi-window workflow

Currently duplicating workspace in another window launches entirely new instance of
vscode, which means double the resource usage and no synching between windows.
I would request the ability to open multiple front-end windows on a single instance backend.

See #367 and #10121


Update documentation to reflect current plans

Before closing this I think we need to address:
-Local mode vs cloud mode (or rather how these change into having a remote controller vs not having one).
-Going to production plans are not in V1 and it should be appropriately reflected  in documentation

Obsolete


Support for robotsflag field based on OpenWayback behaviour

We were looking at using the <robotstxt> field, which is currently not supported by tinycdxserver, and were wondering if you'd be happy for us to submit a pull request that enables it?
The implementation in OpenWayback is rather odd, in that it populate this field using the M meta tags (AIF) field (see here). It's not clear why the meta tags field becomes the robotstxt field, but AFAICT this is the only way to populate that field via the CDX format.
It doesn't look like too difficult a change, but given that it's nearly there but commented out I thought I'd better ask if there's a problem?  Presumably the indexes won't be compatible either?

Sure, would be happy to accept a pull request that implements it.
There's no problem with it. The index format includes a pre-record (per CDX line) version number. So create a new ddcodd

Gah. Sorry. 'close issue' is too near the text box on mobile.
...  So create a new Capture.decodeValueV2() method for a version 2 record format that supports the robots field and update Capture.encodeValue() to write the new format. Then the index server will happily read both new and old records and you can even mix them in the one index while incrementally reindexing to fill in the robots field data.
It was marked as todo simply because I didn't have any CDX files on hand with that field populated and wasn't sure what the data format was or what exactly it was used for in Wayback.


Improve usability of Color Picker sliders

Fixes #69058
Allows bottom half of grabbers to be draggable and adds a visual track for the grabbers to slide along.

And adds a visual track for the grabbers to slide along.

Could you provide a screenshot of how it looks?

Sure thing, here's is a screenshot of the colorized sliders.

Here is one with colorized sliders turned off.

This is my first time contributing to an open source project so any/all feedback is appreciated.

Not sure if I agree on the gray bar at the bottom of the color gradient. Although it makes the marker more visible, it's too thick, a bit distracting. It may actually be worth exploring making the marker more visible in other ways.

The gray bar under gradients looks ugly. How does the grabber icon work? Is it a texture bigger than the slider? Maybe we just need extend input area up to grabber size? (if it's feasible...)

There doesn't seem to be consensus on this PR.


The docker pull command on the hub.docker.com page doesn't work

Details
It tries to pul the :latest tag that doesn't exist. Perhaps you could put the most recent tag up there that does exist? It's nice to have somewhere to click to get a docker pull that just works. (And its annoying to see all these docker pulls that do not work)

That's not an issue, as we are not using an latest tag.


Model classifier weights for  CIFAR100

Hi, will you release the trained classifier weights for all other datasets instead of IMNET ?
I checked  the released repvit_m3 model weights it seems the classifier is for 1000 classes.
Thanks

Hi, thanks, we have not trained repvit on CIFAR100 yet. I suggest that you could also use the weights pretrained on IMNET to finetune repvit on CIFAR100 as well. And I am sorry that I don't have bandwidth for training repvit on CIFAR100 at the moment.

Got it, thanks


[ENH] Add possibility for the user to custom the skipped interfaces

@pdedumast If needed I activated the generation of the doc for this branch. I can be viewed at https://mialsrtk.readthedocs.io/en/27_custom_skipped_interfaces/

For the future, we should have in mind to set skip_stacks_ordering to false in the configuration file (we could also make two different configuration files) otherwise this decreases code coverage.

@sebastientourbier Indeed, skip_stacks_ordering=False is the default value.
I did not mean to commit the json parameter file, this is a mistake. Though, as how it is implemented now, the list of output files will not be modified when switching skip_stacks_ordering on and off.

@sebastientourbier  seems that old required tests are blocking the possibility to merge. Any idea?

@sebastientourbier seems that old required tests are blocking the possibility to merge. Any idea?

Yes, for the moment I need to force the merge. That's what I did ;)


Create BMR unit test for receiver functionality

Overview
Create BMR unit test for receiver functionality
Rationale
We don't have unit tests for BMR receiver functionality

Final the icon receiver file code coverage is about 80%


Mention order of operations

And has higher precedence than or, so intersection should have higher precedence than union.

That's conveniently what we get from & and |.

True.  Should we mention it in the PEP or is it obvious enough?

I think it's worth mentioning that it's a consequence of Python's operator precedence.  No reason to leave a doubt about the PEP author's intention.


Improve documentation

Guys, if you feel that you can make any contribution to docs, don't hesitate. Make the pull request.
They are in the docs/chapters folder and you can check how it looks like locally when you do npm run docs. before that, you have to do npm install.

Do you still need help?


tests: WinError 32 on CI again

While deleting the temporary directory:
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process:
While my initial reaction is that this some Windows BS again... maybe there are broken tests. Our test setup is in some cases unnecessarily complex and could hide issues.
Full log from https://github.com/theupdateframework/tuf/pull/1337/checks?check_run_id=2296694965:
2021-04-08T12:27:41.4005743Z ======================================================================
2021-04-08T12:27:41.4007002Z ERROR: test_update (test_multiple_repositories_integration.TestMultipleRepositoriesIntegration)
2021-04-08T12:27:41.4008300Z ----------------------------------------------------------------------
2021-04-08T12:27:41.4009113Z Traceback (most recent call last):
2021-04-08T12:27:41.4011194Z   File "D:\a\tuf\tuf\tests\test_multiple_repositories_integration.py", line 175, in tearDown
2021-04-08T12:27:41.4012361Z     shutil.rmtree(self.temporary_directory)
2021-04-08T12:27:41.4013338Z   File "c:\hostedtoolcache\windows\python\3.7.9\x64\lib\shutil.py", line 516, in rmtree
2021-04-08T12:27:41.4014214Z     return _rmtree_unsafe(path, onerror)
2021-04-08T12:27:41.4015136Z   File "c:\hostedtoolcache\windows\python\3.7.9\x64\lib\shutil.py", line 395, in _rmtree_unsafe
2021-04-08T12:27:41.4015989Z     _rmtree_unsafe(fullname, onerror)
2021-04-08T12:27:41.4016900Z   File "c:\hostedtoolcache\windows\python\3.7.9\x64\lib\shutil.py", line 395, in _rmtree_unsafe
2021-04-08T12:27:41.4018012Z     _rmtree_unsafe(fullname, onerror)
2021-04-08T12:27:41.4018950Z   File "c:\hostedtoolcache\windows\python\3.7.9\x64\lib\shutil.py", line 404, in _rmtree_unsafe
2021-04-08T12:27:41.4019860Z     onerror(os.rmdir, path, sys.exc_info())
2021-04-08T12:27:41.4020803Z   File "c:\hostedtoolcache\windows\python\3.7.9\x64\lib\shutil.py", line 402, in _rmtree_unsafe
2021-04-08T12:27:41.4021550Z     os.rmdir(path)
2021-04-08T12:27:41.4023055Z PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'D:\\a\\tuf\\tuf\\tests\\tmplg5mtj4n\\TestMultipleRepositoriesIntegration_ziar2llq\\repository_server2'

In the example case the test creates a tempdir using tempfile, then creates another tempdir inside it using unittest_toolbox, then it starts two server processes that use the inner temp dir...
Then when tearing down it calls unittest_toolbox teardown first, which probably deletes the directory while the process is still running. So:

Process shutdown should always be the first thing in test teardown
test setup should not be as complex as it is

The only flaw in this theory is that the error only comes in line 175 in test_multiple_repositories_integration.py -- how did the original unittest_toolbox..TearDown() succeed on line 164?

from teodora:

Modified Test Case ignores permission error as a subclass of OSError

This explains why line 164 "succeeds" -- it just quietly fails to remove  the directory.


add separate task pages for adding Linux/Windows nodes with kubeadm

follow up on discussions in:

https://github.com/kubernetes/website/issues/34476

slack:

https://kubernetes.slack.com/archives/C1J0BPD2M/p1725978983889459

proposed plan for a PR:

creates the Linux task page by moving / refactoring the existing "join node" contents from the "create a cluster" page:
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#join-nodes
creates the Windows task page by taking the content from https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/guides/guide-for-adding-windows-node.md
at the end of the Windows page we add note/disclaimer whatever that says that CNI on Windows needs special handling and we link to the various CNI choices at:
https://github.com/kubernetes-sigs/sig-windows-tools/blob/master/guides/guide-for-adding-windows-node.md#networking-configuration
adds tabs in the https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#join-nodes to choose between OS for joining nodes.

/sig cluster-lifecycle docs windows
/assign

/triage accepted

I'm afraid that this seems similar to https://github.com/kubernetes/website/issues/44248
/triage duplicate
/remove-triage accepted

Can we use #44248? I'm sure we'd be happy to revise the description of that existing issue @neolit123.

assigning myself to the other ticket.

/close not-planned


how can I remove the expand icon of the non-data rows ?

What version of React-Table are you using?
v6.8.0
https://codesandbox.io/s/jp640jzlv5
codesandbox example's the child data in row 2 is empty but it can be expandable.
how can I remove the expand icon of the non-data rows ?

You should be able to pass Expander property to column definition, and then render it based on your preferences.
Please look at https://react-table.js.org/#/story/readme section Column.
It should look like Expander: props => condition ? null : <default expander>

@pnaw94 thanks your answer.
I did this way.
{     expander: true,     width: 65,     Expander: ({ isExpanded, ...rest }) =>{       if(rest.original.hareketler.length > 0){         return (           <div>             {isExpanded               ? <i className="fa fa-minus c-red"/>               : <i className="fa fa-plus c-green"/>}           </div>         )       }       return (         <div>           <i className="fa fa-plus disabled" style={{color:'#e8e8e8'}}/>         </div>       )     }   }

@mikdatdogru : could you update the example with the fix you had. I also had same issue

@krishna63
working demo here:
https://codesandbox.io/s/8l464jrm19


undefined: io.Discard and io.ReadAll in latest code push

Describe the bug
Currently, the Go Client is broken due to io.Discard and io.ReadAll being undefined in latest version of the code.
Expected behavior
Should be able to run the Go Client without getting undefined errors unrelated to my code.
Logs
# go.mongodb.org/atlas/mongodbatlas
/root/go/src/go.mongodb.org/atlas/mongodbatlas/mongodbatlas.go:450:20: undefined: io.Discard
/root/go/src/go.mongodb.org/atlas/mongodbatlas/mongodbatlas.go:521:15: undefined: io.ReadAll
Error: Process completed with exit code 2.

Hi @DrewCurd, I'm assuming this is a go version prior to 1.16 where io.Discard and io.ReadAll where added and ioutil deprecated, sadly we dropped support for any version prior to 1.16 (https://github.com/mongodb/go-client-mongodb-atlas/pull/242) in line with our support policy, from our README

Note that go-client-mongodb-atlas only supports the two most recent major versions of Go.

Which is also aligned with the go support policy
https://golang.org/doc/devel/release#policy


update listener benchmark

What type of PR is this?

What this PR does / why we need it:
A random address is set for the listener in the test case
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

/lgtm
/approve


Update Convert-WikiAndWebPartPages.ps1

Fixed typo in output message; Replaced wike with wiki;

Thanks for the fix @JarbasHorst


How to stop the rotation of model and hdr

Hello,
I managed to do this by adding another transparent view over the sceneview, that will block access for the touch events


#156687695 Add New Dashboard Tab for Unresolved Checks

What does this PR do?
Adds a new dashboard link that allows a user to view failing jobs that they have been notified about.
The following files have changed:

hc/front/views.py
hc/front/urls.py
templates/base.html

And the following files have been created:

templates/front/my_unresolved_checks.html
hc/front/tests/test_adds_unresolved_checks.py

Description of Task to be completed?
When a user logs in, the dashboard tab "CHECKS" that displays the user's past checks does not have failing jobs in a separate view from the rest of the past checks. Create a new dashboard tab to show only the checks that have failed and that the user has been notified about.
How should this be manually tested?
Run the app as described in the README. Create an account, and login. Check whether the dashboard contains a tab for unresolved checks dubbed "UNRESOLVED CHECKS".
Create a Check, make it fail and stay failed past the grace period. Check the notification on your email for this check. Check whether the Check appears under "UNRESOLVED CHECKS" tab on the dashboard.
What are the relevant pivotal tracker stories?

https://www.pivotaltracker.com/n/projects/2163622
Story ID: 156687695

Screenshots?
The screenshot below is showing an unresolved check:

The screenshot below is showing a message when there is no unresolved checks:

Pull Request Test Coverage Report for Build 211

1 of 14 (7.14%) changed or added relevant lines in 1 file are covered.
9 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.6%) to 78.824%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

hc/front/views.py
1
14
7.14%

Files with Coverage Reduction
New Missed Lines
%

hc/settings.py
1
97.83%

hc/api/management/commands/ensuretriggers.py
8
100.0%

Totals

Change from base Build 167:
-0.6%

Covered Lines:
1381

Relevant Lines:
1752

💛  - Coveralls

I like how the UI for the unresolved stuff looks. There is a nice blend of colors that does not throw the user off

I added the tests. I added them in this module: hc/front/tests/test_adds_unresolved_checks.py. Let me know if you feel some edge case I forgot to cover


global: remove ETag/Last-Modified headers

removes the ETag/Last-Modifies headers when returning the records
REST responses to prevent caching of extra fields added at
serialization time.
closes #851
closes #852
closes #857
closes #861

Not very happy with the solution, in particular in the case of PUT requests. But I couldn't find anything better.
I can explain more about the PUT requests issue by voice.


Support Node 22

Node.js Release Schedule

Initial release: 2024-04-24
Active LTS start: 2024-10-29

Status doc (internal-only link)
Our Release Schedule
Please see our roadmap for the latest estimates: https://github.com/Azure/azure-functions-nodejs-library/wiki/Roadmap

For things like Service Bus triggers using AMQP over HTTPS, will that use Node 22's native (undici-based) WebSocket or will they still pull in the ws implementation as an extra dependency?


Tags doesn't always work in monorepos

When using this for a monorepo it's not unlikely there will be commits to other services between a push and a tag, this then breaks when we check for the commit hash since we're using Build.SourceVersion which just checks the latest hash that triggered the build.
We need a different way of finding the hash, either by looking at previous pipeline runs for the service or by looking at the dev yaml.

@ulrikstrid according to our call, this works as expected and the issue occurs when tagging a newer commit than what was pushed for a specific service.
I'm assigning you the issue to create a script that tags the correct commit to make it easier.

Created this script that works for our usecase:
#!/bin/bash
get_tag () {
    prev=$(git tag | grep -E "$1")
    if [ -z "$prev" ]
    then
        echo "$1-1"
    else
        number="${prev:9:2}"
        next_number=$((number + 1))
        echo "${prev:0:9}-$next_number"
    fi
}

now=$(date +"%Y%m%d")

service_name=$1
service_path=$(find src -name "$service_name")

commit_sha=$(git rev-list -1 --all "$service_path")

next_tag=$(get_tag "$service_name/$now")

git tag -m "$2" "$next_tag" "$commit_sha"
git push origin "$next_tag"

@ulrikstrid updated it a bit:
#!/bin/bash
set -ex
get_tag () {
    prev=$(git tag | grep -E "$1")
    if [ -z "$prev" ]
    then
        echo "$1-1"
    else
        service=$(echo ${prev} | awk -F"/" '{print $1}')
        date=$(echo ${prev} | awk -F"/" '{print $2}' | awk -F"-" '{print $1}')
        number=$(echo ${prev} | awk -F"/" '{print $2}' | awk -F"-" '{print $2}')
        next_number=$((number + 1))
        echo "${service}/${date}-$next_number"
    fi
}

git fetch --all --tags

now=$(date +"%Y%m%d")

service_name=$1
service_path=$(find src -name "$service_name")

commit_sha=$(git rev-list -1 --all "$service_path")

next_tag=$(get_tag "$service_name/$now")

git tag -m "$2" "$next_tag" "$commit_sha"
git push origin "$next_tag"

Can be slightly simplified to this:
#!/bin/bash
set -ex
get_tag () {
    now=$(date +"%Y%m%d")
    service=$1

    prev=$(git tag | grep -E "^$1/$now")
    if [ -z "$prev" ]
    then
        echo "$1/$now-1"
    else
        number=$(echo ${prev} | awk -F"/" '{print $2}' | awk -F"-" '{print $2}')
        next_number=$((number + 1))
        echo "${service}/${now}-${next_number}"
    fi
}

git fetch --all --tags

service_name=$1
service_path=$(find packages -maxdepth 1 -name "$service_name")

commit_sha=$(git rev-list -1 --all "$service_path")

next_tag=$(get_tag "$service_name")

git tag -m "$2" "$next_tag" "$commit_sha"
git push origin "$next_tag"

Also solves the case where you have services with names that include each other "my-service" and "y-service".


fail maven install

execute maven install -Dmaven.test.skip=true,
but when the execution fails here
[INFO] Installed npm locally.
[INFO]
[INFO] --- frontend-maven-plugin:1.0:npm (npm install) @ pinpoint-web ---
[INFO] Running 'npm install' in /Users/summer/Downloads/pinpoint/web/target

Hi ruizlake,
we'll probably need more information about the error to try and figure out what's failing.


INCIDENT-24014 Revert base changes from #16040

What does this PR do?
While we still don't fully understand why, the addition of the tracked_query decorator seems to have been causing out of memory kills. In order to unblock things, this PR reverts those changes. This is the first part of the revert that removes the new decorator and, following, we'll revert the usages in mysql, postgres and sqlserver integrations.
Motivation

Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] Changelog entries must be created for modifications to shipped code
[ ] Add the qa/skip-qa label if the PR doesn't need to be tested during QA.

It turns out this change wasn't having the impact we thought it did. Closing.


more documentation for duplicate_count

From a comment by Mathieu of vidjil group:
In particular, we used the duplicate_count key to describe the number of
reads gathered in each clone, as you suggested us in your previous
email. To enable a better interoperabilityn maybe this suggestion could
be clearly stated in AIRR documentation of this field? For example,
taking inspiration on what was already on the sequence_id field,
"duplicate_count (...) This may also be a total number of gathered
sequences in cases where query sequences have been combined in some
fashion by the tool."

Agreed, we need to describe this in more detail. To make sure we are all on the same page, my interpretation of what the docs should say is:

consensus_count indicates the total number of raw reads for a given sequence.
duplicate_count indicates the number of UMI-collapsed reads for a given sequence.
The counts in consensus_count and duplicate_count should be identical for non-UMI protocols.
duplicate_count maps to the MiAIRR field "Read count", which in turn maps to the custom AIRR_READ_COUNT keyword for Genbank annotation.

Is this correct?

Is this correct?

Actually I think it is switched around based upon what Jason has mentioned before.

consensus_count is the number of UMI-collapsed reads for a given sequence. That is, UMI is used to build a "consensus" sequence.
duplicate_count is the total number of raw reads for a given sequence. Or really in general, any collapsing of reads/sequences that are considered "duplicates".

However, duplicate_count can be a bit fuzzy. For example, some tools that pre-process raw reads, before VDJ assignment is performed, will collapse identical sequence (same length and nucleotides) into a single sequence with a duplicate_count. Other tools don't collapse on sequence but on clones and duplicate_count is the number of sequences/reads in the clone. There is also the scenario that two or more sequences will have different UMI codes, but they are identical, and thus can be collapsed as duplicates.
In the first case of pre-processing, you can imagine that there can be two or more rows of sequences (that differ slightly in length or nucleotides), each with their own duplicate_count value, but all of those rows belong to the same clone. To get a true count for the clone, you would need to sum up the duplicate_count for all of those rows.
Maybe this ambiguity is not good, and we should have a separate clone_count field?
I think the intent of duplicate_count is for collapsing sequences that are considered "identical" (accounting for errors and such) without considering the biological interpretation of the sequence, i.e. "identical" just from an informatic perspective.

Hrm. I think you  two (@schristley and @bussec) might be saying the same thing? Not sure.
First, I think we should avoid the word "clone" in this discussion, because its meaning is ambiguous. In a BCR context it usually means a collection of related variants, but in a TCR context it usually means a collection of identical sequences. Same thing - all sequences assumed to represent the same original V(D)J recombination event. But, they are counted in a different way.  I think Mathieu means the TCR definition.
I see the fields as:
consensus_count:  The "confidence level" of the sequence. The number of reads used to build a consensus sequence. I only use this when the count is purely technical with no real biological meaning. Usually, this would be the number of reads contributing to a UMI consensus sequence. But, it could also be from some other error correction approach, such as clustering sequences inferred to differ only by sequencing error and aggregating them somehow (see IgReC  for an example).
duplicate_count:  The "copy number" of the sequence. This could be the count of UMIs for each unique sequence (as measured by the number of identical copies) or identical sequence counts for non-UMI protocols.  I'm pretty certain the latter is exactly what the Vidjil group wants.
So... I think that's the same thing you're both saying?  Example:
After UMI consensus generation, but before duplicate removal:
UMI1  AAAAA     consensus_count=4
UMI2  AAAAA     consensus_count=3
UMI3  CCCCC     consensus_count=2

After duplicate removal:
UMI1  AAAAA     consensus_count=7    duplicate_count=2
UMI3  CCCCC     consensus_count=2    duplicate_count=1

For non-UMI protocols, I just wouldn't include consensus_count. Though, I think making them identical, as @bussec says, makes sense also. As for AIRR_READ_COUNT, I believe this is suppose to be consensus_count, because it was intended to reflect the confidence level for the consensus sequence.
I think we should wait on defining a clone_count field that would define the count of clonally related variants. That sounds like part of the lineage schema.

@bcorrie, which part of the MiXCR output are you referring to? Depending upon which value it is, it could be consensus_count, duplicate_count, or something like the clone_count field @scharch added. Looks like they have several aggregating steps (raw reads, identical junction, V/J/C gene).
(Pinging @mikessh and @dbolotin.)

Sorry, in this case it is the cloneCount field from the MiXCR annotation output. Which you might say obviously should be mapped to clone_count, but given the above discussion I was not clear. And I suspect that given that MiXCR is a commonly used annotation tool, I suspect that we might want to make sure we are clear as to what this mapping should be.
@emilyvcbarr or @nishanth would be able to comment further on which MiXCR processing steps that produce this output file.

Hello all, just following up on this issue - hoping to maybe close it out... Any input as to the mappings from MiXCR clone count fields to the AIRR fields?

We discussed duplicate_count and consensus_count a bit more at MinStd this week.
The suggestion was that for each rearrangement record the duplicate_count and consensus_count may or may not exist. The meaning of these fields would depend on the parameters in Section 3 and Section 5 of MiAIRR (PCR prep and Data Processing) and that the actual meaning and interpretation of these counts would likely be ill-defined without considering the higher level metadata.
That is, a researcher would need to know information from Sec 3 and Sec 5 in order to interpret (and more importantly compare/analyze) the consensus_count and duplicate_count provided in two data sets (repertoires) from two different studies.
This means that when providing simple summary statistics (counts of rearrangements) about aggregate data across many repertoires, it is problematic (and possibly misleading) to aggregate the consensus_count and duplicate_count because of the interpretation required.
Does my interpretation make sense given the above discussion.

Yeah, I think that's accurate. This is further confounded in the case of single-cell data with contig assembly. For example 10X V(D)J will have reads that went into building the contig and UMI count (expression level). Because I don't have a use for the contig read count, I've been using consensus_count for the UMI count and duplicate_count for duplicate V(D)J sequences (as normal).
But, the semantics are misleading in that case, because in bulk UMI projects, the consensus_count will be the count of assembled reads and the duplicate_count will be the UMI count...
I'm not sure exactly what to do about it, but we should maybe bring this topic up in the DR-WG? I'm starting to think we should maybe have count_* fields instead  (count_duplicate, count_read, count_umi, count_clone). Not sure.  It's very difficulty, maybe impractical, to support multiple different experimental protocols and analysis protocols with two fields.

Is it possible to separate out the case where a field unambiguously acts as a multiplier for abundance for the rearrangement (versus for clones)? That strikes me as the most important to be unambiguous. If programs need to perform some sort of logic to determine how a field is used, that can be error prone.

A thought on this as someone who is NOT a domain expert.
It seems to me like we are starting to get into "analysis". Admittedly very simple analysis, but analysis just the same... As soon as you start aggregating things with a non-identity (or not precisely defined) equality test then the test you use for equality is open to interpretation. More importantly, for someone to use the aggregation you have they will need to have a description of how the data was aggregated so they can decide if it makes sense for them to use the aggregation in comparisons.
I suppose I would argue that if we are talking about data sharing and in particular comparing two data sets, having an aggregation that can't be used across data sets isn't particularly useful from a AIRR/MiAIRR data sharing perspective. Certainly important from an analysis perspective, but...
UMI/consensus_count and exact sequence/duplicate_count (equality) seem to me to be well defined. I was hoping that we could define them exactly, but it seems like this is not the case. At the same time, it seems like the confusing thing is not so much that we can't come up with a well defined definition, but it is more that the definition would not be adequate for many different cases (the definition would be too limiting?).
Would it make sense to try to define these precisely (so there are a small number of well defined aggregation metrics), recognizing that if other aggregation metrics are required (other count_* fields) to capture other things there would be other mechanisms to define and record such counts? It seems like if we do define such counts, we also need a mechanism to describe how the aggregation was done...
I would argue that such aggregation metrics (the count_* fields) are definitely starting to go down the analysis path, and it seems to me that we should be separating the storing of the fundamental annotation data from the analysis artifacts that are created for that data.
I suppose what I am wondering is whether analysis results (including aggregations that are loosely defined) should be treated as metadata that is attached to the "basic" or "fundamental" annotation data that we currently have in our existing AIRR DataRep format???

It seems to me like we are starting to get into "analysis".

This isn't problematic to me. In my mind, "pre-processing" of the raw data is "analysis" because you have to make decisions about quality, and what to include/exclude with your filters. Though I do agree that leaving a field open for interpretation is best avoided.

definition would not be adequate for many different cases (the definition would be too limiting?)

Are these different cases listed anywhere? I cannot think of the top of head what they would be. We've done this before so it's reasonable that we don't try to represent everything.
Related to this is the issue that some experimental protocols aren't "quantitative" in the sense that any counts or quantities don't directly relate to the number of receptors/cells in the biology. They might be counting something else like the read coverage, or the number of RNA molecules for example. Comparisons with other data might produce incorrect results.

It seems to me like we are starting to get into "analysis".

This isn't problematic to me. In my mind, "pre-processing" of the raw data is "analysis" because you have to make decisions about quality, and what to include/exclude with your filters.

I think that is the issue I raise... We are already capturing analysis steps, and I think we are going to hit a brick wall soon because of the explosion of possible different analysis steps.
For the pre-processing you speak of (which we can consider analysis) we have an explicit, well defined process (quality control) and a metadata section that captures the parameters used for that process (e.g. the metadata we capture in SequencingRun and/or DataProcessing) to produce some data. We have been able to capture that because we think it is well defined enough to capture.
This is similar if you consider the processing that is done for annotation in that we have a metadata section that describes how that was done (e.g. in DataProcessing).
In this instance we are talking about collapsing sequences that have been annotated. My argument is that if we can define this precisely, then we can capture it in our current metadata. If duplicate_count is defined to be an exact sequence match, then we make it clear that that is what we mean by duplicate_count and we don't need to do any more and we can use duplicate_count as is.
If we are considering other types of processing/analysis (which we should be) such as collapsing sequence reads using non precise or fuzzy equality metrics or clone counts that produce other analysis artifacts (e.g. @javh count_clone or my new count_duplicate_fuzzy) then we need a metadata section that describes how the process (e.g. clone construction or fuzzy duplicate count) was performed and the parameters used for that process (e.g. number of NT that can differ in my fuzzy duplicate count match).
In the general case, we need a mechanism that links 1) an analysis step (an algorithm) with 2) a set of parameters used in the analysis step with 3) a set of analysis artifacts produced using a specific combination of 1) and 2). This is basically a mechanism to incrementally add analysis layers to a set of data, in principle adding more and more complexity to the analysis.
My understanding is that because the domain starts to get so rich and complex at this point (everyone has their own favorite tool or technique), a general, flexible, and extensible mechanism is required to capture all of the cases. It seems like now might be the time to consider a general solution, as it doesn't seem practical to keep extending well defined analysis parameters - because they aren't well defined any more.

definition would not be adequate for many different cases (the definition would be too limiting?)

Are these different cases listed anywhere? I cannot think of the top of head what they would be. We've done this before so it's reasonable that we don't try to represent everything.

The cases that I was talking about were what @javh mentioned:

I'm not sure exactly what to do about it, but we should maybe bring this topic up in the DR-WG? I'm starting to think we should maybe have count_* fields instead (count_duplicate, count_read, count_umi, count_clone). Not sure. It's very difficulty, maybe impractical, to support multiple different experimental protocols and analysis protocols with two fields.

There are many count_* fields that one could imagine,  @javh mentioned four here. I am suggesting that for any count_* field that isn't well defined (is algorithmic) for it to be useful you need to be able to describe how it was calculated so that users of the data know whether things are comparable or not. count_clone is probably the best example, because it probably has a wide variety of viewpoints on what it means.

Related to this is the issue that some experimental protocols aren't "quantitative" in the sense that any counts or quantities don't directly relate to the number of receptors/cells in the biology. They might be counting something else like the read coverage, or the number of RNA molecules for example. Comparisons with other data might produce incorrect results.

I think we are agreeing 8-) I am suggesting that in this more general analysis world we need to have a general mechanism for linking emerging "DataRep fields" (e.g. count_clone) with a general analysis description of how they were calculated (my clones are exact CDR3 matches) so that a researcher can decide whether it makes sense to compare clone counts across two different analyses. I think we want to do that without pre-defining the count_* fields (or all the other analysis fields that will arise). If a researcher can't compare two data sets because the clone counts are not comparable, then they either need access to the underlying data so that they can generate the "desired" count_clone that they can use for comparison or the won't be able  to use that data for their comparison.
As you suggest, what we definitely want to avoid is having someone compare count_clone fields between two data sets because they exist when the mechanism for determining count_clone in the two data sets was not comparable...

we need a metadata section that describes how the process (e.g. clone construction or fuzzy duplicate count) was performed and the parameters used for that process

Yes, but isn't this already taken care of by including software versions and parameters/command lines in the metadata? I think it's fine to expect users to lookup how ChangeO defines clones versus SONAR, instead of requiring that to be explicitly repeated into the metadata. In fact, as we get further down the pathway of "analysis," the metadata would explode if the details of every step had to be spelled out.
Certainly there are exceptions to this, like undocumented tools. But in that case, what are the odds that the person using that tools is going to back-fill the metadata, anyway? Maybe there needs to be a field for cases of manual curation, but I would expect those to be fairly rare.

Yes, but isn't this already taken care of by including software versions and parameters/command lines in the metadata?

I agree with this. This can be formalized more but I think there are diminishing returns for the usefulness of that metadata, and IMO this gets beyond the scope of DRWG.

As you suggest, what we definitely want to avoid is having someone compare count_clone fields between two data sets because they exist when the mechanism for determining count_clone in the two data sets was not comparable

Yes true but also no. From a scientific standpoint these comparisons are done all the time as part of data exploration, comparison of methods and so forth. If count_clone has the same definition but different calculation method for those two data sets, then I think it is quite reasonable to compare them. For example, people do this for v_call.
Regardless, I understand your point, if you want to show some sort of graph, which uses abundance numbers, is there any way to insure those numbers are comparable across studies? I think this can be done for quantitative experimental protocols with some well-defined fields. What I worry about are the non-quantitative protocols, which can still be used for comparison, but they might need to be normalized in a certain way to make that comparison valid or useful.
It seems to me that the fields duplicate_count, consensus_count and (maybe) clone_count can be given strict definitions, and I'm fine with renaming them as @javh suggests if that helps.

duplicate_count is exact sequence match (equality).

consensus_count or count_umi is number of reads (or sequences?) used to build a consensus sequence. While this might be interpreted as a "confidence level", I would suggest that another field might be better for that to support other forms of "confidence", like a probability value.

clone_count is the number of ... should it be the informatic "clonotype" or the biological "clone". Some experimental protocols do allow the biological clone number to be estimated. Maybe we should split this into two fields by adding count_clonotype field?

I was just chatting with @psathyrella and we might have another problem with the duplicate_count field. The naming is somewhat misleading in that it implies that it's the count of additional duplicate observations (copy number minus 1) rather than the copy number.
copy_count might be better semantics.

Interesting, it never occurred to me to interpret duplicate_count that way. I don't prefer copy_count though because that terminology is frequently used in genomic studies, e.g. the copy count of a gene, and this might lead to confusion down the road. How about some more literal names like number_of_exact_sequences, exact_sequence_count, total_equal_sequences, ... ?

That's a good point about copy_count.  Honestly, I think our stated intent to prioritize backwards compatibility probably means we shouldn't change the name of duplicate_count in favor of just having better documentation (including not reversing the names to count_*).

I agree, better not to change the field name at this point.

I wasn't actually confused because of the name -- it's somewhat ambiguous, but I think most choices also would be. I was confused because to me in the description:
Copy number or number of duplicate observations for the query sequence.
                For example, the number of UMIs sharing an identical sequence or the number
                of identical observations of this sequence absent UMIs.

"copy number" sounded like the total number of copies, i.e. including the "main" sequence, while "number of duplicate observations" sounded like it excluded it. I think there's other ways to read this description so it's not contradictory, but either way it seems easy to just make it super unambiguous.

@javh This has come up again as I've been processing single cell datasets. 10x is putting a read count in duplicate_count, which is confusing compared to other usages where it indicates a count of duplicate sequences. If the duplicate_count for 10x data gets used as an abundance then it gives confusing results.
For example, say I do genomic DNA bulk sequencing, with little to no amplification, the number of sequences is pretty close to the number of genomes. duplicate_count is then a measure of abundance. Am I incorrect in this usage? Is the 10x using the duplicate_count wrong? Are we both using it correctly but the semantics of duplicate_count is overloaded?

@schristley, I think 10x is using it correctly and the semantics of duplicate_count is overloaded.
They are using duplicate_count for the transcript UMI count and consensus_count for the raw read count for the contig assembly, which are consistent with how they are used for bulk protocols with UMIs. These map the the umis and reads columns in the cellranger contig annotations file, respectively.
In changeo, we've been using the custom field umi_count for the 10x UMI count to avoid the problem of ambiguous interpretation of duplicate_count.
If we had it to do over again, and maybe we should, something like this seems more compatible with the current menu of protocols:

read_count - Raw read count.
umi_count - UMI count
copy_count - number of duplicate observations.
clone_count - number of observations within a given clone_id.

The problem with the above is that fields have overlapping semantics for some protocols. umi_count and copy_count are confusingly similar for 5'RACE bulk sequencing; copy_count and clone_count are confusingly similar for gDNA TCR bulk sequencing. But, maybe that's better that's better than insufficiently descriptive for single-cell.

Can we keep copy_count as duplicate_count or do you think it's better to rename and deprecate to "enforce" the change? I'm still a little hesitant about copy_count as it has semantics with gene copy number in my head.

The problem with the above is that fields have overlapping semantics for some protocols. umi_count and copy_count are confusingly similar for 5'RACE bulk sequencing;

I know of some 5' RACE that doesn't use UMIs, even though they probably should...

copy_count and clone_count are confusingly similar for gDNA TCR bulk sequencing. But, maybe that's better than insufficiently descriptive for single-cell.

This might actually be ok as it could be a quick qualitative check about the clonal assignment process.

Can we keep copy_count as duplicate_count or do you think it's better to rename and deprecate to "enforce" the change? I'm still a little hesitant about copy_count as it has semantics with gene copy number in my head.

Yeah, we could probably skip read_count and copy_count in favor of preserving consensus_count and duplicate_count. But, they do seems to have confusing semantics. Eg, for data with just "raw" reads (no UMIs, no contig assembly). And duplicate_count has that issue of whether it means "total duplicates" or "total duplicates - 1".

Yeah, we could probably skip read_count and copy_count in favor of preserving consensus_count and duplicate_count. But, they do seem to have confusing semantics. Eg, for data with just "raw" reads (no UMIs, no contig assembly). And duplicate_count has that issue of whether it means "total duplicates" or "total duplicates - 1".

That's true, read_count sounds less ambiguous. For my code logic, I've been using duplicate_count as the replacement for 1 but I can see thinking about the word "duplicate" could create ambiguity. And partially I'm being selfish because I don't want to change all my codes ;-D
if row['duplicate_count'] is None:
    num = 1
else:
    num = row['duplicate_count']

Maybe it would help in the documentation to provide invariants?
count(post-processed RAW reads) == count(reads in RAW sequencing file) - count(pre-processed filtered reads)

sum(read_count in AIRR TSV) == count(post-processed RAW reads)

sum(duplicate_count for a sequence in AIRR TSV) == count(reads for a sequence in post-processed RAW reads)

@kira-neller can you have a look and comment on this - both from your recent 10X experiences as well as how we have curated data in the past.
Does @schristley's algorithm above work for what we do - in particular when we "unroll" based on duplicate count? I think it does...
@schristley what is read_count in your above calculations? There is no such AIRR field. Is that consensus_count?

@schristley what is read_count in your above calculations? There is no such AIRR field. Is that consensus_count?

Yes, potential rename of consensus_count to read_count

Yeah, we could probably skip read_count and copy_count in favor of preserving consensus_count and duplicate_count.

To clarify for those of us who are slow: so, just adding a new umi_count field?

The problem with the above is that fields have overlapping semantics for some protocols. umi_count and copy_count are confusingly similar for 5'RACE bulk sequencing

I would changed the Required status so that they are essentially mutually exclusive. Either you have UMI data and use umi_count, or you don't and you use duplicate_count.

copy_count and clone_count are confusingly similar for gDNA TCR bulk sequencing. But, maybe that's better than insufficiently descriptive for single-cell.

This might actually be ok as it could be a quick qualitative check about the clonal assignment process.

Yes, I think this is fine

And duplicate_count has that issue of whether it means "total duplicates" or "total duplicates - 1".

I have trouble getting worked up about this, let's just pick one and then make sure the documentation is clear.

Maybe it would help in the documentation to provide invariants?
count(post-processed RAW reads) == count(reads in RAW sequencing file) - count(pre-processed filtered reads)

sum(read_count in AIRR TSV) == count(post-processed RAW reads)

sum(duplicate_count for a sequence in AIRR TSV) == count(reads for a sequence in post-processed RAW reads)

Took me a couple tries to parse these. I think they're useful, but I would also advocate including something like @javh's demo above (https://github.com/airr-community/airr-standards/issues/161#issuecomment-433660899), because that seems like the easiest way of clarifying things, to me.

That's true, read_count sounds less ambiguous. For my code logic, I've been using duplicate_count as the replacement for 1 but I can see thinking about the word "duplicate" could create ambiguity. And partially I'm being selfish because I don't want to change all my codes ;-D

Well, I'm really averse to breaking backwards compatibility if we can avoid it for the sake of all people's codes. :)

To clarify for those of us who are slow: so, just adding a new umi_count field?

Just adding umi_count and clone_count.  We could conceivably add read_count and keep consensus_count, but constraint the meaning to consensus_count specifically to reads used for consensus/assembly.

Just adding umi_count and clone_count.

I thought we decided up-thread that clone_count belongs in Clone, not Rearrangement?

I thought we decided up-thread that clone_count belongs in Clone, not Rearrangement?

Makes sense to me. We could just put a note in the docs that you can copy clone_count up to Rearrangement if you want to.

@kira-neller can you have a look and comment on this - both from your recent 10X experiences as well as how we have curated data in the past.
Does @schristley's algorithm above work for what we do - in particular when we "unroll" based on duplicate count? I think it does...

@bcorrie per 10X documentation they define the two fields as:
duplicate_count | The number of unique molecular identifiers associated with this rearrangement.
consensus_count | The number of reads associated with this rearrangement.
For 10X data, each sequence in the AIRR.tsv is an assembled contig. Let's say we have a contig sequence Z built from reads A and B. As I understand it, if read A has 3 reads with the same UMI, they contribute +3 to consensus_count, but only +1 to duplicate_count. If read B has 5 reads with the same UMI (but different from UMI A), this adds + 1 to duplicate_count and + 5 to consensus_count. So for contig Z you end up with consensus_count = 3 + 5 = 8; duplicate_count = 1 + 1 = 2.
When we unroll, it is based on duplicate_count. Per the example above, our unrolled AIRR.tsv would have the annotation for contig Z present twice. I'm not completely sure if this agrees with @schristley's definition above; is the fact that the sequence in a 10X AIRR.tsv an assembled contig rather than a "raw post-processed read" an important distinction here?

We didn't really get into this one in the November call, but related discussion at: https://github.com/airr-community/airr-standards/issues/543#issuecomment-963526567
My personal sense, based on both the desire for parallelism to the Clone *_count fields and the discussion above is that we should:

add a umi_count field.
revise the documentation of duplicate_count to deprecate its use in favor or umi_count where possible. (duplicate_count would remain available for non-umi contexts.) Per @kira-neller's comment above, this would mean 10x would have to revise/update the output of cellranger.

I think consensus_count looks ok as is and clone_count should not (officially) be part of the Rearrangement schema.


Bug: Word Sprint includes all words in note at start of timer

When trying to write in a note that already has the words, Word Sprint will add the total of the notes words into the word count when starting the sprint instead of only the ones written for this sprint.
Example of error:

I'm also having this issue.

Same here. Any solutions?

Can probably have the plugin check for text already and add it for removing from total. Will have to look into what the API provides and maybe there's a better way of calculating number of words written during that time period

I am having the same problem. Really excited about the plugin otherwise.
Looking at the code in main.ts (line 349) it looks like the previous word count is being stored (or at least potentially stored) at the beginning of the sprint.
Is the bug that this if statement is failing?
SprintRun.ts (lines 140-141, 102-113, 218) seems to implement the needed functionality already.
@kinabalu Is it possible to check if the condition for the if statement that leads to main.ts (line 349) is evaluating to False?

Hi, Is there any update on this?
I really like the plugin, but would like to continue editing a single document for multiple sprints.

Is there any solution for this?

this has been fixed in 0.2.5


Bug 7877542: Simplify EntryNormalize for IsNormalizedString case to avoid LiteralString not allowed assert.

pThis is a propertyString. We can't use the buffer to create the same string if the propertyString's buffer is from a PropertyRecord, which would result in am interior pointer.
Since we are just returning the same string in this case, we should just return pThis.
Fixes Bug 7877542

@curtisman CR please?

@dotnet-bot test Ubuntu ubuntu_linux_debug please

LGTM


Add expected trace template for ruby rails app

Description:

In anticipation of add a sample app showcasing OpenTelemetry Ruby for AWS X-ray, we want to provide the templates we expect the traces a simple Ruby on Rails app would generate.
In our tests, we found that the standard /outgoing-http-call produces the correct default OTel Trace we expect, but the AWS SDK /aws-sdk-call does not. So, we add an option just for this ruby discrepancy and it's expected trace template as a .mustache file.
The trace for /aws-sdk-call is found here, it is only missing the [0].http.response.status=200, attribute.
{
    [0].name=aws-otel-manual-rails-sample,
    [0].id=8b6937b40eef8505,
    [0].start_time=1642644356.856313,
    [0].trace_id=1-61e8c384-fe837006488e7e62b8624d01,
    [0].end_time=1642644357.2015743,
    [0].subsegments[0].name=S3,
    [0].subsegments[0].id=feb9914f56
9361b6,
    [0].subsegments[0].start_time=1642644356.887765,
    [0].subsegments[0].end_time=1642644357.200523,
    [0].subsegments[0].namespace=aws,
    [0].subsegments[0].aws.xray.auto_instrum
entation=false,
    [0].subsegments[0].aws.xray.sdk_version=1.0.2,
    [0].subsegments[0].aws.xray.sdk=opentelemetry for ruby,
    [0].subsegments[0].aws.region=us-west-2,
    [0].subsegments[0].aws.operation=ListBuckets,
    [0].subsegments[0].metadata.default[\"rpc.service\"]=S3,
    [0].subsegments[0].metadata.default[\"rpc.system\"]=aws-api,
    [0].http.request.url=http://app:8080/aws-sdk-call,
    [0].http.request.method=GET,
    [0].http.request.user_agent=okhttp/4.9.0,
    [0].http.response.status=200,
    [0].http.response.content_length=0,
    [0].aws.xray.auto_instrumentation=false,
    [0].aws.xray.sdk_version=1.0.2,
    [0].aws.xray.sdk=opentelemetry for ruby,
    [0].metadata.default[\"otel.resource.process.command\"]=bin/rails,
    [0].metadata.default[\"otel.resource.telemetry.sdk.name\"]=opentelemetry,
    [0].metadata.default[\"otel.resource.process.pid\"]=7,
    [0].metadata.default[\"otel.resource.process.runtime.description\"]=ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux],
    [0].metadata.default[\"otel.resource.process.runtime.version\"]=2.7.5,
    [0].metadata.default[\"otel.resource.process.runtime.name\"]=ruby,
    [0].metadata.default[\"otel.resource.service.name\"]=aws-otel-manual-rails-sample,
    [0].metadata.default[\"otel.resource.telemetry.sdk.language\"]=ruby,
    [0].metadata.default[\"otel.resource.telemetry.sdk.version\"]=1.0.2,
    [1].name=S3,
    [1].id=18d5983800c4d704,
    [1].parent_id=feb9914f569361b6,
    [1].start_time=1642644356.887765,
    [1].origin=AWS::S3,
    [1].trace_id=1-61e8c384-fe837006488e7e62b8624d01,
    [1].end_time=1642644357.200523,
    [1].inferred=true,
    [1].aws.xray.auto_instrumentation=false,
    [1].aws.xray.sdk_version=1.0.2,
    [1].aws.xray.sdk=opentelemetry for ruby,
    [1].aws.region=us-west-2,
    [1].aws.operation=ListBuckets
}

We should create an issue on OpenTelemetry Ruby to fix this.
Link to tracking Issue: N/A
Testing: Passes locally, it will be tested in CI once we have the ADOT Ruby repo setup.
Documentation:
No documentation needed for this right now, since the trace is almost there. However we should aim for parity soon.

Can you add a test case in here?

Can we hold off until they fix the ruby trace to add a status code?

Can we hold off until they fix the ruby trace to add a status code?

We probably shouldn't because it's blocking our work to test everything else on the ADOT Ruby side which is pretty much ready to go. I added the issue we are tracking to fix it in the README above, but that would also have to wait for PR review, merge, and eventual release.
With this solution we're not making any long lasting changes that we won't be able to easily change later, so I think it should be good as a temporary solution?

Can you add a test case in here?

Our downstream apps in the aws-otel-<language> repos consistently test these files, but I can add one here too! 🙂 Could you point me to an example? The closest I see to tests in the validator is https://github.com/aws-observability/aws-otel-test-framework/blob/terraform/validator/src/test/java/com/amazon/aoc/validators/CWMetricValidatorTest.java but this seems to be testing the behavior of the Test Framework itself which makes sense. One way to test this would be to have a ruby app within this repo but that would probably be overkill.
Let me know what kind of test you have in mind? Otherwise I think we should leave the testing of specific validator templates to the language repos.

@NathanielRN A long time ago #227 was fixed to allow templates to be read from a file. We never refactored our repos, but maybe this is the time to put the template in the downstream repo instead of here, what do you think?

@anuraaga
Oh I didn't realize that! That's really good to know! Actually that would be super useful in the Lambda repos where we currently copy and paste our local template into one of the Test Framework templates 😅
I'll open an issue on the repo to do this.
In terms of adding it to every downstream repo, I definitely think that would have its pros! Having them all on this separate repo puts a large amount of distance between the actual sample app/language where we test and the "expected" template we want to test against. Having them next to each other might also be good for "documentation" nice-ity because the user can see exactly what kind of trace they will get if they follow the Sample App setup.
However, I liked having the templates in this centralized place because it reinforces the idea that they should all really eventually produce the default-otel-trace-validation.yml attributes at minimum, and that these extra files are just temporary while we move them to all be consistent. I guess I'm worried that putting them in the downstream repo will make it easier to forget that we need to make them all match?
I think the goal of consolidating is worth keeping them here until we have time to update all repos to have parity in the spans they produce because we hope to one day delete them.  Let me know if I understood you correctly? If I missed any benefit then happy to move this downstream! 😄

It looks like we currently essentially have per language templates in this repo (go, js, java, and default (python?)) but if it seems practical to consolidate as the instrumentation has stabilized over time (one problem last year was that almost every release required editing the validation template 😅 ), then keeping things centralized is good. I think we need to do a sweep to see if that's possible, and we wouldn't need to move the file to every downstream repo.
Separately, for Ruby if there is already churn that we know is coming, it's probably better to keep that in the downstream repo until it settles and then switch to the default template when that'll work.

but if it seems practical to consolidate as the instrumentation has stabilized over time

Lol OTel moves so fast that I feel like practicality is a luxury 😆 But yeah I agree with all you said! I think the biggest plus side is that our team and yours seem to agree that they want consistency among all the languages? But prioritizing the work is another issue so it probably won't be done soon 🙂

Separately, for Ruby if there is already churn that we know is coming, it's probably better to keep that in the downstream repo until it settles and then switch to the default template when that'll work.

Yeah that's fair, although I would say there's no church that is uncommon to the other languages (instrumentation being pre 1.0 for example).
I actually decided to proactively go ahead and make the change I want in Ruby which should give us the change we need in https://github.com/open-telemetry/opentelemetry-ruby/pull/1095! And the maintainers seem to make sense of my change so if that gets released sooner than later we won't need this PR at all 🙂
Will monitor it and keep this PR open. If it gets delayed for any reason then sure I can put it downstream. I guess all in all I should just close this PR if we want to err on the side of the instrumentations changing soon. Thanks for the discussion!


Merge applicable open PRs for APIM 4.2.0-alpha

Description
Need to merge all applicable open PRs in the required repositories for APIM 4.2.0 release
Sub Tasks :

[x] Analyse open PRs in apim-apps
[x] Inform each PR owner on open PRs in apim-apps
[x] Merge open PRs in apim-apps
[x] Analyse open PRs in carbon-apimgt
[x] Inform each PR owner on open PRs in carbon-apimgt
[x] Merge open PRs in carbon-apimgt
[x] Analyse open PRs in product-apim
[x] Inform each PR owner on open PRs in product-apim
[ ] Merge open PRs in product-apim

Affected Component
APIM
Version
No response
Related Issues
No response
Suggested Labels
No response

Update : All open PRs were analysed and the respective PR owners were informed. Some of the PRs in each repo are merged.

Update : 2 more open PRs to be merged in product-apim.

https://github.com/wso2/product-apim/pull/13053
https://github.com/wso2/product-apim/pull/13036

Closing as completed.


Use varargs for satisfiesAnyOf

Remove the previous grouped methods since the solution done in 3d5841fa110c029fc2104fd7425e02dd1ed19384 can be used here as well

Good catch @filiphr, it's integrated now.


improve error handling

Coverage decreased (-11.8%) to 70.0% when pulling 6f921f81a094389528182dd37f1d6a3142578db7 on improve-errors into f08f06b727c26ce5fa7562fa1235ef5d0b19c012 on master.

Coverage decreased (-11.8%) to 70.0% when pulling e4e31563f345ba269b4857c01766ae10cbb34df1 on improve-errors into f08f06b727c26ce5fa7562fa1235ef5d0b19c012 on master.

Coverage increased (+2.5%) to 84.286% when pulling 3e037bec42e48e10d3aecbe3a510714dbae82547 on improve-errors into f08f06b727c26ce5fa7562fa1235ef5d0b19c012 on master.


Crashing If I Load a Schematic On 1.9.4

If I load my schemetic  it is 1 sec frozen and then it crash inmeditly plz can someone help me? I'm in 1.9.4
Thanks

Could you provide the crash report please

crash-2016-06-28_11.44.42-client.txt

Have you tried without optifine ?
Seems to be a duplicate of #137

I'm going to try it..

OMG thank you so much.. It works !!

Cool, so you can close this issue :)

ye I was going to do that ;)


What is the intended use of HealthRecord.Entry.type?

What is the type field of a HealthRecord.Entry intended for? Is it intended to always match the name of the specific entry type that extends Entry? For example, would the type of an Encounter state be "Encounter"?

Entry.type seems to be used in contradictory ways throughout the HealthRecord. For example, the encounterClass is set as the encounter type during encounterStart:
https://github.com/synthetichealth/synthea/blob/master/src/main/java/org/mitre/synthea/engine/State.java#L490
In contrast, a MedicationOrder's primaryCode is set as the type during medicationStart:
https://github.com/synthetichealth/synthea/blob/master/src/main/java/org/mitre/synthea/engine/State.java#L778
Also in contrast, a Report's primaryCode is set at the type during a report, but the primaryCode appears to be arbitrarily chosen as the code of the first observation in that ObservationGroup, whatever that observation may be:
https://github.com/synthetichealth/synthea/blob/master/src/main/java/org/mitre/synthea/engine/State.java#L1207-L1208

I also see places where the type is used to lookup a specific state in present, for example to check for conditionActive in the HealthRecord:
https://github.com/synthetichealth/synthea/blob/master/src/main/java/org/mitre/synthea/world/concepts/HealthRecord.java#L400-L402
Is type then intended to be a unique identifier for a state within a module? Across all modules?

Agree - we need this to be more clearly defined and consistently used.


Lock payouts page when input is invalid

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] I have tested this PR in all supported browsers.
[ ] I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #2457

PR #2458

PR #2459   👈

This comment was auto-generated by Graphite.

Graphite Merge Job
Current status: ⏳ Queued to merge
This pull request is currently queued to be merged as part of a stack.
This comment was auto-generated by Graphite.

Job Reference: fWZhD9sJlygdLuziExGz


Help a weeaboo translate this anime bot :)

So, I love this project and most of the languages presented here are with inaccurate translations because I used "Google Translate", I'm not ashamed or anything like it, I did out of the purest intentions of making it more available; to do so, just check the locales folder.
English version is the most important, the current version was poorly translated from Portuguese.
If you can point out an error and fix it, or even make a new language available, this would help me out and a lot of the people out there who uses this bot, you can be one of them :)

I could fix some issues with Russian

@NogrTL, this would be awesome :)

I could clean up Spanish a bit.

@murrutiar, please :)

I edited 1/3 of the Russian language file, but English version sounds odd to sometimes
#4

@NogrTL this is probably because the English version was automatic translated also, I just glanced over it. But my skills in English are also pretty limited.

@NogrTL this is probably because the English version was automatic translated also, I just glanced over it. But my skills in English are also pretty limited.

Maybe using Grammarly will help. I guess you can send the whole file there and rewrite it based on recommendations.

@NogrTL I'm sharing this with my friend and in social media, if someone checks could fix this English related issues, it would be awesome. I will edit this issue description so anyone who knows Portuguese and English could provide a better translation :)

Undertook updating the Spanish file with some minor tone corrections.

I worked a bit on the german

I also worked through the english, please find an actual user of the bot to work out the english. That way you can easily improve the other languages as well :)

@npx thanks for your hard work :)

@Fazendaaa Are you still accepting translations? I recently found this and I can improve the Spanish one.

@imhenoch Yes :)


[Bug]  Custom search logic for computational column

What I did
I am attempting to create custom sorting and search logic for a column that is calculated on select
In the public function i add an operation:
$this->crud->operation('list', function () {
$this->crud->groupBy('email')
->select('', DB::raw('count() as lastLoginAttempt'));
});
And then attempt to create a column:
$this->crud->addColumn(['name' => 'lastLoginAttempt', 'type' => 'text', 'label' => 'Login count',
    'orderable' => true,
    'orderLogic' => function ($query, $column, $columnDirection) {
        return $query->orderBy('lastLoginAttempt', $columnDirection);
    },
    'searchLogic' => function ($query, $column, $searchTerm) {
        $query->orWhere('lastLoginAttempt', 'like', '%'.$searchTerm.'%');
    },
]);

What I expected to happen
I expect the column to now be sortable and searchable
What happened
The column is sortable and the orderLogic was able to recognize column 'lastLoginAttempt', but when adding the search logic it returns the error: "Column not found: 1054 Unknown column 'lastLoginAttempt' in 'where clause' at"
What I've already tried to fix it
Already posted ticket: [Bug] Custom search logic for computational column #3701, it was confirmed as fixed but after updating i still get the same error: "Column not found: 1054 Unknown column 'lastLoginAttempt' in 'where clause' at"
Backpack, Laravel, PHP, DB version
When I run php artisan backpack:version the output is:
PHP VERSION:
PHP 7.3.28 (cli) (built: Apr 27 2021 17:19:33) ( ZTS MSVC15 (Visual C++ 2017) x64 )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.28, Copyright (c) 1998-2018 Zend Technologies
LARAVEL VERSION:
v7.30.4@9dd38140dc2924daa1a020a3d7a45f9ceff03df3
BACKPACK VERSION:
4.1.45@c9918581306bc4a8d605b87b4757893baa03fcc1

Hello @LavinaHs
As far as I found in my research, SQL only allows the computed columns in orderBy clauses for the same condition, because of the order of evaluation. You need to make nested FROM table to make it work that way and that's not how Backpack applies the constrains in the query.
You can read more about it here: https://stackoverflow.com/questions/41693097/reuse-calculated-column-in-where-clause and https://docs.microsoft.com/en-us/sql/t-sql/queries/select-transact-sql?redirectedfrom=MSDN&view=sql-server-ver15#Anchor_2
I think you can make it work using laravel modifiers virtualAs or storedAs depending on your needs. https://laravel.com/docs/8.x/migrations#column-modifiers
Laravel also has a having method for similar situations. https://laravel.com/docs/8.x/queries#havingraw-orhavingraw
Let me know,
Pedro

Hello @LavinaHs sorry for such a late reply.
I hope by today you already found your answer or found another way of doing what you want.
I suggest you make your query work in SQL first and then migrate it into Laravel eloquent if possible, otherwise use raw sql.
Backpack has nothing to do with "nesting the select", that's an SQL thing, Backpack just gets the query you provide and execute it, so if you are running intro trouble I suggest you first make it work in raw SQL and just then port it to Laravel application.
I am going to close this for now, but please if you still having trouble let me know in the comments or re-open if needed! I will try to help you the best I can. Start by dumping the $query with: dd($query->toSql()) to get the query that backpack is about to execute.
Wish you the best,
Pedro


Remove section on id token validation for SPA app.

The section on validating id tokens is invalid and should be removed.
Implicit flow apps have no reason to validate id tokens. They should trust they're accurate.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: be0884d3-263f-9913-7b8c-170d8092baa2
Version Independent ID: 42c5b06a-81a7-97f7-a4cf-7ca77a30ec37
Content: Secure single-page applications using the Microsoft identity platform implicit flow
Content Source: articles/active-directory/develop/v2-oauth2-implicit-grant-flow.md
Service: active-directory
Sub-service: develop
GitHub Login: @rwike77
Microsoft Alias: ryanwi

Opening on myself to handle later.

@hpsin Thank you for acknowledging the same. We will keep this as a placeholder for now and will update further as you make changes to the system.

reassign:hpsin

#please-close
The fix for this went in last week


.project, .classpath currently not ignored

From @gaellalire on April 25, 2017 15:10
This commit seems to be the cause
https://github.com/dvcs/gitignore/commit/9a2b4b08832124dcd9d52b81e81cf1cf090a8160#diff-033fe2949017fb8e2dffb216a2bafeb7
It is intentional ?
Copied from original issue: joeblau/gitignore.io#345

From @gaellalire on April 25, 2017 15:31
I think you should never remove previously ignored files/directories.
You did it with iml on idea and it has generated problems. You fixed it via intellj+iml, maybe you will fix with eclipse+project but your users may become tired of following your new templates.
If some user wants to keep some IDE specific data just add a minus template like eclipse-project or eclipse+noproject ...
My 2 cents

Yes, this file is copied from which is the current source for most of the templates: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore
If those should be ignore, we can create a Eclipse.patch which will append the changes.  If you want, you can submit that to dvcs/gitignore or I can add it later tonight.
# Eclipse Core
.project

# JDT-specific (Eclipse Java Development Tools)
.classpath

That makes sense and I totally agree.
The peace that you might be missing is that gitignore.io doesn't control that file. dvcs/gitignore make a copy with a synchronize script of the github/gitignore (including that Eclipse template) everyday so if GitHub changes the file, it changes on dvcs/gitignore.  If you look at GitHub's repository, they are the owners of the Eclipse template and they have a documented the reason for removing those files in their patch: https://github.com/github/gitignore/commit/0674ff5b5c77935cbb2ea2269c001bfd84aa1aa5
If you feel strongly about this, you should probably comment there as well.
GitHub is still currently the source of truth for these files so sometimes they make changes that I don't know bout until people comment.  This is why I created the patch system because this isn't the first time GitHub has removed or excluded template features that people rely on.
If you have an idea of how to better manage the syncing, I'm all for it.


x/sys/unix: unix.Klogctl does not allow access to len arg

Linux sys_syslog looks like this:
int syslog(int type, char *buf, int len);

In Go's x/sys/unix, it's this
func Klogctl(typ int, buf []byte) (n int, err error)
// = syslog(typ, buf, len(buf))

That's kinda lame, because the len arg is not only used for the length, as you can see in the man page:
SYSLOG_ACTION_CONSOLE_LEVEL (8)
              The call sets console_loglevel to the value given in len,
              which must be an integer between 1 and 8 (inclusive).  The
              kernel silently enforces a minimum value of
              minimum_console_loglevel for len.  See the log level section
              for details.  The bufp argument is ignored.

So now you, either you gotta construct the unix.Syscall yourself or trick Klogctl into passing the right length:
unix.Klogctl(8, []byte{1, 2}) // Set console level 2!
// Yah ok this is silly

Perhaps there should be another function like this?
func Klogset(typ int, arg int) error
// = syslog(typ, nullptr, arg)

Also, unix is missing const declarations for the typ argument:
const (
         SYSLOG_ACTION_READ_ALL      = 3
         SYSLOG_ACTION_READ_CLEAR    = 4
         SYSLOG_ACTION_CLEAR         = 5
// etc
         SYSLOG_ACTION_CONSOLE_LEVEL = 8
)

Adding Klogset (and the missing const declarations) as suggested sounds good to me. Want to send a CL?

Hello! Is this up for grabs? I'd like to take it up, if that's OK.

Do it!