Improve logging when network fails, but there's a cache hit

Welcome! Please use this template for reporting bugs or requesting features. For questions about using Workbox, the best place to ask is Stack Overflow, tagged with [workbox]: https://stackoverflow.com/questions/ask?tags=workbox
Library Affected: workbox
workbox-sw, workbox-build, etc.
Browser & Platform: Google Chrome 89
E.g. Google Chrome v51.0.1 for Android, or "all browsers".
Issue or Feature Request Description: Uncaught (in promise) TypeError: Failed to fetch
My start_url is set to /?utm_source=web_app_manifest&utm_medium=web_app_manifest&utm_campaign=web_app_manifest
When reporting bugs, please include relevant JavaScript Console logs and links to public URLs at which the issue could be reproduced.

It also errors when deployed on a https url
My config looks like this:
import { skipWaiting, clientsClaim } from "workbox-core"
import {
  cleanupOutdatedCaches,
  precacheAndRoute,
  matchPrecache,
} from "workbox-precaching"
import { setCatchHandler } from "workbox-routing"
import { registerRoute } from "workbox-routing"
import {
  NetworkFirst,
  StaleWhileRevalidate,
  CacheFirst,
} from "workbox-strategies"
import { CacheableResponsePlugin } from "workbox-cacheable-response"
import { ExpirationPlugin } from "workbox-expiration"
import * as googleAnalytics from "workbox-google-analytics"

googleAnalytics.initialize()

cleanupOutdatedCaches()
precacheAndRoute(self.__WB_MANIFEST)
clientsClaim()

function cacheKeyWillBeUsed({ request }) {
  const url = new URL(request.url)
  url.pathname = url.pathname.replace(/\/index\.html$/, "/")
  url.pathname = url.pathname.replace(/\.html$/, "/")
  return url.href
}

const networkFirstStrategy = new NetworkFirst({
  cacheName: "docs-cache",
  fetchOptions: {
    credentials: "include",
  },
  plugins: [{ cacheKeyWillBeUsed }],
})

// Cache page navigations (html) with a Network First strategy
registerRoute(
  // Check to see if the request is a navigation to a new page
  ({ request }) => request.mode === 'navigate',
  // Use a Network First caching strategy
  new NetworkFirst({
    // Put all cached files in a cache named 'pages'
    cacheName: 'pages',
    plugins: [
      // Ensure that only requests that result in a 200 status are cached
      new CacheableResponsePlugin({
        statuses: [200],
      }),
      cacheKeyWillBeUsed
    ],
  }),
);

// Cache CSS, JS, and Web Worker requests with a Stale While Revalidate strategy
registerRoute(
  // Check to see if the request's destination is style for stylesheets, script for JavaScript, or worker for web worker
  ({ request }) =>
    request.destination === 'style' ||
    request.destination === 'script' ||
    request.destination === 'worker',
  // Use a Stale While Revalidate caching strategy
  new StaleWhileRevalidate({
    // Put all cached files in a cache named 'assets'
    cacheName: 'assets',
    plugins: [
      // Ensure that only requests that result in a 200 status are cached
      new CacheableResponsePlugin({
        statuses: [200],
      }),
    ],
  }),
);

registerRoute(
  /\.(?:png|jpg|jpeg|svg|gif|ico|mp4)$/,
  // Use the cache if it's available.
  new CacheFirst({
    cacheName: "image-cache",
    fetchOptions: {
      credentials: "include",
    },
    plugins: [
      new ExpirationPlugin({
        // Cache only 50 images.
        maxEntries: 50,
        // Cache for a maximum of a day.
        maxAgeSeconds: 24 * 60 * 60,
      }),
    ],
  })
)

// Cache the Google Fonts stylesheets with a stale-while-revalidate strategy.
registerRoute(
  ({ url }) => url.origin === "https://fonts.googleapis.com",
  new StaleWhileRevalidate({
    cacheName: "google-fonts-stylesheets",
  })
)

// Cache the underlying font files with a cache-first strategy for 1 year.
registerRoute(
  ({ url }) => url.origin === "https://fonts.gstatic.com",
  new CacheFirst({
    cacheName: "google-fonts-webfonts",
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
      new ExpirationPlugin({
        maxAgeSeconds: 60 * 60 * 24 * 365,
        maxEntries: 30,
      }),
    ],
  })
)

// Catch routing errors, like if the user is offline
setCatchHandler(async ({ event }) => {
  // Return the precached offline page if a document is being requested
  if (event.request.destination === "document") {
    return matchPrecache("/offline.html")
  }

  return Response.error()
})

addEventListener("message", (event) => {
  if (event.data && event.data.type === "SKIP_WAITING") {
    skipWaiting()
  }
})

Apologies, but I need a bit more information to determine how to help.
Are you posting this because you don't expect there to be a request automatically made for your start_url, and you're curious as to why it's being logged in the Network panel? If so, it's probably due to https://developer.chrome.com/blog/improved-pwa-offline-detection/

I'm curious as to why it shows up as an error, yes.

So that's why the request is being made in the first place. In terms of why the request results in an error, are you precaching your /index.html or / URL? If not, and you're just relying on that request.mode === 'navigate' route, I'm assuming the reason it fails is because the /?utm_source=web_app_manifest&utm_medium=web_app_manifest&utm_campaign=web_app_manifest isn't in the cache at the time it's tested.
/ will be added to the cache during subsequent visits, by virtue of that runtime caching route, but it won't be added with all of those query parameters. So you should either add matchOptions: {ignoreQuery: true} to your strategy to tell the Cache Storage API to ignore those parameters when performing a match, or alternatively, modify the cacheKeyWillBeUsed plugin you're already using in that strategy to drop the query parameters.
If you were precaching / or /index.html, then I would expect that initial offline check to pass, since the precache routing logic ignores utm_.* parameters when looking for matches by default.

I am indeed not precaching / or /index.html, would you say that adding that is the better path here or rather the matchOptions version?

It depends! If you precache /index.html, it will be served with a cache-first strategy and won't be updated until the service worker lifecycle allows the latest service worker to take over. If your priority is showing a fresh /index.html each time a user returns your web app, then it won't be a good idea to precache it.
Using the new warmStrategyCache() method in workbox-recipes would be an easy way to ensure that /index.html is cached during service worker installation, without relying on precaching. And then at that point, you can either use cacheKeyWillBeUsed or matchOptions: {ignoreQuery: true} to handle the URL query parameters—since you already have a cacheKeyWillBeUsed that's doing some manipulation, it's probably cleaner to just do that.
Putting it all together, and leaving out the bits not related to the navigations:
import {warmStrategyCache} from 'workbox-recipes';
import {NetworkFirst} from 'workbox-strategies';
import {registerRoute} from 'workbox-routing';
import {CacheableResponsePlugin} from 'workbox-cacheable-response';

function cacheKeyWillBeUsed({request}) {
  const url = new URL(request.url);
  url.pathname = url.pathname.replace(/\/index\.html$/, "/");
  url.pathname = url.pathname.replace(/\.html$/, "/");
  // Clear out all search params.
  url.search = '';
  return url.href;
}

const navigationStrategy = new NetworkFirst({
  cacheName: 'pages',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [200],
    }),
    cacheKeyWillBeUsed,
  ],
});

registerRoute(
  ({request}) => request.mode === 'navigate',
  navigationStrategy
);

warmStrategyCache({
  urls: ['/'],
  strategy: navigationStrategy,
});

Oh awesome, thank you!

@jeffposnick So I tried that, full code here:
import { warmStrategyCache } from "workbox-recipes"
import { skipWaiting, clientsClaim } from "workbox-core"
import { cleanupOutdatedCaches, precacheAndRoute, matchPrecache } from "workbox-precaching"
import { registerRoute, setCatchHandler } from "workbox-routing"
import { NetworkFirst, StaleWhileRevalidate, CacheFirst } from "workbox-strategies"
import { CacheableResponsePlugin } from "workbox-cacheable-response"
import { ExpirationPlugin } from "workbox-expiration"
import * as googleAnalytics from "workbox-google-analytics"

googleAnalytics.initialize()

cleanupOutdatedCaches()
precacheAndRoute(self.__WB_MANIFEST)
clientsClaim()

function cacheKeyWillBeUsed({ request }) {
  const url = new URL(request.url)
  url.pathname = url.pathname.replace(/\/index\.html$/, "/")
  url.pathname = url.pathname.replace(/\.html$/, "/")
  // Clear out all search params.
  url.search = ''
  return url.href
}

const navigationStrategy = new NetworkFirst({
  cacheName: 'pages',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [200],
    }),
    cacheKeyWillBeUsed,
  ],
});

registerRoute(
  ({ request }) => request.mode === 'navigate',
  navigationStrategy
);

warmStrategyCache({
  urls: ['/'],
  strategy: navigationStrategy,
});

// Cache CSS, JS, and Web Worker requests with a Stale While Revalidate strategy
registerRoute(
  // Check to see if the request's destination is style for stylesheets, script for JavaScript, or worker for web worker
  ({ request }) =>
    request.destination === 'style' ||
    request.destination === 'script' ||
    request.destination === 'worker',
  // Use a Stale While Revalidate caching strategy
  new StaleWhileRevalidate({
    // Put all cached files in a cache named 'assets'
    cacheName: 'assets',
    plugins: [
      // Ensure that only requests that result in a 200 status are cached
      new CacheableResponsePlugin({
        statuses: [200],
      }),
    ],
  }),
);

registerRoute(
  /\.(?:png|jpg|jpeg|svg|gif|ico|mp4)$/,
  // Use the cache if it's available.
  new CacheFirst({
    cacheName: "image-cache",
    fetchOptions: {
      credentials: "include",
    },
    plugins: [
      new ExpirationPlugin({
        // Cache only 50 images.
        maxEntries: 50,
        // Cache for a maximum of a day.
        maxAgeSeconds: 24 * 60 * 60,
      }),
    ],
  })
)

