Future of Angular E2E & Plans for Protractor

TLDR
The Angular team plans to end development of Protractor at the end of 2022 (in conjunction with Angular v15).
Why?
Protractor was created in 2013 when WebDriver APIs were not yet a standard and end-to-end (e2e) tests were hard to write due to lack of support for async / await. To solve this problem, Protractor wraps selenium-webdriver and abstracted asynchronous operations from developers with the use of Control Flow.
Since then, the JavaScript standard and ecosystem advanced considerably, providing modern syntax and much better development tools. Nonetheless, Protractor is not able to leverage such technology without forcing users to rewrite their tests. Meanwhile, robust alternatives have emerged in the web testing space. Developers will see more benefits from adopting a more modern testing tool than from updating to a breaking version of Protractor which does not provide additional functionality or developer ergonomic improvements.
We would like to hear from the community on

the deprecation timeline
what we can do to provide reliable integration with third-party solutions
how users can transition by following migration guidelines
additional concerns that would ensure a smooth transition

This RFC will close on Friday April 16, 2021.

State of Protractor
The Angular team created Protractor in 2013 when WebDriver APIs were not yet a standard and end-to-end (e2e) tests were challenging to set up. The proliferation of callback patterns in JavaScript back then made asynchronous operations difficult to write and manage.
Protractor, echoing the approach taken by the underlying selenium-webdriver, solved this problem by managing promises via Control Flow. Control Flow makes asynchronous calls appear synchronous, thereby avoids the use of Promises entirely.
This strategy worked well for some time, but as the JavaScript standards and toolings evolve, Protractor regressed. Starting from ES2017, async / await makes handling Promises significantly easier because they no longer have to be chained. However, async / await is fundamentally incompatible with Control Flow, and support for Control Flow is dropped from selenium-webdriver v4.0 completely. Protractor, being dependent on selenium-webdriver, is not able to upgrade to the new version without introducing a huge breaking change and forcing users to do a migration for all their tests.
Besides dropping support for Control Flow, making Protractor compatible with ES2017 involves a significant amount of work to overhaul its implementation. Legacy dependencies such as jasminewd2 and Q promise library ought to be removed, which will bring about further breaking changes.
Since Protractor was initially designed to support AngularJS, many of its features like locators and mock modules are specific to AngularJS. These features only work in AngularJS and not Angular. They will no longer be relevant once development on AngularJS ceases by December 31, 2021.
Removing Control Flow and dropping AngularJS-specific features would make Protractor essentially just a wrapper around selenium-webdriver that provides no additional functionality.
Current Landscape for Web Testing
Many testing solutions have appeared since the creation of Protractor, and they offer better stability and much improved support for features like cross-browsers testing. Some even eschew the WebDriver standards completely in favor of using the DevTools protocols directly.
In order to understand the adoption trend of these alternatives in the Angular community, we conducted a survey on e2e testing in January 2021. We received close to 1000 responses and got a lot of feedback from the community. A clear signal that we received is that there is no one-size-fits-all solution for all Angular projects out there. Fewer than 20% of the respondents use Protractor in their project. Some users prioritize the cross-browsers support that the WebDriver standards guarantee, whereas other users prefer the stability and flexibility that DevTools protocol offers. A similar survey focused entirely on enterprise customers yielded comparable results.

Moving Forward
Deprecating Protractor is not a decision that is taken lightly by the team. Inside Google, we support thousands of projects and hundreds of thousands of test targets that depend on Protractor. After evaluating the costs and benefits of updating Protractor vs migration effort imposed on users, we conclude that the best strategy to set users up for success in the long term is to encourage migration to a more modern and framework-agnostic testing platform. The reasoning is as follows:
Removing Control Flow from user code is a gigantic effort because it forces users to update all their tests. Google went through this effort, and it took a major infrastructure team half of their time in 2018. Even then, they could only migrate tests written in TypeScript due to the availability of more robust tooling for source code analysis and transformation.
After going through such a massive endeavour, we realize the “new” Protractor is no better than other existing solutions. The only feature that differentiates Protractor from selenium-webdriver at this point is the ability to automatically wait for the application under test to become stable (waitForAngular feature in Protractor).
Although waitForAngular is useful, it strongly couples the testing platform to the Angular framework. Some teams at Google have found that solutions that do not require knowledge of Angular can perform the tests equally well by using a robust retry strategy. We believe this is how e2e testing should be done going forward, and projects in Google are already converging towards a testing platform that is WebDriver compliant and framework agnostic. This allows our web test team to maintain a single solution for all web applications.
Externally, there are many excellent alternatives available to the open source community, such as:

Cypress
PlayWright
Puppeteer
Selenium-webdriver
WebdriverIO

(The list is sorted in alphabetical order and is non-exhaustive.)
Deprecation
The most important focus for the Angular team is to ensure a smooth transition for Protractor users. We have been engaging with different vendors to ensure

there is sufficient documentation / tooling to help users migrate to other platforms
third-party platforms integrate well with Angular CLI, so that CLI configurations are automatically handled by vendor-specific builders

So far, the Angular team has reached out to the teams at Cypress and WebdriverIO to achieve the goals above. We will provide regular updates as more resources become available. If there is a particular platform that you’d like us to reach out to, please let us know in the comments below.
Our proposed deprecation timeline is as follows:

Angular version 12 (May 2021)

Announcement of deprecation
Angular CLI will not include Protractor for new projects
Show warning when @angular-devkit/build-angular:protractor is used
Only PRs that address security issues and fixes for browser releases that break Protractor tests will be merged

Angular version 15 (end of 2022)

End of development on Protractor

No decision is final until we assess all the feedback from this RFC.
Extended LTS
For users who require extended long-term support after the end of life of Protractor, we suggest reaching out to our external partners:

flare.build
xlts.dev

If your team / company provides similar services, please let us know!
FAQs

What about Component Harnesses?
Angular CDK's component harnesses include a ProtractorHarnessEnvironment for using harnesses in Protractor. This environment will be deprecated and replaced with a new environment backed by selenium-webdriver. The harness APIs themselves will be unchanged.
How will Angular CLI handle ng e2e for new projects starting from version 12?
The CLI will not include a default e2e builder for new projects, and users will decide which third-party builder to install. This is because picking an e2e platform really depends on the requirements of the project and there is no clear best fit for all Angular projects.
In version 15, would all Protractor tests break?
The Protractor builder will continue to work until version 15. After that, we plan to remove the Protractor builder (@angular-devkit/build-angular:protractor), which means ng e2e will no longer run Protractor. However, we are open to revising the timeline based on user feedback. Please let us know in the comments below.
Protractor is useful because it automatically waits for the application to become stable. How can I use that in other platforms?
Under the hood, Protractor uses Testability provided by @angular/core to check if the app is stable. This feature can be integrated into other platforms in a straightforward way. See the example for selenium-webdriver.
Which e2e framework is the lowest effort and cost to migrate to from Protractor?
In terms of APIs, selenium-webdriver is most similar to Protractor because it is used under the hood. If your tests still use Control Flow, you’ll have to remove it first by adding async / await to the Protractor calls. After that, you can replace the Protractor methods with those in selenium-webdriver. Although they are not 1:1 replacements, they are very close.
Where will e2e migration strategies be documented?
We are consolidating a list of migration strategies doc written by vendors and community members. See Links section below.
What other packages will be deprecated along with Protractor at the end of 2022?

protractor-cookbook
jasminewd
webdriver-js-extender
blocking-proxy
webdriver-manager

My team just did a migration to disable Control Flow. What are our options?
It is possible to create a thin wrapper around selenium-webdriver to provide APIs that are compatible with Protractor's. This is an idea that needs further exploration. Please let us know in the comments below if such tool is useful to you.

Open questions

Should the Angular team provide a different deprecation timeline?
In addition to migration docs and CLI integration, how can the Angular team support Protractor users in the transition to other platforms?
What are the alternatives to deprecating Protractor?

Links
This section is a work in progress. We will continue to consolidate more links and migration guides here.

Migrating from Protractor to Cypress
https://nx.dev/latest/angular/modern-angular/protractor-to-cypress
Cypress official doc for Protractor users (placeholder link for now, will be live in the future)
http://on.cypress.io/protractor-to-cypress

Cypress is great alternative. I have been using it since few months, easy to configure and write tests. Provide CLI option to add it to the new or existing project?

@pavankjadda we're working with the Cypress team to ensure smooth integration with the Angular CLI.

We have huge e2e code @ Blueface Comcast. A good documentation for common migration use cases would be highly beneficial.

If you are looking for CDK Harness support on Cypress, here it is: https://github.com/jscutlery/test-utils/tree/main/packages/cypress-harness

Hi @batbrain9392. I'm Amir from the Cypress team. We're working on helpful migration guidance. To make this material better for you and rest of the community, I'd love to learn more about your project.
If you're up for it, feel free to email, or schedule a chat.

I am pretty convinced Cypress offers the best DX out there but no more opinion on ng e2e is definitely the best opinion.

I'm glad to see protractor going away and that there is a good plan on how to deprecate it. Selenium/Webdriver is based on technology almost 20 years old and is far too fragile for today's dynamic pages to fulfill the need for a reliable testing platform. Cypress offers a much more consistent and reliable testing platform where testing edge cases becomes almost trivial.

We are using both Cypress and Playwright and have found Playwright to be both easier to use and more robust.
Added benefits are amongst others ability to test Safari/webkit, less flaky tests and possibilities for conditional testing.
Can somebody else that is using both frameworks comment on the advantages they see in Cypress vs Playwright?
Are we missing something?

@amirrustam
Thanks for your assistance. I too have lot of code written in Protractor to migrate to Cypress. I will schedule a chat with you help you understand my requirement.

Looking forward to the e2e upgrade, and have my fingers crossed the transition from Protractor will be fairly seamless. Are the any plans for a CLI update to provide a similar tool to ng update for e2e side of the transition? I know how rough updates were at the start, and really hoping the e2e update will be less painful that the early days and closer to how updates are now.

