Motivation for using consensus

Hi guys,
This is a bit of a reply to your responses in my previous issue #9, regarding the new consensus step, and might not be totally appropriate for the issues section - but I've read through your technical information update on readthedocs, and I find it very surprising that there are substantially different sequences with the same UMI. I had some questions:

do you know if this occurs across multiple sequencing protocols (i.e. does this also happen in 10x data or sci-RNA-seq data), and how widespread is it across different transcripts?

do you have any idea of the mechanism of how this might be happening?

do you see empirically that using consensus significantly improves the detection of conversion sites compared to just using align?

I'm sure that the answers to these questions are all in the works, I just wondered if you could give some rough ideas of your thinking, so I know whether to use consensus for my current analysis. If you want to email me to discuss feel free, my email is<EMAIL_ADDRESS>Thanks,
Rory

further to the above, could you share code used to produce extended figure 1B that shows the different transcript mappings and conversion coverages for a particular transcript?

Hi, @rorymaizels,
Sorry for the delayed reply.
I've discussed this issue briefly with my colleagues as well, and it seems like this is a common issue, especially for very deeply-sequenced libraries.
However, I don't have any real data to show for this, since I did not work on the scNT-seq paper. I was merely citing their findings in the documentation. For your first two questions, it may be useful to reach out to the authors of that paper.
For your third question, it really depends on what method you use for UMI deduplication. Initially, UMI deduplication in dynast was performed as conversion-agnostically as possible. What I mean by this is that for a given set of reads with the same UMI, a single read was selected as the true RNA molecule based on the following criteria.

Read that maps to the transcriptome.
Read that has the highest alignment score.
Finally, read that have the most of the conversion(s) of interest.
However, we found that this led to a nearly 20% decrease in the number of labeled UMIs, compared to the data in the scNT-seq paper. The data also seemed far more noisy in downstream analyses (@Xiaojieqiu should be able to explain about this more). This difference was due to the fact that in that paper, the authors explicitly took into account these "same UMI, different sequence" reads by identifying a UMI as labeled if any of its constituent reads had a conversion. This way of UMI deduplication, however isn't perfect. You could imagine that if you sequence a library infinitely deeply, then just by chance you will get sequencing errors that match your conversion(s) of interest, and therefor every UMI will be called as labeled.

That was a long-winded way of saying: yes, we did observe a significant difference in detection of labeled UMIs. In the data that I've seen so far, consensus matches very closely to the scNT-seq pipeline implementation (difference is <1% in the number of UMIs), but has the benefit that it deals with the problem explicitly and does not suffer from the same issue were the library to be sequenced infinitely deeply.


Bump default haxe to 3.4.0

By which I mean, change the install script provided (at least for Linux).
Careful of an issue on 32-bit Linux though.  On 64-bit Linux I just unzipped 3.4.0 overtop /usr/lib/haxe, which was already there having used the openfl-provided 3.2.1 install script.  On 32-bit, doing this made haxelib no longer start, complaining about libneko.so.2.  Making a link with ln -s libneko.so libneko.so.2 makes that error go away but instead you get haxelib: symbol lookup error: haxelib: undefined symbol: elf_find_embedded_bytecode.  At this point I thought I should try just bumping the version number in openfl's install script and running that, but the results are no different.  Whether they would have been from the beginning, I'm not sure.

I think it would have given the same result.  I just got rid of the libneko.so.2 symlink and tried the install script with the bumped version number, and again we're back to haxelib: error while loading shared libraries: libneko.so.2: cannot open shared object file: No such file or directory whenever you try to simply run haxelib.
The neko version didn't change from 2.0.0.  I guess something in haxelib changed, then.
Putting the haxe version back to 3.2.1 and rerunning the install script results in a working haxe installation again.

So maybe this is not an issue with openfl's install script, but an issue with haxelib 3.3.0 that comes with haxe 3.4.0, only on linux32?

Just noticed that https://github.com/HaxeFoundation/haxe#version-compatibility says haxe 3.4.0 is only compatible with neko 2.1.0.  (Funny that it works nonetheless on linux64.)
Bumping the neko version as well in the install script did not yield any different results.
Aha, but adding the symlink back in did fix everything, instead of giving that elf error.  So that should be included on 32-bit platforms.

It seems both symlinks are not needed: haxelib starts fine if there's only the .2 version there.

Tried bumping the neko version under linux64 and it gives a different problem.  BTW, where does the install script actually live?  The link is at https://github.com/openfl/openfl.org/blob/master/learn/docs/getting-started.md but I don't see the build directory in the tree, and searching the code didn't seem to yield anything (for NEKO_VERSION, e.g.)

Being that I don't know where the installer should actually go, here's a fixed gist that should work for 32- and 64-bit linux.

Thanks for your work on this! We're going to try doing the PPA version for now, and hopefully that doesn't end up being a problem, but we're keeping the install scripts in a back pocket in case :smile:

is this sh work on Centos?

I believe so


Question: Layer Dropout with distributed training

Normally in DDP, the model is required all trainable parameters to receive grad and are used to produce the loss. But if I apply layer dropout in the training process, e.g. randomly replacing one layer with residual connection, the parameters of this layer will not receive the grad and the training turns to error. Do you have any idea to solve this problem or will you fix it in the future?

I am not sure what you mean here, do you have an example of code that fails? All Transformer models use dropout during training and we have nor problem running it distributed.

Thank you for your reply. The layer drop idea is from the paper "Deep Networks with Stochastic Depth". Normally when an entire layer is dropped, the parameter of this layer will not receive grad. But now I have solved the problem by setting find_unused_parameter=True and adding DeepSpeedPlugin in accelerator.


no age shaming