// Cache the Google Fonts stylesheets with a stale-while-revalidate strategy.
registerRoute(
  ({ url }) => url.origin === "https://fonts.googleapis.com",
  new StaleWhileRevalidate({
    cacheName: "google-fonts-stylesheets",
  })
)

// Cache the underlying font files with a cache-first strategy for 1 year.
registerRoute(
  ({ url }) => url.origin === "https://fonts.gstatic.com",
  new CacheFirst({
    cacheName: "google-fonts-webfonts",
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
      new ExpirationPlugin({
        maxAgeSeconds: 60 * 60 * 24 * 365,
        maxEntries: 30,
      }),
    ],
  })
)

// Catch routing errors, like if the user is offline
setCatchHandler(async ({ event }) => {
  // Return the precached offline page if a document is being requested
  if (event.request.destination === "document") {
    return matchPrecache("/offline.html")
  }

  return Response.error()
})

addEventListener("message", (event) => {
  if (event.data && event.data.type === "SKIP_WAITING") {
    skipWaiting()
  }
})

But this would still cause the fetch failure, even after clearing all data and installing fresh.
fetch("http://<IP_ADDRESS>:8000/?utm_source=web_app_manifest&utm_medium=web_app_manifest&utm_campaign=web_app_manifest", {
  "referrer": "",
  "referrerPolicy": "unsafe-url",
  "body": null,
  "method": "GET",
  "mode": "cors",
  "credentials": "omit"
});

Hmm... do you happen to have this deployed to a public URL at which I could check it out live? Feel free to DM @jeffposnick on Twitter if you can't share it in a public issue.

Yes, I can! This is currently deployed on https://development.docs.coregames.com/

This took a while to figure out until I tried it out in a TypeScript project, at which point it identified the following mistake:
const navigationStrategy = new NetworkFirst({
  cacheName: 'pages',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [200],
    }),
    {cacheKeyWillBeUsed}, // <--- this needed to be surrounded by {}
  ],
});

Can you try again with those missing {}?
I am still trying to figure out exactly why there might be even a one-time failure to fetch that page when Chrome automatically checks for offline capabilities, but that fix should at least (I hope) make the cache fallback work for real navigations to your start_url.

I deployed a new version with that change but it looks like the fetch still fails :(

I was having a really hard time understanding why I was seeing your offline.html page instead of your index page when manually navigating to https://development.docs.coregames.com/?utm_source=web_app_manifest&utm_medium=web_app_manifest&utm_campaign=web_app_manifest while offline. And the {cacheKeyWillBeUsed} at least explains that!
But yes, the automatic fetch that Chrome performs that's described at https://developer.chrome.com/blog/improved-pwa-offline-detection/ is still failing. I am now wondering if it might be related to https://github.com/GoogleChrome/workbox/pull/2744, which includes a change to the way some of the asynchronous NetworkFirst logic operates.
I'd like to see if, once #2744 is merged and we cut the next Workbox release, that error from the automatic offline detection is still logged. In the meantime, I don't think it should actually affect the functionality of your web app—offline capabilities when you navigate "for real" are working.

I updated to 6.1.1 today after I saw that the PR was merged but it looks like it still errors. Updated version is at the same URL as above.

Sorry for the delay in getting back to you.
I think that everything is working as "expected," but unfortunately it is a bit confusing now that the automatic offline navigation detection fires off a navigation request for your start_url with the network simulated as offline.
I realize that you're seeing the request failure message logged just because that's what happens when you use a NetworkFirst runtime strategy and you're offline—there's an exception thrown when the network request fails, even though a valid response ends up being provided from the cache. So the installability criteria is met, but there's an error logged.
This came up in another GitHub issue recently, and I guess it's more likely to cause confusion now that the automatic offline navigation detection is fired off by Chrome.
I'm going to leave this issue open to track some work that we could do to improve the logging around a failed network request when using NetworkFirst, just to make it clearer that the response is eventually provided. I'm also going to follow-up with the team at Chrome responsible for the automatic offline navigation detection to see if it might be possible to provide better attribution somewhere in DevTools letting developers know that the request is associated with that detection.

We started seeing "Failed to Fetch" ghost requests errors with Chrome 89 release starting yesterday. These are coming from the new PWA installability checks. Chrome now is triggering a request to / or /index.html that seems to be designed to fail even if you have network connection. This is being done to prove that a website that claims to be installable through reporting a link rel="manifest" is really capable of delivering content while offline.
So if you page is not reporting a manifest file, you'll not get this error reproduced.
I was working earlier to try to get rid of the error message in console, which is misleading, but couldn't get rid of it. Using a StaleWhileRevalidate strategy to cache the root path is getting the new PWA installability check passing, but the strategy tries to revalidate the file using the original request (which is designed to fail) and throws the error.
I couldn't find documentation or an easy way to detect this type of request and avoid trying to send it to network.

This gets a big tough to track down to all the async code, but ultimately, when there's an Uncaught (in promise) TypeError: Failed to fetch message logged, despite the fact that the Strategy (NetworkFirst or StaleWhileRevalidate) is able to generate a response from the cache, it comes from the throw error at the end of
https://github.com/GoogleChrome/workbox/blob/2c8bfe7a840567cc4e693cae38441e46a7b0256b/packages/workbox-strategies/src/Strategy.ts#L221-L242
@philipwalton touched this code most recently, and I'm honestly not sure what the impact would be if the error were not thrown at this point, or only thrown when response is false-y, like
 if (error && !response) {
   throw error;
 }

What do you think, Phil?

In addition to the code highlighted above, there's also console noise (e.g. red error messages) from this code:
https://github.com/GoogleChrome/workbox/blob/2c8bfe7a840567cc4e693cae38441e46a7b0256b/packages/workbox-strategies/src/StrategyHandler.ts#L212-L213
I think we'd have to find a way to avoid both if we want to not scare developers into thinking something is wrong (when it isn't). Experimenting locally, when I comment out both error logging/throwing, my site doesn't emit any scary console messages from the offline check.

@philipwalton touched this code most recently, and I'm honestly not sure what the impact would be if the error were not thrown at this point...