Hi @LanderBeeuwsaert. Amir from Cypress team here. Playwright is also a fantastic tool (and team)!
With regards to Safari, we've added WebKit support to the Cypress roadmap.
Can you elaborate more on your mentioning of "more robust"? I can address any potential concerns for you and the community, and your feedback is always helpful and appreciated for improving the tool.
If you're interested in deeper dive conversation on the topic, feel free to email, or schedule a chat.

Sure thing @vsravuri, and I extend the same offer to everyone else here as well.
The Cypress team is here to help as much as we possibly can.

As for #8 on the FAQs: "It is possible to create a thin wrapper around selenium-webdriver to provide APIs that are compatible with Protractor's."
I am working on this library. It still needs to go through internal open source approvals. 🤞

I tried Cypress and then switched to Playwright. More features and easier to use.

Hey @amirrustam , let me first say that Cypress for us has helped us out amazingly as well.
For us however there have been some things that have made it difficult (or even not possible) to use.
No framework is perfect, and it's cool to see the Cypress team working on a lot of these improvements, so I'm sure it's gonna get even better when time goes on.
For reference, for us the dealbreakers have been:

No Webkit, upcoming, that's super: https://github.com/cypress-io/cypress/issues/6422#issuecomment-762932421
No parallel browser instances. (this one is huge for us, we develop judging software where 20 judges are interacting in parallel. Being able to simulate this with playwright was a big step for us. Also, we run 8 test suites in parallel now on a single computer (albeit with 16 cores :)), cutting our CI testing run times by 8).
Flaky issues with chained selectors: https://github.com/cypress-io/cypress/issues/7306#issuecomment-801952654
Unintuitive Awaiting: https://github.com/cypress-io/cypress/issues/1417
No conditional testing: https://docs.cypress.io/guides/core-concepts/conditional-testing#Welcome-wizard

Thanks so much for putting this (and the whole thought process) together for such a complex problem, @kyliau, and the team!
With AngularCLI dropping scaffolding E2E tests out of the box, it will cause more problems for beginners wanting to start with Angular. We pride ourselves so much in being a complete framework with all this built-in tools and seeing the AngularCLI starting to drop each toolings out of its box (like Linting) hurts a bit.
That said, I do understand the concern about being opinionated about which E2E solution to bake in the CLI when there are gazillion options out in the ecosystem. It would be nice to settle with the most-voted option (looks like Cypress won by a landslide here) and provide the option to opt-out of Cypress.
Another option is the documentations need to be very deliberated about the importance of E2E testing. With AngularCLI not scaffolding an E2E solution, the chance of getting into E2E testing is getting even worse IMO

Thanks for taking this design which was long overdue. Cypress seems to be the obvious way to go given its support and community. And if there aren't any huge turn downs of using it with Angular, I'd say its a win win.
I guess this would give the Angular team more time to invest in the framework core.

I've had an amazing experience using Cypress as my go-to e2e framework for the past 3 years for both enterprise and small scale projects. The community and its' integration with https://nx.dev/latest/angular/cypress/overview is just an added bonus. Also with the increased popularity of web components today, something that is framework agnostic is almost a must have. Great job and details describing the decision making behind this! It's very clear a lot of careful thought and analysis was behind this decision.

If you manage to do some Cypress component testing in browser with angular, fell free to use https://github.com/bahmutov/cypress-angular-unit-test

Knowning that Protractor will be deprecated. Is there a way to remove it from angular 11 projects properly in order to get ehead of v12 deprecation ?

Hey folks 👋 ,
this is Chris maintaining the WebdriverIO project. First of, big thank you to everyone involved developing Protractor, it has been a great framework and WebdriverIO has adopted a couple of feature ideas from it. We are glad that the Angular team has reached out to us to include WebdriverIO as an transition option. The team is happy to offer a free, open governed and flexible framework, hosted under the OpenJS Foundation alongside projects like Node.js and webpack.
WebdriverIO allows you to leverage both the ability to run true cross browser testing based on WebDriver as well as a lot of debugging and introspection capabilities through the DevTools protocol. With the help of various of plugins the framework allows you to run performance and PWA audits through Google Lighthouse as well as mock and stub any kind of browser requests. It comes with a Jest style built in assertion library and tons of reporters, some maintained from the project some by the community.
We are currently actively working on the following items to make the transition for Protractor users as smooth as possible:

