Using conditional requests (If-None-Match) to prevent exceeding API rate limit

Hi!
When using a Github button with a counter on a regularly visited page such as an admin panel, the user will potentially exceed it's Github API rate limit causing the button to stop working after some time. On pages with many buttons the rate limit can be used up quickly.
/**/_({
  "meta": {
    "Content-Type": "application/javascript; charset=utf-8",
    "X-RateLimit-Limit": "60",
    "X-RateLimit-Remaining": "0",
    "X-RateLimit-Reset": "1511616179",
    "X-GitHub-Media-Type": "github.v3; format=json",
    "status": 403
  },
  "data": {
    "message": "API rate limit exceeded for 123.456.789.123. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
    "documentation_url": "https://developer.github.com/v3/#rate-limiting"
  }
})

Github advises to use condition requests as a solution to prevent exceeding the API rate limit (and to save tons of useless traffic on Github's servers).

Most responses return an ETag header. Many responses also return a Last-Modified header. You can use the values of these headers to make subsequent requests to those resources using the If-None-Match and If-Modified-Since headers, respectively. If the resource has not changed, the server will return a 304 Not Modified.

https://developer.github.com/v3/#conditional-requests
It would be nice if the counter could be improved to make use of condition requests to save a lot of all API traffic from github-buttons.

This implementation of GitHub buttons does not have backend. Without a backend, it soly relies on browsers’ caching behavior to reduce requests. As far as I know, if you don’t do hard refresh, most browsers will use the caching and conditional requests. If you are still hitting the limit, there is nothing I can do about it. However, the button should at least render without a count when the API limit runs out.
An alternative solution is to implement a server side proxy for GitHub API, but that means all the users will share API limit, which would run out even faster due to the users number. Shield.io use this method, and their workaround is to let users donate API tokens as a pool. Still, they run out of the tokens from time to time and results in broken service.

Hi!
The browser doesn't add the headers automatically. I tested with Chrome 62 and Firefox 57.
Accept:*/*
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Cookie:_octo=...
Host:api.github.com
Pragma:no-cache
Referer:http://domain.local/wp-admin/admin.php
User-Agent:Mozilla/5.0 ...

It means that for any button there will always be 1 request to Github API.
A backend isn't needed to make it work. It would be possible to use localStorage and Fetch API with custom conditional request headers.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests
Using localStorage you could set a interval at which the API is queried for an update, e.g. once per 5 minutes and/or when the counter is clicked. On an high traffic admin page (imagine Plesk Panel) this will easily save millions of requests per day.

I have an implementation of using CORS instead of JSON-P working, caching is yet to be implemented, because I'm a little bit hesitated on the caching behavior, through.
As you pointed out, we can use localStorage to cache data, but it does not offer expiration control. Browser tends to have 5 ~ 10MB of localStorage quota. When go over the quota, an QUOTA_EXCEEDED_ERR will be thrown. So that we not only need to cache the data, but also need to remove them. A naive solution will be clear the whole localStorage when the QUOTA_EXCEEDED_ERR is thrown, and then keep as much data as possible. A nicer solution would be implement an LRU or whatever cache on top of localStorage, but obvious it would have more complexity.
Caching + conditional requests will reduce the requests count as long as the API data does not change, but this clearly depends on the activeness of a repository.
To really reduce the requests, an extra delay that you mentioned would be required. Maybe caching + conditional requests is already good enough for a repository with average popularity. However, maybe it's not good enough for super popular ones. Then, how long should that delay be? 5 minutes sounded too arbitrary.

The purpose is to reduce traffic so I believe that it would be OK to not worry about QUOTA_EXCEEDED_ERR and simply consider the localStorage cache as a feature that will provide caching for most buttons while the conditional request enables the API to optimize it's request processing. Quota management may be something to consider later to save even more traffic if it proves to be a significant benefit.
To enable automatic cleanup of browser cache it is possible to use sessionStorage. It has about the same browser support and it doesn't add extra code.
https://developer.mozilla.org/nl/docs/Web/API/Window/sessionStorage#Browser_compatibility
In regards to the delay. I am not certain what would be most favorable for Github. Do they mind buttons updating once per hour? Or would they be more happy with once per 12 hours? It may be an option to set it to 12 hours by default and enable to control the refresh interval using a data-attribute.
An other problem is that the buttons require multiple (5) individual requests per button (buttons.js 2x, buttons.css, buttons.html + Github API).

It may be an option to draw the buttons dynamically in a javascript controlled iframe with the CSS included in javascript. When using a dynamic iframe it is simple to write a CSS string to a <style> element. From a management perspective it is possible to use a build tool to dynamically replace a marker in the script with the latest CSS.
It would be possible to reduce the amount of requests to 1 static javascript file + uncached API requests (once per 12 hours) for unlimited buttons.

From MDN document on sessionStorage:

Opening a page in a new tab or window will cause a new session to be initiated, which differs from how session cookies work.

So it's useless in most of the cases.
For multiple request (html + js + css), certainly this is space to optimize. However, since GitHub Pages server set Cache-Control:max-age=600, which means all those file will be cached for 10 minutes, and only be loaded once per page no matter how many buttons there are. Also, GitHub Pages support HTTP/2. For browsers supporting it, multiple requests can be done with one connection.
GitHub API requests has Cache-Control:public, max-age=60, s-maxage=60, so that the same API requests (e.g. for a star count and a fork count) on the same page will only do one actual request.
As you can see many requests are from memory in your screenshot. So, personally I'm worried about repeated requests on the same page, since browsers handle this very well.

sessionStorage would enable to cache buttons for a specific website/admin panel. Only when navigating the web / starting new windows will cause a new API request for the same button.
The advantage of sessionStorage is that it takes less code and that there is less requirement for cache management. It could be added relatively easy and it would provide in a sufficient solution for buttons on actively browsed pages (e.g. admin panels).
In regards to the requests being cached by the browser, that is correct, however the individual requests cause a significant overhead.

A dynamic iframe could be much faster but I agree that it does not help much in reducing the amount of API requests. If you would want to optimize it, it would be an option to look at Shadow DOM as alternative for an iframe.
https://code.tutsplus.com/tutorials/intro-to-shadow-dom--net-34966
http://blog.catchpoint.com/2017/11/03/shadow-doms-encapsulation-progressive-web-applications/
https://www.polymer-project.org/2.0/start/quick-tour (cross browser solution from Google)

I won't use shadow DOM because it is not a stable standard and only Chrome based browsers currently support it by default. It still has a long way to go.
And it's entirely possible that a user open links in your admin panel in new tabs, and that would create a new session for sessionStorage.

A dynamic iframe may be the best solution for performance and compatibility. It would enable to include the buttons.js code inline to potentially draw the buttons with zero requests. It would enable to use the buttons more efficiently in a offline app or progressive web app. It would also reduce the amount of code so it would lead to the best performance possible.
In regards to the timeline. I can imagine Github buttons being used on more advanced apps. Every CPU cycle may count in those areas so for developers the less CPU is used, the better. Requests are very heavy to process, especially on mobile devices. It causes a great overhead. As an example, Google uses localStorage to cache assets in favor of simply using browser cache.

Tests by Google and Bing have shown that there are performance benefits to caching assets in localStorage (especially on mobile) when compared to simply reading and writing from the standard browser cache.
http://www.stevesouders.com/blog/2011/03/28/storager-case-study-bing-google/
https://addyosmani.com/basket.js/

If you want to optimize for CPU availability in heavy / critical apps where the buttons may be used, you could take a look at requestIdleCallback. It will ensure that the buttons will never get in the way of the app / website user. setTimeout(..,0) could make it work cross browser. It could be combined with requestanimationframe for optimal render performance.
https://developers.google.com/web/updates/2015/08/using-requestidlecallback
In regards to sessionStorage. I suggested it from your perspective as it would cost less time and it may be a sufficient solution. If just 50% of traffic could be reduced it would make a big difference. Together with the conditional requests it may be sufficient to solve the main issue (exceeding API rate limit, users being blocked from Github API).
localStorage + management would be a much better solution but it will cost more time to create a solution with the best efficiency and least amount of code.
In regards to a potential implementation. It may be an option to make it a non critical feature that simply provides caching 'if it works' and otherwise uses Github API requests. This could make management simple. If there is a quota issue, it would be possible to simply ignore it and load from a regular request. It would be up to the website owner / developer to manage the localStorage cache. Button counts do not take significant space so it may not require cleanup.

A dynamic iframe

If I understand you correctly, you mean an implementation like mdo/github-buttons, which uses a single HTML containing embedded <script> and <style> tags.
There is a reason to NOT do so. First, such <iframe> cannot be automatically sized, with the content being dynamic, you have to give a size that’s slightly larger than the actual content to give it some space to grow. For example, a different may render a wider content, going from 99 stars to 100 stars will results in a wider content, etc. But your <iframe> width has to be hard coded, which is annoying.
To automatically size an <iframe>, it has to be a same-origin <iframe>. But same-origin <iframe> could be accidentally altered by parent page JavaScript. That’s why we have the current solution:

Load buttons.js on parent page.
buttons.js create a same-origin <iframe>, and render it with an embedded HTML string.
The embedded HTML string will load the same buttons.js from cache, and render the button.
Once button is render, get and save its dimensions.
Reload the <iframe> with buttons.html instead of HTML string. This will be cross-origin.
Set the <iframe> size to be exact dimensions saved in step 4.

Given these steps, if you try to bundle JavaScript / CSS into HTML, it actually increases traffic.
If you really care that tiny bit of loading speed, make a fork and skip step 5, so that you can bundle HTML & CSS into JavaScript.

more advanced apps

Most of advanced web apps today are single page apps. They don’t reload the page thus buttons on the page is just a one time thing. Not so much meanings in optimizing it.

requestIdleCallback

Experimental API, so NO. Using setTimeout to make code execute asynchronously? I already use async as much as possible, expect for parts that are not necessary.
I won’t use experimental technology in production unless it’s widely supported and stable enough. Even if it can be fallback with code that’s more compatible, unless the benefit is significant, I’d rather wait for the API to be widely supported.

Conditional requests with XHR/CORS

First, unlike JSON-P which is essentially a <script>, XHR is isolated from page load event. When XHR load event is triggered, the callback has not been triggered, but in JSON-P, the load event means callback is already finished. And same for the error event.
Those are all extra layers of complexity, but I at least I can live with those, and I already have an experimental implementation of this.

localStorage / sessionStorage

This is where I get uncomfortable. We make compromises all the time in web dev, but I don’t like making compromises saying maybe that’s good enough.
—-
Going back to your admin panel example, as a compromise, the easiest solution would be disable the dynamic count. And if you really care about performance, put a static button directly on the page.
—-
I’m open to ideas. As always, Pull Requests are very welcome.

I just wanted to provide some ideas to consider. I understand that it may not be applicable for github-buttons. Besides the API limit / caching issue the buttons load fast and look professional/authentic.
We will be using the buttons on WordPress admin pages that are actively browsed by website creators during performance optimization.

requestIdleCallback has proven to be exceptionally effective (especially for widgets such as social buttons). It can enable loading a page with 1000+ buttons in 200-300ms while the buttons load smooth based on available CPU capacity. It may be an option to test it with a HTML page with 100+ buttons to see the difference. setTimeout could be used for any browser that does not support it (yet) so that the complexity is low and reliability is high.
In regards to the dynamic iframe, I understand your choice.
In regards to modern apps, a progressive web app (Google PWA) does load each page individually and has no ability to persist a button on the page.
https://developers.google.com/web/progressive-web-apps/
In regards to sessionStorage. If you're interested to invest the time, localStorage may be a better option. However, to quickly solve the main issue sessionStorage may be a safe and easy option.
I am not familiar with coffeescript and didn't know your exact wishes for the project.
I am interested to create a concept / pull request. What options would you be interested in?

requestIdleCallback and requestAnimationFrame
localStorage cache
conditional request based on XHR and/or Fetch API

PWA does not conflict with the idea of single page app (SPA). A web app can be both PWA and SPA at same time. A PWA won't necessarily be a SPA, and vice versa.

For browsers do not support requestIdleCallback, setTimeout changes nothing comparing to the current implementation. On the parent page, the buttons.js has attribute async and defer, and for code inside <iframe>, they are under a different context so the synchronous code does not block parent page at all. So requestIdleCallback may only help browsers supporting it.
Also, there is no magic about requestIdleCallback, parent page code and <iframe> code has to call it separately. My real concern is that the current implementation heavily relies on load, error, and readystatechange event on <iframe> and JSON-P <script>. I detect (<iframe>'s load event (and JSON-P <script>'s (load or error) event if exists)) from the parent page to determine the first time a button get rendered. Adding requestIdleCallback means that the current detection method is no longer working.
Instead, in the step of The embedded HTML string will load the same buttons.js from cache, and render the button.:
On the parent page:

Wait for <iframe>'s load event so that contentWindow will be accessible.
See if loaded is true in <iframe>. If true, we're done (unlikely to happen), otherwise, set up the  hook function onload in <iframe>, and wait for the hook to be called.
Go to the next step to get the button dimensions.

In the <iframe>:

The code shall run with requestIdleCallback.
It should setup a flag loaded if the button is fully rendered.
It should call a callback hook function onload if it is set up when the button is fully rendered.

To JSON-P, the current implementation, "fully rendered" means <script>'s native load or error event.
To CORS, "fully rendered" means it has ((a 200 response and callback is completed), or it has a non 200 response, or CORS' error event). That's already a lot of code to write and test.
What I want to say is: it's really complicated.

For your worst 1000 buttons example, a workaround would be load buttons.js as a CommonJS module, and manually call render() after all important stuff has being loaded.

I would consider CORS XHR + Conditional requests + LRU localStroage cache with JSON-P fallback.
I'm open to requestIdleCallback, but it will be a super low priority, because of the complexity.

requestIdleCallback will benefit Firefox 55+, Chrome 47+ and Opera 34+. Chrome has a 60% market share so it will benefit about 70-80% of all browsers.
The benefit of requestIdleCallback is significant and in essence the functionality is very simple. It simply enables to prioritize javascript execution. It makes it possible to start loading the buttons when CPU is available. On a fast desktop PC there will be no delay while on a overloaded mobile phone the buttons may be delayed for 10+ seconds allowing the main page to be loaded much faster. It will make the buttons more friendly to a page. It sets the priority of the buttons to a lower level so that it won't compete for resources with the main javascript of a page.

parent page code and  code has to call it separately

It would be sufficient to add it in the parent code only (before the iframe is added to the DOM).
Example:
// requestIdleCallback, run tasks in CPU idle time
var idleCallback = function(task, timeframe) {
    if (window.requestIdleCallback) {
        // shedule for idle time
        window.requestIdleCallback(task, {
            timeout: timeframe
        });
    } else {
        // not supported, run task immediately
        task(); // or setTimeout(task,0);
    }
};

// draw buttons
idleCallback(function() {
// original code to insert iframe etc.
},10000); // allow waiting for 10 seconds, then force execution of code

In regards to the CORS XHR + Conditional request + localStorage + JSON-P solution. What you describe is in essence a simple format that should be written in Coffee script. There is nothing special to consider. It appears to be a perfect solution that enables optimal caching.
I am interested provide some examples however I have no experience with Coffee script so it may be best if you would add a solution that would best fit the existing buttons.js.

delayed for 10+ seconds

That’s way too inconsistent. Thus it should be called by users (developers) if wanted instead of a default behavior. On a page there is usually only one or two buttons, which does not slow down the page loading much. If someone really care, as I mentioned in previous comment, you can manually load the library and call the render function. You can then wrap the call with requestIdleCallback.
const { render } = require(‘github-buttons’)

if (window.requestIdleCallback) {
  requestIdleCallback(render)
} else {
  render()
}

It would be sufficient to add it in the parent code only (before the iframe is added to the DOM).

If the end goal is just to delay the start of loading, but not low the priority of the whole loading process, manually call the function would be sufficient, but it could deliver a worse user experience. At the point when it starts loading buttons the browser would be idle, but what if at the same time when code in<iframe> starts, the app code becomes heavy loaded and busy again. Now the code in <iframe> would compete with app code. On a not so powerful device, what user may see then is lagging in app experience itself rather than just lagging in app loading, which to me is clearly worse. That’s why I said you need to call it everywhere to lower the priority of everything if that really matters.

I agree that it may be something for developers to apply manually.
In regards to your arguments however, requestIdleCallback is not intended to delay the loading process, it is intended to enable the browser to delay the loading when it is executing other code (to avoid a race condition during critical execution time).
For a desktop browsers there may be no delay (loading starts in 2-3 ms) while on a mobile phone it may be delayed for 10 seconds (it could be set to 1 second). If the browser decides to delay the code for 10 seconds it may have a good reason to do so. Are the buttons really essential for those devices? In general, requestIdleCallback will load the code as fast as possible so it's not really downgrading code, it's simply optimizing it to make optimal use of 'time in between' windows that are available during code execution.
The buttons will start loading immediately when execution tasks finish (this is what is meant with 'idle'). In practice, a websites script may be active for 100-200ms up to 1 second during a page load. The buttons would start loading instantly when the main script has been processed, or when it simply has some room in between (a few ms would be sufficient).
Example:
var work = function() { var x = 0; for (var i = 0; i < 10000; i++) { x += i; }  };

// Test 1
console.time('setTimeout(fn,0)'); console.time('requestIdleCallback 0');
setTimeout(function() { work(); console.timeEnd('setTimeout(fn,0)'); },0);
requestIdleCallback(function() { console.timeEnd('requestIdleCallback 0'); },{timeout: 1000}); // exec in 1 second

// Test 2 (apply tests individually)
console.time('setTimeout(fn,2)'); console.time('requestIdleCallback 2');
setTimeout(function() { work(); console.timeEnd('setTimeout(fn,2)'); },2);
requestIdleCallback(function() { console.timeEnd('requestIdleCallback 2'); },{timeout: 1000}); // exec in 1 second

In the above tests, the first test shows that the idleCallback waits until the work of setTimeout is completed, while with a few ms delay, it will be executed instantly.
Test 1:

Test 2:

In regards to the requirement to include requestIdleCallback in the iframe and other area's. The primary function is allow the main code of a page to execute more efficiently. When the browser indicates that there is a time window for the buttons to load, it will simply be able to make full use of that opportunity from then on. If the main code then suddenly starts other code execution, that may cause a race condition but the probability will be low. In the current situation the code is loaded via JSON-P causing the exact same situation (the render call is made as soon as the JSON-P request finishes). There is more chance to not cause a race condition by applying a single requestIdleCallback on the render method.
In regards to the benefit from including it as a default feature, it will make the buttons more friendly to diverse real world situations. Browsers will have an ability to hold the code off when it is overloaded so that a website or app has a better chance of satisfying the user with the available resources. The buttons will load within a defined time frame, so if it would be critical to load the buttons within 100ms that would be possible while 100ms still offers a big space for critical code execution.
A time window of 1 second may not cause a noticeable delay in loading of the buttons on slow devices while it would provide the page 1 second of time to use 100% CPU if needed. On powerful devices the buttons would still load within a few ms after the render call.

Looking at Google +1 button, Facebook button, and Twitter button:

Facebook: https://connect.facebook.net/en_US/sdk.js
Twitter: https://platform.twitter.com/widgets.js
Google +1: https://apis.google.com/js/platform.js

Only Twitter's code contains requestIdleCallback. However, if you set a breakpoint on that, you will find that it's only used on embedded tweet / timeline to dynamic resize when viewport changes. The twitter buttons do not use requestIdleCallback at all.
To align with the major buttons providers, a potential 10 seconds delay is clearly an unexpected behavior. If those buttons changes their behavior in the future, I will reconsider it at that time. Thus, the conversation about requestIdleCallback ends here.

Revisiting the workflow as below:

Load buttons.js on parent page.
buttons.js create a same-origin <iframe>, and render it with an embedded HTML string.
The embedded HTML string will load the same buttons.js from cache, and render the button.
Once button is render, get and save its dimensions.
Reload the <iframe> with buttons.html instead of HTML string. This will be cross-origin.
Set the <iframe> size to be exact dimensions saved in step 4.

localStorage does not carry cross-domain. In step 2, localStorage belongs to parent page's domain, In step 5, localStorage belongs to buttons.github.io.
I don't think it is a good idea to pollute parent page's localStorage, but without cache conditional requests won't work. So let's say we use parent page's localStorage anyways. Now in step 5, code in the <iframe> won't be able to read the localStorage on the parent page's domain.

If it is the first time access an API (say, /users/ntkme):

Parent sends non-conditional request and gets response from server.
buttons.github.io sends non-conditional request again, and gets response from browser's cache.

In this case it's same as current JSON-P.

A user would visit different parent page, and they cache different API separately, so they don't run out of space. However, at a point buttons.github.io run out of space, and started purging data.

Assume /users/ntkme gets purged in buttons.github.io's localStorage, but parent page still has it:

Parent sends conditional request, and gets response from server.
buttons.github.io sends non-conditional request, and gets response from the server.

Also it's possible are parent page application also uses localStorage, and it ran out of space.

Assume /users/ntkme get purged in parent page's localStorage, but buttons.github.io still has it:

Parent sends non-conditional request, and gets response from server.
buttons.github.io sends conditional request, and gets response from server.

In either case that one of the two cache get dropped, even though it uses same amount of API limit comparing to current JSON-P, it doubles the actual requests that went to the server. So the only case it does better is when both parent and buttons.github.io has cache.
I'm not saying it won't work. In fact, it would work most of the time in theory. However, it would not only pollute the parent localStorage, but also save lots of messy duplicated data.

To avoid duplicating at least two copies of cache on multiple domains, it's possible to save it only on buttons.github.io and share it with parent using postMessage API with an extra <iframe>:

With in the <iframe>, add a message listener that accepts origin buttons.github.io.
With in the <iframe>, create a second <iframe> for a page in buttons.github.io.
In the second <iframe> page, load the API (with cache + conditional request), then postMessage to parent domain.
In the first <iframe>, receive the API data, and continue.

But this could mess up as well if parent page already has a message listener that does not check origin.

Let me know If you have any better ideas.

My apologies for the delay.
In regards to passing data to buttons.html, it would be possible to load buttons.html using a hash, e.g. buttons.html#1233. The request would use browser cache and extracting the count from the hash costs a few bytes of code.
In regards to overall performance, it seems that the buttons load OK and fast. I believe that a dynamic iframe could increase performance a lot (cached requests cost significant overhead) but the main issue is exceeding the API rate limit / getting blocked by Github so it may be sufficient to keep the existing code and simply add localStorage and conditional requests.
In regards to localStorage space, I believe that it would be OK to simply ignore QUOTA_EXCEEDED_ERR. It would be an option to use a try { ... } catch(e) {} and if it fails, simply ignore it. It would be impossible to know what data is safe to delete so it would be better to leave it up to the site. The buttons won't consume much space. For situations where localStorage fails, the buttons will depend on API requests. For most of the buttons the API rate limit issue would be solved.

We still need a localStorage, and in your proposal it will be the parent domain one.
I simply don't think polluting parent domain's localStorage is a good idea. It's not about the amount of space it uses, but it's more of the namespace - we don't own the parent domain. Although we can prefix all the keys to emulate a namespace, we still cannot assume that it won't cause any side effect to the parent domain, or parent domain code won't cause any side effect to our code.

I believe that it is OK for a social widget to make use of localStorage.
localStorage in essence is like a cookie. If you use a name space it should not cause any problems. To prevent issues it would be possible to use sessionStorage. It would lose the cache when closing tabs however it prevents pollution of localStorage and I believe that it will be sufficient to solve the Github API rate limit issue.
https://scotch.io/@PratyushB/local-storage-vs-session-storage-vs-cookie
You could also consider a JSON cookie and a short URL hash. The conditional requests could be based on a single time stamp of the API request (If-Modified-Since). The counts would cost space per button. 10 buttons would cost about 100-150 bytes in space.
http://hashids.org/

In regards to passing data to buttons.html, it would be possible to load buttons.html using a hash, e.g. buttons.html#1233.

I already use this method to pass data around. However, I won’t pass the count to the <iframe>. If you look at mdo/github-buttons, there is a user case of directly put the final <iframe> into parent page. Using hash to pass the count means two things:

It’s could be a breaking change for the use case I mentioned above, unless I maintain two versions.
As it’s possible to pass any number, it may no longer represent the truth.

After putting those into consideration, it’s not really an option to store the data in parent domain and pass it into our domain. As I said before the other way around, store on our domain and pass it to parent could work with postMessage. Or, just keep duplicated copies on both domains.
I would pick postMessage method if I have to pick one, but still I don’t like that solution.

sessionStorage would leave localStorage free and cross-tab / window cache may not be essential to solve the Github API rate limit issue. sessionStorage also provides in automated cache management.
In regards to the postMessage solution. A combination with sessionStorage could enable a single request for buttons.html for each button. Using a onload on the iframe could trigger a postMessage from the parent with the button config and count.

My suggestion of using postMessage is to avoid touching parent domain cache, and having all the cache in one place to max the benefit of conditional caching. In my case, when the <iframe> receive a request via hash, it will request an API if it's not cached, and post a message containing the API data. No harm can be done.
Your proposal is totally different. Even if you use onload and only accept the message once to minimize the chance of receiving a message that we're not supposed to get, since the listener has to be set before onload, there is a time frame before the onload that parent domain code can simply do this to  screw it:
setInterval(function () {
  postMessage("1234", "*")
}, 10)

Of course, you can add a checker in the listener:
let onceToken = 0
window.addEventListener("message", function (event) {
  // ignore messages that's not from parent domain
  if (event.origin !== "parent.domain")
    return
  // ignore messages come in before our page is fully loaded
  if (!(/m/.test(document.readyState) || (!/g/.test(document.readyState) && !document.documentElement.doScroll)))
    return
  // only accept the first message
  if (onceToken === 0 && onceToken = 1) {
    // do work here...
  }
}, false)

However, even with that level of sanity check, it's still possible to get screwed.
To make it harder, we can generate a random token, and pass it to the <iframe> via hash, then in the message also pass the same token to validate. However, since it requires passing it down to <iframe> via hash, there is no way to hide it. So, still can get screwed.
That's bad security.
You may say: it's just a button and no one will get harmed. What's the point of security,
There is indeed a point. Code security is part of code quality. In some rare cases, one might compromise  security to make something work given specific conditions, but for open source it's must have a strong security standard. Even if there is no harm in this particular case, it's entirely possible other coders might copy part of the code with no knowledge of how this work, and introduce a security loophole in their project.
There was a paper about this: Leveraging Flawed Tutorials for Seeding Large-Scale Web Vulnerability Discovery Well, the paper itself is not super interesting, and their example is SQL injection done by concatenating string to build query. That's extreme comparing to our case.
I don't want to in anyways teach people writing insecure code.

Another reason for insisting doing cache in our domain is trust. Since this is a JavaScript based implementation, which basically means people have to trust it to not do anything malicious. Without knowing what the script is doing, accessing other domain's localStorage, sessionStorage, or cookies is just one step away to a malicious behavior.

I understand your concern about security and for not wanting to access localStorage or sessionStorage on the parent domain.
A solution may be to load the iframe with the username as a hash, use postMessage to the parent to communicate the count and do the size calculation in the background to optionally resize the iframe.
For modifying the size of the iframe I would suggest to have a look at requestAnimationFrame.
https://developers.google.com/web/fundamentals/performance/rendering/optimize-javascript-execution#use_requestanimationframe_for_visual_changes

From the link that you provided:

Avoid micro-optimizing your JavaScript
It may be cool to know that the browser can execute one version of a thing 100 times faster than another thing, like that requesting and element’s offsetTop is faster than computing getBoundingClientRect(), but it’s almost always true that you’ll only be calling functions like these a small number of times per frame, so it’s normally wasted effort to focus on this aspect of JavaScript’s performance. You'll typically only save fractions of milliseconds.

That's indeed the point.
If you profile a page that has nothing but only 100 buttons, you will see >65% of time was spent in "Scripting", <5% of time on "Rendering" and only <0.1% on "Painting". On this particular machine I'm using, "Rendering" + "Painting" uses ~180ms, which is about 1.8ms per button. So, even without testing I would know that it will "only save fractions of milliseconds".

I do not agree with that statement. It may be a good advise for the novice web developer who seeks to address web performance (in order to prioritize their time efficiently) but in my opinion it is not a good advise for the more experienced developer.
Micro optimizations cost a ton of effort and it is true that it is essential to prioritize the major optimizations in favor of micro optimizations, and the way that Google describes it is also correct in itself (a few micro optimizations do not provide a significant benefit), however, 1000 micro optimizations add up. As a core practice - taking the extra effort from the start - micro optimizations will enable to achieve significant better results that are more reliable.
500μs = a fraction of a millisecond. 100 * 500μs = 50ms = a lot. 100ms = users start to feel that there is a delay.
Issues covered in micro optimizations do not stand on itself. They also interact with and influence each other, sometimes causing an exponentially increasing performance hit.
In regards to the buttons. They will be added on almost any type of websites. Websites in general become more and more javascript heavy, demanding more and more from the devices / CPU. If the buttons would save just 1ms it will simply be one of the 100 factors that could potentially save 1 full second. In itself 1ms is negligible. Together with just 100 other factors on a website, it is a major aspect that deserves optimization.
requestAnimationFrame is listed as a major optimization by Google. Just think about the unique situation that is described by Google where 2-3 buttons start loading at the end of a frame causing a small visual jank in the rendering. It could simply have been prevented.
I understand that you may consider it a waste of energy and time. I just wanted to share my perspective in regards to the benefits of micro optimizations as a best practice.

Just think about the unique situation that is described by Google where 2-3 buttons start loading at the end of a frame causing a small visual jank in the rendering. It could simply have been prevented.

Seems you have a misunderstanding here.
JavaScript is single threaded. So, requestAnimationFrame would temporarily block other code from running at the beginning of a frame and then start its callback to give it an opportunity to not miss a repaint in this frame.
First, buttons are not animations, so buttons themselves will not have visual janks. If it starts rendering in the later part of a frame, it will simply miss the opportunity to be painted in the current frame, and will be painted in the next frame.
If you are concerning the high CPU of button code that may cause the other animations on the parent page to have janks, as long as the parent page utilizes requestAnimationFrame, it should get higher priority and be in good shape.
If we use requestAnimationFrame and the parent does not, it helps nothing, because we can block parent page code and it may cause jank in parent page animations.
If both the button and the parent page have it, they will compete with in a frame, which may again cause a jank. Really the best optimization here is to not use requestAnimationFrame, and let parent page do it if needed.

requestAnimationFrame does not block other render processes. In practice, it will cause less stress during a page load and the buttons will be rendered smooth on physical domready.
https://swizec.com/blog/how-to-properly-wait-for-dom-elements-to-show-up-in-modern-browsers/swizec/6663
The buttons are part of the render and paint process during a page load. My argument is that no matter how small the impact is on performance, any saving will have an impact on a website's ability to satisfy a individual visitor in any situation. Together with 100s of other aspects it will add up.
requestAnimationFrame optimizes the following which applies to the buttons.

The browser can optimize concurrent animations together into a single reflow and repaint cycle, leading to higher fidelity animation. For example, JS-based animations synchronized with CSS transitions or SVG SMIL.

https://github.com/vasanthk/browser-rendering-optimization/blob/master/README.md
In regards to the iframe. When the iframe is rendered within a rAF callback the browser has the opportunity to optimize rendering of the DOM change invoked paint that includes the iframe. It is sufficient to leave it up to the browser.
https://codepen.io/danieldiekmeier/pen/mWRjzb
I understand it if you prefer not to use it, I just wanted to suggest it as an option.
The main issue is the Github API rate limit / users getting blocked from Github.

It may not block “Rendering”, but any single JavaScript code executing must block other JavaScript code from running, as it’s single-threaded. Thus the parent page code that triggers rendering (e.g. JavaScript based animation) could indeed be blocked from running, which would result in a visual jank.
Say you have a callback that would takes more than 16.67ms (a frame based on 60fps), putting it in requestAnimationFrame will guarantee it starts at the beginning of a frame. During the whole frame, it will block other JavaScript code unless another callback gets a similar or higher priority. If another callback for animation shall be run in this perticular frame, with a lower priority it would miss its chance and results in a visual junk. Thus requestAnimationFrame should be primarily use by things that are frame sensitive (which is indeed animation).
Resizing a button only takes less than 1 frame of time, no matter which frame it is, and the reflow would happen anyways no matter if you request requestAnimationFrame or not. Each button on a page would take a random time frame whenever it comes to resize. If it’s lucky and two buttons get resized in the same frame, two reflows will become one reflow. However, that’s very unlikely to happen due to each button loads asynchronously.
Multiple callbacks registered by requestAnimationFrame will be grouped in the same frame only if they are all registered with requestAnimationFrame in the same previous frame. Again, because each button loads asynchronously, even with requestAnimationFrame, we will ends up with the same situation - each button cause a reflow in a random frame unless it gets lucky.
Let’s be clear that requestAnimationFrame on resizing only saves time when those reflowing is end up being bundled with other rendering event with in the same frame. With requestAnimationFrame it will land in next frame, without requestAnimationFrame it will land in the current frame. If there is no other rendering in those two frames, there is no improvement.

The real micro optimization is to group the reflows caused by multiple buttons into a single frame, which means no buttons will appear until all buttons are ready. This is what Google refers as Avoid Large, Complex Layouts and Layout Thrashing according to your link.
Regarding your example:
Insert <iframe> into DOM is a tricky one, because most of the browsers today share the same thread between parent page and <iframe>. The browser will first load DOM in <iframe>, then a reflow happens on parent page. Thus insert <iframe> is costly.
On my machine, the "adding iframes" in the following example takes less than 300ms:
console.time('adding iframes')
let a = 0
while (a++ < 100) document.body.append(document.createElement('iframe'))
console.timeEnd('adding iframes')

console.time('resizing')
ref = document.getElementsByTagName('iframe');
for (i = 0, len = ref.length; i < len; i++) {
  iframe = ref[i];
  iframe.style.height = '500px';
  iframe.style.width = '500px';
}
console.timeEnd('resizing')

On average insert one <iframe> would take less than 3ms, and requestAnimationFrame basically space it out to use first 3ms in each 16.67ms frame to load <iframe>. In that case it does have a little benefit. However, I shall remind you we're testing empty <iframe> here. appendChild is synchronous, but <iframe> loading is synchronous. requestAnimationFrame shall insert a new iframe every 16.67ms, but if loading an <iframe> take than 16.67ms, using requestAnimationFrame will still cause scripts to compete in the same time frame back-to-back.
Now here is the important part: "resizing" 100 <iframe> takes only less than 0.3ms in total in the example above as it's all done in the same 16.67ms frame causing a single reflow. That is what I said previously, the real optimization is to group reflowing and repainting events into same frame. If you try requestAnimationFrame on resizing, what can be done in 0.3ms will be spaced out to into multiple frames, causing every single frame to have an reflow, a.k.a Layout Thrashing, which is much more expensive.

With that said however, grouping all the reflow in the real world means a huge complexity of wrapping all buttons loading with Promise.all() or equivalent. By the way, we don’t have control on other buttons services, so we cannot group them with us. That means things could not add up in a straight manner like you would expect.
On average there are less than three of github buttons on a page. So even if we implement a complex mechanism, the average benefit will be saving less than two frames of reflowing. - that’s a fraction of a milliseconds, which is exactly a micro optimization that’s not worth doing.

Nevertheless, I would thank you for giving an opportunity for me to deeply looking into some new technology I was not aware of.

The main advantage of requestAnimationFrame for the buttons is that the rendering of the buttons would be scheduled for the moment that the browser is ready to paint to the screen, thus providing a lot more CPU time for expensive scripts that may be running on a page during a page load. In practice, requestAnimationFrame would cause the buttons to start rendering on physical domready.

Inserting <iframe> is relatively lightweight and synchronous. Loading <iframe> is heavy, and it's asynchronous from the parent page perspective, but within the <iframe> the page loading itself is synchronous. So we can model inserting button <iframe> with requestAnimationFrame like:
requestAnimationFrame(function () {
  setTimeout(aHeavyComputingFunction, 0)
})

requestAnimationFrame is supposed to run some light weighted callback before the repaint, to paint within the given frame with minimal overhead. However, we're running some heavy stuff instead, and that heavy code requires a long time before it will really trigger what a browser would concern as "Rendering" (remember ~65% time in "Scripting"). At that point it may simply missed the given repaint frame.
From that perspective, we're not using requestAnimationFrame as it was intended. We're now using it to delay the beginning of the heavy execution. Because we cannot use requestIdleCallback which could delay execution for a unknown time, so we should use requestAnimationFrame instead to delay it for a random time between 0 - 16.67 ms? Why don't just do setTimeout() to have a guaranteed delay then?
That is abusing features.

My argument is that relatively light weight is a major factor when seen as part of 100 similar factors. If the buttons would be able to reduce the load by just 1ms, it would be a significant advantage. From my perspective, it would be best if the buttons would never get in the way of the page load / rendering of a website or app and would load based on available CPU resources once the page is already visible to the user. On some devices the buttons may be delayed for a few seconds to provide a faster time to interactive and on other devices the buttons should load instantly without an additional delay compared to the current format. The buttons are an 'addition', almost never a primary feature.
requestIdleCallback is a solution that enables to achieve the described result.
https://developers.google.com/web/updates/2015/08/using-requestidlecallback
requestAnimationFrame is also able to provide a similar result when specifically applied to DOM changes and in the context of a page load. I agree that you can consider it a sort of abusing of a feature, however, the result is what matters.
In regards to the iframe, Google is planning to make cross origin iframes multi threading which would enable to do more heavy work in the iframe.

Subframes are currently rendered in the same process as their parent page. Although cross-site subframes do not have script access to their parents and could safely be rendered in a separate process, Chromium does not yet render them in their own processes. Similar to the first caveat, this means that pages from different sites may be rendered in the same process. This will likely change in future versions of Chromium.

https://www.chromium.org/developers/design-documents/process-models

When you abuse requestAnimationFrame for 100 similar factors you are pretty much guaranteed to have exactly 100 separate repaints / reflows, versus without it you get at max 100 repaints / reflows based on the order of execution. Say that we can finish 4 buttons per 16.67 ms, then we have 25 repaints without requestAnimationFrame, with requestAnimationFrame we have 100 repaints - that's Layout Thrashing.
More complex a page is, the layout trashing cost more. You cannot simply say it will reduce the load time without analyze the possible side effect. Things do not become faster just because a Google article says so.
requestIdleCallback is the right solution to delay execution. In the previous comment, I have already made clear that it will not be the default behavior. It up to the user to use the API exposed by this library, and wrap it when needed.
I've heard that Google is going to do multi threading for cross-origin <iframe>, but remember that in this implementation we do a two pass rendering, the first pass is in a same origin <iframe>, and that is never going to be on a different thread.

requestAnimationFrame actually prevents layout trashing.
http://wilsonpage.co.uk/preventing-layout-thrashing/

All rAF callbacks always run in the same or next frame of work
Any rAFs queued in your event handlers will be executed in the same frame.
Any rAFs queued in a rAF will be executed in the next frame. (Same for any queued within IntersectionObserver or ResizeObserver callbacks.)
All rAFs that are queued will be executed in the intended frame.

https://medium.com/@paul_irish/requestanimationframe-scheduling-for-nerds-9c57f7438ef4
rAF callbacks are stacked so if you would draw 50 buttons at once, it will complete the work for 50 buttons and then paint to the screen (1 repaint).
In the context of a page load, which would apply to the buttons, rAF could provide a similar advantage as requestIdleCallback.
There are several options for optimization. It would be possible to use a javascript inserted rel="preload" as="document" for browsers that support it with a onload handler that triggers a rAF that draws the buttons on the screen. It would reduce the load on the main thread and drawing the buttons would be smooth and efficient.
https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/
https://developer.mozilla.org/en-US/docs/Web/HTML/Preloading_content

You cannot simply say it will reduce the load time without analyze the possible side effect. Things do not become faster just because a Google article says so.

I agree. If you would be interested to try an optimization solution it would be best to create a test to measure it's benefits.

Following are examples for loading 10 cross-origin <iframe> without and with requestAnimationFrame.
const loadIframe = function () {
  const iframe = document.createElement('iframe')
  iframe.src = 'http://buttons.github.io/buttons.html#href=http%3A%2F%2Fbuttons.github.io%2F%23&data-icon=octicon-star&data-text=Star&data-size=large'
  document.body.appendChild(iframe)
}
let i = 0
while (i++ < 10) loadIframe()

const loadIframe = function () {
  const iframe = document.createElement('iframe')
  iframe.src = 'http://buttons.github.io/buttons.html#href=http%3A%2F%2Fbuttons.github.io%2F%23&data-icon=octicon-star&data-text=Star&data-size=large'
  document.body.appendChild(iframe)
}
let i = 0
const callback = function () {
  loadIframe()
  if (++i < 10) {
    requestAnimationFrame(callback)
  }
}
requestAnimationFrame(callback)

Putting requestAnimationFrame in our use case will cause layout trashing due to the nature of this implementation. Now you have a benchmark to look at so I don't have to repeatedly explain the same thing over and over again. Look at the (14 - 3 = 9) extra frames, ~5 ms extra time in rendering and ~2 ms extra time in painting. Exactly what I have explained! So please stop pasting links and claiming them as universal truth without considering any specific use case.
You may say that when a page has 100 <iframe> buttons, even if requestAnimationFrame causes layout trashing, it appears to be smoother. That is true, but that's only because it spaces out the heavy work and paints much more frequently, which would eat more CPU in the end.
For the typical use case which is a tiny number of buttons, using requestAnimationFrame does not give parent page much time for execution. It would actually perform worse in terms of both loading time and total CPU time.

Preloading cross-origin document requires CORS headers. I’ve looked at preload long time ago, and at that time GitHub Pages did not have CORS “Access-Control” header. I just checked again and now they set it to “*” so preload should be feasible now.

The test isn't realistic. You are comparing rendering in 100% CPU time without a page load context. In the real world the requestAnimationFrame would function like a prioritization mechanism allowing the app to load faster and the buttons to render smoothly.
Further, in your test you are writing the iframes in separate frames on purpose. requestAnimationFrame could serve as a callback stack that will write all DOM changes in 1 frame. Simply writing 20 iframes to the DOM is actually layout trashing while correct usage of requestAnimationFrame would prevent it.

Oh My. First, please don’t say it’s on purpose. I modeled it from a link you pasted in previous comment: https://codepen.io/danieldiekmeier/pen/mWRjzb
And here is the result for you new example:

First timeline looks exactly same as my example without requestAnimationFrame. What happens here is that you delay the start of the benchmark by a random 0-16.67 ms. And everything after that is the same as the example without requestAnimationFrame.
Again, I have said multiple times: when abusing requestAnimationFrame to lower the priority of its callback in the scheduler, it's actually done by delaying, and it does not really lower the priority of any work in it once the callback starts. Putting in the app context means you will only save a single random 0-16.67 sec for the parent page. That's all.

<link rel="preload" href="https://buttons.github.io/buttons.html" as="document" crossorigin="anonymous">

Chrome warns, <link rel=preload> must have a valid `as` value. It turns out Chrome does not support preload as="document".

In the context of a page load the callback behaves differently. I've put the requestAnimationFrame test on a regular website (www.people.com) and the callback fires in 500-600ms.

As the buttons basically perform just DOM mutations, requestAnimationFrame is a method for optimizing the priority of the work to the moment that the browser is ready to paint to the screen. Drawing 2-3 buttons doesn't cost significant time but during a page load a lot is being done. The browser on a heavily loaded mobile device could be processing 3MB of CSS code + 1MB of jQuery scripts that also modify the DOM. The buttons could start to compete for resources during the critical phase of a page load while the buttons are not a critical feature of most websites.
Simply inserting the iframes + modifying it's size will cost significant effort in a mobile device during a page load. requestAnimationFrame could reduce the stress significantly.
My argument is that it may be best to optimize the loading of the buttons so that they will load as fast as possible, but never get in the way of the primary parts of a website during a page load.
In regards to the buttons, an option to investigate could be to use 2+ requestAnimationFrames so that the buttons would start to render after the primary parts have been painted to the screen, enabling an app to load a fraction faster while the buttons would render almost just as fast.

From MDN:

requestAnimationFrame() calls are paused in most browsers when running in background tabs or hidden s in order to improve performance and battery life.

Did you tested it with the window not visible or not focused so that it is considered as background tabs, and the callback is delayed? I tested the following for on people.com for more than 20 times on both Chrome and Safari, it consistently fired with in 17 ms.
console.time('fire')
requestAnimationFrame(function() {
  console.timeEnd('fire')
})

Simply inserting the iframes + modifying it's size will cost significant effort in a mobile device during a page load. requestAnimationFrame could reduce the stress significantly.

This is something you misunderstood. Look at the profiler result again, "Scripting" is where the most cost comes from, which means the logic code before inserting, and code in <iframe> are taking the most CPU time. A single requestAnimationFrame only delay it for 0 - 17 ms, but it does not reduce the stress.

load as fast as possible, but never get in the way of the primary parts of a website during a page load.

Again, requestIdleCallback is the right way.

You are forgetting the context of a page load. In that regards, it has nothing to do with animations on a site. There is just 1 action to perform at 1 time (DOM mutations).
When you would add the test code to the header and load the page (you could easily test the HTML by adding <base href="http://www.people.com/">) then you will see that requestAnimationFrame can be used to prioritize the loading of the buttons to a moment at which there is less likeliness that the buttons could get in the way during the critical phase of a page load.
For example, you could use 2 or 3 requestAnimationFrame callbacks to ensure that the main DOM changes are visible before the buttons start painting to the screen. This could improve time to first meaningful paint (TTFMP), a term coined by Google that indicates the time that it takes before a website is visible to such extend that it can be perceived by the user.
https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint
The buttons simply have a significant impact on this aspect (when not custom optimized) so it would be very beneficial if it would be optimized in buttons.js to serve millions of website visitors.

When user is using <script async src="buttons.js">, because the script is loaded asynchronously, it will land after TTFMP. After TTFMP, calling requestAnimationFrame will only delay 0 - 17 ms. It you want to requestAnimationFrame, you have to load the script synchronously, which is definitely not a good idea.

From MDN:

"The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers as per W3C recommendation."

I played it more, and it turns out requestAnimationFrame does not even try to get close to the fps when busy. When the browser is really busy, the behavior is similar to requestIdleCallback that the delay is unpredictable.

As you can see in my test on www.people.com, requestAnimationFrame is fired after 600ms (when the browser starts to paint).
Drawing the buttons isn't an animation, it is part of the browser's render / paint process. requestAnimationFrame can be used to optimize the browser render / paint process.
My only argument for it's potential usage is that it would be best when the buttons would never get in the way of the main website / app and start rendering after TTFMP. This could be achieved using requestAnimationFrame (e.g. using 2-3 callbacks to select a later frame).
For cached requests, buttons.js will be loaded instantly and start rendering before TTFMP. It will start competing for resources during the critical phase of a page load.

Putting requestAnimationFrame directly on the page sometimes gives 450 ms in my tests, replacing it with requestIdleCallback does exactly the same.
Putting it in a <script async src="buttons.js"> on poeple.com will randomly give mostly 0 ~ 30 ms, sometimes 80 - 90 ms in my tests.
The reason is requestAnimationFrame does not do best effort scheduling, and I believe best effort scheduling is the correct implementation for requestAnimationFrame. There is an issue opened on Chromium since 2015:
https://bugs.chromium.org/p/chromium/issues/detail?id=527123
There isn't any effort in the two year since it's been opened, but at least someone in Chromium team do agree requestAnimationFrame and other animation related function should use best effort scheduling. When is the implementation is going to change is unknown, and may be it will never change since there are already tons of cases of abusing requestAnimationFrame as a requestIdleCallback polyfill.


Pick up latest markdown language service

This failed yesterday due to a cache issue in dev ops. We need this version for testing

Confirmed that Install deps in passing again in our official builds too


RtcEngine.create crash

"react": "16.13.1",
"react-native": "0.63.1",
"react-native-agora": "^3.0.1-rc.2",
error: ibc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0xfffffff9 in tid 32010 (mqt_native_modu)
ios: no problem

have you set correct AppId?

you can reopen this issue if the problem still exists.

i have same issue in react native v061.3 @xiaoyongchen , Can you tell me how to fix it?.


also provide Apache as an http-proxy

i'm throwing berkshelf on a shared-web server that has apache doing vhost-based routing, so this works better for me than running nginx on a different port and supporting two systems doing the same thing

@kplimack thanks for the PR! I would recommend wrapping the Berkshelf-API cookbook with your own that includes the http proxy recipe of your liking. I don't want to support multiple proxy types in the core cookbook.


Feature request: 3 dot syntax for diff in GithubGenerator

Hi
Wondering if the three dot syntax for Github diffs could be supported in https://github.com/IonBazan/composer-diff/blob/main/src/Url/GithubGenerator.php#L23 - similar to the GitlabGenerator
Two dot: https://github.com/IonBazan/composer-diff/compare/v1.8.0..v1.9.0
Three dot: https://github.com/IonBazan/composer-diff/compare/v1.8.0...v1.9.0
The three-dot syntax shows a list of commits and file changes in tabs, which is useful for  review and ability to review a single commit quickly.
2-dots could be retained for BC, so maybe an option to the command to switch to 3 dots ?
See: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests#three-dot-and-two-dot-git-diff-comparisons
Thanks!

I had no idea there are 2 different diff views on GitHub 🫢
I think we can consider this a non-breaking change as it still shows a diff in the end - unless someone opposes.
I just checked that both @renovatebot and @dependabot use the 3-dot URLs in PR descriptions. Let me implement this change.


Adding post code validation for 17 additional countries

Added post code validation for the following countries:
Australia (au)
Belgium (be)
Brazil (br)
China (cn)
Denmark (dk)
France (fr)
Germany (de)
India (in)
Italy (it)
Latvia (lv)
Netherlands (nl)
New Zealand (nz)
Portugal (pt)
Russia (ru)
Slovakia (sk)
Sweden (se)
Switzerland (ch)
The two letter country codes are based on the ISO 3166-1 alpha-2 naming scheme and can be found here:
http://www.worldatlas.com/aatlas/ctycodes.htm
The regular expressions used are based on expressions found here:
http://regexlib.com/Search.aspx?k=postal+code&c=0&m=0&ps=20&p=2
http://stackoverflow.com/questions/578406/what-is-the-ultimate-postal-code-and-zip-regex

Thanks!
We'll keep an eye on the popularity of the request.


Line chart with several dimensions in view

Hi All. I try to migrate from Tableau to Superset. And everything looks fine, except one type of chart which I couldn't create in Superset. I'm talking about a chart which splitted to a several pieces, and the number of pieces is the diversity of some of the dimensions. For instance:

So,  we can see 7 pieces with graphs regarding to the number of filter_id and in the each area I have another dimension and can see the diversity  of this dimension inside each area.
In the Superset's plugins I see some types but there are not so flexible and convenient. For instance (Time Series Table and Horizon):

Could you please help me? Maybe I missed something which I could use.
What do you think?
Thanks

I'm looking for the same thing.  Have you found any ways achieve something like this?

I'm looking for the same thing. Have you found any ways achieve something like this?

Unfortunately, no. I'm so surprised that this visualisation type is missing in Superset

You're not the only one to wish for such things, but this is more of a feature request than a bug. We're open to proposals and PRs to enhance the product. Meanwhile, closing this as stale since it's been silent for so long, and we're trying to steer toward a more actionable Issues backlog. Thanks!


Set Duration Before Recording LIVE Programme

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2017.03.26. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2017.03.26

Before submitting an issue make sure you have:

[x] At least skimmed through README and most notably FAQ and BUGS sections
[!!] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[ ] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[x] Question
[ ] Other

The following sections concretize particular purposed issues, you can erase any section (the contents between triple ---) not applicable to your issue

Hello. How can I set the ending-time before I begin to record a LIVE video? I JUST need a CLIP. And that programme is a non-stop one. THX

Currently not possible.


Upgrade to Vite v6

Announcement: https://github.com/vitejs/vite/discussions/15886
Checklist:

[ ] Wait until vite-plugin-node-polyfills upgrades vite as peer dependency
[ ] Check breaking changes https://vite.dev/blog/announcing-vite6
[ ] Upgrade Vite to v6
[ ] Upgrade Vitest if required

Currently there are issues with peer dependencies:
pnpm upgrade vite@latest -r

 WARN  Issues with peer dependencies found
pro/frontend
└─┬ vite-plugin-node-polyfills 0.22.0
  └── ✕ unmet peer<EMAIL_ADDRESS>|| ^3.0.0 || ^4.0.0 || ^5.0.0": found 6.0.5


python312Packages.pyogg: normalize pname

Description of changes
part of #245383
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 296739 run on x86_64-linux 1

2 packages failed to build:

onthespot
onthespot.dist

8 packages built:

python311Packages.librespot
python311Packages.librespot.dist
python311Packages.pyogg
python311Packages.pyogg.dist
python312Packages.librespot
python312Packages.librespot.dist
python312Packages.pyogg
python312Packages.pyogg.dist


Fix a minor typo in daemon/container.go

Signed-off-by: Lei Jitang<EMAIL_ADDRESS>I think ip table should be iptables

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "fix_minor_typo" git@github.com:coolljt0725/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

This will update the existing PR, so you do not need to open a new one.

@jfrazelle Gordon is acting weird on this one, commit is signed properly.

LGTM

LGTM


press.html - update contact information

The press page still lists Josh as the contact. This should be updated to the appropriate email alias for the comms team.

I have a draft open here #52

@TraceyC77 what should this email alias be ?

I see this was answered in the PR but for completeness, we have the "comms" alias at getsol.us for the press address. Thanks for your work!


Include method of hyperspace transition

Should be based on something like this, but with assets that are either provided by the user or are licensed safely https://drive.google.com/drive/folders/1hH0NHC82FJcXMk4TgPmFpfRh5rlaC0QK

[x] Implement a proof of concept with the videos transitioning between scenes
[x] If possible, use the transition in and out of hyperspace from the compendium. It doesn't look like this is possible.
[x] Copy space, hyperspace, and space combat scenes into my development environment
[x] Test that the parallaxia animations are persisted. If they're not, document them somehow.
[ ] Convert the scenes into a compendium
[ ] Create and link a form application to launch the transition in and out of hyperspace
[ ] Optionally animate a tile of a planet expanding into the scene during the end of the animation

I've implemented a variation of the guide above, using its assets. The difference is I created two scenes to represent the transition in and out of hyperspace. I took this approach because the fx module used doesn't provide a callback to detect that the video has loaded and has completed. This approach hooks the scene to ensure close to prefect timing. It's going to need a socket synchronization similar to what we did for the credit crawl.
https://gist.github.com/bheiskell/a33b37331b30b4149f9d0b3793852c34
There's still a fair amount left to do for this. Updating the ticket description.

Haven't received any feedback from the asset creator on youtube. I'm not seeing my comment. Not sure why, but at this point, it isn't worth stalling further. It looks like Sequencer has some code that can ease these transitions and provide some assets that we can reference from the module.

@bheiskell what's the latest here?

I'll take a look at this tomorrow.

For the posterity, here's a crappy code snippet I used to glue a series of scenes with video backgrounds together in a way that should seamlessly execute for each user. Note, this is local only, but the code works as a macro whether the user can see the scene or not. The reason I'm executing the transitions locally is it allows for timing the transition exactly at the end of the video playback.
let enter_scene = game.scenes.getName("Hyperspace Enter");
let exit_scene = game.scenes.getName("Hyperspace Exit");

let enter_preload = game.scenes.preload(enter_scene.id);
let exit_preload = game.scenes.preload(exit_scene.id);

await Promise.all([enter_preload, exit_preload]);
$("#loading").css({"left": -1000});
console.log("Activating scene");
await enter_scene.view();
console.log("Delaying scene");
//await new Promise(resolve => setTimeout(resolve, 1000));
// Stop the video loop
console.log(canvas);
canvas.background.bgSource.loop = false;
canvas.background.bgSource.currentTime = 0;
await canvas.background.bgSource.play();

await new Promise(resolve => {
        console.log("Resolving 1");
        canvas.background.bgSource.onended = () => {
            console.log("Resolving 2");
            resolve();
        };
    });
await exit_scene.view();
//await new Promise(resolve => setTimeout(resolve, 100));
// Stop the video loop
canvas.background.bgSource.loop = false;
canvas.background.bgSource.currentTime = 0;
await canvas.background.bgSource.play();
await new Promise(resolve => {
        console.log("Resolving 1");
        canvas.background.bgSource.onended = () => {
            console.log("Resolving 2");
            resolve();
        };
    });
await game.scenes.getName("Test").view();
$("#loading").css("left", "");

Documentation added: https://github.com/wrycu/StarWarsFFG-Enhancements/wiki

Merge request is up. Going to try to do a screen record to demo its usage.

Added a credit to the user in discord that provided the Google Drive links for the video and original idea of this feature.

https://user-images.githubusercontent.com/96167/147160446-df0b2755-43ad-4d93-a77d-10702c26524a.mp4


visualization

thank you for your nice work. Your new idea about the cascaded detail modeling and body filling model is very impressive, but I still have some unclear details about the implementation.May I ask you how the visualization of Figure 9 in the paper. just print attention feature? could you release some codes?

best wish ❤

Thanks for your interest in our work!
Regarding the left visualization of attention, we just download the attention map and visualize it using Matlab colormap (https://nl.mathworks.com/help/matlab/ref/colormap.html).
Thanks again and it is more than welcome to pose further comments!
Happy Mid-Autumn Festival

Thanks for your interest in our work!
Regarding the left visualization of attention, we just download the attention map and visualize it using Matlab colormap (https://nl.mathworks.com/help/matlab/ref/colormap.html).
Thanks again and it is more than welcome to pose further comments!
Happy Mid-Autumn Festival

Thank you for your quick reply.


How to setup Http.Sys with SSL

I created a new Project with dotnet new webapi.
I want to use Http.Sys with Windows Authentication.
My setup looks like this
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
            WebHost.CreateDefaultBuilder(args)
                .UseHttpSys(options =>
                {
                    options.Authentication.Schemes = AuthenticationSchemes.NTLM | AuthenticationSchemes.Negotiate;
                    options.Authentication.AllowAnonymous = false;
                    options.MaxConnections = null;
                    options.MaxRequestBodySize = 30000000;
                })
                .UseStartup<Startup>()
                .UseSerilog();
    }

And the launchsettings.json like this
{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "MyProject": {
        "commandName": "Project",
        "launchBrowser": false,
        "environmentVariables": {
            "ASPNETCORE_ENVIRONMENT": "Development",
            "ASPNETCORE_URLS": "https://localhost:5101;http://localhost:5100",
            "ASPNETCORE_HTTPS_PORT": "5101"
        }
    }
  }
}

I´m getting redirected to https://localhost:5101/api/values when trying with http://...:5100 but all i get is this:

If i remove the UseHttpsRedirection Middleware everything works fine.
It looks like HttpSys is not binding to 5101.
What am i making wrong?

There are quite a few hoops to jump through go get this setup on windows.
https://stackoverflow.com/questions/51823878/how-to-https-ssl-with-self-hosted-asp-net-core-2-app-httpsys

Yea, as @dallancarr says it's complicated. HTTP.SYS requires you to register an SSL certificate against the ports you want to listen on, but a VS install should be doing this for you (assuming you installed VS)
What version of the SDK are you using?
What does dotnet dev-certs https -c -v say?
Finally what does netsh http show sslcert show? (You'll probably want to pipe that output to a text file.
What you're looking for is an IP:port combination of <IP_ADDRESS>:5001 in the output from netsh http. If that isn't there you need to manually bind the certificate with
netsh http add sslcert ipport=<IP_ADDRESS>:5001 certhash=THECERTHASH appid={ANY NEW GUID}
You can get the cert hash by looking in your certificate store for the ASP.NET development cert (if you're using the self signed cert the dev-certs command generates) or whatever cert you want to use, and just generate any old guid for the app id

Thanks guys. The stackoverflow link solved it! :)


Feature Two Hand Manipulation + Bounding Box Normal Mode

Overview

This Pull Request is based on TwoHandManipulatable script made by Julia Schwarz(@julenka) and David Calabrese (Issue #1604)
This script allows for an object to be movable, scalable, and rotatable with one or two hands. You may also configure the script on only enable certain manipulations. The script works with both HoloLens' gesture input and immersive headset's motion controller input.
The example also includes Bounding Box Basic for the normal mode. In normal mode, Bounding Box Basic gives the visual boundary of the object when you interact with the object. You can find this behavior in the cliff house. (Grab and move, rotate, scale with two motion controllers)

Demo Video
https://gfycat.com/ColossalEnlightenedAntipodesgreenparakeet
Supported devices

HoloLens
Immersive headset

Test Scene
TwoHandManipulationTest.unity
Technical details
You can find technical details on the README page:
https://github.com/johnppella/MixedRealityToolkit-Unity/blob/Feature_UX_BoundingBox_TwoHandManipulation/Assets/MixedRealityToolkit-Examples/Input/Readme/README_TwoHandManipulationTest.md
Known issues

Adjust mode Bounding Box(handles) and App Bar will be added through different Pull Request.
In the immersive headset, current input system only shows single pointer cursor. While holding an object with the first controller, pointing and selecting the object with the second controller will activate the manipulation behavior. Multi-pointer cursor visualization will be updated through different Pull Request.

This PR also includes the fix for some of the broken materials in Button prefabs used in the InteractableObject and ObjectCollection.

@julenka Could you please take a look?

Made a few changes tonight but need to go to sleep, will try to pick this up over the weekend since I'll be busy Friday night.

Hi @StephenHodgson I've made a few more changes based on your comments, I still am not sure about using the InputManager.RaiseManipulationStarted event though. Things looks good in the test scene when running in editor, but I have not yet tested on device. Hope to get to that later this week or this coming weekend.

Untiy [Universal Windows Platform] Platform does not support.
The Socket code is written and the Thread code is written and the FileStream code is written, you know what?
I used the network communication section to find that this part of the code could not be transferred to the [Universal Windows Platform].
After I tested Unity 2017.2.0f3 (64-bit) version,Unity 2017.3.1f1 (64-bit) version,Unity 2017.2.1f1 (64-bit) version.
They don't support it.
Do you have any feedback on untiy?
When I wrote socket and IO and Thread related code in the program, untiy packaging times was wrong,
The socket.Connect function is not supported.
The socket.Receive function is not supported, and the
socket.Send function is not supported.
The filestream.close function is not supported,
New Thread(recv) is not supported,
Does not support Thread. IsBackground,
Does not support Thread. To Start,
But if I just write in the code.
The Socket client = null;
Thread the Thread = null;
FileStream filedata = null;
This way, the Universal Windows Platform is passed.
I think it should be the flaw in the Platform library of untiy [Universal Windows Platform].
Please help me to feedback this question,
------------------ 原始邮件 ------------------
发件人: "Stephen<EMAIL_ADDRESS>发送时间: 2018年3月2日(星期五) 上午7:17
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS>主题: Re: [Microsoft/MixedRealityToolkit-Unity] Feature Two HandManipulation + Bounding Box Normal Mode (#1727)
@StephenHodgson approved this pull request.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Untiy [Universal Windows Platform] Platform does not support.
The Socket code is written and the Thread code is written and the FileStream code is written, you know what?
I used the network communication section to find that this part of the code could not be transferred to the [Universal Windows Platform].
After I tested Unity 2017.2.0f3 (64-bit) version,Unity 2017.3.1f1 (64-bit) version,Unity 2017.2.1f1 (64-bit) version.
They don't support it.
Do you have any feedback on untiy?
When I wrote socket and IO and Thread related code in the program, untiy packaging times was wrong,
The socket.Connect function is not supported.
The socket.Receive function is not supported, and the
socket.Send function is not supported.
The filestream.close function is not supported,
New Thread(recv) is not supported,
Does not support Thread. IsBackground,
Does not support Thread. To Start,
But if I just write in the code.
The Socket client = null;
Thread the Thread = null;
FileStream filedata = null;
This way, the Universal Windows Platform is passed.
I think it should be the flaw in the Platform library of untiy [Universal Windows Platform].
Please help me to feedback this question,
------------------ 原始邮件 ------------------
发件人: "Julia<EMAIL_ADDRESS>发送时间: 2018年3月2日(星期五) 凌晨2:49
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS>主题: Re: [Microsoft/MixedRealityToolkit-Unity] Feature Two HandManipulation + Bounding Box Normal Mode (#1727)
@julenka commented on this pull request.
In Assets/MixedRealityToolkit/InputModule/Scripts/Utilities/Interactions/TwoHandManipulatable.cs:

+using UnityEngine.Assertions; + + +namespace MixedRealityToolkit.InputModule.Utilities.Interations +{ +    ///  +    /// This script allows for an object to be movable, scalable, and rotatable with one or two hands.  +    /// You may also configure the script on only enable certain manipulations. The script works with  +    /// both HoloLens' gesture input and immersive headset's motion controller input. +    /// See Assets/MixedRealityToolkit-Examples/Input/Readme/README_TwoHandManipulationTest.md +    /// for instructions on how to use the script. +    ///  +    public class TwoHandManipulatable : MonoBehaviour, IInputHandler, ISourceStateHandler +    { +        // Event that gets raised when user begins manipulating the object +        public event Action StartedManipulating;
Okay, I'll look at that this weekend.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@julenka @StephenHodgson I think we can merge this and consider adding a new event as an improvement. Thanks!

I'll merge this update to our Bounding Box and App Bar branch and submit PR.


User signIn and login

There seems to be some glitch in user sign in and login .
Password and confirm password are the same still the account is not getting created.
I will build the complete user registration and login feature in the backend and take care of all the glitches
Please assign me this issue under GSSOC22

Yaa this isn't an expected behaviour. @coding-geek21 , Can you give some insights on this?
@prateekmohanty63 Anyway, for further proceedings with the project, the user registration has to be redefined . This time email is included (possibly with verification). If you can do that this will be assigned as level3 issue under GSSOC22 .

Yeah sure assign me this .
I will do it

@yaswanthsaivendra

oh wow thanks @coding-geek21  for the information , i was kinda of confused cause when i saw in the deployed version signin was working fine , but not in my local machine.
Yeah I will add the email things . Thank you

@coding-geek21  I had one more doubt , like I have added the email field and taking it as input during registration.
Should I also send verification mail to user once the user has registered?
Like can you exactly define the requirements ?

Or do i just send to check if the email being entered is correct?

@coding-geek21 I had one more doubt , like I have added the email field and taking it as input during registration. Should I also send verification mail to user once the user has registered?
Like can you exactly define the requirements ?

You have to send a User authentication link to the mail id specified by the user  so that they can confirm their account by clicking on the link they received
Once they confirm account will be created for them

ok cool got it , thanks

@coding-geek21  I have completed the thing
Here is the output

Ok @prateekmohanty63  make PR

i I have hidden  my credentials , put your and it would work fine

in setting.py

@coding-geek21  which branch should I send a pr

@coding-geek21 which branch should I send a pr

develop branch

@coding-geek21 I have sent the pr
Please merge it
Thank you


[BUSINESS PROCESS]: Report an injury or illness

Contact details
<EMAIL_ADDRESS>Organization type
Parnter / ISV / Independant consultant
End-to-end business process
Hire to retire
Which business process area is this article related to?
Manage occupational health and safety
Enter the name of the business process you are starting work on
Report an injury or illness
Enter any additional comments or information you want us to know.
I would like to author this article
Specify the date you expect the article to be completed and ready for review.
11/13/2024
Code of Conduct

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

Hi Parag, please go ahead.


Some dependencies need upgrading

Some dependencies, for example, GMavenPlus plugin need to be upgraded to the latest versions for 2.1.

fixed via https://github.com/spring-cloud/spring-cloud-contract/commit/1b1d4049d428e404b594c3bd11dbd6d6880f7a8e


Missing return "<- Back to collection" when browsing empty collection

When entering an empty collection, the "<- Back to collection" link in the left navigation bar is not displayed.

Shipped in 3c032563526dc64e4fbce480a4103aa1fddf6f02.


Release 1.0.0 Source code (tar.gz) can not compile

cmake 3.6.1 error：
The C compiler identification is MSVC 19.0.24210.0
The CXX compiler identification is MSVC 19.0.24210.0
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
CMake Error at CMakeLists.txt:68 (add_subdirectory):
The source directory
D:/grpc/grpc-1.0.0/third_party/boringssl

does not contain a CMakeLists.txt file.
CMake Error at CMakeLists.txt:69 (add_subdirectory):
add_subdirectory given source
"D:/grpc/grpc-1.0.0/third_party/protobuf/cmake"
which is not an existing directory.
CMake Error at CMakeLists.txt:70 (add_subdirectory):
The source directory
D:/grpc/grpc-1.0.0/third_party/zlib

does not contain a CMakeLists.txt file.
Configuring incomplete, errors occurred!
See also "D:/grpc/grpc-1.0.0/CMakeFiles/CMakeOutput.log".

Have you tried regular make? Our support for cmake is only early experimental. We're glad to get feedback and bug fixes for it but can't help very much. Maybe a community member could help?

Our cmake support is not in much better shape. We strongly suggest migrating to the latest version.
https://github.com/grpc/grpc/blob/master/INSTALL.md#windows


Filler text in IE

This seems to be a common issue with IE, but the update location input form does not work properly with filler text. Unless the user double clicks on the textbox, the filler text "enter a location" becomes part of the search.

This was accidentally fixed during the mobile optimizations. Removing the input field as a subset of
 and placing both the map and input in
 is probably the cause of this fix.
Not sure when it started working, but definitely fine as of 11f39d3c1a5f5583ce48540c872d8650efe95d3e.


Added New Social Button [GSSoC'23]

Added new button to the list
Fixes Issue
Closes #1719

Changes proposed
Added New Animating Social Button  !

Screenshots

Checklist

[x] You've linked this PR to the correct issue.
[x] You have checked that the code is working correctly.
[x] You ⭐ the repository!

Note to reviewers

@Spyware007 Sir can you please check and merge it ?

@Spyware007 can you please check and merge it !

🎉 The GSSOC'23 program has reached its conclusion, prompting us to officially close all pull requests (PRs) and issues. We extend a heartfelt thank you for your amazing contributions! 🙌 Keep the coding spirit alive with the same enthusiasm, and may luck 🍀 favor you in all your future coding adventures!


expose the move_camera interface to the user

A small improvement to expose the already present move camera action to the user.

Alright


focasting length question

Just wanna ask a simple question here, is there anyway procasting several days at once? e.g. use 25 days to train and forcat 15 days. Thanks

Maybe you can try to cycle


Remove: purocean.YankNote version 3.6.4

## .\Tools\YamlCreate.ps1 -SkipPRCheck -Mode 5 -PackageIdentifier purocean.YankNote -PackageVersion 3.6.4

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

/azp run


⚠ Samsung has degraded performance

In 90fd87e, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2548 ms

Resolved: Samsung performance has improved in ba08931.


generate default name from class/field name

resolve #11
Even though I think I made the feature work, I couldn't pass a test PrefsProcessorTest#tableNameNotDefined.
Probably I missed something, but processor module can't import "library" module(since it's aar), so test fails after code generation is actually succeeded.
todo

[x] test
[x] readme
[x] sample?

@hotchemi PTAL.
I ended up creating new module called "compiler-test"

Wow cool! Let me check!

Sorry for the late, I'll review tonight 🙇

LGTM! Really appreciated for your amazing work. I'll take a look again and release next ver in this weekend. And so sorry for being late 🙇

NVM, I understand maintaining multiple personal projects along with full time job is hard :D
thanks anyway!


Enable mdsmtls test suite, skip tests if the MDS doesn't offer tls creds

/cc @dorileo @ChaitanyaKulkarni28

/lgtm


Test ticket from Code Climate

@Olivia-Chiong Do we need to keep this

@Olivia-Chiong Do we need to keep this

Test issue worked, Closed


Mechanisms unit tests

Adds a unit test templated over the mechanism to be tested.
A "prototype" mechanism is also need so that we can verify the results of the mechanism generated by modcc. As prototype mechanisms I used the current versions of the generated mechanisms.
Aliasing of indexes can also be introduced, which is in fact the case of the expsyn and exp2syn mechanisms unit tests.

There have been quite a few changes to the generated mechanisms in the gpu branch. The front and middle of modcc are unchanged, however the cprinter and cudaprinter generate different code to accommodate the refactoring elsewhere in NestMC.
I think that this is a very, very good idea to test that mechanisms generated by modcc are correct. But I wonder if it would be better to introduce it after the gpu branch is merged?

Sure, this PR can wait until the big GPU merge is done.


%% not working when not at the beginning of the line

Hello,
Thanks for developing and maintaining a great package.
I have a template that looks like this
# -*- coding: utf-8 -*-
%%pip install package
if <some condition>:
    %%pip install <some other package>

This gets rendered into
# -*- coding: utf-8 -*-
%pip install package
if <some condition>:
    %%pip install <some other package>

where the last line starts with (some spaces) + %%
Trying to template
# -*- coding: utf-8 -*-
%%pip install package
if <some condition>:
    %pip install <some other package>

Raises
Thanks again

hi
these must be escaped as mentioned at https://docs.makotemplates.org/en/latest/syntax.html#control-structures
so in this case you'd want %%%

I don't know what's up with the second one, might be a bug, but Mako is not maintained right now (unless someone wants to wriet a PR w/ tests).
try a literal block

t = Template("""
# -*- coding: utf-8 -*-
%%%pip install package
if <some condition>:
    ${"%"}pip install <some other package>

""")

Thanks for the reply

Hai Zhu has proposed a fix for this issue in the main branch:
fix percent escape not working when not at the beginning of the line https://gerrit.sqlalchemy.org/c/sqlalchemy/mako/+/5111

I've reverted in edf44dc36ef2ed42746352 and revoked 1.3.1.  This issue remains un-fixed

1.3.2 is released thanks again, will revisit here if further problems


Crash on credential refresh

https://travis-ci.org/jay0lee/GAM/jobs/630968578#L1068
we seem to crash when we get a 502 response and attempt to refresh. request is a function (at least it is when we're using service account credentials). Need to figure out how to properly refresh credentials here.

$gam users "$newbase-bulkuser-07 $newbase-bulkuser-08 $newbase-bulkuser-09" modify messages query in:anywhere maxtomodify 99999 addlabel IMPORTANT addlabel STARRED doit; fi
Searching messages for<EMAIL_ADDRESS>Got 3 messages for user<EMAIL_ADDRESS>modify 3 messages
Traceback (most recent call last):
File "/home/travis/build/jay0lee/GAM/src/gapi/init.py", line 84, in call
return method(**parameters).execute()
File "/home/travis/virtualenv/python3.7.5/lib/python3.7/site-packages/googleapiclient/_helpers.py", line 130, in positional_wrapper
return wrapped(*args, **kwargs)
File "/home/travis/virtualenv/python3.7.5/lib/python3.7/site-packages/googleapiclient/http.py", line 856, in execute
raise HttpError(resp, content, uri=self.uri)
googleapiclient.errors.HttpError: <HttpError 502 when requesting https://www.googleapis.com/gmail/v1/users/me/messages/batchModify?prettyPrint=false returned "Bad Gateway">
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "gam.py", line 14689, in
sys.exit(ProcessGAMCommand(sys.argv))
File "gam.py", line 14463, in ProcessGAMCommand
doProcessMessagesOrThreads(users, 'modify', 'messages')
File "gam.py", line 5853, in doProcessMessagesOrThreads
userId='me', **kwargs)
File "/home/travis/build/jay0lee/GAM/src/gapi/init.py", line 94, in call
service._http.request.credentials.refresh(create_http())
AttributeError: 'function' object has no attribute 'credentials'

I'll submit a PR for this when PR #1064 is done.

Can you reproduce this? How does #1066 affect it?

Not easily reproducible. Above instance was on a command using SA and we have no way of knowing if we have SA or user credentials at this point.
Handling bad gateway with a normal backoff/retry may solve here.

@jay0lee @taers232c Just curious if there's any backstory as to why this behavior was originally added (I just ported it over when I migrated)?
service._http.request.credentials.refresh(create_http())
As far as I can tell, when you're building a service object, you're forcing it to use a google_auth_htplib2.AuthorizedHttp here and here, but AuthorizedHttp is already purpose-built to refresh credentials and retry the request when necessary.
Is this still needed?


Change String Normalization and Logical Type Names

closes #186
closes #199

About to add a few more tests, stay tuned :)

Alright, this should be it :tada:


Allow for proper punctuation when asking 'who's on call?'

We are always asking "who's on call?" and not getting results back because the regex doesn't expect a trailing "?". This patch adds that optional "?" to the regex.

👍

Released with v2.1.18


Several flash related fixes

Work around cases where initing the flash algo in VERIFY mode fails by attempting to reinit in ERASE mode.
If the gdbserver gets an exception while programming flash, it deletes the FlashLoader instance it was using. This prevents conflicts when trying to add data to the stale FlashLoader if another attempt is made to program flash.
Moved the create_flash init task to the end of the init sequence, just prior to the post-connect notification. This allows the memory map to be modified or replaced during initialization without losing existing flash instances.
Fixed the Flash_kl28z.prepare_target() method signature. Thanks to @Hoohaha for this fix.

Fixes #851
Fixes #865

/morph test