I think we could potentially remove the re-throw. I remember not being sure about this when I was implementing it, and I chose to keep it to help make sure developers didn't have errors in their caching logic (or something like that).
If a developer wants to know if their waitUntil() code throws, they can check for an error property passed to the handlerDidComplete callback. (Though they have to be looking for that, it won't be made obvious in devtools.)

Thinking about this a bit more (and playing with a few options in the code), I don't think we need (or want) to remove the rethrow in the _awaitComplete() method.
The problem currently (upon further investigation) is that the fetch error is even making its way to the _awaitComplete() method in the first place. I think this is happening because in StrategyHandler#fetch() we add the response promise to this.waitUntil().
https://github.com/GoogleChrome/workbox/blob/2c8bfe7a840567cc4e693cae38441e46a7b0256b/packages/workbox-strategies/src/StrategyHandler.ts#L150-L151
I remember I originally chose to do this because I wanted to mimic the fact that event.respondWith() adds the response promise to the extendible event lifetime promise set. But the side effect of doing this is any error thrown as part of generating the response will also make its way into _awaitComplete() method.
I think we don't actually need to pass the response promise in either the fetch() or the catchMatch() method of the StrategyHandler class. Instead, we should only be calling this.waitUntil() for promises that aren't part of generating the response (e.g. adding a response to the cache after it's returned).
When I try removing the this.waitUntil() bit from the fetch() method, the error doesn't make its way to the _awaitComplete() method.
However, even if we do this we'll still need to address the error logged here (as mentioned above):
https://github.com/GoogleChrome/workbox/blob/2c8bfe7a840567cc4e693cae38441e46a7b0256b/packages/workbox-strategies/src/StrategyHandler.ts#L212-L213

I hit the same error with a home-grown service-worker and came to "workbox" in the hope it would be over it already.
I don't get the scary red messages in Firefox. Alternatively removing the site's manifest (!) avoids generating the messages.

Thanks for looking into this, @philipwalton.
Regarding the development build logging messages, I think that's okay, as we also log additional info about how we're falling back to the cache:
https://github.com/GoogleChrome/workbox/blob/2c8bfe7a840567cc4e693cae38441e46a7b0256b/packages/workbox-strategies/src/NetworkFirst.ts#L207-L214
If folks are using the development build, I think there's enough info about what's going on that they can at least determine that the request was ultimately successful, even if we log that network failure. I'm more concerned about folks using production builds, who just see the logged exception without any other context.
Regarding that exception, your suggestion about only explicitly waiting on promises that aren't used for generating a response sounds good, but also sounds like a breaking change, so that might need to wait until Workbox v7.
What I'm thinking for v6 is to decorate the exception message to at least provide some context, like:
if (error) {
  if (response) {
    const message = `The request for ${request.url} succeeded, ` +
        `and this error can be ignored: ${error.message}`;
    throw new Error(message);
  }

  throw error;
}

(Exact wording to be decided.)

And we can also change that logger.error() in StrategyHandler.ts to a logger.info() to make it clearer that it might not ultimately be a failure.

I made both those changes in a local copy of Workbox used on https://so-pwa.firebaseapp.com/, and this is what ultimately is logged in the console when the automatic offline check takes place:

This is still not "great" in that there's some red logged, but at least there's context. (It's a little noisy because the URL is long, unfortunately.)

Also, I wanted to let folks know that separate from the issue of how Workbox logs things, we are actively working with the Chrome DevTools team to provide more context about what's going on during the automatic offline check. Those improvements would help developers regardless of whether they're using Workbox or not.

After chatting with @philipwalton about this, I think the consensus is that making the change outlined in https://github.com/GoogleChrome/workbox/issues/2749#issuecomment-796410150 falls more into the category of "bug fix for unintended behavior" than "breaking change of documented API" so we should be able to get it out sooner in the next Workbox v6 release.

Hi @jeffposnick , my app have similar issue.
https://songbook.app/en?standalone=true - while this page URL is already in cache - workbox still throws error can't fetch it.

I've tried to add it to runtime cache using axios get request and also directly adding it to cache like this:
if ('serviceWorker' in navigator) {
      window.addEventListener('load', function() {
        caches.open('sb-runtime-cache-v1').then(function(cache) {
          cache.match('/en?standalone=true').then(function(response) {
            if (!response) {
              cache.add('/en?standalone=true')
            }
          })
        })

        navigator.serviceWorker.register('/sw.js', {
          scope: '/'
        })
      })
    }

I think issue relates to "improved offline check".
Could you help to figure out how to fix this issue?

This should be resolved in https://github.com/GoogleChrome/workbox/releases/tag/v6.1.2

Awesome, thank you!

CC: @jeffposnick
Hi all, after some digging and testing. I found an INTERESTING way to pass new offline check in Chrome properly.
With workbox 6.1.2, this issue is mitigated by not logging the failed fetch as an error to console. Which is good so that you are not bombed with this red error message and don't know what you should do. But it appears the Network tab in development tools still shows as an failed fetch network request under simulated offline scenario.
My solution will completed remove that failed network request in Network tab, implementation in next-pwa is here:
https://github.com/shadowwalker/next-pwa/blob/3dfda13890a00b297ad171ee9122f623b4e6f848/index.js#L246
runtimeCaching.unshift({
  urlPattern: basePath,
  handler: 'NetworkFirst',
  options: {
    cacheName: 'start-url',
    expiration: {
      maxEntries: 1,
      maxAgeSeconds: 24 * 60 * 60 // 24 hours
    },
    networkTimeoutSeconds: 10,
    plugins: [{
      // mitigate Chrome 89 auto offline check issue
      // blog: https://developer.chrome.com/blog/improved-pwa-offline-detection/
      // issue: https://github.com/GoogleChrome/workbox/issues/2749
      // I know this seems dummy, but it does the trick by gain some time for the cache to be ready :)
      requestWillFetch: async ({request}) => (Request(), request)
    }]
  }
})

Note the requestWillFetch plugins callback is doing nothing but returning same request passed in, but before that it create a Request object and throw away.
My guess is that due to some asynchronous magic, this delays the offline check request in Chrome 89+ a bit, so that cache will be ready to serve that request.
So what you should do if you are not using next-pwa. You can create a runtimeCaching config or registerRoute with the same plugins requestWillFetch configured, then you should have same result.

Hello @shadowwalker—I'd very much suggest not attempting to avoid DevTools noise via that approach. There's overhead in re-creating the request, and I don't really understand what's going on that would cause it to lead to different logs being displayed.
The Chrome team has heard the feedback from this thread and elsewhere, and rolled back the automatic offline check, starting with Chrome 90. Stay tuned for updates to the public guidance. The check may be reinstated at some point in the future, but the developer experience will be taken into account in anything that gets reimplemented.
Thanks for everyone's patience regarding this in the meantime!

Also encountering this issue on iOS Safari 12-14.x with next-pwa v5.1.4. Looks like dynamicStartUrl became the default in https://github.com/shadowwalker/next-pwa/commit/c6416215bcdec6cc49540259f47863f14ea8f39d

@jeffposnick I am using both offlineFallback for offline page and warmStrategyCache to fetch the URL without visiting the page and using runtime caching but even after the HTML for that URL is cached I am seeing the offline page.
// Offline Page
setDefaultHandler(
  new NetworkOnly()
);

offlineFallback({
  pageFallback: '/static/offline.html',
  imageFallback: '/static/images/blank.book.lg.png'
});

function matchFunction({ url }) {
  const pages = ['/', '/account/login', '/account', '/account/books', '/account/loans', '/account/books/already-read/stats'];
  return pages.includes(url.pathname);
}

// runtime caching as the user visits the page
registerRoute(
  matchFunction,
  new NetworkFirst({
    cacheName: 'html-cache',
    plugins: [
      new ExpirationPlugin({
        // Keep at most 50 entries.
        maxEntries: 50,
        // Don't keep any entries for more than 30 days.
        maxAgeSeconds: 30 * 24 * 60 * 60,
        // Automatically cleanup if quota is exceeded.
        purgeOnQuotaError: true,
      }),
      // only cache if it the request returns 0 or 200 status
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  })
);

const strategy = new CacheFirst();
const urls = [
  '/account/login',
];

warmStrategyCache({urls, strategy});


V10.6.1 private

Do not merge.
This is for a CI run.

LGTM.
The CI may need some work to get passing.
Please also update the release note and version number.

@zezha-msft  https://github.com/Azure/azure-storage-azcopy/pull/1162/files Changes by Narasimha needs to be in it.

Ok in that case this PR has go through the dev branch then, how else can we publish a release without having the tests run.


Embrace continuous delivery and DevOps API

This is an epic aimed at encompassing the multitude of related issues encountered, discussed or proposed by either @dpb587, @mrdavidlaing or @sopel during the life time of this project.
While we've come a long way automating the operation of a fairly complex software cluster, we've ironically fallen short on a few basic engineering principles, amongst them items 2 & 3 of the well known Joel Test: 12 Steps to Better Code:

Can you make a build in one step?
Do you make daily builds?

I'm referring to Continuous Delivery as defined by Martin Fowler, i.e. build software in such a way that the software can be released to production at any time, esp. including push-button deployments of any version of the software to any environment on demand

We have builds for unit tests and scripts for deployment in place, but all this is both fragmented and incomplete and fails to deliver on what I'd also phrase as follows:
I consider a build system to be the API for all your DevOps tasks, which ideally combines all available aspects of development and operations via a unified layer (e.g. Rake or Gradle) to provide discoverability and implicit documentation of what's available, no matter how diverse everything might be implemented under the hood (be it inline vs. separate scripts vs. external APIs). The goals here are obvious:

it should be possible to hand over the entire system to a new team member simply by providing a DVCS URL and a build command.
once you have that API in place, it can be driven by arbitrary clients as usual, be it a person, a CI job or a chat bot for example

I'll stress again that we have touched on all those aspects already one way or another (we use Git, we have some builds, we offer a Vagrant box) , but at least for me it still falls short of the desired state of affairs far enough that I consider this to be an impediment.
:information_source: I'll link all related issues to this epic as I proceed converting my scribbles into something tangible.

Closed as Incomplete due to project being retired to the CityIndex Attic.


Identification of resources

By OAI spec, we identify resources by Path templates. But in implementation of REST APIs, we most often identify resources by URIs. Obviously, there are gaps among Path Templates, URIs (RFC7320) and URI Templates (RFC6570).
Per framework capability, it might be difficult to use OAI to document code-first REST APIs sometimes. For instance,

Jersey requires to use path templates to design resource identifiers
Spring MVC allows much more flexible resource identification by combination of path, query params and headers.

What's OAI's view on resource identification by documentation?

  I believe that sentiment is shared by the others in the TDC with the caveat of "not at any cost".
As you can see from this meta issue #574 we took a pretty big swing at addressing the many issues that are related to this topic.  Somewhere in those issues (I searched but haven't found it yet) I make the assertion that I believe what we want is a deterministic algorithm for matching an instance URL to an operation description.   Once you introduce optional path parameters, query parameters and discrimination by parameter value, it becomes challenging to identify an efficient algorithm.
However, if we could find a reliable, efficient way, to say this URI maps to this Operation without ambiguity, then I am convinced we could get it into the spec.  My concern is that the only realistic way is with a "best fit" algorithm and I really don't want to go there unless all other options are exhausted.

Thanks for the link to these good discussions. I don't have deep research on the URI matching algorithms, but in practice, ant style path matching is a reliable approach, AntPathMatcher.

This wouldn't fit in 3.x, but might fit under Moonwalk's operation signatures principle.  You might want to join discussions in that repo such as this one:

https://github.com/OAI/sig-moonwalk/discussions/30


Fix websocket endpoint

Fix up the websocket endpoint all the DB and other refactoring.
It's slow again due to bringing back the reverse geocoding removed in #27. I will see with the frontend changes as well if it's reasonable to remove this issue somehow.

This PR should be ready for review - the websocket should be functional again returning the status of the calculation for a specific event but requires the event to exist already based on previous POST requests.
A few possible follow-ups that I'd like to add:

remove the reverse geocoding again - added it back to progress quickly on other piecies but it makes things very slow as @F-Ruxton noticed on #27.
Add better error handling - e.g. if websocket is opened on a non-existent event / participant the error messages aren't very helpful / graceful.
Move away from plain ints as event IDs. At least use a hashed string (harder to guess) or even the event's name in some sensible way.
Delete the old static html dashboard included in this repo

I've developed and tested this against the latest dashboard code in https://github.com/RemotelyGreenOrg/co2-calculator-dashboard/pull/6.
@F-Ruxton if you're able to review this I'd be very grateful. I might close this in a day or two if I haven't heard anything back by then to be able to deploy and move forwards easily, but feel free to review after that date still :slightly_smiling_face:


fby4: sd: Support MP2856/MP2857 fw update through pldm

Description:
Add vr components for pldm fw update
support MP2856/MP2857 device
Motivation:
Support PLDM vr update and get crc
Test Plan:

PLDM update vr fw: pass
PLDM get vr crc: pass

Test Log:
[get pld crc]
root@bmc:~# pldmtool fw_update GetFwParams -m 60
...
{
"ComponentClassification": "Downstream Device",
"ComponentIdentifier": 1,
"ComponentClassificationIndex": 0,
"ActiveComponentComparisonStamp": 0,
"ActiveComponentReleaseDate": "",
"PendingComponentComparisonStamp": 0,
"PendingComponentReleaseDate": "",
"ComponentActivationMethods": [
"AC power cycle"
],
"CapabilitiesDuringUpdate": {
"Firmware Device apply state functionality": " Firmware Device will execute an operation during the APPLY state which will include migrating the new component image to its final non-volatile storage destination."

{
"ComponentClassification": "Downstream Device",
"ComponentIdentifier": 1,
"ComponentClassificationIndex": 0,
"ActiveComponentComparisonStamp": 0,
"ActiveComponentReleaseDate": "",
"PendingComponentComparisonStamp": 0,
"PendingComponentReleaseDate": "",
"ComponentActivationMethods": [
"AC power cycle"
],
"CapabilitiesDuringUpdate": {
"Firmware Device apply state functionality": " Firmware Device will execute an operation during the APPLY state which will include migrating the new component image to its final non-volatile storage destination."
},
"ActiveComponentVersionString": "MPS 7a5d125c",
"PendingComponentVersionString": ""
},
...

Duplicate


Fix character field bounds update error

Closes #251

coverage: 98.844% (+0.001%) from 98.843%
when pulling 937aee019fc7f66ebe1d05f9d082b8cc7c131020 on jeromekelleher:fix-parse-bug
into 20e6dd172fd74f24902117ef1081099bd71fd5f4 on sgkit-dev:main.

coverage: 98.887% (+0.04%) from 98.843%
when pulling 937aee019fc7f66ebe1d05f9d082b8cc7c131020 on jeromekelleher:fix-parse-bug
into 20e6dd172fd74f24902117ef1081099bd71fd5f4 on sgkit-dev:main.


Faulty code passes all the tests for Bonfire: Everything Be True

Challenge Bonfire: Everything Be True has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.
My code:
function every(collection, pre) {
  return collection.every(function(e) { return e[pre]; });
}
every([{'user': 'Tinky-Winky', 'sex': 'male'}, {'user': 'Dipsy', 'sex': 'male'}, {'user': 'Laa-Laa', 'sex': 'female'}, {'user': 'Po', 'sex': 'female'}], 'sex');

And this one too
function every(collection, pre) {
  return return typeof pre === 'string' ? true : false;
}
every([{'user': 'Tinky-Winky', 'sex': 'male'}, {'user': 'Dipsy', 'sex': 'male'}, {'user': 'Laa-Laa', 'sex': 'female'}, {'user': 'Po', 'sex': 'female'}], 'sex');

Working on the PR

Might be resolved in #3620

@abhisekp is correct that this challenge has already been fixed in the staging branch. Both in clarifying the goal and adding test cases. The solution you posted originally actually is a valid solution, since the goal of the challenge it to check if the predicate is truthy for every object in the collection and the second solution is not valid and does not pass in the corrected version.
Closing since this is fixed in staging.
Thanks and happy coding!

@ltegman the first solution will fail for this
every([{'user': 'Tinky-Winky', 'sex': false}], 'sex');

@abhisekp is correct and I checked it using
every([{'user': 'Tinky-Winky', 'sex': 'female'}, {'user': 'Dipsy', 'sex': 'female'}, {'user': 'Laa-Laa', 'sex': 'female'}, {'user': 'Po', 'sex': 'female'}], {'sex': 'female'});

It should return true but returns false.

Both the problem and the tests were changed by that PR. It never should have been asking students to check if a property was defined and none of the test cases should have included a full object as a predicate. The wording of this problem after the PR is "Check if the predicate (second argument) is truthy on all elements of a collection (first argument).", it just hasn't been merged into the master branch yet.


Development Environment?

Hi.
Thinking I might be interested in picking up this project, wondering if you could explain to me the tool(s) you used in development? I have previously used Cloud9, VSCode, and Atom for development. How were you building to test? etc.

OOPS: This should be in a different repository that uses this as a dependency, cubezapp. I'll move the issue over there


Downgrade 3 dependencies for Colab & fixed Path error

pillow, numpy & gdown don't really need latest version to run, and when they were forced to upgrade on Colab, required restart and conflicted with other libraries in project.

Valid point. I usually have to pin Pillow to 9.5.0 in other things but it's not necessary here (not dealing with BGR24 formatted images directly at any point).
Have fixed up path_from_cwd inside the function, if you could rebase this onto main to remove the merge commits (otherwise I'll have to do it this side) and drop 204de3715f3c361efdc37317266337f49822d10b i'll get this pulled in 😄

Alright, no problem... Reverted that patch since you got it cleaner within the function.  Looks good and works well. Thanks, I pretty much don't need to be using my fork anymore now that we're past those minor issues.

Awesome! Let me go ahead and merge this before I push a bunch of refactoring to make it possible to call this like a library without reloading the model every time...


[Dialog] Should probably have theme property for zDepth

There appears to be no way to set the shadow amount for the dialog content div. It's currently hardcoded as

It looks like there was a formatting issue in your post. Did you mean to display some code?

Nope. No code. It's readily apparent here:
https://github.com/callemall/material-ui/blob/master/src/Dialog/Dialog.js#L334

Nope. No code.

Oh, ok. I just got confused by the second sentence in your post; it looks unfinished.

It's readily apparent here:

I'm sorry, I'm not following you. But then again, I don't know this codebase very well yet.

The <Paper /> component is the MUI implementation of material design paper. zDepth is the property that controls how "heavy" the box-shadow of the paper is.
The <Dialog /> component uses Paper but the zDepth property is hardcoded to 4 meaning you can't change it as part of an MUI theme (unless you give the Dialog a className and add a global css property of .my-dialog > div > div > div { box-shadow: initial; }).
If no one else is up for it I'll take a crack at adding the property myself later today.

We have been reworking the theme logic on the v1-beta branch, everything is customizable now.


[Bug]: Needs to add alt, ARIA, attributes to Respective Image, Social Links and Form Sections and Other Minor Changes

Describe the bug

I want to add alt, ARIA, attributes to Respective Image, Social Links and Form Sections and Other Minor Changes
Missing alt attribute and it's text missing in some Image Tags
Also, ARIA Attribute needs for web accessibility and screen readers in DOM with Assistive Technologies(AT)
Other Side, we needs to add title(Tooltip), target, rel, ARIA Attributes  for Social Icons
Additionally, Respective Social Icons are not Visible on Footer Section Area. Before going to those above Multiple Issues, I will go with Social Icons visibility Design

To Reproduce
Steps to reproduce the behavior:

Go to 'https://akshitagupta15june.github.io/PetMe/'
Click on '....'
Scroll down to 'Footer Section'
See error on Respective Social Icons are not Visible and need Much Design for Improvement with HTML, CSS (Tailwind CSS)

Expected behavior

Above Raising attributes are added to Respective Elements and Expect Zero Level Bugs to these Changes

Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [Windows]
Browser [Chrome]
Version [115.0.0]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context

The aria-label attribute provides a way to place a descriptive text label on an object, such as a link, when there are no elements visible on the page that describe the object. If descriptive elements are visible on the page, the aria-labelledby attribute should be used instead of aria-label .
The rel attribute specifies the relationship between the current document and the linked document. Only used if the href attribute is present.
The target attribute inside anchor tags (  ) tells the browser where the linked document should be loaded. It's optional, and defaults to _self when no value is provided.
The title attribute gives users an important indication as to where they will be directed to when they click on a link. If the user hovers with the mouse over a link reference, the title text, which was defined in the attribute, will be displayed.
The required alt attribute specifies an alternate text for an image, if the image cannot be displayed. The alt attribute provides alternative information for an image if a user for some reason cannot view it (because of slow connection, an error in the src attribute, or if the user uses a screen reader).

For Reviewers

Additionally I wants to add Proper Design for Social Icons because of these are not Properly Visible on Footer Section Area
After that, I proceed with the above Multiple challenges and It's easier for Me
So, Actually I work on Two Issues like because One Issue is Based on Another Issue combines with  Created A One Issue

Hi @akshitagupta15june . Please Review on this Issue as soon as Possible. Thank You !

@akshitagupta15june . Please Review on this Issue. Thank You !


Electrolyzer

The Electrolyzer converts 1 H20 to 1 H and 1 O, but it should make 2 Hydrogen and 1 Oxygen.

I'd assume its for convenience, it is easier to pipe a 1:1 ratio then a 1:2 ratio, especially when only the hydrogen becomes 2

it is indeed, unless I can find another hydrogen sink or some way to dissipate H2, though I may consider implementing venting functions in the future.


Add managed identity live tests in new e2e module

I'm curious as to why this is its own entity instead of part of another library? Is this going to get filled in with end to end tests for other areas? This module was added to pom.client.xml but it's not part of any pipeline build, should it be? When/where are these tests supposed to be running.


Variety of changes with updates.

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.


Unselect JSON/YAML Schema

When syntax-highlighting YAML-Files one can select a "schema" in the light-blue lower pane of VS Code. VS Code starts out with "No JSON Schema" but once a schema has been selected one cannot go back to "No JSON Schema". No such entry does appear in the "Select JSON Schema"-list, nor any icon indicating "unselect all schema". Thus, if one has a "custom data yaml file" without a provided schema it'll stay red-flagged forever which is not deal-breaker but somewhat annoying.

You need to file this issue against the yaml extension: https://github.com/redhat-developer/vscode-yaml/issues


Task selector dropdown in Terminal window is too short

Issue Type
Bug
Description
I remember this was reported in the past, but i could not find the exact issue. In any case , the problem still remains - i.e., the task selector dropdown in the integrated Terminal window is too short and cannot be resized, and thus long task names are cut off. See picture below:

VS Code Info
VS Code version: Code 1.20.1 (f88bbf9137d24d36d968ea6b2911786bfe103002, 2018-02-13T15:34:36.336Z)
OS version: Windows_NT x64 6.1.7601

@cleidigh fyi, what is your strategy for the size of the list widget?
@yuval-gilboa from that screenshot it is not clear to me if the last element has more text?

No the last element in the dropdown is shown in full. The expanded dropdown is fine. The problem is that in the collapsed state it is narrower than in the expanded state and then the text is cut.

@yuval-gilboa got it. this is just a matter of how much space we reserve for the dropdown.

@isidorn I believe I created a similar issue after you did some refactoring and you just increased the width a little? It's much easier to hit the max width now:

@Tyriar it is possible to have a better layouting strategy in the title area, however the issue is with the pushing of elements and who has priority. It can get quite complex if multiple of elements in that area have a variable width.
Currently I am using flex for everything to work nicely. People who want to play with this and try to fix it are very welcome, code pointer
https://github.com/Microsoft/vscode/blob/isidorn/searchPanel/src/vs/workbench/browser/parts/media/compositepart.css#L11

@isidorn  I tested the following fix (written in .less format) and it works. It automatically expands/contracts the selection box based on its contents, without affecting the overall flex layout of the title bar.
Hope this helps.
.monaco-workbench > .part.panel > .composite.title > .title-actions {
   flex-grow: 1;                 // allow the actions area to grow (was set to 0 by some other rule)

   & .actions-container {
      display: block;            // let the actions container to fit to content

      & .select-container {
         max-width: none;        // remove the hard-coded max-width constraint (was set to 170px)

         & .select-box {
            margin-top: 0;       // fix the vertical position of the selection box
            margin-bottom: 7px;
         }

      }
   }
}

@yuval-gilboa the dropdown expanding like that is ideal, however it pushes the other actions off the right side of the window:

@Tyriar Current overflow behavior is a bit better, but will also eventually push the other actions off screen:
Overflow under current implementation:

Overflow under proposed implementation:

You could use CSS selectors to choose between the two implementations depending on the terminal window docking position. I.e., use the proposed implementation when the terminal window is docked to the bottom (wide layout), and fallback to the current implementation when the terminal window is docked to the right (narrow layout).
P.S.,
The action buttons overflow issue can be alleviated by folding them into a "more" menu, similar to how it's done on the workbench titlebar. I would like to have that option anyway, to reduce visual clutter. But that would be the topic for a different issue report.

@bpasero
on your question about width strategy:

I do not Control any layout for the header is to select - I let the other parts do that.
The width of the expanded select is controlled by the largest option, although there may be an issue there.  in terms of the screen edge I control the bottom margin and the context view controls  side margins.

@yuval-gilboa
@Tyriar
@isidorn
there is another dynamic positioning issue I saw I mentioned a long time ago.  with the right terminal width and location of the expanded drop-down, you can end up with the expanded dropDown straddling the border between the terminal and sidebar with the header cut off.  a rare scenario but related to what you are talking about in terms of dynamic positioning.

@Tyriar  @isidorn
IMO - the perfect solution would be, to give the user a chance to resize this dropdown by himself.
Those users, who need a bigger dropdown - will resize it.. everybody else - leave it as is...

@yuval-gilboa
@Tyriar
@isidorn
While making the select "header box" expandable would provide a lot of flexibility , it makes managing
the overflow and icons more complicated.  It would still have to be dynamic based upon any window resizing.
Maybe making a configurable minimum size?  This would prevent collapsing the terminal with to a minimum?

This is a long-standing issue.
But I see now you've solved this issue in the Problems panel:

Why can't you do the same for the Terminal panel? The original reported bug still exists there:

@yuval-gilboa tabs for terminal have not been forgotten, it's one of the highest rated features https://github.com/Microsoft/vscode/issues/10546


Add missing documentation to Viewport

This PR fills all of the class reference's descriptions that have been missing from Viewport. It also tweaks existing descriptions very slightly.
In particular, the descriptions for sdf_oversize, sdf_scale, snap_2d_transforms_to_pixel, and snap_2d_vertices_to_pixel have almost been copied word-for-word from the equivalent Project Settings.
I could have rewritten them outright, but the time I spend on these is directly proportional to how long it will take for them to be reviewed and merged.

Thanks!


Create Postman test for Threshold

Postman test to ensure decryption works with only threshold amount.
Test does not have to pass since this is to cover expected bug at lower level.

API moving to python this issue will become obsolete.


[task/ECP-1040] - Upgrade ruby version from 2.6.7 to 2.7.0

Closing as will be replaced as some additional work has been done in preparation


Code block missing for windows build documentation

I noticed that the code block for windows is missing:

Thanks, I will fix that 👍

Fixed in 07f6c6e.


[ACR] Fix: various bug fixes

Related command
az acr manifest and az acr repository command groups
Description
3 bug fixes.
Testing Guide

History Notes
[acr] Fix: Some az acr manifest commands do not correctly handle -u/-p credentials resulting in auth failure when not logged in to az cli
[acr] Fix: Some az acr commands do not handle certain next-link tokens correctly resulting in exceptions when paging
[acr] Fix: az acr manifest commands do not correctly parse some FQDNs resulting in exceptions

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

acr

/azp run


Example for use with Serverless framework?

Has anybody used this shim in conjunction with the Serverless framework? Examples would be great. Thanks

https://github.com/yunspace/serverless-golang :smile:

Thanks!


[Feature][zentao] Collect&Extract&Convert bugs

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
Collect&Extract&Convert bugs
Use case
Collect&Extract&Convert bugs
Related issues
#2961
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I am willing to submit a PR

closed by #3779


Create an issue in Homebrew/brew about the locale-gen thing

details incoming

relevant PR https://github.com/lynncyrin/base-image/pull/43

here's a CI build where you can see the warning https://circleci.com/gh/lynncyrin/base-image/66?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
It's at the bottom, above an (unrelated) message about MANPATH.

/root/.linuxbrew/bin/brew shellenv
/root/.linuxbrew/Homebrew/Library/Homebrew/brew.sh: line 4: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory

Here's (as far as I can tell) the PR where that line was added https://github.com/Homebrew/legacy-homebrew/pull/47247. The PR says its closed (?) and the code has moved to live here https://github.com/Homebrew/brew/blob/3cef1088967291a27583b41c09c32a041b52b00e/Library/Homebrew/brew.sh#L4 since then. But that PR definitely looks like the origin for that line 🔍

PR that's possibly related https://github.com/Homebrew/brew/pull/616/

Possibly related comment https://github.com/Homebrew/brew/pull/171#issuecomment-215999975

🔍  this comment looks more related than the others! https://github.com/Homebrew/brew/pull/982#issuecomment-247768552

another related comment https://github.com/Homebrew/brew/issues/3082#issuecomment-324291935

another comment https://github.com/Homebrew/brew/issues/708#issuecomment-265176458

I managed resolve the issue by exporting LANG to en_US.UTF-8 at the start of my shell.

^ this is essentially what I'm doing in https://github.com/lynncyrin/base-image/pull/43/commits/54103b643700415c16f50dd97ba8e9c9dec60f2d

I've discovered that setting the locale is something I should be doing, but I'm not sure why I should be doing it 🔍

possibly related (and complicated!) comment https://github.com/Homebrew/brew/issues/126#issuecomment-215963830

🔍🔍🔍 getting closer!!! https://github.com/Homebrew/brew/pull/3666#issuecomment-357511531

https://github.com/Linuxbrew/brew/issues/568

The brew.sh script appears to ignore the locale information (en_GB.UTF-8 in this case), and impose
en_US.UTF-8, which doesn't exist on my machines.

This is exactly what I'm experiencing 👍

Here's my default locale, for future reference
root@REDACTED:/projects# locale                                                                                LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

another helpful comment https://github.com/Homebrew/brew/issues/932#issuecomment-247531212

this issue went away when I made this change https://github.com/lynncyrin/base-image/pull/43/commits/3e204adb658049c0ccec4383251a8e2d9a9756db

or... did it? I didn't actually check 😆 either way, I probably don't feel like following up here

nevermind! looks like the example image has an issue with this too https://github.com/Linuxbrew/docker/blob/b05ca597c615921204e211d5ebb1f95826b8cd3d/bionic/Dockerfile#L10


Create github-actions-demo.yml

Summary

Changes

Closes:
Task list

[x] For workflow changes, I have verified the Actions workflows function as expected.
[x] For content changes, I have reviewed the style guide.

test

test


Add skills tabel to about section, add background to hero and splash screen, minor style changes.

Good to go.


Optimize the pit collector script

Description

Optimize the pit collector script
Motivation and Context

I made a few changes to pit collector script:

Split the download script into two parts: download data and normalize data
Split _get_data_from_baostock method to improve readability
Corresponding adjustment README.md and test_pit.py

How Has This Been Tested?

[ ] Pass the test by running: pytest qlib/tests/test_all_pipeline.py under upper directory of qlib.
[ ] If you are adding a new feature, test on your own test scripts.

Screenshots of Test Results (if appropriate):

Pipeline test:
Your own tests:

PIT test results:

Types of changes

[ ] Fix bugs
[ ] Add new feature
[ ] Update documentation

According to the PIT test results image you provided, I did the test and found some error messages and would like to get your help to fix it.

According to the PIT test results image you provided, I did the test and found some error messages and would like to get your help to fix it.

hi, @SunsetWolf, in qlib/data/data.py 1166 line:
try:
    return DatasetD.dataset(
        instruments, fields, start_time, end_time, freq, disk_cache, inst_processors=inst_processors
    )
except TypeError:
    return DatasetD.dataset(instruments, fields, start_time, end_time, freq, inst_processors=inst_processors)

It will catch the TypeError exception, but the exception is not captured in the screenshot you can provide, can you provide more information?

I would be more than happy to provide you with more detailed information about the error I received, and I hope this information is useful to you in helping me resolve this issue. Thanks!

Running this test requires initializing the calendar and instrument data.
Please execute the following command before running the test(you can find them from the comments in test_pit.py):

python scripts/get_data.py qlib_data --target_dir ~/.qlib/qlib_data/cn_data --region cn

python scripts/data_collector/pit/collector.py download_data --source_dir ~/.qlib/stock_data/source/pit --start 2000-01-01 --end 2020-01-01 --interval quarterly --symbol_regex "^(600519|000725).*"

python scripts/data_collector/pit/collector.py normalize_data --interval quarterly --source_dir ~/.qlib/stock_data/source/pit --normalize_dir ~/.qlib/stock_data/source/pit_normalized

python scripts/dump_pit.py dump --csv_path ~/.qlib/stock_data/source/pit_normalized --qlib_dir ~/.qlib/qlib_data/cn_data --interval quarterly

Everything looks much simpler and cleaner than Qlib's initial version!
It looks great!
Thanks!


Is it very difficult fix the build warnings ?

I mean the warning messages when installing the package
Something like this:
./fuse-bindings.cc:625:34: warning: missing initializer for member ‘fuse_operations::readlink’ [-Wmissing-field-initializers]

It would be cool make them silent or do the things gcc saying ..

It would be cool make them silent or do the things gcc saying ..

Better the second option ;-)

Hahaha, yes, when your gcc is happy galaxy grows ))


Variations: Transparency and Glow

This will be a question, more than anything: is it possible, within the scope of FCB's code, to create transparent blocks and blocks that self-illuminate? Colored glass would certainly do the stained glass window crowd a favor, and self-illumination would be very stunning for low-light displays and 'magic' things. I was inspired partly by Armourer's Workshop, RiskyKen's 1.7.10 mod which featured HSV-colorable normal, transparent, glowing, and glowing transparent blocks, all of which offered a lot of variety.
The reason I ask why it's possible: I understand that FCB generates -tons- of colors and shades at any given time, and the Crafting Tool is already a saving grace in terms of limiting what's visible to narrow a search. How would one diversify that? A 'transparent' and a 'glowing' tool? A toggle or sliders of some sort on the UI?
I'm very interested in this, not just from a 'gimme feature' standpoint, but also one of feasibility. Generating it all is one thing, but implementing it in a smooth way that doesn't cause the game to explode is definitely another. If it -were- possible, and without a backbreaking amount of work, I think it would make quite a splash.

I am quite fond of the idea to add semi-transparent shades, I believe that the stained glass possibilities would be pretty impressive, especially if combined with Chisels&Bits to make intricate detailed glass works.
I'm a little less enthusiastic about glowing variations.. but I can see their being a desire for such blocks, and I can see where they could be used to create some interesting creations. ( I'm mostly enthusiastic about using this with C&B to create bright colored patterns in dark stone. )
That said I believe it might be pretty limited by default....
The mod by default uses about 81 block ids if memory serves, adding just 1 shade of glass, and 1 shade of glow would take that too 243 (3x of what it is now)
I could mitigate that by make per type HSV/varation settings, but Its a legitimate concern with how I do the blocks since the main reason I did FCB was to enhance C&B's capabilities.
I'll think about it some, but I think its a good idea even if I need to add extra configurations.
As for crafting I think the same tool could be used but require an extra material ( such as glowstone for glow, or glass instead of cobble for glass )

I believe one step of transparency (MC stained-glass level) and one step of glow (total self-illumination, xy-esque?) would already be a step in the right direction. I've been instantly obsessed with C&B since I saw it come out-- I love the mini-blocks concept, a gap that I hadn't had filled since Minepainter/DaVincing dropped off the map somewhat. And it's easily the best implementation OF that concept I've seen, with the usage of patterns, modes, and-- probably one of the absolute most impressive features in my eyes, the ability to ignore block grids.
But enough gushing-- thank you very much for your swift response and satisfactory explanation. I agree on a lot of your ideas for implementation, and I look forward to seeing where C&B and FCB go from here.

Should be ready.. will probably release FCB 1.2 tomorrow.


Migrate from Travis to Github Actions

Replace Travis with Github Actions.
Fixes #235

Codecov Report

Merging #237 (6c4365a) into master (cb421f1) will increase coverage by 3.06%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #237      +/-   ##
============================================
+ Coverage     72.55%   75.61%   +3.06%
- Complexity      245      259      +14
============================================
  Files            48       48
  Lines           849      849
  Branches         40       40
============================================
+ Hits            616      642      +26
+ Misses          209      183      -26
  Partials         24       24

Impacted Files
Coverage Δ
Complexity Δ

...org/zalando/stups/tokens/AccessTokenRefresher.java
86.56% <0.00%> (+2.98%)
18.00% <0.00%> (+1.00%)

...rc/main/java/org/zalando/stups/tokens/mcb/MCB.java
83.33% <0.00%> (+8.33%)
5.00% <0.00%> (+1.00%)

...n/java/org/zalando/stups/tokens/mcb/MCBConfig.java
93.33% <0.00%> (+13.33%)
6.00% <0.00%> (+4.00%)

...main/java/org/zalando/stups/tokens/mcb/Closed.java
92.30% <0.00%> (+15.38%)
6.00% <0.00%> (+1.00%)

...c/main/java/org/zalando/stups/tokens/mcb/Open.java
68.00% <0.00%> (+68.00%)
7.00% <0.00%> (+7.00%)

Continue to review full report at Codecov.

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

👍

:+1:

👍

👍

:+1:


yarn install --flat

when I do flat install (to avoid duplicates)
I see there is a lot of packages to resolve.
is it important to do a flat install?
can we approve something to avoid duplication of packages versions?

No, it is not important because those are mostly build dependencies which you shouldn't worry about (and probably can't make an informed decision about since they are all implementation details).


Strict

strict validation, configurable via either config or on a field.
As well as allowing general strict validation, this will also be used for the first pass during union validation, see #23
:eyes: @PrettyWood

I'll add more tests in a restructuring of tests after #23 is merged.


[sns] get default region by env var

https://github.com/spulec/moto/issues/4901

Thanks for creating a PR for this! As I said in the issue itself, the sns_backends variable would be the correct way to access this information.
In addition, the AWS_DEFAULT_REGION is not guaranteed to be set, so this is not the right solution for everyone.
I'll raise a PR shortly to fix the docs, and I'll remove the sns_backend-variable as well to remove any confusion.


[FEATURE] Upgrading to Ansible 2.10 and beyond

Description
Starting with ansible==2.10.0, the following error started to appear in the idempotence stage when running the mysql scenario with MOLECULE_DISTRO=debian:buster-slim:
TASK [mysql_role : MySQL | Ensure MySQL users are present] *********************
failed: [mysql] (item={'name': 'testing', 'password': 'testing', 'priv': ['test01.*:ALL']}) => {"ansible_loop_var": "item", "changed": false, "item": {"name": "testing", "password": "testing", "priv": ["test01.*:ALL"]}, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}

Further investigation is required. This could be easily fixed adding python3-pymysql to mysql_required_libs under vars/mysql.yml, but I don't think this is the best approach as it adds another dependency.
Why is this needed?
Additional Information
Can be reproduced upgrading to ansible >= 2.10.0 and running MOLECULE_DISTRO=debian:buster-slim pipenv run molecule test -s mysql
Module documentation: https://docs.ansible.com/ansible/latest/collections/community/mysql/mysql_user_module.html

Fixed in #80


502 bad gateway error

I’m` trying to install Huginn on my own server. Getting an error 502 - Bad Gateway.
I’m a newbie, have spent some hours trying to figure it out for myself, reading other posts, would love some pointers if anyone could assist.
My installation:
Installed Huginn on Debian 10 using the instructions:
github.com/huginn/huginn/blob/master/doc/manual/installation.md
During installation, the only issue I recall was that I was unable to install libssl1.0-dev, I got this error message:
Package libssl1.0-dev is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libssl1.0-dev' has no installation candidate

I’m unsure how to fix the above issue, however I carried on with the rest of the installation.
Sockets:
I notice there is no unicorn socket.
ls -la sockets
total 8
drwxr-xr-x 2 huginn huginn 4096 Aug 30 13:13 .
drwxr-xr-x 5 huginn huginn 4096 Aug 30 13:45 ..
huginn_error.log
2020/09/02 04:22:04 [crit] 30494#30494: *22884 connect() to unix:/home/huginn/huginn/tmp/sockets/unicorn.socket failed (2: No such file or directory) while $
$n/tmp/sockets/unicorn.socket:/502.html", host: “huginn.mysite.com”

[note: the log includes my actual domain name, I’ve changed it here to “mysite.com"]
Unicorn.log
I, [2020-09-02T00:01:05.406178 #14272]  INFO -- : Refreshing Gem list
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/rubygems_integration.rb:200: warning: constant Gem::ConfigMap is deprecated
bundler: failed to load command: unicorn (/home/huginn/huginn/vendor/bundle/ruby/2.6.0/bin/unicorn)
$ cannot open shared object file: No such file or directory

Production.log
[empty]
sudo bundle exec rake production:check
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/rubygems_integration.rb:200: warning: constant Gem::ConfigMap is deprecated
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-1.17.3/lib/bundler/rubygems_integration.rb:200: warning: constant Gem::ConfigMap is deprecated
[  OK  ] Everything is fine

unicorn.rb
wd = File.expand_path(File.join(File.dirname(__FILE__), '..'))

app_path = wd

worker_processes Integer(ENV["WEB_CONCURRENCY"] || 2)
preload_app true
timeout 180
listen "#{wd}/tmp/sockets/unicorn.socket"

working_directory app_path

rails_env = ENV['RAILS_ENV'] || 'production'

# Log everything to one file
stderr_path "log/unicorn.log"
stdout_path "log/unicorn.log"

# Set master PID location
pid "#{wd}/tmp/pids/unicorn.pid"

before_fork do |server, worker|
  ActiveRecord::Base.connection.disconnect!
  old_pid = "#{server.config[:pid]}.oldbin"
  if File.exist?(old_pid) && server.pid != old_pid
    begin
      Process.kill("QUIT", File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
      # someone else did our job for us
    end
  end
end

after_fork do |server, worker|
  ActiveRecord::Base.establish_connection
end

Procfile

###############################
#         DEVELOPMENT         #
###############################

# Procfile for development using the new threaded worker (scheduler, twitter stream and delayed job)
# web: bundle exec rails server -p ${PORT-3000} -b ${IP-<IP_ADDRESS>}
# jobs: bundle exec rails runner bin/threaded.rb

# Old version with separate processes (use this if you have issues with the threaded version)
# web: bundle exec rails server
# schedule: bundle exec rails runner bin/schedule.rb
# twitter: bundle exec rails runner bin/twitter_stream.rb
# dj: bundle exec script/delayed_job run

###############################
#         PRODUCTION          #
###############################

# You need to copy or link config/unicorn.rb.example to config/unicorn.rb for both production versions.
# Have a look at the deployment guides, if you want to set up huginn on your server:
# https://github.com/huginn/huginn/doc

# Using the threaded worker (consumes less RAM but can run slower)
web: bundle exec unicorn -c config/unicorn.rb
jobs: bundle exec rails runner bin/threaded.rb

# Old version with separate processes (use this if you have issues with the threaded version)
# web: bundle exec unicorn -c config/unicorn.rb
# schedule: bundle exec rails runner bin/schedule.rb
# twitter: bundle exec rails runner bin/twitter_stream.rb
# dj: bundle exec script/delayed_job run

###############################
# Multiple DelayedJob workers #
###############################
# Per default Huginn can just run one agent at a time. Using a lot of agents or calling slow
# external services frequently might require more DelayedJob workers (an indicator for this is
# a backlog in your 'Job Management' page).
# Every uncommented line starts an additional DelayedJob worker. This works for development, production
# and for the threaded and separate worker processes.
We don't have tested the manual installation method with the new(er) Debian based distributions yet. The installation on Debian 9 or use the docker images. To be honest I am not sure if we will continue to update the manual installation guides because any change also has to be manually tested on any other supported distribution.

Thanks for the response, and that makes sense.


Create performance regression tracking for specific select functions

[ ] Getting cell connections (#90)
[ ] Cell morphology query (#21)
[ ] Neuron().load() (#42)

I wonder if we can use the functions named in the specific issues #42, #90, #21 as our first functions in PyOpenWorm to put under performance regression? This would help move the whole milestone forward as well as giving a specific focus in a lean way to this effort.

I can take a look at those while we refine progress on various workflow-related aspects of the performance regression work.

Just a quick question, are these poor-performing tests currently pushed to the dev branch of PyOpenWorm so I can replicate on my local machine?

I think there may be some cross-communication here. Stephen is referring to testing the speed of each of the mentioned functions. There may not yet exist tests which just simply run each of these functions on their own.
Since the profiling suite right now operates on tests, it may be useful to write these tests, or incorporate into the profiling suite the ability to load individual functions and time them separately.
@cheelee does this description make sense?
cc: @kevcmk @slarson
Also related to discussion in #90

@travs gotcha. I'll do a grep for the offending functions in the PyOpenWorm source instead. I had searched the tests folder. It will be helpful to know from the people working on this if the offending functions are currently being exercised in our test code - is there a quick way to perform a static function call-tree discovery in Python? Or an Eclipse-like IDE available (I'm imagining one is)?

@cheelee I know people praise pycharm, though I've never used it myself.
As for a visualized call-tree, this exists, but I cannot verify how well it works.
For which functions are being used (same order as the original comment by Stephen):

some_neuron.connection.get() (not called)
some_cell.morphology() (skipped)
Neuron().load() (called among other functions)

I'm thinking that maybe writing a single test for each of these functions may be a place to start testing their performance, or setting up something that runs functions outside the test suite but still under the profiler. What do you think @cheelee ?

@travs Thanks for the links!! I think new test cases for each would work best while we sort out the testing/regression framework. Right now we have a framework that is capable of testing everything we have. A more refined one that can be tasked to test subsets is slightly further away I believe. Personally, I still need to acquaint myself with pytest.
Could someone familiar with the functions please write a simple test case (with minimal context) for each of them? I am assuming they are not stand-alone functions that can be invoked without context.

@cheelee I agree about writing individual tests for each function. I can do this up tonight. Will link the commit here when it's merged.

@cheelee Ok, added those functions. Note that morphology does not seem to actually be implemented, so we can just go with the other two for now.

@travs Awesome, will try to put them through their paces later today. Thanks!

@travs Just a quick update: I've patched in your new tests into a sandboxed version of the dev branch on my local machine, and they have been run using the py.test framework with the basic output captured in this gist: https://gist.github.com/cheelee/9a9a1fce712bcf786118
It is taking around 10 seconds for synapses and 2 seconds for neurons.
I'm currently waiting to hear back from @kevcmk because I lost his link to his fork which contains the profiling framework he has developed, but my next immediate step is to just directly use cProfile to generate more detailed performance information about the invocations down the call-tree that contribute to the 10 and 2 seconds respectively. I'll post any new information up as and when I get them.

Ok, this is clunky and I'm not sure how initially useful this will be, but this is the breakdown of the most expensive function calls made by any Python module. "Tottime" refers to all of the time spent inside a function's code segment. "Cumutime" refers to all the time spent inside a function's code segment AND any time spent by the child functions it invokes. Anyway, the goal here is to get people an initial idea of where time is spent for those 2 functions:
https://gist.github.com/cheelee/42be90eeee63ea1d4539 (Neurons Cumulative)
https://gist.github.com/cheelee/4772e75f4aa9c9a438f6 (Neurons Total)
https://gist.github.com/cheelee/cb9b3f33924a18988be6 (Synapses Cumulative)
https://gist.github.com/cheelee/d7b2c6610ca3d9383601 (Synapses Total)

@cheelee Thank you for this. After looking through those data it is apparent that we may need some way to profile those functions without wrapping them in test calls. I cannot find the original synapses call in the synapses outputs, so maybe if we do something like cProfile.run('net.synapses()') it will be a bit easier to know what is going on.
What you say here about callpaths would be particularly useful, it seems.

When we store the FunctionProfile object, we can instead seek out the actual function we're concerned with, as opposed to the test_* function
There are potentially a few ways to do this, two of which are: parsing the tests' name, decorating the test with a wrapper that takes a string argument of the function in mind

@travs @kevcmk In the performance profiles I've captured, I had also filtered out anything that did not include "PyOpenWorm" in its path string. The idea there was to only identify costly function calls that we are likely to have control over. It may well be necessary to figure out the costs of functions from associated library calls external to our packages. I can quickly generate output including that information if needed.
@kevcmk that works. However, it will not handle the scenario where multiple tests are part of the same run that merges their performance profiles, that is:
TestSuite (same run, same profile)
TestCase1 -> ... -> FuncA
TestCase2 -> ... -> FuncA
will have performance information for TestCase1 and TestCase2 merged for FuncA in a flat profile. In a callpath profile, we'll see the performance information partitioned according to the actual function call path at runtime. So we'd see something like:
TestSuite -> TestCase1 -> FuncC -> FuncA
TestSuite -> TestCase2 -> FuncD -> FuncA -> FuncA
And right away, it should be clear that callpath profiles are significantly more expensive for an instrumentor to collect, but worth significantly more where performance information is concerned.

I'm slowly starting to believe what we need to close this issue is not performance regression per se, but a decent way to conduct performance analysis for the "offending" test functions. We need to figure out:

if those tests really ought to take as long as they do - for that, we'll need domain experts who are familiar with the work that gets done in those tests, and to identify specific functions that appear to be behaving badly, or mis-used in the code.

how to fix badly-behaved functions if we find any.

I found a tool that might help with the analysis process: http://www.vrplumber.com/programming/runsnakerun/
Any thoughts?

That looks awesome.  I think we should consider looking into that code to find a way to generate that chart and upload it from Travis.

On Aug 14, 2015, at 7:18 PM, Chee Wai Lee<EMAIL_ADDRESS>wrote:
I'm slowly starting to believe what we need to close this issue is not performance regression per se, but a decent way to conduct performance analysis for the "offending" test functions. We need to figure out:
if those tests really ought to take as long as they do - for that, we'll need domain experts who are familiar with the work that gets done in those tests, and to identify specific functions that appear to be behaving badly, or mis-used in the code.
how to fix badly-behaved functions if we find any.
I found a tool that might help with the analysis process: http://www.vrplumber.com/programming/runsnakerun/
Any thoughts?
—
Reply to this email directly or view it on GitHub.

@kevcmk It is possible we may not need to do it at test-time. All RunSnakeRun needs is a valid cProfile profile, and it might just be we'd want to use it as an interactive analysis tool to figure out any performance problems outside of the testing/regression framework. It probably does not hurt however, to have Travis-CI generate a top-level image using RunSnakeRun to give an initial overview. Here's my image of the workflow vis-a-vis testing and regression using the ideas you have already developed:

perform test benchmarking to determine performance scaling factor.
apply scaling factor to individual test times.
mark each test that takes longer than a scaled-second.
(maybe) capture the cProfile of tests taking too long.
report in some CI workflow via github status API all the tests that went "wrong."
Conduct Performance Analysis on Tests.

This sounds good.  I'm e-meeting Stephen tomorrow late night to figure out the Travis statuses.

On Aug 14, 2015, at 9:24 PM, Chee Wai Lee<EMAIL_ADDRESS>wrote:
@kevcmk It is possible we may not need to do it at test-time. All RunSnakeRun needs is a valid cProfile profile, and it might just be we'd want to use it as an interactive analysis tool to figure out any performance problems outside of the testing/regression framework. It probably does not hurt however, to have Travis-CI generate a top-level image using RunSnakeRun to give an initial overview. Here's my image of the workflow vis-a-vis testing and regression using the ideas you have already developed:
perform test benchmarking to determine performance scaling factor.
apply scaling factor to individual test times.
mark each test that takes longer than a scaled-second.
(maybe) capture the cProfile of tests taking too long.
report in some CI workflow via github status API all the tests that went "wrong."
Conduct Performance Analysis on Tests.
—
Reply to this email directly or view it on GitHub.

Given what I know about what's limiting PyOpenWorm's performance, I don't see much value any more in continuously tracking performance of selected functions. Most of the delays should be dealt with as they become problematic or as part of a dedicated effort to speed things up in a particular effort.  There must be benchmarks to aid in such tasks, but they don't need to be formally tracked.

@mwatts15 that's a fair point.  This is a pretty outdated issue and is from the time when Travis and I were laser focused on expanding all things testing related.


wip: using {active, 100} instead of recv

A few quick benchmarks just on my laptop with wrk showed a consistent improvement over use of recv.
I'd like to try some more values of n including {active, once} both just to see if there are any clear differences and to tune the default. (Oh right, need to make n overridable as well before this is ready for possible merge.)

This needs a rebase of course, but would be nice to sneak into 4.0. Conceptually I'm down, so long as it's configurable in the end.

Cool. I'd like to get some performance testing done. This is a major change since elli wasn't even use {active, once} before.
This might be more useful in like http2 (plan to try it in chatterbox) or streaming http1 requests. When a body size is available it might be better to keep it as just calling recv with that size. Or maybe it isn't since it would be able to start receiving the next requests headers and body instead of blocking... I don't know, need performance tests :(

let's not rush it


Include Rancher-API

Hi Jan,
Currently it seems that this program is used to be bundled with an other program (like nginx) which then can be reloaded etc. via the shell exec command.
In my case i'd like to run the rancher-gen in an sidekick container and then notifying the "main" container every time if there are changes in the template, but this is currently not possible.
So i thought it would be great if the rancher-api is included in this program so rancher-gen is possible to send the notify-cmd or check-cmd over the rancher-api to the desired containers (multi-host capable).
In our fork @emcniece and I are currently working to enable notification support depending on an container label so rancher-gen would be able to execute its notify/check-cmd on each container with the specified label.
Currently we have 3 options to achieve the notification over rancher-api:

rancher-gen and rancher-api are running in its own containers and rancher-gen uses the -privileged function to execute the command on rancher-api which then send the command to the provided containers
rancher-api is directly loaded into rancher-gen and running the commands "directly?"
Maybe we can use something like go-plugin (rpc) to implement an plugin system into rancher-gen and rancher-api is than a plugin which can be dynamically loaded into rancher-gen

I hope you understand what i mean and it would be great if you can give us your feedback.

Just solve the problem by bundling nginx with rancher gen ! I post the image link in your github issue tracker

We want to avoid bundling nginx with rancher-gen at all costs so thank you for that repository but that doesn't solve the problem.


Licensing

Hi! Nice set of sample charts, I especially appreciated the stacked area example. I was hoping to make a simple adaptation and re-publish some of the code for the stacked area example in a github template repo that I expect may be forked a lot. But seeing as this code does not have any published license, this may be a bad idea.
Do you intend to apply a general open-source license to this repo and the example code in particular? (If you do and are unsure what license is appropriate, perhaps https://choosealicense.com can help. If not that's fine too.)
#30 is related but the author closed it before any discussion occurred.

Hi Joe,
Thanks for your message.
I have absolutely 0 knowledge on licensing and that's something I should be more interested in.
But for now I have absolutely 0 bandwidth for that :(. So please use the code how you want, but just cite the URL of the gallery 🙏
If you have any suggestion about how I should license appropriately, I'm interested.

I recommend using MIT license as it's quite permissive and will also protect you. If you're looking for more details or would like to compare licenses, you can have a look on https://www.tldrlegal.com/ or follow the guide here:
https://choosealicense.com/
If you're ok with MIT License, you can simply merge #98 👍
Feel free to close the PR and pick a different one if you prefer :)

thanks!!!!!


on iOS play/pause resets the playback speed to 1

Configuration
React Native Environment Info:
System:
OS: macOS 10.14.4
CPU: x64 Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
Memory: 73.02 MB / 8.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.15.1 - /usr/local/bin/node
Yarn: 1.9.4 - /usr/local/bin/yarn
npm: 6.9.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
Android SDK:
Build Tools: 23.0.1, 23.0.3, 24.0.2, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.2, 26.0.3, 27.0.3, 28.0.2, 28.0.3
API Levels: 23, 24, 25, 26, 27, 28
IDEs:
Android Studio: 3.4 AI-183.54<IP_ADDRESS>52501
Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
npmPackages:
react: 16.8.6 => 16.8.6
react-native: 0.59.6 => 0.59.6
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
react-native-track-player 1.1.4
Issue
On iOS whenever the playback is paused and then played the speed is reset to 1.
Code
TrackPlayer.setRate(2); // play at 2x speed
TrackPlayer.play();
TrackPlayer.pause();
TrackPlayer.play(); // the rate is reset to 1

@alangumer : I am facing same issue with latest version

I'm also having this issue - any work-arounds, or fixes? Thanks!

Faced this issue

I'm having this issue again with the latest version. It works on Android, but play/pause on iOS resets the speed back to 1.

Faced this issue

any updates on this?

Alright, friends. This is still an issue even in version 3.2.0, but I've taken an afternoon to isolate a specific minimal-code repro here.
It turns out the following sequence is problematic:
  await TrackPlayer.setRate(2);
  await TrackPlayer.play();
  await TrackPlayer.seekTo(position + 15);
  await TrackPlayer.play();

Specifically, if you seek while playing, and then call play() in the new position, it'll reset the playback rate. I've not debugged into SwiftAudioEx enough to figure out the cause, but this is at least a reliable repro.
You can check out the repo above, which includes both the code and instructions to get a quick repro. In the meantime, I'm going to dive into react-native-track-player and SwiftAudioEx in hopes that inspiration hits.

Okie doke. Fix for this 3+ year bug now submitted in this PR: https://github.com/doublesymmetry/SwiftAudioEx/pull/37.


Client dsl with body first

Builds on #2202

Call out for help, I have zero scalafix knowledge still.

I want to get this feature in place and I want to release.  Should we merge now and have a scalafix to follow?

I think that seems the best idea. Help out migration as soon as we can, get the baseline code in place first.


Feature/nwd 1044

I went and added some padding to the hover background on the CSET logo.

was set to merge to wrong branch


Temaki mangás

Source name
Temaki mangás
Source link
https://www.temakimangas.xyz/
Source language
PT BR
Other details
18+= NO
Acknowledgements

[X] I have checked that the extension does not already exist by searching the GitHub repository and verified it does not appear in the code base.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a meaningful title with the source name.
[ ] I have admitted that I am a clown by having checked this box, as I have not read these acknowledgements.
[X] I will fill out all of the requested information in this form.

The source no longer receives updates, so I don't think it's worth creating an extension


Repo sync for protected CLA branch

The pull request is created from main638022295444452874sync_temp to main to fix git push error for protected CLA branch

Learn Build status updates of commit 2eacce4:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

#assign: @corob-msft
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Learn Build status updates of commit 3f7bd2e:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel


Mismatches for mret behaviour between Spike and RTL

Whenever we see a mret instruction, Spike sets mstatus.mprv to 0 and that affects our LSU related PMP checks. Relevant commit that adds this functionality (that comes with newer privilege spec version 20211203) can be found at https://github.com/lowRISC/riscv-isa-sim/commit/327084128246e5cf562293cfe82d2570a6d5629e. Note that in privilege spec v1.11, this mret behaviour is not existing and we are officially supporting that version. So, it looks like we have two options

Keep spike in line with priv. spec. v1.11 for this one and do the same kind of patching for future mismatches
Update Ibex to priv. spec. 20211203

You can see the behaviour in the tests mentioned in https://github.com/lowRISC/ibex/issues/1694

Certainly the updated version seems more secure, if M mode is doing something using mprv and mret gets executed without clearing it U mode could end up with M mode access. It adds a new fault injection possibility (e.g. skipping to an mret or somehow inserting one when mprv is getting altered).

I tend to agree with updating to more recent privilege spec. I definitely agree that the changes that such a change would bring have to be understood (especially the major ones).
We could compare the sources of the specification (e.g., https://github.com/riscv/riscv-isa-manual/compare/Ratified-IMFDQC-and-Priv-v1.11...draft-20211203-cb99010) and filter for the files that form the privilege spec. That would still require careful examination of differences, but it would probably be less error-prone and more systematic than having the current and the target spec as PDF next to each other and comparing them visually.
Which spec version would we target?

I would target the last ratified version. Version 1.12 is currently under review, thus it would be the one Canberk referenced. The pdf lists the changes compared to 1.11 Ibex currently supports on Pages i and ii.

So looks like the ratified version is 1.12 it's just pending the integration of some extensions (such an ePMP)?
So really because we have ePMP I think we have to move to 1.12 as 1.11 with ePMP isn't an 'official' architecture config. In particular the mseccfg is defined in 1.12 but not mentioned at all in 1.11
Looks like the changes are very minimal, we'd need to add menvcfg but it can just read as zero and ignore writes.

Ah actually it's not so simple there's the menvcfg CSR which is new. Some of it relates to cache management extensions which may impact us due to the ICache. Potentially we can do a quick implementation of these (e.g. just treat any of the cache management operations that effect the icache as FENCE.I). More to investigate here.

Adding estimate of 32 as there are potentially many areas that will need to be investigated for privilege spec change.

Updated estimate to 2 to cover the work of reverting spike back to the old behaviour. New issue created to cover the move to v1.12 https://github.com/lowRISC/ibex/issues/1733
Remaining work here is packaging a new build of spike cosim so we can get the updated mprv behavior (no clearing) available for CI and regressions.

New version of spike cosim has been released that includes this fix