[x] build an Angular CLI schematic (see webdriverio/webdriverio-schematics ✅ )
[ ] setup a codemod to help transform Protractor code into WebdriverIO commands (webdriverio/webdriverio#6659)
[ ] Add Angular framework stabilizer (webdriverio/webdriverio/issues/6660)
[ ] Write up docs with a step by step description how to transition over

Feel free to raise an issue in the WebdriverIO project if you see anything else from the Protractor ecosystem you want to see adopted. WebdriverIO as it is right now can already being used for any kind of Angular projects but with these additional initiatives we hope to help with the transition even further. Cheers!

Thanks @kyliau for news and plans share.
I would like to share my opinion and several points which could be critical and need to be revised.

First of all - yes, Control Flow should be removed and this is not thing that should live in 2021 and of course in future.
Million users around the world are using Protractor and rely on it. Why? Different reasons:

simple of usage within modern async/await
selenium-webdriver wrapper (selenium is w3c standard now)
own config and runner
waitForAngular hook
Protractor is own @Google and @Angular project, which adds more confidence (company with the great name)
Unfortunately not all users know about deprecation plan and still thinking that Protractor project maintained by Google (see above)

Migration will be simple for teams using E2E as part of its own web projects based on Angular (using under angular-cli). But, this will be a very huge pain for companies and teams, which have independent E2E infrastructure with Protractor as dependency.

By this concerns, users should be concentrated on migration to unknown 3d-party framework without any guarantee what will with it in future and not on test cases development and E2E coverage.
My propositions and options:

Deprecate legacy Protractor which have Control-Flow and notify users (according to current plan till the end of 2022);
Introduce some light version of selenium-webdriver wrapper which will have: Protractor API, runner, configuration to use Jasmine 3.X, default hook for Angular testing (waitForAngular) and, the main, modern selenium 4.0 which is fully w3c.
Here could be sub options:
2.1 Implement next gen light version of Protractor or pick-up Protractor 6 where control-flow was removed and it on selenium Most of work was done here, just refresh it and it will help users instead of deep investigation of external 3d frameworks, its documentation, transitions and more-more pains. IMO, this will require less time-investments.
2.2 Another new lib, like teased by Craig @cnishina, with the further support.
Actually, such lib will have very-very simple support since it will be fully rely on selenium-webdriver, its API and functionality. From your side need just support config+runner, waitForAngular and dependency upgrades from time to time.

We asking to re-thinking about initial plan and have compromise option.
Thank you in advance!

I think giving the choice on install is the best option.
It's great that Cypress has this success, but it might not be the best default choice for every team and project.
I can name a situation where it can be tricky : behind a corporate proxy ...
@MikaStark I think you can do exactly that, that's what we do when we enable Cypress.

Consider using CodeceptJS https://codecept.io as an alternative.
With it, you can easily switch between engines like WebDriver or Playwright. So one engine gets deprecated and a new one emerges you will need to write 0 code to transition.

Great to see the Cypress team is extending support for a smooth migration. Looking forward to having Cypress as default for E2E.

Hi,
This is Alex from the DevExpress TestCafe team. TestCafe supports many of the mentioned features out of the box:
[V] Safari support, including Safari mobile
[V] Cross-browser support (Chrome, FF, IE, Edge, etc.)
[V] Latest JavaScript/TypeScript Syntax Support
[V] Run parallel browser instances
[V] Robust and stable test cases
[V] Automatic awaiting mechanisms
and much more.
We'd love to chat and answer your questions if you have any. Feel free to contact us at<EMAIL_ADDRESS>

Playwright is owned by Microsoft, and they also own TypeScript. Consider this fact too please.

We migrated our e2e codebase (thousands of tests) from Protractor to Cypress over a year ago due to the uncertain status of Protractor, and have seen great improvements in productivity and reliability as a result. I am not affiliated with the Cypress team in any way, but strongly recommend it.
Thanks to the Protractor devs for all your hard work over the years, and thank you for making the state of the project clear so that the community can adapt.

It was good while it lasted! #goodbye 😎

Although a long video almost certainly isn’t the comment information density the Angular team is looking for, others might enjoy this hour+ discussion today among me and a couple other folks at Oasis Digital about Protractor, Cypress etc.
https://www.youtube.com/watch?v=tEdvyaTYPPY

Hey folks, 🖐✋,
This is Michael Mintz of the SeleniumBase project.
I'd like to start by thanking the entire Protractor/Angular community for all the hard work that they've put into creating Angular and making Protractor an amazing tool for web automation. It's never easy to sunset a project that one has spent countless time and effort on, but sometimes the benefits of moving on to bigger projects outweighs the costs of continual maintenance on a project in an uphill climb.
I'd like to offer an existing test automation alternative that offers an easy migration path from Protractor: SeleniumBase, a Python framework.
SeleniumBase has had active funding and support from companies such as HubSpot, Veracode, and iboss.
Some of you may have seen me before, as I've spoken at multiple meetups for companies such as Google (https://www.meetup.com/GDGCloudBoston/events/230839686/?showDescription=true), Microsoft (https://events.powercommunity.com/sessions/testing-web-and-mobile-apps-on-microsoft-edge-with-python-and-selenium/), The Ministry of Testing (https://www.meetup.com/ministry-of-testing-boston/events/275574548/), Boston Code Camp (https://www.bostoncodecamp.com/CC25/sessions/details/16352), Boston Python, Granite State Code Camp, the "Rapid Software Testing" community, and others. I also cohosted HubSpot's old marketing tech podcast 4 times while filling in for Mike Volpe. And of course you may already be familiar with my SeleniumBase work.
I took the time over lunch break today to demonstrate how easy it is to switch from Protractor to SeleniumBase. The SeleniumBase/examples/migration/protractor folder contains tests that have been migrated over from https://github.com/angular/protractor/tree/master/example , where the original file ends in .spec.js and the updated version ends in _test.py. Here's an example of a Protractor test, followed by the SeleniumBase version:
Original Protractor test (https://github.com/angular/protractor/blob/master/example/angular_material/mat_paginator_spec.js)
describe('angular-material paginator component page', () => {
  const EC = protractor.ExpectedConditions;

  beforeAll(async() => {
    await browser.get('https://material.angular.io/components/paginator/examples');
    await browser.wait(EC.elementToBeClickable($('.mat-button-wrapper>.mat-icon')), 5000);
  });
  it('Should navigate to next page', async() => {
    await $('button[aria-label=\'Next page\']').click();
    await expect($('.mat-paginator-range-label').getAttribute('innerText')).toEqual('11 - 20 of 100');
  });
  it('Should navigate to previous page', async() => {
    await $('button[aria-label=\'Previous page\']').click();
    await expect($('.mat-paginator-range-label').getAttribute('innerText')).toEqual('1 - 10 of 100');
  });
  it('Should change list length to 5 items per page', async() => {
    await $('mat-select>div').click();
    const fiveItemsOption = $$('mat-option>.mat-option-text').first();
    await fiveItemsOption.click();
    await expect($('.mat-paginator-range-label').getAttribute('innerText')).toEqual('1 - 5 of 100');
  });
});

Here's the above test converted to SeleniumBase (SeleniumBase/examples/migration/protractor/mat_paginator_test.py)
from seleniumbase import BaseCase

class AngularMaterialPaginatorTests(BaseCase):

    def test_pagination(self):
        self.open("https://material.angular.io/components/paginator/examples")
        self.assert_element(".mat-button-wrapper > .mat-icon")
        # Verify navigation to the next page
        self.click('button[aria-label="Next page"]')
        self.assert_text("11 – 20 of 100", ".mat-paginator-range-label")
        # Verify navigation to the previous page
        self.click('button[aria-label="Previous page"]')
        self.assert_text("1 – 10 of 100", ".mat-paginator-range-label")
        # Verify changed list length to 5 items per page
        self.click("mat-select > div")
        self.click("mat-option > .mat-option-text")
        self.assert_text("1 – 5 of 100", ".mat-paginator-range-label")

The end result is a clean, simple test that you can run in all web browsers: Chrome, Edge, Safari, Firefox, IE, and Opera. (SeleniumBase adds pytest command-line options for setting the browser and much more.)
If you have any questions, you know where to find me.

Just to add to the conversation. I work for a large company and we use Protractor to drive thousands of end to end tests. Of course, we have considered alternatives (Cypress, Test Cafe, and most promisingly Playwright).
Playwright is the only alternative that offers what we need. A free model (no hidden pay walls), ability to emulate different browsers (not just chromium), and easy to mix it in with Cucumber.js.
The main draw to Protractor for us though is it works great with tabs/frames (we have 'legacy' pains to deal with) as it is driven by webdriver protocol. Also, it has a very nice parallel execution configuration for sharding capabilities etc using the MultiCapability config model.
I really see no obvious alternative offering free model, parallel execution, webkit support, and also cucumber support.
The closest seems to be Playwright though and am surprised so many are opting to go the Cypress route when Playwright is most likely the superior alternative at this point.

As many teams will be evaluating different options to move away from protractor and migrate all those test cases, please check this option described below as well.
Typically e2e tests are built by developers and many frameworks are oriented towards developers (and automation test engineers) with programming background. While there are tools to extract and provide documentation that can be reviewed by anybody in team, contributing a test is still limited to those with programming background.
We attempted to make e2e tests (user journey tests / acceptance) accessible to anybody in the team, so anybody in team can also contribute to writing test cases without programming background, using Gauge and Taiko.  We have implemented most common steps/actions a typical user will use to interact with an application in a browser at https://github.com/softrams/gauge-taiko-steps. So with this combination, any team member now could write e2e user journey tests. Another side benefit is, with little effort we could switch the driver (currently Taiko) seamlessly if needed, without having to update any test cases.

Why does it have to be such a big toy as @cypress-io to write tests for the top of the test pyramid?
All this effort and artificial complication, as it also comes through Angular's world, will further reduce the trust in SPAs from management.

@Phonesis the only thing that isn't free about Cypress is the Dashboard and parallel execution, and both of those have open source alternatives. Multi-browser and iframe support are both built in, and there are plugins for using Cucumber etc.
Cypress can feel monolithic and heavy at first, but it's surprisingly flexible and easy to work with.

Reading comments and understanding something another.
No constructive pros/cons regarding tools, nor Protractor, nor alternatives (Cypress, etc). Just who chose what, who loves what and which tool is using now with.
I've already described pros above my post and could continue: API usability (extended from selenium), configuration, remote running, parallel execution, and more-more.
Could thousands of e2e run on different remote machines using cypress out of the box?
What about iframes, parallel runs, different browsers (not only chromium based)? Can't see this, only feature requests and plans in roadmap. So, community should rely on external tools and waiting for bicycles which are working now with Protractor.
Can I also rely to young Playwright which is from 2020? Maybe, but also a lot of uncertainty.
Well, unfortunately, RFC looks like an advertising of external tools, not more.
And I'm very not sure about percentage in use.
Just if looks downloads from npm:

Actually, Protractor has been deprecated a year ago when version 6.0 rolled back by uknown reasons. From this time we can't see any development on this project
We are all people and we understanding that in big opensource world it happens that there are not enough resources for development and support of tools which as result lead to deprecation. We understand this as main reason why Protractor is being deprecated and I'm not understanding people who refer to this project as garbage in twitter. There are a lot of time and resources spent for development, it working now and people using it. Very hard to realize that this work and time thrown away.
Special thanks to @Google and Julie (@juliemr), Craig (@cnishina), Mike (@heathkit) and all contributors for hard work and investment to Protractor.

Unfortunately this RFC is on course to become a soapbox for everyone to proclaim their favourite alternative to Protractor 😄
Aside from thanking the Protractor team for years of hard work which has directly led to thousands of more stable, reliable websites, my primary point would be to request that the CLI doesn't support or favour any one E2E library out of the box. That tight coupling to an unaffiliated project could lead to problems in future if the chosen project becomes stagnant. Clearly, there are many great tools out there that already work well with Angular, and as such I believe the Angular team should leave it to development teams to assess what best fits their need.

@Phonesis the only thing that isn't free about Cypress is the Dashboard and parallel execution, and both of those have open source alternatives (see e.g. https://github.com/sorry-cypress/sorry-cypress). Multi-browser and iframe support are both built in, and there are plugins for using Cucumber etc.
Cypress can feel monolithic and heavy at first, but it's surprisingly flexible and easy to work with. The community is very active and you will find a ton of plugins meeting different needs you may bump into.

Thanks for info but the fact you need an open source alternative to run in parallel is not really ideal solution for us - lots of considerations around security / nexus scans etc. There is only chromium support so it isn't really multi-browser either (although looks like Webkit on roadmap).

There is only chromium support so it isn't really multi-browser either

Firefox is supported as well, with more on the way. It's true that the range of supported browsers is not as broad as Selenium though.  https://docs.cypress.io/guides/guides/cross-browser-testing

While I'm happy to see a decision, it's kind of disappointing that angular is moving away from all batteries included approach. First linting, now e2e tests and I guess time will tell when same thing will happen for unit tests?
I understand that people have different needs, but I also believe that having certain defaults brings a lot of value. Could you consider having cli builders for cypress, playwright(others?) and provide an option for initial scaffolding for users to choose from? You are the trusted experts and could continue to steer the community towards best practices.

I'm approaching this from the perspective of Quality Control/Testing. I'm not a developer, but I do write the automated tests. We have thousands of Protractor tests that have already been converted to async/await. The best migration path that I see here is the option from FAQ#8, a thin wrapper with a compatible API. Ideally, we would be able to keep all of our tests and conf files mostly as-is, with minimal changes needed. The next best option is migration to straight selenium-webdriver; detailed guides for doing this conversion would be greatly appreciated if the then wrapper doesn't work out.
Providing resources for people who want to switch over to Cypress or some other framework is fine, but that seems to be more of a "complete rewrite" than a "migration".
Personally, I think the migration path to a thin wrapper or selenium-webdriver should be top priority (since these would be the easiest paths and actually rely on the same underlying technology). I think these things should be nailed down first, and then we can start the deprecation timer (a year or two after that work is complete), rather than starting the timer now and hoping that stuff will be completed in time for people to start planning and implementing their migrations.

Cypress is awesome. Cool to see that I wasn't wrong when I adopted it 3 years ago. 👍
I would like to see something included by default in Angular though, so I don't think deprecating Protractor without a replacement is the best plan. Maybe include Cypress by default then?

Hey folks, huge thanks to Julie (@juliemr), Craig (@cnishina), Mike (@heathkit), and all the people who have contributed to Protractor over the years. I really value your hard work ❤
@kyliau - From what I've seen in the industry and over the last 6-7 years working with Protractor, teams opting for Angular tend to do so because it makes building complex applications easier. However, complex applications typically mean complex workflows, and complex workflows mean complex tests (i.e fill in a 10-page long insurance claim form that changes depending on your answers, enter patient data into a healthcare system that only works in IE, etc.).
Additionally, software systems tested with Protractor, particularly in insurance, healthcare, finance, or banking industries, tend to be assembled from other, often legacy systems; so it's not just the nice Angular app our test needs to interact with, it's all the other "stuff" around it. This means that you'll often see iframes, multi-tab/window navigation, and an odd JavaScript alert every now and then. Not to mention that many of those auxiliary systems only work in IE (sadly, that still happens), and don't provide interfaces other than the UI to make them easier to test. While Protractor is not as shiny as some of the other alternatives, it's still perfectly capable of handling those scenarios.
The ability to run tests in parallel, integrate with test grids, and use the same framework for both web and mobile testing was another benefit of sticking with Protractor, and probably another reason why it's still downloaded so often.
It feels like the above points, as well as the fact that a complete re-write of a test suite is typically not given the highest priority for most delivery teams, FAQ#8 and a thin abstraction layer proposed in the comment by @cnishina look like the least disruptive way to migrate from Protractor to another, conceptually similar test framework (i.e. WebdriverIO).
A note to Serenity/JS users reading this thread - Serenity/JS will continue to support Protractor until at least the end of 2022, with support for other test runners like WebdriverIO and Playwright (and maybe even Cypress) coming soon.
We're also planning to make it easy for people to switch from one test runner to another if your tests follow the Screenplay Pattern, so watch this space and follow us on Twitter for updates 😃

@kyliau Would you mind to share the full results of the survey you conducted in January 2021?

In addition, we would like to say that regarding this and any similar topic need to dedicate at least 2 groups within any IT company who actually involved in E2E: directly developers who using e2e inside its angular projects (with angular-cli) and parallel teams (Automation QA) who building and supporting E2E infrastructure for testing angular and not only. The project provided by @jan-molak (Serenity-js) is a great example - automation QA engineers create and maintain e2e solutions which using Protractor as dependency.
Keen @kyliau, please, don't give up the Protractor in favor of Cypress or any other product. All these solutions do their job well and you understand it perfectly. If people have chosen Protractor and new people continuing to choose it - then it solves business needs.
Please consider this and provide ability to support and improve Protractor as independent E2E solution.
We will wonderful to see Protractor with new selenium 4.0 and without control flow. It will be very good choise to have it as next gen, as more light ver (developing by Craig).
Thank you in advance!

In addition, we would like to say that regarding this and any similar topic need to dedicate at least 2 groups within any IT company who actually involved in E2E: directly developers who using e2e inside its angular projects (with angular-cli) and parallel teams (Automation QA) who building and supporting E2E infrastructure for testing angular and not only. The project provided by @jan-molak (Serenity-js) is a great example - automation QA engineers create and maintain e2e solutions which using Protractor as dependency.
Keen @kyliau, please, don't give up the Protractor in favor of Cypress or any other product. All these solutions do their job well and you understand it perfectly. If people have chosen Protractor and new people continuing to choose it - then it solves business needs.
Please consider this and provide ability to support and improve Protractor as independent E2E solution.
We will wonderful to see Protractor with new selenium 4.0 and without control flow. It will be very good choise to have it as next gen, as more light ver (developing by Craig).
Thank you in advance!

Fully agreed. A new version of Protractor with just async/await support and Selenium 4 would be the ideal move.

In my opnion, the best migration path is the option from FAQ#8.
I am working for BMW and we have hundreds of developers working in internal projects using Angular and Protractor. Of course, we have some projects with other frameworks and tools (React, Jest, Cypress). Cypress is not an alternative, it works, but it is not the same. We are writing tests with Cucumber and we need to run these tests in different environments; multiple browser tabs open; in parallel; using sellenium grids; exporting the results to Jira, etc., etc. So, how can we use Cypress and migrate our tests? I can't find an alternative without losing resources.
Control flow is very old and used in AngularJs applications. I migrated old apps to async/await. Too easy. For large projects,I recommed creating two suites, because, it will take a long time. Deprecating Protractor, in my opinion, is too much. A new version with breaking changes will make everyone happy.

Angular team, would it be better if you get together with Microsoft (as you did for TypeScript) and come up with smooth migration from Protractor to Playwright? This way 1) it may be (I hope) a smooth migration and not too much trouble for you guys; 2) MS will still own Playwright and you communicate with each other as you do for TypeScript; 3) Angular devs and QA teams will get the best experience and long term support from two giants.
How about that?