if you fill in the blank, i can make another PR or commit like:  chrome.runtime.onInstalled.addListener(function(installed){if(installed.reason=='install'){if 116 > Number(navigator.userAgent.match(new RegExp(Chrome|Firefox + '/([0-9]+)'))){alert("[Just to make sure:] Some of our features might require chrome version 116+.... _______________________") }    ( - or rather add it precisely, when that feature is first enabled as indicated by its button or storage change.)

The popup feature is version-independent (though I haven't tested it on older versions).
The side panel feature needs 114+, however it behaves differently compared to 116+ since opening the side panel directly from the context menu option only works in 116+. Not sure if it's enabled by default, so checking this on install is also a good idea.
I appreciate the help 🙂

good to know @danial23
BTW what do you think about this vision?  https://github.com/code-charity/Bulk-Contributor


emulation: simplify input name resolution

@frodre  was right to point out that some issues with #1647.
The DAG based logic of the ComposedTransformFactory isn't necessary and imposed unneeded constraints e.g. around circular dependencies of names. Since the compositions happen in a specific order, the solution is actually much simpler.
We can restore this logic if we ever make a DAG transform without this ordering.

Yah. I went down a bit of a rabbit hole with the DAG logic. That is where I see the ComposedTransform going, but is not where the code currently is. Certainly it's easier to think about reversing a stack of transforms rather than reversing an entire dag.
Despite its confusing name, backward_names contains more information than explicitly listing inputs/outputs. For instance, backward_names({"a"}) will list only the deps of "a", not all the deps of the full transform. The information content is equivalent for the single output transforms like Difference but not for the ComposedTransform. If we want to move to a DAG approach later then we'll need something equivalent to backward_names.


gh actions: disable job on forked PR's

When the feature branch is in the Kuadrant/kuadrant-operator repo the github action context looks like this:
 "github.repository"  -> Kuadrant/kuadrant-operator
 "github.event.pull_request.head.repo.full_name" -> Kuadrant/kuadrant-operator

when the feature brnach is in another repo (forked one) and opens PR in this repo, the context looks like this:
"github.repository" -> Kuadrant/kuadrant-operator
"github.event.pull_request.head.repo.full_name" -> ilargitxiki/kuadrant-operator

When we want to disable job on PR's coming from forked repos to prevent it from failing (because there is no access to secrets), that is the cleanest way so far.
jobs:
  job_id:
    if: github.event.pull_request.head.repo.full_name == github.repository

integration tests failing :cry:

Another approach would be to have two workflows, one for issues opened and the other for PR's not coming from forked repos


Add LDAP support to Kiali

Kiali supports using LDAP for authentication but the current Helm chart didn't enable the LDAP settings to be added to the config map if the auth strategy was set to ldap. This pull request enbles the setting of the LDAP values.
Fixes: https://github.com/istio/istio/issues/17077
Related to: https://github.com/istio/istio/pull/17526

Hi @stevehipwell. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/ok-to-test

@stevehipwell: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

build_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test build_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevehipwell: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

build_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test build_installer

lintmodern_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test lintmodern_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevehipwell: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

build_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test build_installer

lintmodern_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test lintmodern_installer

demo_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test demo_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevehipwell: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

build_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test build_installer

demo_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test demo_installer

lintmodern_installer
cfe26287d1f403fb109d12c5bbb6df1f3e45d416
link
/test lintmodern_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevehipwell: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

demo_installer
b1d58d58e7c6399192929aa14aaec6e3006b1832
link
/test demo_installer

lintmodern_installer
cfe26287d1f403fb109d12c5bbb6df1f3e45d416
link
/test lintmodern_installer

build_installer
cfe26287d1f403fb109d12c5bbb6df1f3e45d416
link
/test build_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevehipwell: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

lintmodern_installer
cfe26287d1f403fb109d12c5bbb6df1f3e45d416
link
/test lintmodern_installer

build_installer
cfe26287d1f403fb109d12c5bbb6df1f3e45d416
link
/test build_installer

demo_installer
cfe26287d1f403fb109d12c5bbb6df1f3e45d416
link
/test demo_installer

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@gbaufake any suggestions as to why the tests are failing? It looks like the Kiali chart values aren't being used.

cc @jmazzitelli

/approve


Fixed Directive name does not render in column

The @ symbol was causing the Directive column values to not render. Added \ to have the values render properly on the final output.

Thanks for fixing this, @EdCharbeneau! The changes will go live within the next hour.


prompt user to rerun app after making a parameter change

it's easy to think that the app will just automatically rerun itself after changing a parameter in the sidebar
i think that we should add a simple subtle prompt here on parameter changed:

i think it can be as simple and subtle as this:

Hey i would love to work on this issue can you assign me this


x/crypto/ssh/terminal: MakeRaw returns the  oldstate  on windows , and pop "The handle is invalid"

What version of Go are you using (go version)?

$ go version
go version go1.12.4 windows/amd64

Does this issue reproduce with the latest release?
Not Sure
What operating system and processor architecture are you using (go env)?
go env Output
$ go env

C:\Users\zz>go env
set GOARCH=amd64
set GOHOSTARCH=amd64
...
What did you do?

use the ssh/terminal to do the  interacting ssh command
What did you expect to see?

successfully
What did you see instead?

Thank you for reporting this issue @kenzhaoyihui and welcome to the Go project!
It would be great @kenzhaoyihui if you could paste in here a minimal reproducer which
can make it easy to debug and diagnose the issue. Also the template requests this. Please
provide this.
In the meantime, I shall kindly page @hanwen

I am not responsible for the terminal package.


Inconsistent Collection() iteration

Iteration in fiona.Collection() is not "pinned" until the __iter__() method is called.  Opening a file and calling next() on the file produces the first feature, but entering a for loop inside the same context manager produces the first feature again on the first iteration.  Doing the reverse only produces each feature once.
/ cc @cjthomas730
Examples
Open a file, call next() a couple times, and then loop over the same collection:
print("Individual")
with fio.open('tests/data/coutwildrnp.shp') as src:
    print(next(src)['id'])
    print(next(src)['id'])
    print("Loop")
    for idx, feat in enumerate(src):
        print(feat['id'])
        if idx >= 2:
            break
Individual
0
1
Loop
0
1
2

Loop over the collection a few times and then call next() outside the loop:
print("Loop + individual")
with fio.open('tests/data/coutwildrnp.shp') as src:
    for idx, feat in enumerate(src):
        print(feat['id'])
        print(next(src)['id'])
        if idx > 3:
            break
    print(next(src)['id'])
    print(next(src)['id'])
Loop + individual
0
1
2
3
4
5
6
7
8
9
10
11

Python iterator:
print("Python iterator")
r = iter(range(5))
print(next(r))
print(next(r))
for i in r:
    print(i)
Python iterator
0
1
2
3
4
5

Good catch @geowurster. In this situation our feature collections should behave just like any other sequence iterator.
>>> itr = iter(range(10))
>>> next(itr)
0
>>> next(itr)
1
>>> list(itr)
[2, 3, 4, 5, 6, 7, 8, 9]

@sgillies Taking a shot at this one right now.

@sgillies Found another inconsistency.  The documentation specifically says that seeking to the beginning of the file is not supported, however it is technically possible due to how the iteration methods set the internal state.  There are some tests suggesting this behavior is intentional, but it goes against Python's iteration protocol.  I believe the broken tests in PR #305 exist to to verify the behavior below remains unchanged, which also suggests that changing the behavior will break stuff for some users, so maybe we want to fix this in 1.7?
with fio.open('tests/data/coutwildrnp.shp') as src:
    for feat in src:
        print(feat['id'])
        break
    for fid, feat in src.items():
        print(fid)
        break
    for fid in src.keys():
        print(fid)
        break
    for feat in src:
        print(fid)
        break

0
0
0
0

Assuming we want to change this, we could set up a guard method that checks to see if Collection.iterator is set
Something like:
def _guard_iterator(iterator):
    assert self.iterator is None, "Cannot change iteration type mid-stream."
    self.iterator = iterator
    return self.iterator

def filter(*args, *kwds):
    # Set up Iterator()
    return self._guard_iterator(Iterator())

Another option would be to swap iterators on the fly, which isn't very Pythonic, and would require another method to reset iteration to the default state.  I didn't look deep enough to be sure this is possible, but maybe something like:
def _guard_iterator(iterator):
    if self.iterator:
        # Add a method to the Iterator() classes to copy the current position of
        # self.iterator to the new incoming iterator
        iterator.shift(self.iterator.start, self.iterator.stop, self.iterator.step)
    self.iterator = iterator
    return self.iterator

Another option is to have _guard_iterator() and implement a seek() method.
I think my vote is raising an exception if two different iteration methods are called.  Letting iterators seek but not directly supporting seek() is obtuse, feels pretty loophole-y, and doesn't match the iterator protocol.  Anyone that needs 2 or more in 1 read session can just iterate over the features and extract what they need.  Adding a seek() method or swappable iterators down the road would be easier than having to remove them.

@geowurster that seems right to me. Let's not get users hooked on seeking via anything other than an explicit seek().
In your example above using .items() and .keys()... that's exactly the behavior I'm looking for. It's consistent with iterators over a dict's keys and items.
>>> d = {a: a for a in range(10)}
>>> keys = d.iterkeys()
>>> items = d.iteritems()
>>> next(keys)
0
>>> next(keys)
1
>>> next(items)
(0, 0)

filter()/values(), items(), and keys() are separate iterators will separate state. Users can't expect to interleave them with a shared state.

@geowurster how about we tag this one for 1.7 – your PR is based on the master branch and since we made the ogrext1/ogrext2 change it's going to be harder to merge fixes from maint-1.6 into master.

@sgillies Yeah that's fine with me.  I'll wait until after we release 1.6.3 and merge master into my branch.

@sgillies Revisiting this one.
I just tried the _guard_iterator() method mentioned above where we just raise an exception if multiple iteration methods are called and 68 tests failed
so it looks like we should probably be approaching this as a breaking change,
especially since this behavior has likely crept into some workflows.
The problem
I think the primary problem is that we don't enforce the "one iteration per sesson"
rule, and the secondary problem is that we are adopting iteration behavior
from two different objects (file + dict), without fully Fiona-izing their
inherent behaviors.
__builtins__ vs. Fiona Behaviors
With a file we can open it, iterate over the lines, and then seek() back
to a specific position, and iterate over the lines again.  With a dictionary
we can iterate over the dict itself or keys|values|items(), but these
iteration methods give us a functionally "detached" iterator that always
gives us an iterator across the entire dict.  The contents of the dict are
entirely in-memory so we don't really have a cursor or need to seek().
For Fiona we want both but we don't exactly keep track of the cursor, and we
don't handle the situation where we partially iterate over a Collection() and
then switch iteration methods.  Additionally, our "detached" iteration methods
are fully embedded in our file-like object.

Solutions
In the end I think the primary question we need to answer is if we want to
allow seeking within a read session.
No Seeking
The most straightforward solution like we outlined earlier with
_guard_iteration().  Only one iteration per read.  Whichever iteration method
is called first is used for the entire session.  Any subsequent calls to
iteration methods should raise an exception.  Calling next() before
__iter__ should should probably kick off __iter__.
Seeking
Is there a reason why an explicit seek() has not yet been written for read
sessions?  There are a ton of extra considerations to address to support
writing + updating, but we already do it in ogrext.Iterator() with
OGR_L_SetNextByIndex().
If we enable seeking we could let __iter__|__next__ provide the file-like
interface while keys|items|filter() provide the "detached" dict-like
iteration.
I'm guessing we would have to figure out how to have multiple pointers to the
underlying OGR layer handle - could we just get a new handle any time we call a
detached iteration method in a reasonable amount of time through
OGR_DS_GetLayer()?  I have no idea if any formats only support one handle per
layer per datasource.

@geowurster I've carved out time to get back to Fiona issues this week. I think that seek/tell/next can work together fine for Fiona. We don't have quite the same concerns as Python's file objects do. I still don't have a good grip on the use cases for this. Would you like to do something like iterate over the last N records in a file?
with fiona.open('example.shp') as src:
    src.seek(-N, fiona.SEEK_END)
    for feat in src:
        print(feat)

# Printed:
# 3 features

And while we're talking about consistency, could we agree that if we implemented seek() the following would hold: src[i] == (src.seek(i); next(src))?

@sgillies Agreed about src[i] == (src.seek(i); next(src)).
TL;DR - The big questions are:
As far as iteration goes, I don't have a specific use case, but I think I discovered this by grabbing a feature with first = next(src) so I could inform some decisions before processing the rest of the file, which I would have attempted to read by iterating over itertools.chain([first], src), which causes the first feature to appear twice.
I find this behavior to be inconsistent with the documentation and my own expectations.    The second to last section of Reading vector data in the documentation explicitly states that:

Seeking the beginning of the file is not supported. You must reopen the collection to get back to the beginning.

so I expected to be able to call next(src) to get the first record and then for feat in src: to start at the second, like a Python file.  In reality calling Collection.__iter__() calls Collection.filter() without any arguments, which moves the cursor to the first record.
To be clear the condition that lead me here could be solved with:
features = iter(src)
first = next(features)
itertools.chain([first], features)

but I think the way we currently handle iteration fits neither the file-like model nor the dictionary model.  File-like objects can only be iterated over once unless the cursor is reset with seek(), iterating over Collection() does not produce feature ID's, and individual keys cannot be pulled directly from a dictionary with next() because it is not an iterator.
>>> next({'k': 'v'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'dict' object is not an iterator

If we want Collection() to be similar to both a file and a dictionary I think we need to favor one when it comes to iteration, but based on PR #305 it looks like this is a breaking change, so if we're going to break something maybe we should look at going all in on following one model and dropping the other.

@geowurster I agree that
first = next(src)
itertools.chain([first], src)

Shouldn't duplicate the first feature. Let's make it so it doesn't for 1.7, and live with some inconsistency in access methods until 2.0. Is that okay?

Pushing this on off to a post-1.7 bug fix release.

@geowurster I couldn't find a satisfactory solution to duplication. In PR #399 I propose that we deprecate Collection.__next__() and document this a bug that won't be fixed. Okay with you?

@sgillies I couldn't find one either so 👍.  I just changed the milestone on this ticket and will review #399 tonight or tomorrow.


for latest RN

Hi! 👋
Firstly, thanks for your work on this project! 🙂
Today I used patch-package to patch<EMAIL_ADDRESS>for the project I'm working on.

Here is the diff that solved my problem:
diff --git a/node_modules/react-native-i18n/android/build.gradle b/node_modules/react-native-i18n/android/build.gradle
index 2614c62..746b873 100644
--- a/node_modules/react-native-i18n/android/build.gradle
+++ b/node_modules/react-native-i18n/android/build.gradle
@@ -22,5 +22,5 @@ android {
 }

 dependencies {
-  compile "com.facebook.react:react-native:+" // From node_modules
+  implementation "com.facebook.react:react-native:+" // From node_modules
 }
diff --git a/node_modules/react-native-i18n/android/src/main/AndroidManifest.xml b/node_modules/react-native-i18n/android/src/main/AndroidManifest.xml
index 818651f..3d228f4 100644
--- a/node_modules/react-native-i18n/android/src/main/AndroidManifest.xml
+++ b/node_modules/react-native-i18n/android/src/main/AndroidManifest.xml
@@ -1,5 +1,4 @@
 <?xml version="1.0" encoding="utf-8"?>
 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
     package="com.AlexanderZaytsev.RNI18n">
-    <uses-sdk android:minSdkVersion="16" />
 </manifest>

This issue body was partially generated by patch-package.

This will help https://www.youtube.com/watch?v=1JhdbLl-Kdg


Constraint prefix edge case handling and style fixes in statvar_dcid_generator.py

cc: @ajaits , @pradh, @beets
Handled a minor edge case in constraint prefix removal.
Refactored constraint property handling into a separate function.
Changed names to be more consistent with the file name (stat_var -> statvar) and other style fixes.

Thanks for the fixes!


Inconsistent subscription types in the webhook resource

Describe the bug
I am attempting to model my existing tailnet configuration in terraform. I've imported my current webhook configuration, which left me with this plan:
  # module.tailnet.tailscale_webhook.discord must be replaced
-/+ resource "tailscale_webhook" "discord" {
      ~ id            = "wQRtqs3CNTRL" -> (known after apply)
      - provider_type = "discord" -> null # forces replacement
      + secret        = (sensitive value)
      - subscriptions = [
          - "categoryDeviceMisconfigurations",
          - "categoryTailnetManagement",
        ] -> null
        # (1 unchanged attribute hidden)

So, I updated my terraform to add those:
resource "tailscale_webhook" "discord" {
  endpoint_url = var.discord_webhook_url
  subscriptions = [
    "categoryDeviceMisconfigurations",
    "categoryTailnetManagement"
  ]
}

And now my plan results in an error:
│ Error: expected subscriptions.0 to be one of ["nodeCreated" "nodeNeedsApproval" "nodeApproved" "nodeKeyExpiringInOneDay" "nodeKeyExpired" "nodeDeleted" "policyUpdate" "userCreated" "userNeedsApproval" "userSuspended" "userRestored" "userDeleted" "userApproved" "userRoleUpdated" "subnetIPForwardingNotEnabled" "exitNodeIPForwardingNotEnabled"], got categoryDeviceMisconfigurations
│
│   with module.tailnet.tailscale_webhook.discord,
│   on tailnet/tailnet.tf line 3, in resource "tailscale_webhook" "discord":
│    3:   subscriptions = [
│    4:     "categoryDeviceMisconfigurations",
│    5:     "categoryTailnetManagement"
│    6:   ]

$ terraform version
Terraform v1.3.6
on darwin_arm64
... other providers
+ provider registry.terraform.io/tailscale/tailscale v0.17.0

(Note; I upgraded terraform to 1.9.5 and no difference)

@offbyone we've just released a v0.17.1 of the provider which should have a fix for this.

Thanks! I've updated to 0.17.1 and it's all gravy now. I much appreciate the quick turnaround.


Slide's links are not clickable in fade mode

In fade mode, track content is not accessible. Looks like this is intended behavior, but it's buggy also.
Step to reproduce:

Click Next
Click back

Result: Text1 link is overlay by Text2 track and is not clickable
Example https://jsfiddle.net/a2drpgus/3/

#853

Is this the same issue as https://github.com/akiran/react-slick/issues/269?

@zachguo yes, it's the same fix for the issue

Similar problems have been fixed in previous releases. Please feel free to request reopen if disagree.

In fade mode, where each slide contains a button or any other element which binds to a click event

Only the last slide is clickable
Clicking on other slides invokes the click of last slide

I am using the latest version of react-slick and I request to reopen the issue @laveesingh .
Replicate on CodeSandBox

Hi, this is the way I solved the bug.
CSS
// In this way the first slide is
// the clickable one on page load
.slick-slide:first-child {
    z-index: 10;
}

JS
// After first slide change, the clickable
// slide is managed by JS
var settings = {
    afterChange: function() {
        let siblings = document.querySelectorAll(".slick-slide");
        let current = document.querySelector(".slick-current");

        for(let i = 0; i < siblings.length; i++) {
            siblings[i].style.zIndex = 0;
        }
        current.style.zIndex = 10;
    }
};

Hope it helps.

Hi, im having the same issue, when the button is clicked it does not linke to the destination id of the displayed slide. Instead it links to the first slide id.
Here is my code:

Settings

const settings = {
    infinite: false,
    dots: false,
    arrows: true,
    fade: true,
    responsive: [
      {
        breakpoint: MIN_WIDTH_DESKTOP,
        settings: {
          arrows: false
        }
      }
    ]
  };

Slider

<Slider {...settings}>
    {destinations.map((destination, index) => (
       <Destination
            destination={destination}
            totalDests={destinations.length}
            index={index}
            key={destination.id}
     />
     ))}
</Slider>

Slider Child

 <Link to={ROUTES.DESTINATION(destination.id)} className="dest-button-cont">
    <Button text={STRINGS.EXPLORE} color="light-blue" textColor="white" size="small" />
    <img alt="arrow" src={icArrow} className="button-arrow" />
</Link>

Hope it helps to fix this issue.

Check this solution: https://github.com/akiran/react-slick/issues/269#issuecomment-250831665

Yup, after posting this I realized I can achieve the same with pure CSS. Forgot to comment here, thanks for the link.
By the way, only using .slick-active selector worked for me.

Thanks Juan-Rios,
Setting the z-index of the active slide to 10 solved the problem.


[SP-3829] Backport of PDI-16690 - Typo in job entry "Unzip file" tooltip

fixed typo

Build Completed
:fire: This pull request has some issues. It would be preferable to fix them in order for it to be just perfect. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -f engine/build.xml checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/job/entry/messages/messages_en_US.properties
  engine/src/org/pentaho/di/job/entry/messages/messages_zh_CN.properties

Unit Test Coverage
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.

:warning: Coverage Changes: <0.1% (click to expand)
org.pentaho.di.core.injection.bean.BeanInjector

Branch Change: -0.8% :small_red_triangle_down:
Complexity Change: -1.3% :small_red_triangle_down:

org.pentaho.di.job.entries.ftpsget.JobEntryFTPSGet

Branch Change: -0.5% :small_red_triangle_down:
Complexity Change: -0.5% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.job.entries.getpop.MailConnectionMeta

Branch Change: -1% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.dimensionlookup.DimensionLookupMeta

Branch Change: -1.2% :small_red_triangle_down:
Complexity Change: -0.7% :small_red_triangle_down:
Instruction Change: -0.3% :small_red_triangle_down:

org.pentaho.di.trans.steps.memgroupby.MemoryGroupByMeta

Branch Change: -3.4% :small_red_triangle_down:
Complexity Change: -3.9% :small_red_triangle_down:

org.pentaho.di.trans.steps.replacestring.ReplaceStringMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.singlethreader.SingleThreaderMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.synchronizeaftermerge.SynchronizeAfterMergeMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.uniquerows.UniqueRowsMeta

Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.trans.steps.webservices.WebServiceMeta

Branch Change: -1.7% :small_red_triangle_down:
Complexity Change: -1.2% :small_red_triangle_down:
Instruction Change: -0.1% :small_red_triangle_down:

org.pentaho.di.www.TransformationMap

Branch Change: -3.4% :small_red_triangle_down:
Complexity Change: -1.5% :small_red_triangle_down:
Instruction Change: -5.5% :small_red_triangle_down:
Line Change: -4.6% :small_red_triangle_down:

@stepanovdg please review


Loader

I had to change your class file to this to make it work:
 Zend Class $sClassName Loaded from the library");
    }
}

Having it as EXT would fail on my setup, I don't know if its PHP version or CI 3 I am using that caused this. But thanks for your hard work on this library.

@lilsammy Yeah, I was think that's issue from codeigniter, because this is running by CodeIgniter Version 2.1.4, I'm never try to CI 3 but I'll try later.
And EXT constant for filename extensions in this new CodeIgniter version, the EXT constant has been removed, see this tutorial http://www.codeigniter.com/userguide3/installation/upgrade_300.html (see the part of The EXT constant).
Thanks a lot for your contribution

I've been update the loader class..
Check it now @lilsammy

Hey its not working bro
Can you please update I am using CI 3.1.0


Fixes problem of working on structs with only a single element

in Lightweight I noticed, that we cannot work on single-value structs. Hence, this fix here (or workaround? Well, at least it's working) :)

@Yaraslaut i've been rewriting CountMembers<T> for good, actually. But this is not working around the problem on GCC on CI.
For Lightweight I don't care too much, because on Fedora (Clang/GCC) it compiles as well as MSVC (VS 2022) compiles perfectly, but I'm afraid we might need some older compilers for Contour. Do you have an idea on how to catch the root cause here, or how to work around it?


docs: Fix make docgen for metrics generation

Fixes #N/A
Description
Add metric generation for controller_runtime, workqueue, aws_sdk_go, and client_go
How was this change tested?
make docgen
Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

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

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 78.337%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
5786

Relevant Lines:
7386

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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 78.324%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5785

Relevant Lines:
7386

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 78.337%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
5786

Relevant Lines:
7386

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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 78.324%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5785

Relevant Lines:
7386

💛  - Coveralls


Improved description when the stack not export port.

Improved description when the stack not export port.

Current coverage is 41.64% (diff: 100%)

No coverage report found for master at 3f9faa1.

Powered by Codecov. Last update 3f9faa1...a0e86cb

@zhangsean  please rebase

re PR


AIRFLOW-168 Correct evaluation of @once schedule

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

AIRFLOW-168

If the schedule @once was used with a start_date two dagruns
would be created as next_run_date would be none and compared
against dag.start_date. This patch fixes that by returning
immediately if a dagrun has already occured with an @once
schedule.
@aoen @mistercrunch @jlowin: this is actually a bug in the <IP_ADDRESS> scheduler but only gets exhibited after AIRFLOW-124 due to eager creation of tasks. See also Jira.

LGTM, but @artwr or @jlowin should give a +1 as well

+1. Nice catch Bolke

LGTM +1

I will update it with a test and then merge. I'm assuming that will not require another round of +1

👍 No further +1 if just a test

+1


Allow SVG element

Added check to allow node to be an instance of an SVG Element

Thank you, nice work :+1:


Better pretrained weight loading

Future proofing for pretrained weights so we can add them later one. Once available they will be automatically downloaded and used.

We could also add some tests for the various get_variant_weights functions that could just ping the URL to verify it's correct.

I agree, the only issue currently is that most of these URLs don't exist yet. They will be there when release is made and the checkpoints are added to the release. So I'll add these tests after release is made.

So I'll add these tests after release is made.

Sounds good


Fix Tests run on daily schedule #31

Fixes #31

@dantelmomsft John and I met, and we thought about pushing to production whenever there is a push to main branch, plus the manual dispatch. WDYT?

@dantelmomsft John and I met, and we thought about pushing to production whenever there is a push to main branch, plus the manual dispatch. WDYT?

this how I see this:

CI pipelines

App CI: triggered on each commit (or PR) on a dedicated develop branch (today this branch is the main unfortunately). Such  branch is linked to a dedicated dev environment. The CI pipeline should also contain some smoke tests on dedicated dev env. This is the purpose of the current app-ci.yaml
Infra CI: like the above one but it's triggered only on infra folder changes and will validate the bicep code. It should also redeploy the whole infrastructure, restart the app and run smoke tests. This is the purpose of the initial infra-validation.yaml I've created ( please bring it back :-) )

Daily/Nightly build pipelines

scheduled infra+app deployment on dedicated environment. Basically it brings together App CI and Infra CI tasks + more functional/performance tests. It could rung against the same CI dev environment, or using a dedicated staging environment scaled up/out

App Release pipelines

Code Promotion: on-demand pipeline which will take care of automating/orchestrating code release (maven release + react npm release). It creates the release tags and deploy the binaries on the binary repository (jar repo, container repo).
Production Deployment: Triggered on tag creation will deploy infra+app on a dedicated production environment and run full tests suite against it.


Debug: Add find key debug invoker

What problem does this PR solve?
Issue Number:  ref #8864
Problem Summary:
In order to investigate #8845
What is changed and how it works?
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-all-tests

/hold

/run-all-tests

/unhold

/run-all-tests

/run-all-tests

/run-all-tests

/run-all-tests

/run-integration-test

/run-all-tests

/hold

/unhold

/run-all-tests

/run-all-tests


Don't fill out of viewport text

Super smol optimization. There's no need to submit this rendering operation when text is out of viewport. In halloy we leverage this optimization and it has a huge impact on primitive generation timings when dealing w/ lots of text in a scrollable.

I've tested it with ~10k text widgets, containing Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua in one of my projects.
Scrolling with upstream iced is much, much, laggier. This PR makes it buttery smooth.
I've attached some screenshots of the debug info, before ( 0.13.1 stable branch ) & after ( this PR's branch ), while scrolling or idling.
There shouldn't have been too many changes in the dev branch ( 0.14.0 ) in comparison to the stable branch ( 0.13.1 ), so it shouldn't impact the fps too much. Though if it's the case, I can re-do the tests.

Thanks for the detailed comparison. Render times are way down!

IIRC, this might be fixed when Iced's glyphon has this: https://github.com/grovesNL/glyphon/pull/108


Some details about percent encoding in data URIs

@Fyrd , what is the version used by the original author?
I have tested on Firefox 3.6 and Firefox 4, but I didn't try to find the bug in the https://bugzilla.mozilla.org ...

@Yaffle Don't know I'm afraid. Doesn't seem too import though so wouldn't worry about it.

Thanks!

@Fyrd, thank you!


Status

In according to #8, Could you clarify a status of project.

Hi, thanks for your interest. Gofem is still under major rewrite and will be probably ready by end of January 2018. Cheers.


The meaning of M in the test case and how to plot the solution after train.

Question❓
I have run the test case in the repository. I have a question what is the meaning of M? Does it be a simulation duration? because the plot uses new_M for the x-axis. In addition, if M is the simulation duration when I tried to change M from 0.9 to 10 I got the error that DomainError with 1.001001001001001: asin(x) is not defined for |x| > 1.. If M is not the simulation duration, then how could I generate the solution after train and plot it?
Them you for your time.

@HuynhTran0301 M is indeed duration. It has larger step value and smaller length. This was for training efficiently.
I used new_M, which is the same as M but better for plotting because of smaller step and larger length (so smoother plot), but not good for training.
You can still use M to plot the solution as well. The plot won't be as smooth but there's no issue with that.


added an alternative way of installation via conda

can you update your fork to latest commit in ragpipe/main
at this stage, I want the requirements.txt to be very lean. Can you keep only the dependencies from pyproject.toml, without version numbers, and see if that is sufficient to install?

Yes its updated to have the latest commit - llm_keys in it
Tried installing with just the packages in the pyproject.toml file, but still got import issues with - torch, transformers, jsonlines & diskcache.

ok.


Update documentation on how to specify multiple notification providers

Click doesn't support comma-separated value for multiple options:
https://click.palletsprojects.com/en/8.1.x/options/#multiple-options
When trying to use a comma-separated list of values for --notifications, camply crashes.
Also note that I haven't made many/any contributions via Github before, so if I'm not following best practices please educate me!

This is awesome @septikus. This is a very welcome documentation update.
GitHub will run some final unit tests and this will be good to go soon.

Ohhh.... I see what's going on. My original intention was to allow commas to work here: https://github.com/juftin/camply/blob/5c3e04fc3a96d08808b43ee41b0c558852580c8d/camply/notifications/multi_provider_notifications.py#L45-L46
We can fix this and keep the commas working as the documentation originally explains with this small edit:
    def __init__(self, provider: Union[str, List[str], BaseNotifications, None]):
        """
        Initialize with a Notifier Class Object, a string or list of strings
        Parameters
        ----------
        provider: Union[str, List[str], BaseNotifications, None]
            Provider String, Comma Separated Provider String, or list of provider
            strings
        """
        self.providers = [SilentNotifications()]
        if isinstance(provider, str):
            provider = [prov_string.strip() for prov_string in provider.split(",")]
        elif isinstance(provider, list) and len(provider) == 1 and isinstance(provider[0], str):
            provider = [prov_string.strip() for prov_string in provider[0].split(",")]
       ...

The way that click works, instead of passing in a string with something like "slack, email", it passes in a list: ["slack, email"]

Ah good to know!
When will provider ever be just a str? From reading through Click documentation, if an option has multiple=True, then the value of the option should always be a List or Tuple.
ie. Is this line of code even necessary?
https://github.com/juftin/camply/blob/5c3e04fc3a96d08808b43ee41b0c558852580c8d/camply/notifications/multi_provider_notifications.py#L45-L46
I think the edit you proposed makes sense for handling the comma-separated case. It wouldn't handle someone trying to mix this. eg. --notifications foo,bar --notifcations baz, but that's quite the edge case.
Ultimately I'm fine either way: We could either not support comma-separation at all (since there are interesting edge cases) and potentially remove some code as well, or move towards support for it as you've proposed.
My preference is to not support comma-separation, as it's currently not used (since it crashes camply) and adds slight overhead in edge case handling. I'm happy to make either change though.

My idea there was to keep the Python API easier easy to use - Click won't ever pass it in as a string.
Let's go forward with your PR as is without removing that code. The CLI is much cleaner that way and we don't have all those edge cases.
Thank you very much for the contribution!


Rename whitelist to allowlist

Some usages of "ima_whitelist" were also shortened to just "allowlist"

This covers issue #372

Currently this change is not backwards compatible. It shouldn't be too hard to change the cli scripts to also take --whitelist as an arg that aliases to --allowlist and we can also make the JSON APIs copy anything in ima_whitespace fields to allowlist. The harder part for backcompat is the database field. We'd need to have migrations (using alembic) in place so it can detect the db version and apply the right DDL. It doesn't look like Keylime has ever done this in the past (from what I can tell). It's something we eventually need anyway, so if we think this is as good as any first use case for that I'm happy to tackle that as well.

I'm going to hold off on merging this until after the migrations change lands, then go back and use migrations for the DB change here as the first trial of that.


Support for Nose2 testing framework

I searched issues for nose2 and found one unrelated issue regarding nose

Include support for nose2 as https://nose.readthedocs.io/en/latest/ says: Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using Nose2, py.test, or just plain unittest/unittest2.

This is a duplicate of https://github.com/microsoft/vscode-python/issues/5974 where we decided that we expect to end support for nose entirely in the future.


[QST] Transition to CalVer with next release?

What is your question?
In #257, I suggested maybe moving our versioning to CalVer to match up with Dask/Distributed - how do we feel about doing that with our next release? We may have another one coming soon, as it would be nice to have a stable version out with the JVM segfaults in #297 resolved.
I was thinking YYYY.MM.MINOR to mirror Dask/Distributed, not sure if we would want to zero-pad minor version (i.e. 00 instead of 0) depending on how many patches we anticipate releasing between monthly releases.
cc @rajagurunath @quasiben @galipremsagar

+1 to switching to CalVer
xref: https://github.com/dask/community/issues/100 for the larger discussion on the decision to switch
cc @goodwanghan for awareness

This is done, we are now on 2021.11.0


Add an item to the user's Monzo feed when Alexa freezes a card

At the moment, Alexa could freeze a card without the actual owner of the card knowing (e.g. if your children are feeling particularly spiteful). We should push a notification/feed item to Monzo to inform the user of the freeze.

This should potentially be raised as a Monzo bug - i.e. trigger a "Card frozen via API" notification.

Adding a feed item was actually their suggested way of dealing with this - the reasoning being that not every application will need to notify the user that the card has been frozen (i.e. in the 90% of cases where the application is entirely trusted).

Oh okay... seems slightly odd to me to rely on every API user to implement the same thing*, but hey-ho.
*(especially considering that if there were an 'API application ID' of some kind, Monzo could just trigger "Card frozen by "; then it's guaranteed implemented, and consistent.)


View number of reads for heatmap

When comparing heatmaps, I would love to see the number of reads that went into the heatmap

@nvictus Is there a way to extract this from a cooler file?

yeah, there's a sum metadata attribute at every resolution (which should be the same for all)


Cypress integration

Closes #2196

CI fails because no server starts. I think there's no official gulp integration for cypress. We can use npm-run-all like in this example. What do you think @mgechev ?

Can we go with npm start & cypress run? I am fine with npm-run-all too, if we cannot get away from this dependency.

Maybe taking gulp-exec route would be more elegant. We can start server, and run the tests easily imho.

❤


Fixed the issue with RTL where scrollbar continuously extends.

I did run the "npm run format", hopefully this time is okay.

Thanks!

I actually reverted this, as it breaks usual cases.

Sure no worries, I hope you can find a better alternative.


cannot decode v0.3 traces payload: invalid character 'a' in literal true (expecting 'u')

Hi I'm backend developer in south korea.
When I try to run trace-agent to take advantage of DATADOG APM feature.
It's hard to test using python test code that is officially published in link below.
https://docs.datadoghq.com/api/?lang=python#tracing
It show error message like the following.
cannot decode v0.3 traces payload: invalid character 'a' in literal true (expecting 'u')
please let me know what's wrong?

Closing this issue for inactivity. If you're still experiencing this issue feel free to re-open! Thanks!


Allow retention policy look up trigger cache-invalidate

The call RetentionPolicy() in meta/data.go returns an error when the given retention policy cannot be found. This prevents the associated call in meta/store.go from then hitting Raft to see if the policy exists on the leader. This change fixes this, and makes RetentionPolicy operate the same as Database().
This change also adds some small logging which I believe is needed since some databases and retention policies are auto-created, and this helps see this going on.

@jwilder @benbjohnson

:+1:


Add specs

This is the generator changes with change the primitives example to use the _spec form of primitives.

Thank you Dave. I'll merge this in later this week when I get done traveling.


Fix some typos in "Auth" directory root files.

Fix some typos:

AuthManager.php - hyphens by a rule: http://www.oxforddictionaries.com/words/hyphen (compound adjective);
RequestGuard.php, TokenGuard.php - indefinite article is not used with plural nouns;
SessionGuard.php - commentary for property changed to correspond commentary for its getter ("Get the last user we attempted to authenticate.").

I've removed controversial parts.

These changes are not required as previously discussed.

These changes were not discussed, we've talked about pronouns. I'm interested why don't you want to fix grammar errors. All these changes are based on rules.

There are no actual errors here.

But I have even provided corresponding rules, that's why I do not understand the reason:)

For what it's worth, the hyphens are a solid case.


Add integration test for extra signers using tx preconditions

new integration test case for using the Precondtions.ExtraSigners parameter with a standard AccountID as the additional signer.

I just show that the verify-range test is failing, I tried to rerun it

@sreuland Is this PR ready otherwise? @Shaptic can you take a look if so?


bugfix #243

apply changes according to @yuhui-zhao bugfix to image breaks

#243

I am using this change i my production app since 2-3 months. This works as expected.


Output % difference for failed comparisons to console

This should be useful for debugging, especially when using some tolerance level.

There is an open source implementation in javascript here: https://github.com/yahoo/blink-diff, might be helpful if you want to create this feature


Add HasFactory trait to Post model generation command

Description
This pull request enhances the make:model Artisan command by ensuring that models generated with the --all option automatically include the HasFactory trait. This addition streamlines the process for developers by providing a ready-to-use factory for database testing and seeding.
Benefits to End Users

Simplifies model creation by automatically incorporating the HasFactory trait, which is essential for database testing.
Reduces boilerplate code for developers, allowing for quicker development cycles.
Maintains backward compatibility with existing features of Laravel, ensuring no breaking changes.

Testing
I have added a feature test that verifies the Post model file is created with the HasFactory trait included. The test has been executed successfully and all assertions passed.
Documentation
The relevant documentation in the make:model command section should be updated to reflect this new behavior. I will make sure to provide the necessary updates in the documentation as part of this pull request.

Tests fail.

Fixed tests

Thanks @crynobone for fixing this and ensuring the tests pass

hi Adel
it works, thank you so much for your help!


WIP: GPU Operator: Test create_olm_bundle_1.8.2

Small cleanup of operator_bundle_image_builder_script.yml

/test ?

/test gpu-operator-commit

/test gpu-operator-commit

/test gpu-operator-commit
On Thu, Sep 23, 2021 at 10:01 AM openshift-ci[bot] @.***>
wrote:

@kpouget https://github.com/kpouget: The following test failed, say
/retest to rerun all failed tests or /retest-required to rerun all
mandatory failed tests:
Test name Commit Details Required Rerun command
ci/prow/gpu-operator-commit dc02614
https://github.com/openshift-psap/ci-artifacts/commit/dc02614b3128322cd314922b2f9c6214a398a795
link
https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift-psap_ci-artifacts/259/pull-ci-openshift-psap-ci-artifacts-master-gpu-operator-commit/1440937826827898880
true /test gpu-operator-commit
Full PR test history
https://prow.ci.openshift.org/pr-history?org=openshift-psap&repo=ci-artifacts&pr=259.
Your PR dashboard
https://prow.ci.openshift.org/pr?query=is:pr+state:open+author:kpouget.
Instructions for interacting with me using PR comments are available here
https://git.k8s.io/community/contributors/guide/pull-requests.md. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
https://github.com/kubernetes/test-infra/issues/new?title=Prow issue:
repository. I understand the commands that are listed here
https://go.k8s.io/bot-commands.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift-psap/ci-artifacts/pull/259#issuecomment-925586703,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZVQITWDTOFZPI4CENCN3LUDLNDPANCNFSM5ER6LN3Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

/test gpu-operator-e2e

/approve
version identifier of the master branch updated to 9.9.9-latest.git.$COMMIT_SHORT
https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift-psap_ci-artifacts/259/pull-ci-openshift-psap-ci-artifacts-master-gpu-operator-e2e/1442826971808534528/artifacts/gpu-operator-e2e/presubmit-master/artifacts/operator.version

/lgtm

thanks Omer :)
On Tue, Sep 28, 2021 at 5:42 PM OpenShift Merge Robot <
@.***> wrote:

Merged #259 https://github.com/openshift-psap/ci-artifacts/pull/259
into master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift-psap/ci-artifacts/pull/259#event-5374867539,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABZVQIXZLT2WOCE56IRAYFTUEHO6HANCNFSM5ER6LN3Q
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Integrate asciidcotorj

Add quarkus-qute-web-asciidoctor extension.
Leverage asciidoctoj and asciidoctorj-diagram libraries to render asciidoc content.
I did not try every kind of possible diagram or native.
Links #119

Ouch, I think JRuby and native won't play very well. I will try to dig a bit more.


refactor(reg-exp-router): Routes are returned in the registration order.

Fixes #322

@usualoma Thank you!


Rsgcn qm9

Please merge this after PR #103

support RSGCN in QM9 example
modified GraphConvPredictor to work on SchNet as well
update argparse to use '-' instead of '_' which is same with tox21 example
Change default batchsize=32

Codecov Report

Merging #104 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #104   +/-   ##
=======================================
  Coverage   73.54%   73.54%
=======================================
  Files          68       68
  Lines        2499     2499
=======================================
  Hits         1838     1838
  Misses        661      661

LGTM!
I can execute train_qm9.py with RSGCN successfully.


The result of CurlFactory::retryFailedRewind should return an array

When curl has the error status "65" "rewind failed". Which can happen when putting a big file via a resource. Which gets a redirect as response. Then this flow will happen:
We have a curl error
https://github.com/PBWebMedia/RingPHP/blob/master/src/Client/CurlFactory.php#L90
return !empty($response['curl']['errno']) || !isset($response['status'])
            ? self::createErrorResponse($handler, $request, $response)
            : $response;

We have error number 65
https://github.com/PBWebMedia/RingPHP/blob/master/src/Client/CurlFactory.php#L112
// Retry when nothing is present or when curl failed to rewind.
        if (!isset($response['err_message'])
            && (empty($response['curl']['errno'])
                || $response['curl']['errno'] == 65)
        ) {
            return self::retryFailedRewind($handler, $request, $response);
        }

Nothing of the above happens so we run the handle (gues he follows the redirect)
https://github.com/PBWebMedia/RingPHP/blob/master/src/Client/CurlFactory.php#L544
return $handler($request);

But the problem here is that the handle does not return an array but an CompletedFutureArray
Here is the handle set:
https://github.com/guzzle/RingPHP/blob/master/src/Client/CurlHandler.php#L78
return new CompletedFutureArray(
            CurlFactory::createResponse($this, $request, $response, $hd, $bd)
        );

As we can see in the row above that will return a CompletedFutureArray
Which it will put in CompletedFutureArray::__construct()
But the constructor accepts an array and not a CompletedFutureArray.
I thought it would be weird to modify CompletedFutureArray so it can also accept itself.
It seemed more clean to make sure that CurlFactory::createResponse always return an array instead having 1 case that returns an object.

You have any ideas on this issue? @mtdowling


Fix typo in ADVANCED.md

Thank you for this sophisticated library and the helpful documentation!
I found a minor typo in the documentation.

Thanks for the kind words @kaklakariada - sorry it's taken this long for me to get back to this. We had a missing CLA workflow on this repo that I've now remedied. Going forward in the future the process will be more automated - but as of now, to merge this PR we'll need one of:

Sign the CLA vs the temporary PR https://github.com/deephaven/deephaven-csv/pull/111
Create and push a new commit to this PR (an empty commit, a rebase, or merge from main should all work), and then accept the new CLA dialog that shows up here

Thanks for your contribution :)


Update most non-void returning const member functions to be [[nodiscard]]

It's become a generally accepted pattern in C++ to make non-void returning const member functions be [[nodiscard]] (or in the case of Herb's cpp2, the default everywhere). The idea is that a const function is not modifying any state, and therefore the caller should be interested in anything the function returns. I also went ahead and addressed things in the wistd namespace (even though std doesn't have the attribute) with the thought that it should benefit callers in general. There are a couple of exceptions to this, though:

Functions with "out"/"in out" parameters were kept as-is. This was to avoid breaking too much valid/correct code that either doesn't care about the return value or can deduce the return value by the side effects to the output parameter (e.g. functions that do a QI).
Functions that may have irrelevant return values/types for some subset of input values. E.g. waiting with INFINITE time. This was also done to avoid breaking too much correct code.
Functions that are "too generic" to the point where we can't make any assumptions about their semantics were left alone. E.g. wistd::function::operator().

Functions were identified by a combination of clang-query and manual code inspection. The mostly correct matcher argument for clang-query that I used was:
m cxxMethodDecl(isConst(), isExpansionInFileMatching("include[/\\]wil[/\\].*"), unless(hasAttr("attr::WarnUnusedResult")), unless(ofClass(isLambda())), unless(isDeleted()), unless(returns(voidType())))

The list of const member functions that didn't have the attribute added are:

wistd::function::operator() - can't statically determine the semantics of the call.
wil::event_t::wait - callers can - and generally do - assume the call can't fail when called with INFINITE wait time.
wil::com_ptr_t::(try_)(query|copy)_to - callers can - and sometimes do - deduce the return value from whether or not the output pointer is null.

This change does not:

Address any non-const member functions with the exception of functions with the same name as a const function to reduce confusion (e.g. begin, etc.).
Address any non-member or static functions, even though these may have similar semantics of not modifying state.
Re-visit whether some non-const member functions can/should be made const.
Do anything to prohibit violating this rule in the future. We'll just have to be vigilant going forward.

I chose not to tackle these to limit the scope. We can try and tackle these in another change, if desired.
The plan is to just (void) any existing offending calls that are found. The idea is more to catch bugs moving forward, not find/fix bugs that may or may not already exist.

Argh. Looks like we're randomly exhausting device space with building tests now :/

Kinda wish the standard had gone the other direction... everything is nodiscard unless you say "it's ok to discard this." I guess that makes updating existing codebases harder.

Kinda wish the standard had gone the other direction...

As you guess, the answer is back-compat. Of course, if you start fresh, you can choose whatever defaults you want


🐛 BUG: C3 2.8.2 always initialises JavaScript, even when TypeScript is selected

Which Cloudflare product(s) does this pertain to?
C3
What version(s) of the tool(s) are you using?
C3 2.8.2
What version of Node are you using?
20.10.0
What operating system are you using?
Windows 11
Describe the Bug
c3 2.8.1

npm create<EMAIL_ADDRESS>-- --no-auto-update
use all defaults - ensure you say "yes" to TypeScript
you'll get a TypeScript project, with src/index.ts

c3 2.8.2

npm create<EMAIL_ADDRESS>-- --no-auto-update
use all defaults - ensure you say "yes" to TypeScript
you'll get a JavaScript project, no types, src/index.js

It seems this regression was introduced in https://github.com/cloudflare/workers-sdk/pull/4470 and unfortunately wasn't caught in any automated testing. It also took longer than I care to admit to find that PR, without a changeset 😅

I can confirm!

I also ran into this issue


Debug's session badge is slighty confusing in js-debug

Insiders:

debug a simple express app with js-debug

Observe:
the debug icon's badge shows 2 sessions:

This is slightly confusing since a user is only aware of a single session.
The first "session" is an implementation detail of js-debug. It is not really a debuggee that the user can interact with (e.g. set breakpoints and stop somewhere). We should not count it as a real debug session (and we should consider to hide it in the CALL STACK view as long as there is only a single child).

Agree, since this debug session is an implementation detail it should not be visible anywhere in the UX, not only in the badge.
So it should not be seen in the call stack, repl dropdown, debug toolbar etc...
I believe we would need new api for the debug extension to be able to specify this to the frontend.

I think the badge should count how many top-level sessions there are, without counting children. From a naive user POV that's what I assumed its intention was.

I can also change how the badge counts as you propose. However I do not see the value of seeing the parent session in the call stack view, or I might be missing something?
Also for the cluster sample, it might be nice to have the total number of clusters. Do I do agree that just having 1 might work.

However I do not see the value of seeing the parent session in the call stack view, or I might be missing something?

We may want to hide it from the UI if there's only a single child, but in js-debug having the parent session is important. If I have a shell script as my program that spins up multiple concurrent Node processes, these Node process will end up being children of the 'virtual' parent session; if we didn't have the parent we'd show the first process. We could alternately have some shim with custom dap requests that result in multiple startDebugging requests for each child, but then there's no way for a user to easily terminate the entire tree of debug sessions.

For terminating multiple debug sessions -> this seems like an unrelated issue which we can fix via introducing a new command, or allowing multi selection in the call stack view.
Yes, havgin mutliple startDebugging for each child makes sense to me.

I don't agree that it's unrelated. Say I have a shell script like that which spawns a cluster of processes in some way, and a config that debugs a frontend. Right now, if I go ahead and boot that from a compound launch config, users get a tree like this:
Open Frontend
└── index.html
Start Server
├── cluster.js
├── cluster.js
└── cluster.js

Without a top-level session that would be simply
index.html
cluster.js
cluster.js
cluster.js

It becomes harder to see which is which, and there's no clear way to kill all the cluster children. Mentally I think this should be a hierarchal view since the clusters are children of a single launch config.

I meant we have that issue other way that there are multiple sessions which the users wants to close together.
If you really like the hierarchial view you can stick with that but please use the heuristic: if there is only one child, do not create a parent.
We use this heuristic across the CallStack view to make the data more presentable to the user - we do not show threads if there is only 1, same with sessions etc...

The difficulty from the debug adapter is that we cannot know if there will be multiple children until the point in time that we see them--a program might spawn any number of children at any time--at which point our session is already set up and running. We could terminate the old top-level session and recreate it as a child, but restoring all the debugger state perfectly would be very delicate.

IMO there are two issues:

what does the badge show?
what do we do with "pseudo" debug sessions (sessions that are not really debuggable but only exist as an implementation detail).

What does the badge show?
It should show the number of user initiated sessions, but not their sub-sessions. So for the cluster example or a session with the new js-debug the badge always shows 1 (independent from the number of worker processes or spawned sub processes).
For compound session we could use the same approach but I understand that might be difficult to achieve since we have no representation of a compound config. We only see two or more sessions without a common parent.
What do we do with "pseudo" debug sessions?
To avoid cluttering the CALL STACK view with "uninteresting" sessions (e.g. the pseudo session of the new js-debug), we should use the "compact" tree rendering that we use elsewhere: automatically hide parent nodes if they only have a single child. We do this already in the CALL STACK and LoadedScripts view. Now we should extend this for hierarchical sessions as well.
But there is a twist: if the parent is actually a "real" debug session (and not a pseudo session), there must be a way to turn off the auto-hiding. Whether the distinction between the two cases can be made implicitly by DAP usage or whether we need explicit extension API, is an open question.

Agree for the number badge. I have pushed a fix for that.
Also agree for the "pseudo" debug sessions argument: we should hide them.
We can first try to be smart and if that does not work we need to add API (for example a capability).
Oversimplified heuristics which might work:

when there is only one parent session A and only one child session B, only render the sessions if they are stopped. We would only render A if B exists and A is stopped. Of course we render A if it has multiple child sessions B1, B2... Downside of this approach is that user can not pause / terminate A when it is not stopped.
We consider a session a dummy session if some request has never been sent to it. Dummy sessions we do not render we they have only one child.

Just want to add that showing the parent sessions is one of the biggest pain points for me personally while self hosting.
@connor4312 let me know how you would prefer that we tackle this. Also js-debug can not compute better names than the current number naming?

Naming is definitely something we can fix, at least in most cases :)
As far as getting rid of the top-level wrapper session. There have been some refactors in js-debug recently which make this easier to do. That is, not have the wrapper session and if there are multiple children they would appear as separate top-level sessions in the UI.  For instance, if the 'program' is a shell script that runs node a & node b & wait in bash, we currently have the ability to kill that command by sending terminate to the wrapper session. If node a and node b were totally separate debug sessions, how would that work? We could make killing one also kill the other, but that seems like a kind of weird experience.  User has to manualy kill both. Once users complain this is too much work we can think about simplyfing.
This problem is similar to the Compounds on VS Code side. Killing one session does not kill the others that were launch with it as part of the Compoound. Users find this behavior intuitive, and we should not change it for js-debug imho

@connor4312 just a friendly ping for this. Could we look into imrpoving the multi sessions for js-debug. Also unassagning myself for now since this should mostly be done by the js-debug extension

Thinking about this some more, there's another case I'm having trouble with. Say I have this shell script that I set as my program:
npm run build
sleep 10 # or do other things...
npm test

Today this is not hard to deal with. We have the top level session, and the build and tests tasks would come in as children as they start up. During the sleep, there would be no child sessions.
Without a top level session, the question arises--what happens during the sleep? There is no Node.js debug target running. The options I see are:

Not show anything any running session during this time. This would be the natural result of not having the top-level session, but then the shell script would be a background task that's impossible to monitor or terminate.
This is the approach the debug terminal takes today, but the terminal itself is the UI that can be used to monitor and terminate the script. Running from a launch config using the internalConsole (vs an internal or external terminal) we don't get this.

Open runtimeExecutables that aren't  node/node64 in the integratedTerminal by default. I don't like this very much as it forces a workflow change on users.

Keep whatever the last session target we had open as a 'zombie' and use that as the handle to the shell script. That is, we would pretend npm run build is still ongoing until the new script starts. Would solve the problem but kind is a bit of a hack and confusing to users.

Don't support this scenario / treat it as an edge case: kill the shell script when the number of attached targets reaches 0.

I feel like both 1 and 4 are ok options. I would go with 1 and if the user need arrises for this we can investigate what can be done (create some zombie fake session etc)

I think this is now resolved with the compact sessions work. Reopen if there's any remaining parts to address.


Chado check failure - not enough genes

We're getting this in the Chado check log:
pombe_genes - FAILURE:  expected >= 6980 but got 6966

It might be caused by the deletion of the dubious genes, but it needs checking.

Jira tickets from Val mention 14 deleted genes - 12 "dubious" in https://www.ebi.ac.uk/panda/jira/browse/PB-2501 and 2 ncRNA in https://www.ebi.ac.uk/panda/jira/browse/PB-2485
Does that cover everything?

Yep, that's probably OK then.  The Chado check was expecting 6980 but got 6966 which is 14 genes less.
Thanks for checking Jira.  I'll modify the Chado check.


Add custom icons on chart(earnings, conference calls, etc.) (v0.4)

Only if this possible.
There are news on US market(earnings, conference calls, etc.)
Show you chart for example:

On hover I get information about news:

Usually configurations:
Earning:

date, format 28-10-2015-15-15 ---> day-month-year-hours(24)-minutes
estimates value, format $0.238 prefix is currency symbol for other markets ($, €, £, ¥ etc.)
current value, format $0.31 prefix is currency symbol for other markets ($, €, £, ¥ etc.)
icon style.

Conference calls:

date, format 28-10-2015-15-15 ---> day-month-year-hours(24)-minutes
icon style.

Custom news:

date, format 01-01-2016-00-00 ---> day-month-year-hours(24)-minutes
event: "Happy New Year"
icon style.

For icons will be the best suited font:
https://fortawesome.github.io/Font-Awesome/
https://icomoon.io/app/#/select
or other...

this will be a good addition. There is still lot of work left on 0.4, and I don't want to delay it further. will plan 0.5.

How does this api look?
<Chart>
	...
	...
	<Annotation when={d => d.high - d.low > 1}>
		{props => <Label className="glyphicon" key={props.d.idx} {...props}></Label>}
	</Annotation>
</Chart>

 is the character which creates the bootstrap icon glyphicon-earphone
I got this to work for
<ChartCanvas type="svg" ...>

working on a canvas implementation.

Changed API
also example updated for both svg and canvas

fixed, published in 0.5


Robotoff questions is looping in some conditions

What

Robotoff questions is looping in some conditions

Video
https://user-images.githubusercontent.com/1689815/197280691-862014aa-aa50-4b28-9617-e73413137862.mp4

Fixed by @omkarChend1kar's #3314 fix of #3291.


remove GTM scripts

Description
As GTM is not working correctly with onetrust, owing to timelines we decided to go ahead only with onetrust. Hence reverting GTM integration code.
Issues Resolved
[List any existing issues this PR resolves, or any Discourse or
StackOverflow discussions that are relevant]
Check List

[ ] New functionality includes tests
[ ] All buildkite tests pass
[ ] Full omnibus build and tests in buildkite pass
[ ] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/main/CONTRIBUTING.md#developer-certification-of-origin-dco
[ ] PR title is a worthy inclusion in the CHANGELOG

Adhoc build: https://buildkite.com/chef/chef-chef-server-main-omnibus-adhoc/builds/6080


changed styles for the add link dialog

fixed base styles for the link dialog

updated styles and clicking

added new  controls and  functionalitн


Add .exe extension to the Windows binary

Description

Refs: https://github.com/nodejs/single-executable/discussions/65#discussioncomment-5681096.
Linked Issues
https://github.com/nodejs/single-executable/discussions/65
Additional context

I have confirmed that this works by running CI on my fork in https://github.com/RaisinTen/unbuild-sea/actions/runs/4771305855/jobs/8483155231#step:8:5.
cc @yjl9903

Thanks for your answer!


Fixing mixed content http-> https to stop warnings

There's an image loading over http rather than https which is causing a mixed content warning and a warning symbol on the lock in the url bar

@edjw, thanks for the fix!


Rewrite the RUNBOOK.md moreInformation and monitoring fields

they are currently tables, and would probably be better suited not to be

this seems fine


Force worldmatrix to be updated before baking vertices

Followup on https://forum.babylonjs.com/t/navmesh-parenting/14329/3
World matrix was not properly updated when creating a navmesh. Forcing its update before baking vertices.

LGTM :)


tinkerbell: Move to fedora based image

cfssl package for alpine has been removed. Hence the build fails. This
commit moves to a fedora based image.

Created a PR upstream: https://github.com/tinkerbell/sandbox/pull/86


Need Audio Track Change Feature and Sleep Timer Feature

Audio Track Change feature will help to change audio language in MrBeast Video.
Sleep Timer feature will help to pause the video at sleeping time.

The audio track feature isn't implemented by YouTube in the mobile web version. So it's sort of difficult to implement it seperately.
Regarding the sleep timer , we can do something about it.


AddOrUpdate acts like AddOrReplace?

Should not there be an overload that allows to update the value rather than completely replace it? I  might have an unsorted incoming stream of items with the same ID but different versions. If there was an overload accepting an update function I would be able to take the latest version of the same ID.
This is something ConcurrentDictionary provides: https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentdictionary-2.addorupdate
I guess the IEqualityComparer overload of SourceCache.AddOrUpdate could be abused to pass a comparer that will do revision_current >= revision_new but it feels weird.
Unless I am supposed to use ConcurrentDictionary along with SourceCache here by design? What would be the DynamicData ideomatic approach?

You can use this https://gist.github.com/RolandPheasant/3bba5e32f2eefb70c538ce4acabf17cb

@RolandPheasant thank you very much, I will try it now!
Just for my information, you don't believe this belongs to the main package philosophically?

@RolandPheasant thank you, but I don't think it will work. It really needs to happen close to source SourceCache rather than consumer IObservable. The source needs to stay reliable. If I pick the TKey to be string ID then the source will have the last incoming version rather than latest; if I pick the TKey to be (string ID, long Version) then the source will be denormalised and TransformWithInlineUpdate will not work. This method is however still super-useful for not replacing the whole view-model and some of my need, however the original requirement can only be satisfied by something around SourceCache.

Yet another alternative alternative would be to use the edit overload:
mycache.Edit(innerCache =>
{
   //do some operations on the inner cache e.g
   foreach (var item in myItems)
  {
      var existing = innerCache.Lookup(item .Key);
      if (existing .HasValue)
       {
         //update the original item
       }
      else
      {
          //add the new item
          innerCache.Add(existingItem);
      }
   }
});

This may be what you are looking for

I think there is no such thing as just Add method, only AddOrUpdate on the ISourceUpdater or am I wrong? Additionally would it not be non-atomic and thus not thread-safe?

That is just bad typing.
      var existing = innerCache.Lookup(item .Key);
      if (existing .HasValue)
       {
         //In place update the of the original item
           var originaltem = existing.Value;
           existing.PropertyA = item.PropertyA ;
           existing.PropertyB = item.PropertyB ;

         //You may also need to do the following [if properties are used for filtering, sorts, grouping ext]
         innerCache.Refresh(existing);
       }
      else
      {
          //This is an add as we have checked above
          innerCache.AddOrUpdate(existingItem);
      }

This will work, or maybe I am missing the point.

@RolandPheasant now I understand completely, thank you very much for your help!


Added executable scripts for benchmarks and stresstest

Two executable scripts have been added in sub-folder bin/

bin/benchmarks: Performs all memory bandwidth and peakflop tests on all GPUs within a node
bin/stresstest: Performs stresstest on all GPUs within a node

@carstenbauer I agree with your points. I should have fixed now all the points you have mentioned. If I have missed something, please let me know.


Update Podspec to support watchOS 2

When using libPhoneNumber-iOS with watchOS 2, then I get error message when running pod install
Please update the podspec for libPhoneNumber-iOS to support watchOS 2.
like here
Pod::Spec.new do |s|
s.watchos.deployment_target = '2.0'
end
thanks !

Thanks, but please leave version to 0.8.8. It will update next update cycle/


WIP Propose more comprehensible terminology for “disable optimizations”

This is a strawman for discussing options for improving the user feedback when unsafe/incomplete implementation or configuration of a work unit causes “optimizations” to be disabled.
Tests have not been updated to reflect the proposal.
For the common case of not using --info, before:
Before:
Property 'myPrivateInput' is private and annotated with @Input. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. Execution optimizations are disabled due to the failed validation. See https://docs.gradle.org/7.0-20210201140000+0000/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.
> Task :myTask
Validation failed for task ':myTask', disabling optimizations:
  - Property 'myPrivateInput' is private and annotated with @Input.
Execution optimizations have been disabled for 1 invalid unit(s) of work during the build. Consult deprecation warnings for more information.
BUILD SUCCESSFUL in 60ms
1 actionable task: 1 executed

After:
Property 'myPrivateInput' is private and annotated with @Input. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. See https://docs.gradle.org/7.0-20210201140000+0000/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.

> Task :myTask
Avoidance and parallel execution have been disabled for task ':myTask' in order to ensure correctness, due to the following reasons:
  - Property 'myPrivateInput' is private and annotated with @Input.

Avoidance and parallel execution were disabled for 1 unit(s) of work during this build in order to ensure correctness, which potentially increased the build time.
Please consult the build log and deprecation warnings for more details.

Both are problematic, with the most problematic probably being that the given documentation link will do very little to help any non-expert comprehend what is going on here.
Regardless, I propose that the after is better in that:

It does not using potentially confusing concept of “validation”, which makes sense to us but not to users
It avoids the ambiguous (for a user) concept of “disabling optimizations”
It gives some indication that this is actually benefiting a user
It makes it clearer that this has a negative build time impact and is different in that manner
It is generally more human oriented

Nice improvement.
The only issue I see is that the "avoidance" part may not be clear. People may think of "task configuration avoidance" or "compile avoidance".
What exactly are we referring to avoidance here? Up-to-date checking and build caching?

I very much agree that the new message is more user-friendly. In general we assume too much about the user understanding what we mean, so more context is better.

Avoidance and parallel execution were disabled for 1 unit(s) of work during this build in order to ensure correctness, which potentially increased the build time.
Please consult the build log and deprecation warnings for more details.

"correctness, which potentially increased" reads a bit strange. I'd split that:

****** and parallel execution were disabled for 1 unit(s) of work during this build in order to ensure correctness.
This potentially increased the build time.
Please consult the build log and deprecation warnings for more details.

I don't know what to use for "avoidance" because I'm unsure myself what it refers to, but it should be explicit.

AFAIK, the three optimizations we are talking about are “Up-to-date checking”, “build caching” and “parallel execution”. These messages are already lengthy, so I tried using “Avoidance” to cover “Up-to-date checks” and “build caching”. I agree that it is awkward. I think the verbosity is better than the ambiguity when all things are considered. I'd update that.

"correctness, which potentially increased" reads a bit strange. I'd split that:

+1 on that suggestion.

AFAIK, the three optimizations we are talking about are “Up-to-date checking”, “build caching” and “parallel execution”. These messages are already lengthy, so I tried using “Avoidance” to cover “Up-to-date checks” and “build caching”. I agree that it is awkward. I think the verbosity is better than the ambiguity when all things are considered. I'd update that.

I think we should use the term "execution optimizations." This is a term that both sufficiently covers the things that are in question today and in the future, and it also captures what's important for the user (=they care that their build is executed as optimal as possible).
Note that "avoidance" rhymes with "compilation avoidance" which is not affected by validation problems.
Also note that in some cases we can't disable parallel execution (e.g. because we detect the problem too late). We could say here that "certain execution optimizations are disabled." I think it's sufficient to clarify the actual optimizations being disabled in the linked documentation.

Another thing we should probably do is to emphasize that the user can get more information (including the documentation link) for deprecation warnings by supplying --warning-mode=all.

BTW, yet another optimization that is disabled in incremental execution. We might have other things disabled in the future, too.

I’ll leave it to the execution team to resolve from here as desired.


Set proper surname of @ladyleet

cc: @ladyleet

Lgtm

Ping @siddharthkp

Never too late to merge it, I guess 😅
Thanks!

Can't merge this PR anymore so updated it myself in https://github.com/siddharthkp/react-amsterdam-videos/commit/2b243a69927f896b68545c905c76500ac3477fc2


Create service bus resource during PR

JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/AM-1273
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[X] No

Parking this PR for now.


Chore(lambda-chaos): Adds docs for AWS Lambda chaos to update function memory and timeout

Harness Developer Pull Request
It will add the docs for lambda function chaos to update memory limit and timeout value for a certain chaos duration to check the function stability.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[ ] Tested Locally
[ ] Optional Screen Shoot.

Preview environment: https://ci.pr.harness.io/pr-143

Preview environment: https://ci.pr.harness.io/pr-143

Preview environment: https://ci.pr.harness.io/pr-143


Consider replacing adrian with a tiny shell script

I've been looking at atomist which seems to have means to do distributed maintenance, such as version bumping etc, based on typescript functions.
It would be nice to be able to test and/or roll-out a change to the myriad of applications that use zipkin's libraries, in and outside our org, without necessarily depending on my caffeination levels.
There might be other tools, but seems atomist might help here?
cc @openzipkin/core @openzipkin/devops-tooling
(ps I don't mind maintenance work, it is good for the ecosystem that we push updates, just wondering if we can make it require less labor)

PS rod mentioned this for content https://vimeo.com/247562710
beyond selfish aims of maintaining things, seems atomist could also be a way to help instrument libraries. I didn't think of this angle.

Happy to see how we could help. Distributed library updates are definitely doable; we've examples in both Maven and package.json.

 Any sample PRs we could look at to see what we're talking about?
Which orgs?

sure. here are some examples. some have inherent workflow so not sure if appropriate or not
automatically update to latest finagle version

Finagle updates once a month, but the day might change. Update and immediately cut a release

nag issue placeholder https://github.com/openzipkin/zipkin-finagle/issues/38
version bump before release tag https://github.com/openzipkin/zipkin-finagle/commit/221a74bc7f7e8f5f045e09afcddd65df571f1824

update spring-cloud-sleuth

once a "notable" release is done to our core library, put it in spring-cloud-sleuth. deployment decoupled as out of our org, usually 2 branches to do

https://github.com/spring-cloud/spring-cloud-sleuth/commit/92e434e26129bef00215cd20253a58b32c8ee12d

update extension to our docker image

update extension library with latest zipkin, on green build make a release-0.8.5 tag to kick automation

thing to do to update versions: https://github.com/openzipkin/zipkin-aws/commit/107d9df6cadcd68c20547e4bba9b3543522c1f62

once that's done, it is synced to bintray, so we can update and cut a docker image via 0.8.5 tag

thing to do to update versions: https://github.com/openzipkin/docker-zipkin-aws/commit/91198770444766a848e7a8900de1702ab1b658e3

All these look doable.

I assume cutting a release means a tag and updating release notes?
Not sure I fully understand the POM changes here, but certainly editing the POM is a core capability
Editing docker files is also relatively easy

Another angle is we have a number of example projects to show how to configure zipkin. While some are starting anew, many are copy-pasting things out of these into existing apps. Some sort of means to inject zipkin could be great for support.
https://github.com/openzipkin/brave-webmvc-example
https://github.com/openzipkin/zipkin-php-example
https://github.com/openzipkin/brave-webmvc-example
(there are many others)

Not sure how much of a manual chore doing releases still is (apart from writing the release notes and kicking bintray / travis around), if so maybe github actions could be leveraged. But ultimately it's @adriancole to call this, as he's doing most releases.

A single release.sh script ain't going to happen, github actions are being leveraged more and more. Instead of this, specific issues can be opened for different parts of the release automation. Sorry Adrian, you're not scriptable !


Some improvements are needed for IDTagger

while nice, re-write of the component hash when page has changed should be only optional, as we might want to keep same component ID over MSM copies,
we should provide ID retrieval possibility, and write possibility to the outside world

We need to get the discussion started in #140 over, but this is to be closed