@kyliau Thanks for the update , this is a really sad news as protractor when used as it is supposed to by disabling control flow and using await instead.
So we have some projects that is in maintenance mode and no other future test scripts are required , could we keep using protractor we need to migrate legacy projects also ?

Thank you for all the fish, Protractor team.
Please do not leave ng-cli without a built-in testing tool (when I use ng generate component I would love to still have some test files auto-generated).

I don't think market share is 64% for Cypress!

@ankushpoly13 according to Cypress it's probably 94%!))

Thank you to @kyliau and the Angular team for opening this topic up and requesting input. That we are all able to voice our support and list our concerns is such an important part of the community and I really appreciate the RFC. I'm also learning a lot reading the comments on this RFC about other frameworks. Such a great conversation!
I have the same concerns as a few others others have commented. I'm sad to see that e2e won't come ready to go out of the box. One of the things I like about Angular and what I found so helpful when I started is that Angular is opinionated and that a fully functioning app worked immediately. And as I became more experienced using Angular and learned more about the ecosystem, I liked that I could change my tooling to suit my needs.
Angular is still an opinionated framework and tries to encourage best practices from things like file structure, templated code via schematics, and enabling strict mode by default in v12. Shouldn't the encouraging of best practices continue with default e2e testing (and linting tools too)??

We are using both Cypress and Playwright and have found Playwright to be both easier to use and more robust.
Added benefits are amongst others ability to test Safari/webkit, less flaky tests and possibilities for conditional testing.
Can somebody else that is using both frameworks comment on the advantages they see in Cypress vs Playwright?
Are we missing something?

Do you mind sharing why you think Playwright is better than Cypress (specific reasons/examples)? Thanks!

I strongly recommend that the Angular team should leave everything that saves time to do better from others. Angular has other strengths and those are the ones that should be further developed and focused on. In this context I think that the Angular Component Team is working on the migration to MDC Web. This brings many advantages. You have more time for more important things. What I'm getting at is that the same is true for e2e testing. You should rely on technologies such as Cypress that have gained industry acceptance and basically build Angular tooling (Harnesses, etc) with the Cypress API.

@SerkanSipahi Yes, and we rely on Protractor which have gained industry acceptance since 2013, it solve business needs and we don't understand why we need to rewrite all code base to another framework.
We know that it was developed by @google and this was a main reason why we choose Protractor. We don't know who is the Cypress in the world (but we know who is Google and Angular), we investigated that it very limited for our needs.
And, also, within the same opinion could say like "khmm we evaluate that React (or something else) good, we will stop development on Angular and you can switch to React".

Can someone explain to me why is Cypress so supported when it's nothing more than overrated version of Selenium 1 (yes you read that correctly Selenium 1) but done in JS. When the community worked so hard to improve that and move away from it to things like DevTools protocol or WebDriver 3/4, why do we want to go back now to something that was horrible?
Please consider the following table before answering 🤔

PROs
CypressJS
CodeceptJS
Playwright
WebDriverIO

Quick & Easy to setup
Built by a large community of SDETs
Cross browser support
Very mature community

Fast to implement & debug
Supports multiple test libraries
Built and maintained by a large company (Microsoft)
WebDriver 7 is very fast

Relatively fast to execute simple tests
Single syntax
Full docker support
Full API testin support

Modern tool
Multiple reporters supported
Typescript focused out of the box
Large collections of plugins, examples and helpers

Considered a standard by FE developers
Active community and updates
Fast running
Very good documentation

Good for startups
Support for mobile web testing
Multi language support
Parallel run

Large community
Support for hybrid mobile testing
Bidirectional events
Easy debugging

API mocking support
Support for native mobile testing
Auto-waiting for elements
Full docker support

Adopted by a lot of large companies
Full docker support with multiple options
Stubbing and mocking through traffic capturing
Multiple reporters supported

Easy debugging
Supports iFrames
Multiple runners supported

Multiple debugging options made available
Supports multi-tabs
Supports multi-tabs

Parallel runs through multi-process
Supports BDD
Full support of iFrames

Parallel runs through Worker threads
Reporters support
Supports multi-session browser tests

Support for multiple browsers
Flakiness detection feature
Supports all browsers

Large number of plugins and helpers made available by the community
Supports multiple runners (Mocha Jasmin Jest)
Supports BDD

Full support for iFrames, multi tabs and multi browser sessions
Headless Browser with event-driven architecture
Has mobile support (Native, hybrid and web)

Easy setup for services like Browserstack/Saucelabs
Partial mobile support
Fully event driven

Full BDD support
Multi session support
Very stable and reliable

SMART features (Autowaiting and more)
Supports multi-page and third-party implementations
Many maintainers and very mature community

Easy to keep using the latest versions of packages
Doesn’t generate any files
Supports Shadow DOM

Can be built to become a distributable package
Parallelisation support
Supports interacting natively with Angular and React elements

Support Shadow DOM
Fully event driven
Extended support for DevTools Protocol

Database support

Front-end performance metrics gathering

Full API support (REST and GraphQL)

Continuously growing and improving with newer and newer features

Flakiness detection through ReportPortal.io

Can natively talk to Puppeteer instances if needed

Stubbing and mocking support

Easy debugging

Fully event driven

Multiple options for Visual testing

Multiple options for visual testing

Support for REST and GraphQL testing

Supports single syntax for all libraries supported (WebdriverIO, Playwright, TestCafe, Puppeteer, Protractor etc)

Multi DB engine support

Full integration with Browserstack/Saucelabs/ReportPortal/Selenoid

Easy syntax

Supports mocking and stubbing

CONs
CypressJS
CodeceptJS
Playwright
WebDriverIO

It has issues scaling up
Requires getting used to the syntax
Fairly new
Can be slow if not setup correctly

Features offered for free in other tools, either cost money with Cypress or demands you to build it yourself
Does have a learning curve
API is still evolving so things you learn now may change next version
Slow if WDIO version used is lower than v6

It has difficulties with uploads and downloads
It does require custom code if you want to have a helper allowing you to test kafka for instance
Small community for now
Does not have auto waits for elements

They are moving more and more features behind the subscription model
Not a framework but a wrapper
Does not support real devices but supports emulators
Retry mechanism needs to be built (however there are already a ton of examples of reliable stable mechanisms built by the community)

Limited support for iFrames
Supports only JS/TS
Has no support for IE11 or non-browser platforms

No support for multi-tabs
Mocha only as a runner
Documentations and community are not as good as the other framework yet.

Can not drive 2 browsers at the same time
Depending on library chosen and configuration tests can be slow (however they can also be very fast)

Does not provide support of IE or Safari

Parallel runs require a machine with significant amount of resources

Does not support any type of mobile interaction

No Shadow DOM support

Can’t navigate to a different domain URL

API testing is inefficient if needed because Cypress always runs a browser, while API testing does not require one

Developers need to find a lot of workarounds to issues the tooling has

Flakiness detection is a paid feature instead of being tied to reporting (like many other frameworks out there)

Supports only JS/TS

👋 everyone!
Here is Diego, a core member from the Selenium project. We'd like to thank the Protractor team and its contributors for their huge efforts over all these years 🤗 Protractor is one of the main reasons why the JS Selenium WebDriver bindings have been highly used during the last years.
To continue this amazing collaboration, we'd like to invite anyone who is interested to provide a solution like or similar to the one mentioned at FAQ#8 (@cnishina how can we support you?), to let us know how we can help at the Selenium project. Feel free to reach out to us through our Slack/IRC channel, we are here and there to help the community.

Reading through all the pros and cons of the different existing technologies, it seems that there is quite some variation in what the preferred technologies is for different teams.
Any technology choice will leave the people that have chosen a different technology disappointed that angular has not chosen their technology as the default one.
My question would be how feasible it is to give the choice to the end-user, similar (but I presume much more complex to pull off) as with the choice between css/scss/… when starting a new angular project.
IMO it would be ideal that angular facilitates the different e2e testing tools, without limiting to a specific one.
Probably this would necessitate some sort of collaboration between the angular team & some of the major tools.
Where angular provides some generic scaffolding that each tool/technology can build upon/integrate with.
This would then by default also future-proof the solution when new tools arise.
A similar concept would be useful for the whole jasmine/jest/… choice for unit testing.
Even without understanding specifics, I can imagine that this would probably be the most time-consuming and complex solution for the angular team; but it would probably also be the one that serves the community the most.
I have no clue of course about feasibility and/or budget considerations, just my 2 cents.
Whatever the choice; thank you for asking the community for their input about this subject.
It is enlightening to read the multiple viewpoints and opinions that have to be taken into account by the team.

@StanislavKharchenko
When it comes to that point, you can throw React in the garbage because they often release a new API which is supposed to be the new standard and declare the old one not good. Do you want to rewrite your React app every time? I don't understand the confusion about Protractor which is hardly or not at all supported anymore.

@LanderBeeuwsaert me and others have been saying this all along. Don't force developers to pick a framework, provide bindings for the most popular ones instead. Angular should have never tied itself to an e2e framework in the first place.

Angular should have never tied itself to an e2e framework in the first place.

 I'm thankful to them for this.
Phrases "I strongly recommend" and "you should never" look ridiculous from persons who are not even contributors to the Protractor code. Give some respect.

I agree that one of the biggest points of Angular is all-in-one package that just works. I mean starting from DI to material, to e2e testing. For me (and my clients) it means predictability and not wasting time looking around for some sh*t to make it work.
Angular team spent time collaborating with MS on TypeScript, they also provided VS Code extensions. I'm sure they can work with MS on Playwright or stay with Protractor.
But they should keep to the idea "all-in-one and it works" (c) :)

I don't think that having a default (whatever that default would be) and giving choices that can be easily switched to (for those who have different needs outside of that default); are mutually exclusive.
So I'm not sure the whole discussion about; "angular has to provide an all-in-one package" versus "angular needs to give developers the choice"; is even necessary.
If it would be easy to setup different/extra e2e tools; suppose that you could be able to set them up easily in parallel (we run cypress & playwright for example); it would possibly make the decision/migration/... around protractor also easier.
Giving teams that use protractor the option to code their new tests with a different tool while not having to lose their investment into protactor.
Not ideal maybe, but for a lot of teams probably better than a big migration-at-once approach.

"If it would be easy to setup different/extra e2e tools" is never easy ;) Mostly because you depend on something you don't really control.

Maybe. Any level of abstraction implies some loss of control.
Alternative is to write everything in assembler.

@e-oz wow, looking at your history you are somebody who should take his own advice. Not being a contributor does not bar anyone from commenting on design decisions, as you clearly know.

@GSasu the main driver of Cypress is usability. I can agree that the paywall is a problem, but gains in productivity are significant. It all depends on the problem you are trying to solve. We use Cypress for all our e2e needs (including live monitoring) and it works fantastic. It's not a perfect fit for everyone, but then again neither is WebdriverIO (which is also great.
I don't agree that Cypress is a regression in terms of architecture though. It's not trying to be Selenium or even fit all the same use cases.

@csvan I'm not saying people what they "should" or "should not" do. As I understand, Ng team is asking for your opinion here, not for the instructions.

Ng team is asking for your opinion here, not for the instructions.

It is my opinion. You reading it as an instruction is not my problem, especially when the context makes it obvious that was not the case.

@GSasu the main driver of Cypress is usability. I can agree that the paywall is a problem, but gains in productivity are significant. It all depends on the problem you are trying to solve. We use Cypress for all our e2e needs (including live monitoring) and it works fantastic. It's not a perfect fit for everyone, but then again neither is WebdriverIO (which is also great).
I don't agree that Cypress is a regression in terms of architecture though. It's not trying to be Selenium or even fit all the same use cases.

The main driver of a test framework should be stability, reliability, reusability extendability, feature maturity, documentation and documentation, not usability.... that's something only FE engineers care about in a test tool. SDETs other QA engineers are usually capable of make any test tool "usable". I am happy that you are having a great time with Cypress, there are exceptions to all rules.
You don't have to believe me or take my word on the architecture regression of Cypress (I'm not the holder of absolute truth nor the father of all knowledge), but take the steps I took and then come back with the feedback:

pull down/fork the cypress repo and go through it
next look through the deprecated documentation of Selenium 1 (not WebDriver) and compare Cypress feature with let's say Selenium IDE (And all it's add-ons)
tell me what's different in there other than the language?

If Cypress is so great, we might as well go back to Selenium IDE and accept being called "monkey testers" because all we do is "clicky clicky things" and we are not real engineers right?
If we are so sure of Cypress and we as a community start accepting paying for features that other tools offer for free than I'ld rather pay for a real tool like let's say Ranorex than Cypress. Just a thought 🤔

Maybe. Any level of abstraction implies some loss of control.
Alternative is to write everything in assembler.

Genius! Go on, the whole thread is listening...

@GSasu
Calm down, nobody (me included) is saying that Cypress is absolutely fantastic and the de-facto way to do e2e testing. It isn't. It is, however, extremely good at the niche of e2e testing that it is focused o, and it provides a lot of value for those needing that niche. Other tools do the same things in their respective areas, and everybody should pick whatever helps them deliver value and build sustainable solutions.
I haven't done the digging you have done regarding Cypress vs. Selenium architecture so I can't comment. Even if that is the case, it doesn't change the fact that Cypress is great at what it does, and that is what we need it for.

@csvan I was and still am very calm, don't know what made you think I wasn't 🤔 . The example with the "monkey testers" is because historically speaking that's how we were described as in the past with Selenium 1. SO to me, anything that wants to reproduce this is just plain old bad.
In terms of the "de-facto" you haven't said you, but I don't think you know how large is the amount of FE engineers that come in and tell SDETs that they want Cypress because that's the industry standard.
I don't and probably never will consider it a standard, it's far from it, but maybe we should all bold out the fact that it's not a standard maybe that way other FE engineers stop calling it that way.
I wish other tools receive the same marketing that Cypress receives, I'm sure at that point Cypress would drown in it's own pot.

@GSasu I absolutely don't consider Cypress a standard (or think it should be) so no disagreement there :)

I think from my perspective (Admittedly a weak one), of attempting to create a new JS framework from all the ones mentioned was that I came from a Ruby / scripting area (This was in a previous job, and I've since gone back to ruby).
What I found when using Cypress and what others may consider the "leading standard", was it was very easy to setup as a novice JS user. But it also didn't let me do the things I wanted to as an Engineer with several years experience. Perhaps this was misconfiguration on my part, but Cypress felt very good and easy if you did things the way they told you. For example just some 1liners that I found almost impossible in Cypress were things like

Store an element as a value (Not the text, but the web element itself). It wanted me to chain a function onto it.
Create a scripted like test where I stored value 1, then I got value 2, then I did this. It likes you writing in a very heavy JS way with 5 method chains.
Integrating with other plugins / trying to mix-n-match with things I like (I quite like the layout of cucumber, I like using external plugins like reporting e.t.c.)

Compare that to my brief experience with wd.io, which whilst it wasn't as nice to setup, and I couldn't get working as well, was permitting for me to to code things and store things the way I wanted. I think Angular sat somewhere inbetween the two when I trialled it.
So for me, given everyone is proclaiming pros and cons, I think the best thing angular can do is just link to every migration guide it gets, but steers 100% clear of saying this is the migration you should do. A few people have said this is good and a few have said this is bad. But when you trade on your name, when you leave your area, the name you pass on will be associated to you.

Go with cypress

Why not consider CodeceptJS? https://codecept.io/. It's a nice API with "I" syntax which supports any engines underneath:
Supported Engines out of the box:

WebdriverIO
Playwright
TestCafe
Nightmare

If anything changes in the future, just switch the engine underneath without rewriting any tests ❤
More advantages: Exclusive support for Shadow DOM elements for both WebdriverIO and Playwright. Just write a simple CSS locator without worrying about Shadow/WebComponent implementations
I.click('any-shadow-element') // runs agains Wedriver.io and Playwright

^^ We have implemented at Salesforce. For more info on ShadowDOM support, take a look at SaleforceEngineeringBlog

Hey everyone! Thank you so much for all your feedback. We will review the comments thoroughly, and post an update here once we decide the next steps. We truly appreciate all the inputs!


Given groups=1, weight of size 48 256 1 1, expected input[1, 128, 80, 80] to have 256 channels, but got 128 channels instead

Thank you for your code! I'm  training the model on my datasets using xception backbone , but got above problem. I noticed that the output of xception backbone has two part: 'x' and 'low_level_feat'  in your code . The low_level_feat has 128 channels, but decoder module expect 256 channels when backbone is xception specified by your code. Anyone else got the same problem?

You code is right,I make a mistake.


Added a document about Shared Preferences

Description 📜
I have added a documentation about the Shared Preferences plugin.
Fixes #1694

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Android Dev #(Flutter)

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

@thisisamank can you please review my PR?


Water and ions

At one point, we had separate FF files floating around for water (TIP3P) and ions. Currently, this does not seem to be the case (at least not in this repo) which means that someone applying our FF to a full system (e.g. a host-guest system for example) that is solvated will likely end up with flexible force field water and, I THINK, no parameters for their ions.
We should probably provide auxiliary libraries here for ions and TIP3P. (When we switch to another water model that should also be provided.)

(OTOH I think these are available in the openforcefield repo, e.g. tip3p.offxml is at least. Not seeing the ions offhand.)

What is OpenFF's relation to openmm-forcefields? To the best of my knowledge, SMIRNOFF/OFFTK has no particular advantages regarding the existing water/protein/ion models. So if we'd just end up maintaining the same parameters in different formats, we might officially endorse that package (and use it in examples) to avoid duplication of effort.
OFFTK has test_forcefields/tip3p.offxml file. But the OFFXMLs in that directory are explicitly not for use in production simulations, and the files inside (including tip3p.offxml) have been hand-modified several times. So, I think the first step on this issue is to define a process for

How do we decide that we want to add a new FF to openforcefields? (probably quorum among maintainers)
If another implementation of the parameters exists, what validation of the new file is required, and who reviews it? (this should become one of the duties of a SS or PI)
How are new FFs stored in the package hierarchy (do they go into the same folder as parsley? Do we attempt some other organization?)
How are new FFs versioned (do we make it tip3p-1.0.0.offxml, to let us keep up with bugfixes/spec changes?)

What is OpenFF's relation to openmmforcefields?

openmmforcefields is a stop-gap solution to delivering SMIRNOFF and GAFF force fields within the legacy OpenMM ForceField ecosystem. It is intended to be replaced wholly by the openforcefield toolkit in the future.

To the best of my knowledge, SMIRNOFF/OFFTK has no particular advantages regarding the existing water/protein/ion models. So if we'd just end up maintaining the same parameters in different formats, we might officially endorse that package (and use it in examples) to avoid duplication of effort.

We should not let the existence of the stop-gap openmmforcefields preclude us from continuing to develop the openforcefield toolkit as an independent approach to delivering a complete force field parameterization solution. In particular, we need to start integrating water and ions in SMIRNOFF format as a first step toward expanding SMIRNOFF to support biomolecules and biopolymers.
The openforcefields repo would be a sensible place to put these, but it's possible we want to reserve this for force fields we have generated ourselves, and hence may want a legacy-forcefields repo that will provide SMIRNOFF versions of legacy force fields.

OFFTK has test_forcefields/tip3p.offxml file. But the OFFXMLs in that directory are explicitly not for use in production simulations, and the files inside (including tip3p.offxml) have been hand-modified several times.

Agreed that we do not want to use test_forcefields/ for anything but testing.

How do we decide that we want to add a new FF to openforcefields? (probably quorum among maintainers)

For legacy force fields, we need a way to start integrating these now to achieve the aims of our NIH grant. We need not put them in openforcefields; they can go into a repository for legacy force field conversions.

If another implementation of the parameters exists, what validation of the new file is required, and who reviews it? (this should become one of the duties of a SS or PI)

This depends on the aims of the conversion, which might be to

test the scalability of the openforcefield toolkit to parameterize solvent, ions, biomolecules, and biopolymers
provide an independent route to delivering accurate legacy force fields w
make improvements to (or fix bugs within) legacy force fields

For now, additional fields in the .offxml file might be useful for indicating what level of validation has been carried out. We could even add a tag that issues a warning if we are only at level 1 (unvalidated energies) so the parameters should not be used for production.

How are new FFs stored in the package hierarchy (do they go into the same folder as parsley? Do we attempt some other organization?)

I would vote for something like legacy/tip3p-and-ions.offxml or legacy/unvalidated/tip3p.offxml or some explicit path that makes it clear (1) the parameters are not new parameter sets from OFF, and (2) whether or not the energies have been validated.

How are new FFs versioned (do we make it tip3p-1.0.0.offxml, to let us keep up with bugfixes/spec changes?)

Good question. Not sure about this one.


Install dev version of ispyb

To be able to better test Artemis in a dev environment we should install a local ispyb (see https://github.com/DiamondLightSource/ispyb-database)
Acceptance Criteria

Go through the install procedure as listed above
Get a local instance of Artemis talking to this
Document the process

This isn't required, you can use the dev instance by setting $ISPYB_CONFIG_PATH to point to /dls_sw/dasc/mariadb/credentials/ispyb-dev.cfg and a valid visit path in the config


IGNITE-20871 Fix stack trace in client exceptions

Fixed stack traces;
Added checks to existing tests to ensure we're getting proper stack traces.

In general, the proposed patch is OK.


[IconButton] Add missing color classes

This adds the error, info, success, and warning colors to the iconButtonClasses.ts file.
fixes #33615

Huh, looks like this still needs approval. Did something go wrong?


GCC 6.1.0 compile fixes

The <functional> include was causing compile problems on GCC 6.1.0 under NuttX, as it used the system's header. This patchset removes these includes.
I think eventually we can get rid of px4_nodehandle.h (which is responsible for including <functional>) completely, it seems to be legacy code (only used in platforms/ros and some examples).

Travis-ci failure is my fault, should be fixed on master.

I rebased but now CI is stuck. @dagar any advice how to solve it?

CI passed & merged


Pre-compile Pattern usages

Pre-compiles all of the Pattern uses (/ implicit Pattern uses inString.replaceAll)
with static final pre-compiled Pattern uses.

🚢


STS client doesn't not return Multivalued attributes based on "MultiAttributeSeparator" property in the user store configuration

Moved from https://wso2.org/jira/browse/IDENTITY-6681
sts-client uses AttributeCallbackHandler for token generation. Here mulitattibute-separator is hard-coded to ",,," , only if requested claim comes with MultiAttributeSeparator it get overridden. [1]
Since this is setup with resident IDP, unable to configure an advanced claim "MultiAttributeSeparator" to be default to ",".
Even after defining a cliam "MultiAttributeSeparator" and it is requested in the request, attribute separation only happens for SAML 1.1, not for 2.0. However, when invoking from travelocity client attributes are properly sent to the client with based on "MultiAttributeSeparator" property of the user store. hence, two clients behave differently.
We should consider "MultiAttributeSeparator" property of the user store configuration also here in this flow and should be applied to SAML 2.0 as well.
[1] https://github.com/wso2-extensions/identity-inbound-auth-openid/blob/v5.1.1/components/org.wso2.carbon.identity.provider/src/main/java/org/wso2/carbon/identity/provider/AttributeCallbackHandler.java#L346
[2] https://github.com/wso2-extensions/identity-inbound-auth-openid/blob/v5.1.1/components/org.wso2.carbon.identity.provider/src/main/java/org/wso2/carbon/identity/provider/AttributeCallbackHandler.java#L359
Thanks!

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


v3 core spec: purl urls as identifiers

Citing from @jbms's and @manzt's comments in https://github.com/zarr-developers/zarr-specs/pull/149#discussion_r929162112:

Currently zarr v3 uses a mixture of full URLs and short strings as identifiers. I can see that there are some advantages to using full URLs: rely on existing DNS registration mechanism so there is no need for a separate "name reservation" process, automatic linking to a corresponding explanatory document assuming that the URLs actually remain valid.
However, I think the long URLs would be cumbersome for a user to actually type manually, and even just looking at the metadata, it will be harder to read at a glance, since e.g. all of the codecs will start with the same long prefix, and just the part at the end is relevant. There are also surely a lot of cases where the user will want to specify something that is currently identified only by a URL, e.g. the codec to use, the metadata format to use, the grid to use, the storage transformer to use, etc.
In order to save users from having to type out full URLs to identify these things, implementations may be tempted to invent their own short identifiers as well, and it may be confusing if these identifiers conflict, and there will be the added complexity of having to relate the short identifiers to the full URLs.

It depends on the implementation, but my guess is that users often won't type these full URLs directly (moreover the implementation will likely fill in this metadata).

It would be nice not to have to define an alternative more concise representation of the zarr v3 metadata, as that would likely lead to added confusion.
More generally, users will need some way to specify everything that is in the metadata when creating a zarr repo/array, ideally in a concise way. If the zarr core spec or extension specs do not provide a concise representation, then each implementation may need to invent its own concise representation, which would be unfortunate.

The following questions seem to arise:

Do we want to keep the purl URLs as identifiers in the metadata?
If yes, should there be a common shorthand format for these?
Technical question: Who updates and maintains these URLs? cc @joshmoore @MSanKeys963 @alimanfoo

My proposal is to keep the purl URLs, and recommend a shorthand format for implementations (the actual metadata must have the full URL, but implementations might use the common shorthands in their API), e.g. https://purl.org/zarr/spec/codec/gzip/1.0 <-> codec/gzip/1.0, dropping the https://purl.org/zarr/ prefix for URLs that are hosted under this prefix.

During the last ZEP meeting it seemed like everybody would be fine with using short identifiers (e.g. simply gzip) for everything that part of the official zarr specs. If any external extensions are added, those should probably still use a URL, which also avoids naming conflicts.


Registered Passkeys not found

Is this suited for github?

[X] Yes, this is suited for github

To Reproduce

Create a project with the passkey plugin and database schema
Register a new passkey
Try to sign in with newly registered passkey

Current vs. Expected behavior
When trying to sign in with a passkey it should be found via the id (primary key) field. Currently these values are stored correctly, but the /passkey/verify-authentication does not correctly query the passkey.

^ credentialID field is returned as id in response (wrong)

What version of Better Auth are you using?
1.1.1
Provide environment information
/

Which area(s) are affected? (Select all that apply)
Backend, Client
Auth config (if applicable)
import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {
    enabled: true
  },
  plugins: [
    passkey({
      rpID: "localhost",
      rpName: "localhost",
      origin: "http://localhost:3000",
    }),
  ],
});

Additional context
I have tested that passkey registration and deletion work correctly using the primary key as id field.
The cause of the issue is https://github.com/better-auth/better-auth/blob/809f63f8e2851da44c773a666a4f87202125640a/packages/better-auth/src/plugins/passkey/index.ts#L641-L654
Follow up of: #865
Since the response body has a z.any() schema the issues became undetectable. The schema should be improved to match the correct response.
Possible quick fix: query credentialID from database adapter instead of id field (not recommended, because probably not indexed)
Recommended solution: Endpoint should return correct primary key field instead of credentialID as id so that the database query will resolve correctly.

We can only use credentialID because, initially, we can't know the user's passkey ID to authenticate


Clarify the imread docstring

@ParticularMiner has brought up the fact that the dask.array.image.imread function docstring is slightly misleading. This PR attempts to make the docstring more accurate (suggestions for better phrasing are welcome!)
Ref: https://github.com/dask/dask-image/issues/262#issuecomment-1125063820

I did not expect it in the first place since imread()'s docstring says that a "dask array of all images stacked along the first dimension" will be returned. Besides, the array had only one chunk, ...

[ ] Closes #xxxx
[ ] Tests passed
[x] Passes pre-commit run --all-files

Looks good to me too, @pavithraes !  👍

cc @jakirkham for general awareness


Need to update a few challenges' test texts to wrap certain values in code tags to prevent translation in other languages

Following up on the comment on PR 38309, the following English challenge tests need to be updated as described, as the non-English version were translating these when they should not have been translated.

Standardize Times with the HTML5 datetime Attribute
Issues: All tests need to be re-translated

Use the strong Tag to Make Text Bold
Issues:  "Stanford University" needs code tags so it is not translated.

Add a Submit Button to a Form
Issues: "Submit" needs code tags so it is not translated

Add Placeholder Text to a Text Field
Issues: "cat photo URL" needs code tags so it is not translated

Create an Ordered List
Issues: The first test text "Top 3 things cats hate:" needs code tags so it is not translated.  The same goes for the second test text "Things cats love:"

Headline with the h2 Element
Issues: The third test text "CatPhotoApp" needs code tags so it is not translated.

Inform with the Paragraph Element
Issues:  The second test text "Hello Paragraph" needs code tags so it is not translated.

Use the u Tag to Underline Text
Issues: The second test text "Ph.D. students" needs code tags so it is not translated.

I would like to work on this issue, please.

@RandellDawson  I have managed to fix all the issues, just need some clarification related to the first issue.
Standardize Times with the HTML5 datetime Attribute, When you say all tests need to be re-translated do you mean that the important text in each test e.g "Thursday, September 15th" in test 2 need to be wrapped in a code tag so they aren't translated?

@millwala53 I mean the Chinese version of this challenge was never updated with the changes made to the English version on June 28th, 2019.  This means the all of the text needs to be modified so that the parts in quotes are surrounded by code tags and the rest gets translated to Chinese.  Also, in the last test 2016-09-15 should be surrounded with code tags.

@millwala53 In the time I wrote my last comment @Sky020 created a PR to resolve this issue.


GetJob func

Currently you can only watch jobs. This method would allow users to just check the current status of a job.

Closing, duplicate of #594


Mobile sign-in via Anchor creates unnecessary re-directs/tabs

Description
Logging in via Anchor on mobile creates a new tab containing 'Open Anchor' button. On click redirects back to the login page instead of the app, creating inconsistent transaction and login behavior.
Desired Solution
If a new tab is opened, on successful login it returns to the wallet app logged-in (instead of the login page)

@donnyquixotic I'm currently unable to reproduce this. Could you confirm?


Dev: Deploy to api fails

Run sudo phive --no-progress install --global --trust-gpg-keys 67F861C3D889C656 phpDocumentor
Phive 0.15.2 - Copyright (C) 2015-2023 by Arne Blankerts, Sebastian Heuer and Contributors
Fetching repository list
Downloading https://phar.io/data/repositories.xml
Downloading https://api.github.com/repos/phpdocumentor/phpdocumentor2/releases?per_page=100
Downloading https://github.com/phpDocumentor/phpDocumentor/releases/download/v3.4.0-rc.2/phpDocumentor.phar
Downloading https://github.com/phpDocumentor/phpDocumentor/releases/download/v3.4.0-rc.2/phpDocumentor.phar.asc
Downloading key 8AC0BAA79732DD42
Trying to connect to keys.openpgp.org (<IP_ADDRESS>)
Downloading https://keys.openpgp.org/pks/lookup?op=get&options=mr&search=0x8AC0BAA79732DD42
Successfully downloaded key.
Error:    Needs tty to be able to confirm

	Fingerprint: F33A 0AF6 9AF7 A8B1 5017 DB52 6DA3 ACC4 991F FAE5

	phpDocumentor<EMAIL_ADDRESS>
	Created: 2019-07-26

Import this key? [y|N]
Error: Process completed with exit code 4.

https://github.com/codeigniter4/CodeIgniter4/actions/runs/5862385088/job/15894581166

#7832 and #7833 failed.


Deprecate HTTP download dependencies

This work was originally reverted due to performance regressions.
Contributor Checklist

[ ] Review Contribution Guidelines
[ ] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[ ] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[ ] Provide unit tests (under <subproject>/src/test) to verify logic
[ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:check

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

@big-guy Can you provide insights into the performance failures? I'm having a hard time reading the output in any meaningful way. For example, the worker performance tests failed, and I didn't touch any of that code (as far as I'm aware).


.xaml files are not copied, PRI file not generated correctly when creating NuGet from class library

When you create a WinUI / .NET5 class library, the build output consists of a dll file and of one .xaml/.xbf file for each user control in that class library.
If GeneratePackageOnBuild is set to true, a NuGet is created from the class library. The NuGet file does not contain the .xaml files. Each NuGet has to be manually edited to contain the necessary .xaml files in the right folder structure. Also, the PRI file is not generated.
If that NuGet is installed in a WinUI / .NET 5 project, the .xaml files are not built into the resulting app package, so they are missing. During runtime of the app, an exception is thrown "Cannot locate resource from 'ms-appx:///ClassLibrary1/Views/CustomerView.xaml".
If the .xbf files are copied to the appx folder manually, the app works, showing the right UI, without throwing an exception.
If the nuget is manually prepared with the .xaml files and makepri is executed, and the resulting PRI file is also included in the Nuget, the app works, showing the right UI, without throwing an exception
Steps to reproduce the bug

Create .NET 5 / WinUI project with at least one user control, generate NuGet
Install the generated NuGet package to a .NET 5 / WinUI app project
Add the user control from step 1. to the app project from step 2.
Start the app, navigate to where the user control should be showing
Witness the Exception

Expected behavior
Instead of the error, the UI should be showing
Version Info

NuGet package version:
Most recent 0.8

Windows app type:
Happened on .NET 5 / WinUI 0.8

UWP
Win32

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

October 2020 Update (19042)
Yes

May 2020 Update (19041)

November 2019 Update (18363)

May 2019 Update (18362)

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Xbox

Surface Hub

IoT

Additional context

The .xbf file exposes the structure of the class. Why do I need such files and how can I properly avoid generating them?

Are you running in Debug or Release?  Release mode should have everything packaged into the pri file. But if your in debug mode it might expect them to be packaged into the nuget package.

@StephenLPeters
I built as Release with msbuild command line /p:Configuration=Release /t:clean,build,pack
The described behavior happens when ProjectReunion is imported as transitive NuGet reference... If it is directly imported in the project, it works fine

@alwu-msft do we perhaps have a bug with indirectly imported references?

The .pri not being generated when GeneratePackageOnBuild is set to true makes this sound like an MRT Core bug. @rohanp-msft does this ring any bells?

Here is a repro,
Project A: NugetPackagingRepro has a UserControl1.xaml, and a project reference to Project B
Project B: Has nothing but a package reference to Project Reunion 0.8.1
when running msbuild /p:Configuration=Release /t:clean,build,pack two nuget packages are created
NuGet for Project A: Xaml files included, but no PRI file
NuGet for Project B: PRI file included
NugetPackagingRepro.zip

Looking at this, will update soon.

Hi @edoust ,
The WinUI class library template installs three Project Reunion packages:

Your class library project was missing all three of these packages. I installed them and rebuilt.
Now, I see the PRI:
S:\temp\NugetPackagingRepro\NugetPackagingRepro\bin\Debug\net5.0-windows10.0.19041.0\NugetPackagingRepro.pri
The PRI does contain the XBF:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PriInfo>
	<ResourceMap name="NugetPackagingRepro" version="1.0" primary="true">
		<Qualifiers/>
		<ResourceMapSubtree name="Files">
			<ResourceMapSubtree name="NugetPackagingRepro">
				<NamedResource name="UserControl1.xbf" uri="ms-resource://NugetPackagingRepro/Files/NugetPackagingRepro/UserControl1.xbf">
					<Candidate type="Path">
						<Value>NugetPackagingRepro\UserControl1.xbf</Value>
					</Candidate>
				</NamedResource>
			</ResourceMapSubtree>
		</ResourceMapSubtree>
	</ResourceMap>
</PriInfo>

PRI generation certainly requires the Foundation package.
If I right-click on the class lib project and click on Pack, here's the resulting nupkg:

I hope that addresses your problem. If it doesn't, feel free to reach back out to us :)

Hi @edoust, can we close this issue now?

Hi @rohanp-msft , thanks for the detailed reply, this issue is solved for me.
But in general I think it would be nice if build & packaging would also work correctly if the references to ProjectReunion comes from an imported nuget or a direct project reference rather than from the project that is built (or as an alternative, a build warning / error would be helpful for tracking down the issue)

Hi @rohanp-msft , thanks for the detailed reply, this issue is solved for me.
But in general I think it would be nice if build & packaging would also work correctly if the references to ProjectReunion comes from an imported nuget or a direct project reference rather than from the project that is built (or as an alternative, a build warning / error would be helpful for tracking down the issue)

Will pass the feedback along to our PMs. Thanks.

Thanks for this feedback @edoust, agreed! We've captured your feedback with a new issue in the Windows App SDK here: https://github.com/microsoft/WindowsAppSDK/issues/1111


Azure CLI is using AAD Graph, which is being deprecated soon

This library is using the AAD Graph API ( graph.windows.net ) and that service is scheduled for deprecation in June of this year.  Consequently, users cannot add permissions for the AAD Graph api anymore.  Is there any plan to update the CLI to use the Microsoft Graph API instead?  https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-faq#:~:text=For this reason%2C Azure AD Graph has been,to Microsoft Graph to avoid loss of functionality.

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

ID: ed09ee6c-d023-f470-a976-03536112d556
Version Independent ID: e14c213e-70d4-f6d7-c19b-7fab474b102b
Content: Differences between Azure CLI products
Content Source: docs-ref-conceptual/cli-versioning-identifiers.md
Service: azure-cli
GitHub Login: @dbradish-microsoft
Microsoft Alias: dbradish

Thanks for bringing this to our attention. We will investigate it further and update you shortly.

Hi @RayGHeld,
Great question and thanks for reaching out. The CLI team is currently working on updating the CLI to use MS Graph. You can see the full timeline in this blog post, but the expected timeline is to have a MS Graph using CLI by the end of March.
Feel free to respond here if you have any more questions but I believe we can close this issue. :)

@chasewilson  - Thank you for providing your insights.
@RayGHeld  - I hope @chasewilson has answered your question.
We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Inaccurate SD Card maximum file writing times

In the OpenBCI GUI you can select the SD file sized based on the expected duration of the trail.
It would appear that these sizes are based off a 8 channel data writing rates at 250Hz.  With 16 channels at 1kHz a 1-Hour file is filled in 7.5 minutes.
We need to update the file size based on the sample rate and the board type settings.
I can tackle this if required.
A simple way to implement this would be in the code that allocates the SD space by simply multiplying the number of blocks defined (see below) by 2 for 16-Channel board and 2 or 4 for 500 or 1000Hz sample rate.
#define BLOCK_5MIN  11000
#define BLOCK_15MIN  33000
#define BLOCK_30MIN  66000
#define BLOCK_1HR  131000
#define BLOCK_2HR  261000
#define BLOCK_4HR  521000
#define BLOCK_12HR  1561000
#define BLOCK_24HR  3122000

we should do this programatically but i 100% agree this needs to be done!

I tried to double the BLOCK_24HR to get 24hr 16ch recordings, but then OpenBCI often fails to initialize through the GUI.  Is it necessary to pre-allocate space?  It would be ideal if it can just keep writing until the memory card is full.

@aghariba it looks to me as if the limitation is on the SD library the code uses.  I do not have any background to this, but I know that it is a good strategy in cases like these where we have something like a microcontroller trying to run a file operating system.   I see there are newer SD arduino libraries available, that do not have this limitation, but I do not know how well they perform.
For now, I propose that we make the small changes and @aj-ptw can evaluate whether it is worth rewriting this functionality.
I will give a shot at making some changes and submitting a pull request

@gerrievanzyl I think this is a great idea!!

closed by #102


In any case, there has to be some amount of overhead. I assume you weren't expecting Hint to be as fast as compiled code.

Is that time including Hint loading the modules, or just running them?

Just running them. Could you please look at the code at https://github.com/vacationlabs/hint-test/blob/abcc43dd0199356494ef9881be2fcea85d216584/app/Main.hs#L15-L48 to confirm that module loading is not being included in the benchmark times?

In any case, there has to be some amount of overhead. I assume you weren't expecting Hint to be as fast as compiled code.

Actually, I was expecting that module loading/compilation may take some time, but after that it would run at the same speed. Why is this slower than normally compiled code?

hint does not compile the code, it interprets it, just like ghci. You can, however, compile a module and load it from hint/ghci. See my experimentations on the subject.

Summary: you have to install the package to a package database, calling ghc on your source file is not sufficient for hint/ghci to use the compiled version.

@gelisam that's quite a thread you have there! Did you figure out a way to trigger actual compilation instead of interpretation? Is it somehow related to https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/ghci-obj.html ?

Summary: you have to install the package to a package database, calling ghc on your source file is not sufficient for hint/ghci to use the compiled version.

So, assuming that I compile the .hs file to a .o and .hi file, what magic incantation do I need to give hint so that it uses the .o/.hi files?

I did not know about -fobject-code, thanks!

I did not know about -fobject-code, thanks!

Is it possible for hint to use -fobject-code somehow?

Maybe with unsafeRunInterpreterWithArgs?

Maybe with unsafeRunInterpreterWithArgs?

Erroring out with:
Error while running the interpreter: GhcException "Cannot add module M512196972046601278612963 to context: not interpreted"

what magic incantation do I need to give hint so that it uses the .o/.hi files?

To quote myself from that thread: you need a .dylib file, not a .o!
I believe the trick is to install your code to a package database using cabal install, to point hint to it using something like unsafeRunInterpreterWithArgs ["-package-db ./.cabal-sandox/x86_64-osx-ghc-8.0.2-packages.conf.d"], and then to import your compiled code using setImports or setImportsQ. The code you load using loadModules will always be interpreted (except perhaps using -fobject-code, which I haven't tried yet), so it must be a small shim which calls the compiled code from the package you've just installed.
At least, that's what I can conclude from reading my own thread; it's been a while, I don't remember all the details...

I believe the trick is to install your code to a package database using cabal install

Did you create a separate local package for your plugin/HS file, or did you compile a standalone file using -dynamic -fPIC -shared and then copy it to the correct place manually?

I used cabal install, but obviously cabal is using ghc and ghc-pkg under the hood, so you could run cabal verbosely to see what it does, figure out what is the minimal set of commands necessary for what you need, and only run those. I don't know if the particular set of flags you gave would be sufficient, but at the minimum you would also need to update the package database to register your new package. Hmm, unless you were overwriting a file from an existing package...

It seems to me like there's nothing to fix or add in hint, so I'm closing this issue for now. If I'm wrong, or if this situation changes in the future, feel free to reopen this issue or create a new one. Thanks!


OAuth2 credential support for Azure OpenAI using azure-identity

Validations

[ ] I believe this is a way to improve. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that requests the same enhancement

Problem
As of now, the only supported way to authenticate to an Azure OpenAI endpoint in Continue is by using an API key.  This works well for OpenAI where each user has its own API key, but in Azure, we are limited to 2 keys per endpoint.  We have to share those keys with pretty much everyone in the organization and it is impossible to audit users since API key are not bound to user identities.  A much better way to audit and control access to the Azure OpenAI endpoint is to authenticate the user using one of the many ways supported by Azure.  It would be nice if we could configure Continue to use something else than API keys to access an Azure OpenAI endpoint.
Solution
Azure supports a few ways to authenticate a user, an application or a principal.  Fortunately, Azure provides a convenient Javacript library named azure-identity.  Using this, we can request an OAuth2 access token that we can use as a Bearer token when accessing the OpenAI endpoint.  In other words, this access token becomes your temporary, personal API key.
Via DefaultAzureCredential, Microsoft provides a chain of TokenCredential classes that you can use to easily find an authentication method that is suitable to you.  Under the hood, this class is configured to try a few predefined Credential classes until one works, but it is possible to bypass this method and use a specific Credential instance, or even provide your own.
I was able to make it work using DefaultAzureCredential, but I would need some guidance on how to make it fit nicely in the current codebase.  For my use-case, I would also need to be able to provide my own implementation of TokenCredential since we have a custom requirement for user-impersonation using an external vault.  The details of this is irrelevant to this issue, beside the fact that I'll need a way to provide my own custom implementation.
Does this ask seem reasonable, and inline with Continue's authentication philosophy?

@cccs-eric has there been any progress to support this enhancement? I'm interested in implementing something similar, what has worked for you in the meantime?

Not that I know of.  We have been using shared keys for the tiem being, which is not ideal.  😞


Machine Timer

in 3.2.1 Machine Timer Registers (mtime and mtimecmp)

A machine timer interrupt becomes pending whenever mtime contains a value greater than or equal to mtimecmp, treating the
values as unsigned integers. The interrupt remains posted until mtimecmp becomes greater than
mtime (typically as a result of writing mtimecmp).

Does it mean

a single Interrupt is posted anytime  mtime>= mtimecmp
Interrupts are posted "pressed on" IF mtime>= mtimecmp

Thoughts:
1st case acts as a trigger and is normal behavior of a timer
2nd case is dummy comparison, there's no way to disable interrupt when it's on

Interrupts are disabled as soon as the timer interrupt is taken (because that sets mstatus.mie=0). The handler will write to mtimecmp to reset the timer (and clear the interrupt) before returning.


Bug: lidarlite accuracy report broken

there are reports that the accuracy value report on the lidarlite version !=v3 is not working and giving strange values. To be investigated further.
Apparently it js working on v3, on previous versions and v3 hp it is not
Daniele knows more details

There seems to be an issue in the lidar lite driver when running it for the latest Lidar Lite V3HP. Apparently the following register doesn't exist anymore in the HP version:
#define LL40LS_PEAK_STRENGTH_REG  0x0c
This causes the signal quality calculation in the collect() method to fail and the effect is that we always publish a signal_quality=0. I would like to simplify the calculation just for the HP sensor but I was not able to find a way to distinguish a normal V3 from V3HP since also the HW version register doesn't seem to exist anymore on this new sensor.
#define LL40LS_HW_VERSION         0x41
I guess I will just add a parameter to choose between older lidar lites (including v3) and the V3 HP and simplify the quality check just for the V3HP.

Sure. I checked all the registers on the lidar lite and there is not id or hw/sw version register. We can have a look today and find a better solution than adding a parameter.

I think @mcsauder has fixed this.