text:
Integrating Remix Router with React Transitions

What version of Remix are you using?
1.14.1
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
Remix does not fully integrate with Suspense because the Remix router does not use startTransition. I was wondering if there is interest in exploring a fuller integration where Remix router would be more Suspense-y.
To illustrate this, I will offer a little example.
Initial setup
Suppose I have an /index route that just renders
 and a more complex /about page that loads some data. My navigation to /about looks like this:
https://user-images.githubusercontent.com/810438/224425334-d93ac601-4f35-4788-a62f-d43d26feba0c.mov
The data loads in two stages:

First, the "blocking" part holds the router navigation back.
Then, when the loader is ready, we show some content and "defer" the rest.

My code for about.js looks like this:
import { Suspense } from 'react'
import { Await, useLoaderData } from "@remix-run/react";
import { defer } from "@remix-run/node";

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms))
}

export async function loader({ request }) {
  await sleep(1000);
  return defer({
    username: 'taylor',
    more: sleep(3000).then(() => ({ bio: 'Hi there!' }))
  })
}

export default function Index() {
  const data = useLoaderData();

  return (
    <>

About {data.username}

      <Suspense fallback={
Loading bio...
}>
        <Await resolve={data.more}>
          {more =>
{more.bio}
}
        </Await>
      </Suspense>
    </>
  );
}

So far so good.
A wild suspense appears!
Now let's say I add a component that suspends to my /about page.
import { lazy, Suspense } from 'react'
import { Await, Link, useLoaderData,  } from "@remix-run/react";
import { defer } from "@remix-run/node"; // or cloudflare/deno
+ import Counter from '../counter'
...
export default function Index() {
  const data = useLoaderData();

  return (

about {data.username}

+     <Counter />
      <Suspense fallback={
Loading bio...
}>
        <Await resolve={data.more}>
          {more =>
{more.bio}
}
        </Await>
      </Suspense>

  );
}

Suppose that Counter itself suspends for whatever reason. E.g. maybe it renders a lazy component inside. Maybe it does a client fetch with one of the Suspensey libraries. Maybe it is waiting for some CSS chunk to load (when we add Suspensey CSS integration into React). Etc. In general, you can expect components anywhere in the tree to be able to suspend — and that includes the "non-deferred" parts of the UI.
At first, we'll have an error:

OK, fair enough, it's a React error. It says there's no <Suspense> above it in the tree. Let's fix this.
I could add it around my outlet:
+        <Suspense fallback={
loading
}>
            <Outlet />
+        </Suspense>

But then the whole page "disappears" when it suspends:
https://user-images.githubusercontent.com/810438/224425184-a99c8412-8303-4f54-9ba2-c626937b43ab.mov
Or I could add it around the <Counter> itself:

about {data.username}

+     <Suspense fallback={
loading
}>
          <Counter />
+     </Suspense>
      <Suspense fallback={
Loading bio...
}>

But then my Counter "pops in" independently from the
.
https://user-images.githubusercontent.com/810438/224425518-0518655b-bd93-4d16-8359-b79c814ce7fc.mov
What I really want is to delay the route transition until all content in the "blocking" part (including <Counter /> and whatever it suspended on) is ready.
Is this even possible to fix?
Yes. The canonical fix for this is to wrap the setState which caused the navigation into startTransition. This will tell React that you don't expect that setState to finish immediately, and so it can keep showing the "previous" UI until the render caused by that setState has enough data to show meaningful UI.
As a concrete example, here is a similar navigation implemented in Next.js 13 (App Router):
https://user-images.githubusercontent.com/810438/224426869-74b4abc4-166c-4931-ad3a-d758c3c6f759.mov
Note that although <Counter /> suspends on the client (with an artificial delay), the router still "waits" for it — it "pops in" together with the
. I did not need to add any <Suspense> boundaries — neither around it nor above it.
import { Suspense } from "react";
import Counter from '../counter'

function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function loadUsername()  {
  await sleep(1000);
  return "taylor";
}

async function loadBio() {
  await sleep(3000);
  return "hi there";
}

export default async function About() {
  const bioPromise = loadBio();
  const username = await loadUsername();
  return (
    <>

about {username}

      <Counter   />
      <Suspense fallback={
Loading bio...
}>
        <Bio data={bioPromise} />
      </Suspense>
    </>
  );
}

async function Bio({ data }) {
  const bio = await data;
  return
{bio}
;
}

Of course, if I wanted to, I could add a <Suspense> boundary around just the <Counter>. Then it would not "hold" the router from a transition.
What's the higher-level point?
Remix currently implements its own machinery to "hold things back" until loaders have returned their result. Then it immediately "commits" the UI — even if that UI might immediately suspend.
React implements a first-class feature to "hold things back" — startTransition. (Or useTransition so you can report progress.) So I am wondering if there is some path towards using the built-in feature.
I imagine that, if Remix were to do that, it would start rendering the new route immediately — but it would suspend when in useLoaderData. If the router setState is wrapped in startTransition, you'd automatically get the "stay on the previous route until there's enough data to show the next route's shell" behavior. But unlike now, it would be integrated with anything else that suspends, like <Counter />.
Would love to hear any concerns or if there's something missing in React to make this happen. It's exciting Remix is taking advantage of Suspense for React SSR streaming already. Integrating Remix Router with React Transitions seems like a big next step towards Remix users being able to benefit from all React features.
Expected Behavior

Remix router transitions are React Transitions (see above)

Actual Behavior

Remix router transitions are not React Transitions (see above)

We started Remix on Suspense with the experimental releases back in the day but after a couple releases broke things we stopped relying on it to "hold things back".
Fast forward and now React Router uses useSyncExternalStore (https://github.com/remix-run/react-router/blob/main/packages/react-router/lib/components.tsx#L63-L70). In Remix v2 we're cleaning up the integration points with React Router and I imagine we won't have our own setState at all in Remix at that point, so it'll all just be useSyncExternalStore.
In that world do we still need startTransition?

and stuck to the stable React releases.

Fair enough! I think everything that's needed here is available in React 18, except for the "throw Promise" thing which would later become "use". But setting that aside, this should be possible to build with stable releases (e.g. it's what Relay works).

In Remix v2 we're cleaning up the integration points with React Router and I imagine we won't have our own setState at all in Remix at that point, so it'll all just be useSyncExternalStore.

At the moment, we can't make Transitions work with external stores. (Hence "sync".) I think we've explored potential APIs for more sophisticated multi-version stores but it's further out.
For Transitions to work, the state needs to be "rooted" in React (i.e. useState or useReducer) because we need to be able to pass different versions of state (either current or pending) to your component. This is what allows us to start rendering the "next' version (which may suspend) but keep responding to interactions with the previous version. I believe in Next 13, it's implemented as useReducer in the router component.

In that world do we still need startTransition?

If you'd like Remix users to be able to use Suspense fully (and avoid the issues described above), then yes.
I think it's also reasonable that Remix may choose not to support these patterns, and maintain its parallel implementation. I.e. not every React framework has to support the full range of React features.
Supporting only a subset of React features makes sense if the framework needs to cater to several UI libraries. Then it would have to use the lowest common denominator and, in the current landscape, it's sync rendering.

If you'd like Remix users to be able to use Suspense fully

Remix is designed specifically to avoid this kind of UX where render side effects trigger fetches, slowing down the page shifting the layout all around the screen.
Would love a concrete example of why you'd want to encourage these waterfalls when Remix has patterns to avoid it completely?
I'm quite happy with defer + <Suspense>, what else do you have in mind?

shifting the layout all around the screen

In the above example, it's the Remix version that shifts layout (because you're forced to add a boundary and can't let the content block instead). In the Next example, there is no extra shift because anything that suspends at the top-level "joins" the transition and blocks it. With Next, you have the freedom to decide what should block and what shouldn't. But you decide that on the UI level (with Suspense), not on the model layer (like defer).
If we set aside implementation concerns and forget about frameworks, I think “stuff outside <Suspense> blocks the route, but stuff inside <Suspense> doesn’t” is a rather intuitive heuristic.

where render side effects trigger fetches

Suspending doesn't mean a fetch is necessarily triggered on the client or by rendering. It only means that the component is not ready yet. It could be waiting for something that was triggered earlier and is already being fetched or transferred from the server. (From what I understand, this is how defer already works.)
For example, we're working on a CSS integration so that CSS chunks can be sent in parallel with JS (instead of blocking JS execution on them or loading them all upfront). If JS loads before associated CSS, React can start rendering the component. (Yay, no CSS-JS waterfalls!) But React would "wait" for associated CSS to load before revealing the contents of the Suspense boundary whose content depends on that CSS.
Images is another example where we might offer an API to "hold back" the boundary so that the route "pops together" with, say, a blurred cover image, or button icons.
Another use case is loading code — but it's true Remix is already limited in that sense. From what I understand, Remix can only load code eagerly (bundled with the route) or completely lazily (requested after client render attempt). So there is no way to conditionally prefetch Counter code based on whether loader's data says it will need to be rendered. However, if Remix did support that (via RSC or some other mechanism), then that would be another example of suspending on something that was already being fetched. Like defer but for code.
Finally, some things might just have to fetch on the client. I think it would be great if when you're forced to do this, you could still avoid unintentional layout jumps, and could hold back the router a bit.
All in all, I don't think this is strictly about one specific pattern. React offers a way to hold the UI back. It's ok not to use it, but I think it will start being more noticeable as more things start integrating it. Both under-the-hood things like CSS, and arbitrary user code taking advantage of this support.

I think it would be great if when you're forced to do this, you could still avoid unintentional layout jumps, and could hold back the router a bit.

That makes sense. I've wanted the ability to hold back the router to complete an animation in case the route transition is faster than the animation, or simply avoid flickering a spinner for 10ms.
I still maintain that we should be spending our energy designing APIs to avoid render-initiated asynchrony. Async components make it easier to do the wrong thing.

I feel like the async/await and server components talk is a derailing this issue a bit. It doesn't seem exactly related to the discussion of "remix router transitions should be wrapped in startTransition" - I think the code in the issue description is just showing how it works in server components, but it also applies to the remix of today when you start adding in suspense in it's many forms outside of server components.

Yeah sorry, didn’t mean to imply this has something to do with RSC per se. It’s just the latest example of “stuff can suspend anywhere” in my mind because it’s more granular about sending code. But the CSS stuff I mentioned is not gonna be RSC-specific — I think it would actually be great if Remix could try using it too once we get something working for that.
I also apologize if the focus on that Next example is distracting — Next isn’t where this behavior is. The heuristic itself is in React 18. (Transitions don’t get committed until you have enough to render the new screen.) So you can imagine the existing useLoaderData API, but if the router is implemented in the Suspensey paradigm (rendering the next route is a transition whose render suspends on its data/code), it should “just work” using the same heuristic.

Forgive me for intruding on this conversation considering I'm a nobody 😅. @gaearon with the example you gave with the Counter component, let's say for whatever reason it takes 30 seconds to resolve. Maybe its calling some long running external process and we have no control on how long it takes. With the startTransition approach wouldn't the user basically be stuck on the previous page until whatever long running process Count called completed ?
You could certainly wrap it in Suspense and show the new page immediately with a fallback  but that would need to be something intentional a developer does. If a developer misses that a component will not resolve in a reasonable amount of time well then you have a more jarring user experience in that the user thinks the site is stuck as opposed to showing the new page immediately and then the loader.
It would be great if startTransition maybe had something like a timeout that can be configured. Perhaps that could incentivize adoption as in the very least if a developer makes a mistake or doesn't anticipate something then there is a safety net ?

What you're describing is what the browser already does natively on anchor tag, full page reload navigation. It makes sense for Remix to mirror this as a default IMO.

For example, we're working on a CSS integration so that CSS chunks can be sent in parallel with JS (instead of blocking JS execution on them or loading them all upfront). If JS loads before associated CSS, React can start rendering the component. (Yay, no CSS-JS waterfalls!) But React would "wait" for associated CSS to load before revealing the contents of the Suspense boundary whose content depends on that CSS.

Images is another example where we might offer an API to "hold back" the boundary so that the route "pops together" with, say, a blurred cover image, or button icons.

To put something concrete behind this, we've just landed core support for this in the reconciler (https://github.com/facebook/react/pull/26398). No DOM integration yet, but it's coming. This will — at least initially — only be enabled during Transitions.

@Moro-Code for some time you could pass an object with options to useTransition and control the timeout with the timeoutMs property. Here is the explanation why it was removed: https://github.com/facebook/react/pull/19703
https://hu.reactjs.org/docs/concurrent-mode-patterns.html#transitions

@ryanflorence, is it unlikely that your stance on this issue will change?

That makes sense. I've wanted the ability to hold back the router to complete an animation in case the route transition is faster than the animation, or simply avoid flickering a spinner for 10ms.

I think this is a significant limitation in Remix (and React in general, before Suspense / Transitions). Being able to hold back the rendering of state updates is essential to provide smooth transitions. Both when you add animations to mask fetch delays and the fetch is faster than the animation (the issue I believe you describe?), but also more generally to enable "exit animations" where you keep the old state until an animation is done, before rendering the updated state (sliding content out-of/into view, open/close modals etc.).
I agree on your last comment about avoiding render-initiated asynchrony, but I don't think that's necessarily related?

How are you folks working around this limitation?
Our use case is: we have a SPA using React Router, a global suspense boundary, and a page showing some content using a suspense-compatible data fetching library. The request is driven by a search param. Changing the search param triggers a new request, and we were expecting that wrapping the setSearchParams call in startTransition would keep the previous data till the new one was ready, avoiding the suspense boundary.

startTransition support is added in https://github.com/remix-run/react-router/pull/10438 and will be available once React Router 6.12.0 and Remix 1.17.0 are released

authors: Moro-Code brophdawg11 damianstasik dani-mp gaearon gne ryanflorence tom-sherman


text:
Update on npm

The package on npm is the previous version.
Would you please upload the latest version?
I can't wait to use Promise for my bot 🤘
Thanks a lot! 🍻

+1 please

Will push to NPM later today

source: gharchive/issue

authors: adamjace eXeDK harry830622

repo: remixz/messenger-bot

license: mit

license_type: permissive

license_source: bigquery


text:
When sliding the PageView, the image flashes

I use the PhotoViewGallery in my project and only want to enable the hero animation of the selected item, so I wrote the following code:
PhotoViewGalleryPageOptions _buildItem(BuildContext context, int index) {
  return PhotoViewGalleryPageOptions(
    // ...
    heroAttributes: selectedIndex == index
        ? PhotoViewHeroAttributes(tag: item.heroTag)
        : null,
  );
}

But see the following gif, these code will cause image flash when sliding the PageView:

So I try to check the source code to find the reason. And I find that this library controls the loading animation by itself, rather than using the loadingBuilder option providing by the Image widget. It uses a FutureBuilder to conditionally build an image or loading widget:
Widget _buildImage(BuildContext context, BoxConstraints constraints) {
  return widget.heroAttributes == null
      ? _buildAsync(context, constraints)
      : _buildSync(context, constraints);
}

Widget _buildAsync(BuildContext context, BoxConstraints constraints) {
  return FutureBuilder(
      future: _getImage(),
      builder: (BuildContext context, AsyncSnapshot<ImageInfo> info) {
        if (info.hasData) {
          return _buildWrapperImage(context, constraints);
        } else {
          return _buildLoading();
        }
      });
}

When set the heroAttributes option to null, the _buildImage() will return a FutureBuilder which will always return the _buildLoading() in the first frame. And if the image is cached before, the FutureBuilder will return the _buildWrapperImage() immediately in next frame. Finally it will cause the flash.
I don't think using FutureBuilder here is good. And why not just use the loadingBuilder of the Image widget to show the loading animation? Its implementation is more robust.

Isn't the problem here that the future is being recreated on every build, which then causes the flash?
According to Flutter guidelines, you should create the future once, for instance in initState.

why not just use the loadingBuilder

Some reasons:
1- Because we dont want the user zooming on a circular progress indicator.
2- Because we need the dimensions of the image to perform initial scalings and since we receive providers.

I don't think using FutureBuilder here is good.

PRs are always welcome. Even more the non breaking stuff ones.
That said, you can:
1- Remove the condition to pass the hero attributes. I dont see the need for momiting hero attributes, since the non selecetd ones wont be rendered anyway. heck the gallery on teh example app.
2- You can create a gallery with a PageView.custom and a keepalive as shown here. Since pageview has not such a thing as addAutomaticKeepAlives. That wouldn't rebuild each PhotoView on every page change.

authors: graknol nekocode renancaraujo

license: MIT

license_source: github-api


text:
【Bug】无法启动

Error: Cannot find module 'metadata.js' Require stack: - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+monaco-editor-webpack-plugin@7.0.1\node_modules\monaco-editor-webpack-plugin\out\index.js - E:\work\amis-editor-deploy\config-overrides.js - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+react-app-rewired@2.2.1_react-scripts@5.0.0\node_modules\react-app-rewired\config-overrides.js - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+react-app-rewired@2.2.1_react-scripts@5.0.0\node_modules\react-app-rewired\overrides\paths.js - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+react-app-rewired@2.2.1_react-scripts@5.0.0\node_modules\react-app-rewired\scripts\start.js
重装多次，无论是npm,cnpm还是无法运行

Error: Cannot find module 'metadata.js' Require stack: - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+monaco-editor-webpack-plugin@7.0.1\node_modules\monaco-editor-webpack-plugin\out\index.js - E:\work\amis-editor-deploy\config-overrides.js - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+react-app-rewired@2.2.1_react-scripts@5.0.0\node_modules\react-app-rewired\config-overrides.js - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+react-app-rewired@2.2.1_react-scripts@5.0.0\node_modules\react-app-rewired\overrides\paths.js - E:\work\amis-editor-deploy\node_modules.pnpm\registry.npmmirror.com+react-app-rewired@2.2.1_react-scripts@5.0.0\node_modules\react-app-rewired\scripts\start.js
重装多次，无论是npm,cnpm还是无法运行

monaco-editor-webpack-plugin 里报错 Cannot find module 'metadata.js'
monaco-editor-webpack-plugin和monaco-editor的版本对应出现了问题，需要去官网看下对应关系
参照 https://www.npmjs.com/package/monaco-editor-webpack-plugin

authors: guanyue-leo rencoo

repo: rencoo/amis-editor-deploy


text:
VSTS Package Server URLs are out of date

When attempting to use this extension to push packages to a VSTS Package view I receive the following error in the VSTS log:  ##[error]The remote server returned an error: (400) Bad Request.
It appears VSTS has changed the package server URLs.
Currently my package is hosted at:  https://{account}.visualstudio.com/{team}/_packaging?feed={packageFeed}&_a=feed
This is different from what appears in the powershell script:
$basepackageurl = ("https://{0}.pkgs.visualstudio.com/DefaultCollection/_apis/packaging/feeds" -f $account)
$basefeedsurl = ("https://{0}.feeds.visualstudio.com/DefaultCollection/_apis/packaging/feeds" -f $account)
$packageURL = "$basefeedsurl/$feedName/packages/$packageId/?api-version=2.0-preview"
Attempting to navigate directly to the URL in the powershell script formatted with my account/feed/etc results in a 404 error.

HI,
I'm also experiencing this problem. Is there a workaround?

@DavidJFowler - I've not yet found one.  Keep me posted if you come up with anything.  Currently I'm using a send email task to notify the release requester to push the packages manually.  Certainly not ideal and definitely not automatic or foolproof.
Based on reading through some MS VSTS issue threads it sounds like we may be getting some package management improvements soon.  Hopefully the MS improvements will remove the need for this extension.

Hi,
Sorry for the delayed response. I've been quite busy. I have tested on my own VSTS (multiple) and it all works. In the documentation https://www.visualstudio.com/en-us/docs/integrate/api/packaging/nuget#release-package there is also the url that is used..
Have you tried postman (or something) to run this patch?
try to run this powershell in ISE or powershell and see if it works..
$accountname = "vsts account name "
$pat = "pat"
$basepackageurl = ("https://$accountname.pkgs.visualstudio.com/DefaultCollection/_apis/packaging/feeds" -f $account)
$releaseView = "namereleaseview"
$feedname = "feedname"
$packageName = "packagename"
$packageVersion = "1.3.0"

$userpass = ":$($pat)"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($userpass))
$token = "Basic $encodedCreds"

     $releaseViewURL = "$basepackageurl/$feedName/nuget/packages/$packageName/versions/$($packageVersion)?api-version=3.0-preview.1"

     $json = @{
        views = @{
            op = "add"
            path = "/views/-"
            value = "$releaseView"
        }
    }
    $response = Invoke-RestMethod -Uri $releaseViewURL -Headers @{Authorization = $token} -ContentType "application/json" -Method Patch -Body (ConvertTo-Json $json)
    return $response

The powershell works but the VSTS build step is still failing with "The remote server returned an error: (400) Bad Request."

can you send me the logfile (system.debug set to true in the build/release) and a screendump of the filled in parameters?  You can send it to me in an email rvanosnabrugge AT Live DOT com

If you select the package using the drop down on the task definition it works. if you type a name in, or use a variable you get the bad request error.

I can confirm what @DavidJFowler says - you must select the package from the drop down for the task to work properly.  @renevanosnabrugge can this be improved to allow the use of variable names in the parameter input fields?

Fixed in 1.2.10


text:
Feature/cond value list

add ability to listen to list of fields

Thank you for contributing!

source: gharchive/pull-request


text:
Не можливо малювати

Доброго дня
Зовсім не зрозумілий зовнішній вигляд. Програмні коди, реклама. Зовсім не має віконця, щоб малювати. Нічого не розумію. Скрін додаю

Добрий вечір! Підтверджую, неможливо малювати! При відкритті програми для малювання отримую таку ж саму картинку. Жодного функціоналу для малювання! Поясніть, будь ласка, що зробити, щоб мережа запрацювала. Дуже необхідна в роботі! Дякую. Чекаю відповіді.

repo: replicate/scribble-diffusion


text:
feat(sbctl): add support get configmaps -o yaml

sc-103251
add support to kubectl get configmaps in SBCTL
kubectl get configmap -o yaml
kubectl get configmap -A

In current version, you will get error
Error from server (InternalError): an error on the server ("") has prevented the request from succeeding (get configmaps kotsadm-confg)

Trivy sanner is failing, I don't know why. Could you try to rebase to see if that resolves the failures?

Thank you @banjoh! After you bump the dependency, it is working now!

authors: DexterYan banjoh

repo: replicatedhq/sbctl


text:
Feature: support distributed async threshold signing

What is your proposal?
The rstuf cli provides a tool to sign delegating metadata (root) with a threshold of keys. To do so, it requires all signing keys to be available locally.
This may not be feasible in a scenario, where the keys are hardware tokens, which are physically distributed over the world.
As an example, the PSF members, who hold the PyPI/458 root keys are likely reluctant to meet at least once a year in person, in order to update the expiration time of root metadata.
Rstuf should provide tools to facilitate updating metadata, building consensus about the contents of the update, and signing metadata in a distributed asynchronous manner.
Services it relates to
repository-service-for-tuf-cli
References
@jku’s TUF-on-CI should serve well as inspiration.
Code of Conduct

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

That is my proposal for design implementation.
General flow
sequenceDiagram
    actor User as Key Owner
    participant CLI
    participant API
    participant Broker
    participant Worker

    User ->> CLI: (First Key Owner) Ceremony/Bootstrap
    Note over User, CLI: Defines settings (number keys, threshold)
Add public keys and sign with its key
    CLI ->> API: Send POST /api/v1/bootstrap
    API ->> Broker: Submit the bootstrap task
    API -->> CLI: Bootstrap ID
    Worker ->> Broker: Bootstrap Task
    Worker ->> Worker: Process bootstrap
    Note over Worker, Worker: if threshold >= signature: finished
else:
pending-sign state
    User ->> CLI: (Key Owner) Sign Root, Loads the Key
    CLI ->> API: GET /api/v1/metadata/sign
    Note over CLI, API:  Verifies if
- metadata signing state
- expected public key
    API -->> CLI: Current Metadata
    CLI ->> CLI: Sign metadata using key
    CLI ->> API: POST /api/v1/metadata/sign
    API -->> CLI: Task ID
    API ->> Broker: Send Metadata Sign Task
    Worker ->> Worker: Process metadata signature
    Note over Worker, Worker: if threshold >= signature: finished
else:
pending-sign state

The above design is applied for Bootstrap and any metadata requiring an offline key signature.
Note: Current RSTUF version has only Root metadata with offline keys, but it could allow another role using offline keys. As an example, Targets role.
RSTUF CLI
Feature to get key information
rstuf key info: Give user information about the key (keyid, keytype and the keyval public)
rstuf admin sign: Used to sign specific TUF metadata, i.e., Root.
RSTUF the API
Endpoints:
GET-/api/metadata/sign: This endpoint retrieves current signature state of certain role
POST-/api/v1/metadata/sign: This endpoint receives signed metadata to submit a task to the RSTUF broker
RSTUF Broker
Process the metadata signing (metadata_signing)
It processes the signature:

Verifies what Role is signing
Verifies if the signature is related to Bootstrap
Verifies if the signature is related to Metadata Update
Verifies if the signing process requires waiting for another metadata signature
For example, if the Root changed Targets keys and Root is fully signed, it cannot persist until Targets is fully signed
to update the delegation order avoiding inconsistency.

I'll file tasks issues for the components where we can detail each implementation part.

Required tasks to complete this feature:

[ ] https://github.com/repository-service-tuf/repository-service-tuf-worker/issues/300
[ ] https://github.com/repository-service-tuf/repository-service-tuf-api/issues/355
[ ] https://github.com/repository-service-tuf/repository-service-tuf-cli/issues/294

I just reviewed the tasks for cli, worker, and api, plus your POCs, and left a few comments directly on the commits or issue pages. I love how small the changes are! What's stopping you from PRing this? :D

I just reviewed the tasks for cli, worker, and api, plus your POCs, and left a few comments directly on the commits or issue pages. I love how small the changes are! What's stopping you from PRing this? :D

❤
Thank you, @lukpueh!
I'm doing it. I'm doing the Worker now. I asked you to review something.

I decided to break this feature down into more user stories to make the implementation smaller.
You can see the changes in this comment.

Hi @lukpueh,
I discussed with @MVrachev that we need an extra user story here.
A flow to cancel/stop a signing process.
In case the users have started a signing process for Root (or Targets) role.
Case scenarios examples:

User removed a wrong signing key
User the started a wrong role signing as user's key signs multiple roles
User decides to stop a signing process for bootstrap/metadata update

I suggest that this flows have a similar flow as the signing process, see the example below

Root has the signing keys k1, k2, k3, k4, k5

Root has threshold as 3

Key holder k1 start the singing process

ROOT_SIGNING now has Root metadata with k1 signature

Key holder k2 signs the Root

The Key holders identifies a mistake in the metadata (on signing process)

A key holder that have already signed decides to cancel this metadata signing

k2 sends a DELETE /api/v1/metadata/sing with a rolename and new signature
RSTUF Worker validates the signature and removes k2 signature , now the <ROLENAME>_SIGNING has only k1 signature)
k2 sends a DELETE /api/v1/metadata/sign with a rolename and new signature
RSTUF Worker validates the signature and removes k1 signature , now the < ROLENAME>_SIGNING 0 signatures and become None

It gives the user also to rolback and continue the signing
If you agree I will file the issues.

After a meeting with @kairoaraujo and @lukpueh we came up to the conclusion that there is no need to define a DELETE /api/v1/metadata/sign endpoint but instead seems more reasonable to define a new PATCH /api/v1/metadata/sign endpoint. This way the user will not just delete the old metadata which is part of a DAS process, but will overwrite its value with the correct one.
I created two new issues https://github.com/repository-service-tuf/repository-service-tuf-api/issues/415 and https://github.com/repository-service-tuf/repository-service-tuf-worker/issues/366 for the API and the Worker respectively.
I am thinking about what should be added to the CLI and I need someone with whom I can discuss this.
Let's do it on slack or on a video.

TODO for worker implementation of this task (can ticketize, if desired):
In repository task interface methods bootstrap, metadata_update and sign_metadata we currently use a mix of verify_delegate from the python-tuf Metadata API, a custom helper wrapper _validate_threshold, and an orthogonal signature verification helper _validate_signature to checks if [^1] :

a given signature is valid
all signatures on the metadata are valid
threshold is met

All 3 checks can and should be consolidated by using a single not yet released interface method from python-tuf (see #367)
[^1]: metadata_update only performs check 3 (see https://github.com/repository-service-tuf/repository-service-tuf-worker/pull/355#issuecomment-1748649495), which is the only security critical check. Checks 1 and 2 are still helpful as sanity checks.

Update:
Last night, @MVrachev and I tested it, and it works well!
The only thing that needs to be added is a Functional Test to verify this feature and avoid regression.

authors: MVrachev kairoaraujo lukpueh


text:
Response handling: callback / stream / promise

IMHO the interface would need polishing in regard to the response handling so that alternative implementations can pop up.
First off, the callback needs to be specified in detail. It can be modelled after Request's callback definition:
The callback argument gets 3 arguments:

1. An error when applicable (usually from http.ClientRequest object)
2. An http.IncomingMessage object
3. The third is the response body (String or Buffer, or JSON object if the json option is supplied)

However, when I read this I realise that especially the second parameter is highly implementation specific. In order to make implementations replaceable we would need to define a general response object I guess.
Handling responses as a stream or a promise would ideally be loaded as an optional dependency. In particular for the promise I would define:
request({ ... })
    .then(function (response) {
        // All responses get resolved with the general response object I mentioned for the callback
    })
    .catch(function (err) {
        // Equivalent to the callback getting an error
    });

I just tossed a few more details:

Basic API
Chain API
Promises

You can use the @request/api module in combination with any Promise implementation. The first example that I'm showing is using the built in Promise implementation, for cases when you don't want to include bluebird in your bundle.
I'm currently working on a bunch of modules that are not pushed to GitHub yet, but that's the gist of it. I'm open for suggestions.
What I was showing in the first few examples was the most bare bone API that each HTTP client wrapper should implement - just a function that accepts an options object. As you can anything else can be built around that, and there is no need for the API implementation to be part of your module.

Perfect @simov ! I reviewed all API sections and all looks good to me. It's so flexible. Kudos for your design!
I think at this point it is time for me to create an alpha version of request-promise based on request@next. Although you basically already did all the work I will create a configuration that produces the same api as the current version of request-promise. This way I can give you better feedback if everything falls into place like expected.

I just refactored request-promise to use @request/api (basic type) and @request/client. Everything fell into place like expected. That means I will be able to create request-promise@next without additional breaking changes.
The request-promise tests that still fail can be considered as an effect of request@next still being alpha. They are related to implementation details and not to the new architecture. I won't report the issues right now because they most likely already pop up in request's own tests.

That's great! Just keep in mind that the @request/core refactoring is not published yet, it just takes a bit more time. The only change for you would be that the module containing most of the request features enabled won't be called @request/client but something else probably. Other than that everything else should be working as it is.

Perfect. 👍 Indeed, no rush there, I made the refactoring in a branch.

authors: analog-nico simov

repo: request/interface


text:
Getting the length of responce?

Is there a way to get content length?
I do not see an easy way to see it when json: true.
Possibly, any other like wire size, decoded size, header size... something similar to time option.

This is possible if you call the request with the option resolveWithFullResponse: true.

authors: rileyjshaw tolysz

repo: request/request-promise-native

license: isc


text:
Handling of empty responses when dealing with GZip

This is a continuation of the discussion in https://github.com/request/request/pull/2176
Basically, what should request do when a server returns an empty response with the Content-Encoding header set to gzip?

Basically zlib throws on stream write/end in cases when the compressed data is corrupted. It turns out that similar error is thrown on empty response body as well.
I'm not able to find a way to determine if the incoming response stream contains any data prior piping it to zlib. So the underlying zlib module throws and the error is being forwarded to the end user. Unfortunately at this point your only option would be to swallow the error.

As mentioned in RFC 7230, it seems that there are well defined conditions under which a response may have no body.
All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
   responses do not include a message body.  All other responses do
   include a message body, although the body might be of zero length.

and
Responses to the HEAD request method (Section 4.3.2
   of [RFC7231]) never include a message body [snip]

In these scenarios at least, can we ensure that request does not throw an error, and returns the response body as an empty string?
For example, having a 204 response to a GET is a perfectly valid scenario, and not an error. We should not forward an error to the user in this case, I think.

All 1xx (Informational), 204 (No Content), and 304 (Not Modified)

That sounds reasonable, though as you are aware handling those status codes does not guarantee no errors.
Errors should be forwarded always, that's the point, the status code check should be placed before piping to zlib (we are on the same page).

Yep, I agree with you.. request shouldn't accidentally catch legitimate errors.

Implemented in #2176

authors: czardoz simov

repo: request/request


text:
Requests memory leak: Caused computer to crash

So as I was working on coding a notifier for a website, I came across an issue where my computer would gradually slow down after a long period of time. I thought it was nothing until my computer crashed. I then decided to look up on this issue by testing every single line of code in my while loop until i finally found out that it was caused by the requests module.
I decided to look up on google if anyone else has gotten an issue like this and I actually did manage to find a page with someone who had this exact same problem.
My code that I used to create this memory leak was this:
import requests

ListedItems = {}

while True:
	r = requests.get("urlToGet").json()
	time.sleep(1)
	for itm in r:
		print(itm)
	del r

I even tried to delete the r variable after I got everything I needed, but it still resulted in my computer to crash after a few hours. Please note that I need to have this program running for days.

Hi @Kodingu, we have another issue open (#4601) for something similar, but haven't been given enough information to identify a problem.
Could you please provide the information originally requested in the template used to create this ticket? It also looks like you may have been storing items in ListedItems at some point since you've included it in your repro. To verify, this is the exact code you've used to repro and you aren't storing anything from these responses?
Would you also mind testing this with the minimum required amount of code to reproduce?
e.g. Does this repro the problem for you?
import requests
import time

while True:
    r = requests.get("urlToGet")
    time.sleep(1)
    print(r.content)
    del r

I've used @nateprewitt's sample code and the memory usage seems stable to me:

I'm also curious whether ListItems dict was modified to keep historic or memo-istic records of the json elements.
If you do want to use a dictionary, nonetheless, and would like to have an upper bound for the contained elements, I would recommend using the following dict implementation:
from collections import OrderedDict

class limited_dict(OrderedDict):

    def __init__(self, *a, **kw):
        self.limit = kw.pop("maxsize", None)
        OrderedDict.__init__(self, *a, **kw)

    def __setitem__(self, key, value):
        OrderedDict.__setitem__(self, key, value)
        self.__check()

    def __check(self):
        if self.limit is not None:
            while len(self) > self.limit:
                self.popitem(last=False)

# test
# a = limited_dict(maxsize=10)
# for i in range(20):
#     a[str(i)] = i
#
# print a
# limited_dict([('10', 10),
#               ('11', 11),
#               ('12', 12),
#               ('13', 13),
#               ('14', 14),
#               ('15', 15),
#               ('16', 16),
#               ('17', 17),
#               ('18', 18),
#               ('19', 19)])

Thanks so much for taking the time to look into this @initbar! It does look like there may have been more than just Requests code involved in the initial POC with the potential for lingering pointers.
I think we may need a longer look at memory usage to really rule out a leak, but that should probably be tracked in the main issue. I'm closing this out since @Kodingu hasn't provided any more information, and we'll move forward in #4601.

authors: Kodingu initbar nateprewitt

repo: requests/requests


text:
filter connections (including indicators) based on the state of the r…

…emoteNeed (only use the ones that are actually already in the state and still active)
fixes #1739
fixes #1903

can be tested but must be pushed to int-test first, anyway this will also prohibit the visibility of connections to needs that haven't been loaded yet (or are not reachable) -> we will only show connections that have a corresponding need in the state active (and that is only the case if we were able to fetch the need), this also goes for the counters.
this also fixes the weird ui glitch that shows a connection item without any content but the connectionstate

repo: researchstudio-sat/webofneeds


text:
Doesn't work with ESM typescript files

Describe the Bug
I'm building an app in typescript and I'm using ESM "type":"module". This means that all my imports use explicit file extension .js which is not the de facto extension of the source files. When trying to import anything from my codebase errors occur.

Which package is affected (leave empty if unsure)
No response
Link to the code that reproduces this issue
n/a
To Reproduce

create a project
set type to module in package.json
add an import to external file in the email file

Expected Behavior
everything works
What's your node version? (if relevant)
No response

Same issue here. Beautiful library, but ESM users are left out unfortunately.
@gabrielmfern  I created a self contained repro for this issue here: https://github.com/florianbepunkt/react-emails-esm-repro

@florianbepunkt Thanks for the repro, but it seems to maybe be private 🤔

@gabrielmfern Made it public now, apologies. This should have been fixed in Next.js – not sure why the issue still exists: https://github.com/vercel/next.js/issues/41961

This should now be fixed as the preview server is completely different and bundles the emails using esbuild

authors: florianbepunkt gabrielmfern janek515

repo: resend/react-email


text:
Automated generation of build and documentation files

As we store build objects in the repo along with documentation and of course code, code reviews can get quite difficult when all of the auto-generated files get in the way. If we instead generated these objects post-review, it would mean that the review could focus on the code itself and not have to wade through other files.
Something like

pre-merge: npm run build && npm run doc

Isn't that exactly what https://github.com/resin-io-modules/resin-procbots/pull/123/commits/c6e171b0e01b29063dc0f46cb474f25b36ca9168 helps to mitigate?

Yeah, but we could have auto-generation and "hiding" for want of a better word bundled together, to reduce the manual tasks that must be done before merging a PR.

On Etcher, we similarly have some files that are autogenerated from others (SASS/CSS files, Docker templates, etc.), with both the source and autogenerated files being stored in the repo. A long time ago I asked @jviotti if it would make sense to only have the source files stored in the repo, with the autogenerated files only created at build / install time, and he replied that he preferred seeing the autogenerated files in the GH diff too, as it allowed him to double-check that the tools that created those files were always doing "the right thing".

Yeah, I don't really trust pre-processors, after some incidents from our CoffeeScript days, specially if we're not locking down the version of the transpiler.
I wonder if we can somehow get the best of both worlds: have ProcBots auto-generate the build files, but still provide a way for us to double check the result if we need to do so.

This is a recurring theme and so far the winning argument is the predictability one mentioned by @jviotti (and also @Page- in the past); for interpreted languages, we get to have git history of the exact reversion/codebase that runs in a production setting.
I couldn't agree more that having diffs of autogenerated files is really annoying, but imo suppressing them reduces the pain by a lot (to the point I don't matter having suppressed diffs around, which I can easily skip)

Personally I dislike committing built files on every PR because it makes rebasing and conflict resolution a nightmare, at the same time I don't mind either way for tagged/released versions as it does give that historical view without causing the same pain

authors: CameronDiver Page- jviotti lekkas lurch

repo: resin-io-modules/resin-procbots


text:
Support else clauses in template mappings

Lets say we have a template mapping where we want a certain template to apply if the value is 1, and another if its any number, but 1. For example:
{
  "foo": {
    "mapping": [
      {
        "value": "1",
        "template": {
          "my_property": "1"
        }
      },
      {
        "value": "<<OTHERWISE>>",
        "template": {
          "my_property": "0"
        }
      }
    ]
  }
}

What should we replace <<OTHERWISE>> with?
We can allow value to take an asterisk to represent the else clause, or maybe even allow one of the template mappings to contain no value at all.
For example:
{
  "foo": {
    "mapping": [
      {
        "value": "1",
        "template": {
          "my_property": "1"
        }
      },
      {
        "template": {
          "my_property": "0"
        }
      }
    ]
  }
}

Omitting the value is certainly not an option since it doesn't allow us to go backward. In the example above, if my_property is 0, what would the value of foo be?

Closing as obsolote.

authors: jviotti zrzka

repo: resin-io/reconfix


text:
Undefined downloads

I haven't been able to install resin-cli in debian jessie, I'm encountering the following errors:
node-pre-gyp ERR! Tried to download(undefined): https://github.com/resin-io/node-ext2fs/releases/download/v0.1.1/bindings-v0.1.1-node-v59-linux-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for ext2fs@0.1.1 and node@9.6.1 (node-v59 ABI, glibc) (falling back to source compile with node-gyp)

resin-cli version: (N/A) trying to install last version with --global and --production
Operating system and architecture: debian jessie and x86_64

The URL in there does download successfully for me. Perhaps this was just a temporary github blip - can you reproduce this now @Davidnet? You can see the built node-ext2fs binaries at https://github.com/resin-io/node-ext2fs/releases/tag/v0.1.1, this one should definitely exist.

@Davidnet I believe this was actually caused by #805 - --unsafe-perm is now required as an option to npm install on some systems. That's now in the documentation, which should make it easier to avoid in future.
Assuming that's true, I'm going to close this ticket, but do let us know if you're still seeing issues installing with that option.

authors: Davidnet pimterry

repo: resin-io/resin-cli


text:
WIP add support for stereo amp

Signed-off-by: Carlo Maria Curinga czkzcz.cmc@gmail.com

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@curcuz can we close this PR?

Can one of the admins verify this patch?

Closing this ticket. Comment if this is a mistake.

authors: agherzan curcuz resin-jenkins

repo: resin-os/resin-artik


text:
Add a simple logger example to README

Showing how to use a basic Ruby logger might be helpful for folks who are just trying to quickly debug connections.

This would be helpful.

Superseded by 687ff40d

authors: ab danielfone lulalala

repo: rest-client/rest-client


text:
Bump to most recent ruby/jruby; drop ruby no longer supported

a little housekeeping in an effort to get the ball rolling again.

Thanks for the PR! We tend to take a very conservative approach to dropping support for older versions of ruby, since older versions of ruby tend to be used fairly widely for long after the official EOL dates.
We test on OS X because Apple monkey patches OpenSSL to have different behavior than on other platforms, and rest-client prints some different warnings as a result.
The Travis tests should be working again thanks to #716.

authors: ab joshRpowell


text:
[Bug] Test results format incompatible with bitbucket pipelines

I used restcli to execute tests as part of bitbucket pipeline, and found that bitbucket didn't understand results correctly.
I created request to support, and they respond me:

Test report being generated as the following:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="2" name="IntelliJ Rest CLI - Test Generator">
<testsuite tests="1" name="https://bitbucket.org/"><testcase name="Request executed successfully"/>
</testsuite><testsuite tests="1" name="https://api.bitbucket.org/notexist">                <testcase name="Request executed successfully">
                    <failure type="AssertionFailure">Response status is not 200
File: example.http
Line: 14</failure>
                </testcase>
</testsuite></testsuites>

To get it working, format should be adjusted to:

<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="2" name="IntelliJ Rest CLI - Test Generator">
	<testsuite tests="1" name="https://bitbucket.org/" errors="0" failures="0" skip="0">
		<testcase classname="Test" name="Request executed successfully" time="0">
		</testcase>
	</testsuite>
	<testsuite tests="1" name="https://api.bitbucket.org/notexist" errors="0" failures="1" skip="0">
		<testcase classname="Test" name="Request executed successfully" time="0">
			<failure type="AssertionFailure" message="Response status is not 200">
			File: example.http
			Line: 14
			</failure>
		</testcase>
	</testsuite>
</testsuites>

We suspect that your reporting tool is not following the X-Unit / J-Unit format, because as you can see certain parameters are missing.

Thank you for reporting the issue and create the PR.
I merged your PR.
and I will release new version soon.
Thank you!

repo: restcli/restcli


text:
Fix client-side ParamConverter retrieval

(Not sure if it's necessary to create an issue for this small change so I just created a PR)
At the moment the resteasy-client doesn't retrieve ParamConverters for objects different from Collection and array if the ParamConverterProvider requires the genericType or the annotations. This PR fixes the issue.
I haven't found any tests for the retrieval of ParamConverters on client-side. If there are any could you just point me to them so that I can add a test case for this.

Hello, coder-hugo. I'm waiting for one of the admins to verify this patch with /ok-to-test in a comment.

We will need a JIRA for this, really for any bug. However, I can create that. For now we'll let CI run to see how it goes :)
We require all contributions to be made under the terms of the ASL 2.0 License: http://www.apache.org/licenses/LICENSE-2.0
Do you agree to these terms?

/ok-to-test

Yes, I agree to the terms of the ASL 2.0 License.

@coder-hugo Do you have an example use-case by chance?

If you use for example this ParamConverterProvider:
@Provider
public class UnmodifiedSinceParamConverterProvider implements ParamConverterProvider {

    @Override
    public <T> ParamConverter<T> getConverter(Class<T> rawType, Type genericType, Annotation[] annotations) {
        if (rawType.isAssignableFrom(OffsetDateTime.class) && Optional.ofNullable(annotations).stream().flatMap(Stream::of).anyMatch(this::match)) {
            return (ParamConverter<T>) new UnmodifiedSinceParamConverter();
        }
        return null;
    }

    private boolean match(Annotation annotation) {
        return annotation instanceof HeaderParam headerParam && "If-Unmodified-Since".equals(headerParam.value());
    }

    private static class UnmodifiedSinceParamConverter implements ParamConverter<OffsetDateTime> {

        @Override
        public OffsetDateTime fromString(String value) {
            return value == null ? null : OffsetDateTime.parse(value, DateTimeFormatter.RFC_1123_DATE_TIME);
        }

        @Override
        public String toString(OffsetDateTime value) {
            return value == null ? null : value.format(DateTimeFormatter.RFC_1123_DATE_TIME);
        }

    }

}

for this interface:
@Path("/")
public interface TestApi {

    @POST
    void update(@HeaderParam("If-Unmodified-Since") OffsetDateTime ifUnmodifiedSince);

}

resteasy will register in the current version the UnmodifiedSinceParamConverter for the update method on server side but not on client side.

Thank you @coder-hugo. I'll be back-porting this fix to 6.2 and 5.0 as well.

authors: coder-hugo jamezp wildfly-ci

repo: resteasy/resteasy


text:
gs: add option to set chunk size

By default, the GCS Go packages have an internal "chunk size" of 8MB,
used for blob uploads.
Media().Do() will buffer a full 8MB from the io.Reader (or less if EOF
is reached) then write that full 8MB to the network all at once.
This behavior does not play nicely with --limit-upload, which only
limits the Reader passed to Media. While the long-term average upload
rate will be correctly limited, the actual network bandwidth will be
very spikey.
e.g., if an 8MB/s connection is limited to 1MB/s, Media().Do() will
spend 8s reading from the rate-limited reader (performing no network
requests), then 1s writing to the network at 8MB/s.
This is bad for network connections hurt by full-speed uploads,
particularly when writing 8MB will take several seconds.
Add a backend option to allow specifying the ChunkSize media option,
which sets this internal buffer size in increments of 256KB, with 256KB
as the smallest chunk size.
My connection is around 1.5MB/s up, with nominal ~15ms ping times to
8.8.8.8.
Without this change, --limit-upload 1024 results in several seconds of
~200ms ping times (uploading), followed by several seconds of ~15ms ping
times (reading from rate-limited reader).
With this change and a chunk size of 256KB, --limit-upload 1024 results
in a relatively constant ~30-40ms ping times.
It may eventually make sense to automatically reduce the chunk size if
--limit-upload is set, but at this point I don't have a good heuristic
for what the size should be.
As far as I can tell, --limit-download is not affected by this problem,
as Get().Download() returns the real http.Response.Body without any
internal buffering.
Updates #1216

Codecov Report

Merging #1358 into master will decrease coverage by 5.56%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1358      +/-   ##
==========================================
- Coverage   51.58%   46.01%   -5.57%
==========================================
  Files         135      135
  Lines       13381    13386       +5
==========================================
- Hits         6903     6160     -743
- Misses       5630     6438     +808
+ Partials      848      788      -60

Impacted Files
Coverage Δ

internal/backend/gs/config.go
77.77% <ø> (ø)
:arrow_up:

internal/backend/gs/gs.go
0% <0%> (-65.6%)
:arrow_down:

internal/backend/b2/b2.go
0% <0%> (-79.93%)
:arrow_down:

internal/backend/azure/azure.go
0% <0%> (-75.35%)
:arrow_down:

internal/backend/swift/swift.go
0% <0%> (-73.9%)
:arrow_down:

internal/backend/swift/config.go
34.37% <0%> (-56.25%)
:arrow_down:

internal/checker/checker.go
68.19% <0%> (-3.84%)
:arrow_down:

internal/archiver/archiver.go
65.36% <0%> (+0.16%)
:arrow_up:

Continue to review full report at Codecov.

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

Oh, good point, thanks for digging into the problem!
I'd like to avoid exposing this option to end users, is there any harm in using 256KiB by default?
From the backend, it's not possible to directly see if the upload limit is configured, so we'd need to pass that in when opening the backend. The upload limit divided by four or eight should be a good heuristic.
What do you think?

Actually, looking into it more, I think it might be reasonable to set the chunk size to 0 by default.
The GCS library is doing this chunking to implement resumable uploads. It uploads the object in chunk size chunks and has automatic retry and exponential backoff if chunk upload fails.
The main purpose of resumable uploads is to avoid having to re-upload lots of data if a request fails. (Max re-upload is the chunk size). However, the default chunk size is 8MB, and if I understand correctly, the maximum pack size is 12MB (4MB min pack size + 8MB max blob size), so the default chunk size isn't much more than the maximum object size we'll upload anyways.
Setting the chunk size to 0 disables resumable uploads altogether and uploads the entire object in a single request. The passed Reader is used more directly, without explicit large buffers.
This wouldn't eliminate all buffering; the GCS libraries still io.Copy the Reader to an io.Pipe(), and net/http does a fair amount of io.Copy'ing itself, but I suspect this would get the best rate limiting behavior we can easily achieve.
Thoughts?

I think we can set the chunk size to zero.

PTAL

benchcmp agrees:
benchmark                                               old bytes     new bytes     delta
BenchmarkBackendGS/BenchmarkLoadFile-4                  373032        344088        -7.76%
BenchmarkBackendGS/BenchmarkLoadPartialFile-4           72112         72680         +0.79%
BenchmarkBackendGS/BenchmarkLoadPartialFileOffset-4     72336         84205         +16.41%
BenchmarkBackendGS/BenchmarkSave-4                      8581304       206912        -97.59%

authors: codecov-io fd0 prattmic

repo: restic/restic


text:
doc: mention metadata that is not backed up currently

See: #3497
What does this PR change? What problem does it solve?
Document some metadata that is not backed up.
Was the change previously discussed in an issue or on the forum?
#3497
Checklist

[x] I have read the contribution guidelines.
[x] I have enabled maintainer edits.
[ ] I have added tests for all code changes.
[x] I have added documentation for relevant changes (in the manual).
[ ] There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
[ ] I have run gofmt on the code in all commits.
[x] All commit messages are formatted in the same style as the other commits in the repo.
[x] I'm done! This pull request is ready for review.

I've finally found one old issue again which was already discussing some attributes which are not backed up: #1622 . That issue also mentions one more missing piece of metadata, the file creation date. With that the list is probably somewhat complete.
My current feeling is that we should remove the reference to #2075, as it's not providing additional information.

I moved the issue mentions to the commit message rather than the docs itself.

authors: MichaelEischer mathstuf


text:
Make sure SaveFile always returns a node

Closes #699

Current coverage is 51.55% (diff: 0.00%)

Merging #700 into master will increase coverage by 0.14%

@@             master       #700   diff @@
==========================================
  Files            95         95
  Lines          7476       7476
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           3843       3854    +11
+ Misses         3084       3070    -14
- Partials        549        552     +3

Powered by Codecov. Last update 85c87b9...9885aea


text:
Add instructions to Readme for local dev setup with MSI (using Azure VM)

Description:

Update README with instructions on how to set up the local dev environment on an Azure VM and how to set up Managed Identity to remove any need for storing client id/password/secret locally

This won't be necessary with the new SDKs

This is no longer necessary because the Java SDK supports using az cli credentials

authors: aflinchb bartr

repo: retaildevcrews/helium-java


text:
kernel32-sys fails cross-compilation (32-bit target, 64-bit toolchain)

Install 64-bit rust toolchain rustup default stable-x86_64-pc-windows-msvc
Add the 32-bit target rustup target add i686-pc-windows-msvc
Check out the 0.2 branch of the repo
cd lib/kernel32
cargo build --target i686-pc-windows-msvc

Expected: it builds successfully
Actual: build failure during link (module machine type 'X86' conflicts with target machine type 'x64')
This is true of the kernel32-sys crate hosted on crates.io, which means that any crate that depends on this one also cannot be cross-compiled to a 32-bit MSVC target using the 64-bit MSVC toolchain. This causes https://bugzilla.mozilla.org/show_bug.cgi?id=1350001 for example.

I talked to @retep998 on IRC about this. He explained that this happens because mozillabuild uses vcvars.bat to set up the build environment. Basically the 32-bit mozillabuild shell set up the MSVC environment to always produce 32-bit output. However rustc, when cross-compiling, uses the "host" environment for the build scripts. Therefore rustc is producing 64-bit artifacts and MSVC is trying to link with 32-bit artifacts, and this causes the breakage. I verified that trying to build kernel32-sys without vcvars (i.e. from a plain windows cmd prompt) works fine. So this is not really a bug in kernel32-sys per se but interaction between how rust does builds and the mozillabuild system using vcvars.


text:
add SOCKADDR_IN6

Per #533
Actually, since we're breaking anyway, I've deviated from the 0.2 version which had sockaddr_in6 and instead provided SOCKADDR_IN6 - since this seems like it's more consistent with having SOCKADDR_IN.
It's possible that I haven't grokked whatever naming convention you would have used for the inner union, but so far as I can tell this definition does what I expect when I use it.

Whether the naming is consistent with other definitions is irrelevant. The only thing that matters is whether it is the same as the identifiers in the Windows SDK headers.
The naming convention for unions is documented in CONTRIBUTING.md.

We're at cross-purposes re sockaddr_in vs SOCKADDR_IN... these are different in the Windows headers - see here and there.  So it's not that I'm changing the name for consistency: it's that I'm changing which one is provided for consistency.
Thanks for the pointer to the naming convention - I'll make tweaks as best I understand those notes!

MSDN is not the definitive reference on these things. According to the headers, SOCKADDR_IN6 is a typedef to SOCKADDR_IN6_LH which is the actual type name. sockaddr_in6 meanwhile is merely the struct name which by convention winapi does not use unless there is no type name for the struct.

Well, colour me confused!
Let's not play "guess what I'm thinking"... what change, if any, would you like to see in this pull request?

What I would like is for the PR to match the definitions in 10.0.16299.0\shared\ws2ipdef.h.

I think you mean: "please rename SOCKADDR_IN6 to SOCKADDR_IN6_LH (and make corresponding changes to the pointer type and anonymous union)".  Yes?
I'll push those changes and hope that's indeed what you intended.  If I've misunderstood, may I suggest that we'll likely draw this one to a close sooner if you would be explicit about what change you would like to see...
Thanks!


text:
Req: Export progress bar displaces the search bar

Log ID: 7NJTUZ4T-euc
When exporting, the progress bar displaces the search bar which becomes a moving target if you are trying to use it. It would be nice if the progress bar was placed next to the Zotero Sync icon. This way the existing toolbars would stay where they are.

That was super-fast. Thanks. I think there is less jumping around now, but not by much. BBT will always displace the search bar if it's injected to its left. Here are screenshots showing the three states as I see them:

In addition to rearranging elements, it may be a good idea to replace the progress bar with a pie chart, like downloads in FF. Precision is not required anyway, and the pie chart takes up a lot less space. This may be more important if that area gets crowded with add-ons adding more icons etc.

The shows a clock instead of a progress bar. I am not really happy with how it looks though. a pie chart could be an option if it were a standard UI element, but it's not in Zotero, there's only the progress bar. i tried making a pie chart using svg and css but it was a pain to do.

That one uses the standard progressbar but moves it to where it can't affect the search bar

this one has a passable pie-chart I think.

No more bars jumping around! Thanks. Here is what I see:

The 'stop' button on the left appears when Zotero syncs. I would expect that to appear next to the syncing icon instead, unless it displaces BBT elements. I think it is safer to make the pie chart green, consistent with the syncing icon etc, for when people use dark themes.
The beginning of the pie chart looking like a line is displayed for quite a while. Not an issue really, but I found it confusing initially.
But this is already much more functional. Thanks.

One of the best-looking progress indicators. Only problem is when the Zotero sync stop button appears it displaces the BBT elements for a few moments. It looks odd but it doesn't affect functionality, so not a huge problem.

Since stuff appears there dynamically, something is going to shove something else. UI is not my forte -- I would propose leaving it at this.

Only idea I can think of is placing the progress indicator immediately after the Locate drop-down menu followed by the BBT status text ('preparing' etc.). Locate is fixed in place and would work as an anchor. The length of the BBT status text varies but coming after the progress indicator, it won't displace anything.
Anyway, just a thought and it's more than fine as it is. I know even less about UIs (well, nothing) so I can't help unfortunately. Thanks.

A new build will drop in 10 minutes that moves the progress report to after the menu, but it ends up centered between the menu and the stop button. I don't know what to do about that, this technology is severely underdocumented at this stage.

There is some jumping around inevitably, but I think this is by far the
least offensive, possibly because of the more generous spacing. This is
perfectly acceptable imv. If documentation improves one day, a small
tweak may fix this completely.

Documentation is never going to improve. This is a technology (XUL/XPCOM) that Mozilla has abandoned for general use years ago. I reckon the people who know this arcane beast best are a few within the Mozilla team, and a few in the Zotero team. All of this will change (and will have to be redone) when Zotero moves to Electron.

this will be in the next release.

authors: glocalglocal retorquere

repo: retorquere/zotero-better-bibtex


text:
Posible Bug with video splash in RetroOrangePi 4.1 for Pi PC

Hi.
I have found a fault in your images for OPI PC.
The images of the version 4.1 for the OPI PC do not allow to use videos like splash.
The mp4 video that comes by default (or any video) does not go. It only plays the audio.
I have tried with 2 different SD.
I have tested with 2 different OPI PCs.
I have tested the image of the USA server and the European server.
Just installed the image, loads retro orange pi, go to menu of options, open retropie-setup.
Configuration Tools -> 831 Splashcreen.
Splashscreen enabled.
Randomizer disabled.
Choose Splashscreen -> own / extra -> splash-720-only.mp4
back, back, reboot ...
When you restart, you only hear the splashscreen audio, there is no video.
Thanks.

fixed in v4.2,  release soon


text:
error not defined error

   if (playPromise != undefined) {
      playPromise.then(function (success) {}).catch(function (err) {
        console.log('Error playing! \n\n', error);
      });
    }

The param name is err.

Good catch! Fix is merged in master and part of react-modular-audio-player version 1.2.0
Thanks!

authors: knod retrofuturejosh


text:
Tagging:  Multi-generation example would be helpful

It's not immediately obvious why the rounding_hole_mask is ignored in this example:
`include <BOSL2/std.scad>
back_half() {
diff()
cyl(h=5, d = 20, anchor = BOT)
attach(TOP) recolor("red") tag("remove") cyl(h = 2, d = 12, anchor = TOP)
attach(TOP) recolor("blue") tag("keep") tube(od = 20, wall = 2, h = 10, anchor = BOT)
attach(TOP) tag("remove") rounding_hole_mask(d = 18, rounding = 3);
}`

So in experimenting a bit, I found that basically what seems to be happening is that you're using the "keep" tag which is the tag to "force this to be kept" and it's overriding the "remove" tag below it.  If you stop using "keep" then I think it works as intended.  I'm not sure if there's a way to make this behave better.  (This whole tagging business is incredibly complex and mysterious.  Like I spent weeks fiddling with it to try to get it to work right all the time, and there always seemed to be cases where it did something unexpected.)
So:
back_half() {
diff()
  cyl(h=5, d = 20, anchor = BOT)
    attach(TOP,overlap=-.01) tag("remove") cyl(h = 2, d = 12, anchor = TOP)
      attach(TOP) tag("don't-remove")tube(od = 20, wall = 2, h = 10, anchor = BOT)
        attach(TOP) tag("remove") rounding_hole_mask(d = 16, rounding = 3)
  ;
}

I'll have to look into what exactly is happening and see if there is a way to make it behave better.

Well, tags just set tags.  By default, diff() pays attention to the "remove" and "keep" tags, as noted in the wiki.  Any other tags are treated as the based objects by diff()...unless you invoke diff() with different tags to use, which you can.  That is, it doesn't have to be "remove" and "keep".
I'm not sure what you mean by "a keyword for something other than remove or keep".  Did you find the wiki unclear when it laid out the categories of things matching "remove", things matching "keep", and everything else?
tag("keep") in the spot you have it does NOT ignore the mask.  It tags the first item with "keep" and its child (the mask) also gets kept.  That is, the child tag of "remove" is being ignored.   The mask is included in the model.  (Note, I found the colors distracting.  Also your mask is in the wrong place and of a questionable size, but you can see it below adding a rim to the model.)

Tags are inherited, so if you omit the tag then from the tube then it inherits "remove" from its parent and gets removed...which is to say, it never appears.

Wait, that previous example was wrong.  I had changed something.   So it does look like with the mask tagged as "remove" it never appears.
Actually on thinking a bit more, this is what is supposed to happen:   you have got four objects.   The cylinder has no tag.  It's the base object.  You have two objects removed:  the first cylinder and the mask.  Removing the mask does nothing.  Then you have one object kept, the tube.  The tube is kept as you requested!  Kept objects, as the wiki says, are unioned in after other objects are removed.

Note that it appears above that you suggest that diff() have a third keyword for what is currently "everything else".  That is impossible.  How can I have a keyword that lists everything else?   Suppose it was designed with a "remove", "force" and "keep".    What happens to objects that don't have any of those three tags???   (And in particular, what about the parent if you neglected to tag is as "keep"?)   Basically there always has to be some catch-all for the objects that are untagged or don't have tags matching the special ones.

Yes, I did have the wrong rounding_hole_mask diameter for that tube with that wall size.  It should have been 16.
After spending about an hour staring at example 12 in diff() I think I'm beginning to see what's going on, and why my suggestion of a third standard tag string makes little sense.   ....although I do think I'll be using tag("base") for things like the tube in my problem example to keep the code a little more readable for simple folk like me.
Examples 8 & 13  in diff() just make my head hurt!
Many thanks for your patience as I try to get my head around this.

authors: RAMilewski adrianVmariano


text:
Revision of login page, and rooming module.

Clean up of modules as well, ensuring nothing is particularly buggy.

@erchiggins i've finished work on this, merge whenever you're ready!


text:
fix view for importing a spend tx

utACK ab7b089c0e37a60206c91a749bef1945eb56a111

ACK 59626684ba082eac50c81bcff5858abb7d8f7718
on top of Daniela utACK

authors: danielabrozzoni edouardparis

repo: revault/revault-gui


text:
feat: add pseudo style-selectors

EDIT:
So I went on and implemented active([...]) as well, using the same approach with adding active to the Style-type. Which perhaps is still not ideal, but may be good enough. So in my mind, the extractPseudoStyles-function is the mainly what needs improvements.

Draft for brainstorming
Ok, so this is still a work in progress! I've stumbled upon a few things which I'm still trying to get my head around.

~Did you have any specific ideas on how to hold state in the Primitives.re @Akin909? I just added something to get it to render hover-styles on screen for now (any text-element that is being hovered will apply the styles)~

~Currently to make the Style.create-function accept the list(textStyleProps) we're forced(?) to add hover to Style.t. This also leads me to add it to applyStyle which I've currently made recursive to loop over all the properties of the hover-styles. Right now we could just return style since it's not used at all.~

Eventually closes #352

@lessp, I wonder if since the setState is happening inside of a component we could actually just actually use Hooks.state (might not be the exact api of the top of my head) to keep track of the Idle and Hover status

@lessp, I wonder if since the setState is happening inside of a component we could actually just actually use Hooks.state (might not be the exact api of the top of my head) to keep track of the Idle and Hover status

Thanks @Akin909, I'll have another look!
The main-issue I have with how it works now (apart from the temporary state-handling) is the extractPseudoStyles-function and the fact I can't figure out a good way to not have to add hover to the Style-type. So if there are any ideas on that let me know! 🙂

@lessp re. having to add hover to Style.t, that seems like the right and tbh inevitable thing. We can't have any value in that list that isn't in the type so I think it should be there so having to add it to the other helper functions also makes sense

@lessp re. having to add hover to Style.t, that seems like the right and tbh inevitable thing. We can't have any value in that list that isn't in the type so I think it should be there so having to add it to the other helper functions also makes sense

Cool! I'll have another look-over at this and then implement it to the others as well! 🙂

@Akin909, I made some minor adjustments and added hover-styles to most primitives, I did notice that there's a conflict with the View-primitive rooting from the fact that general styles can be passed to the Input-component and then filtered out respectively to its Primitive via extractViewStyles, which is a very nice feature, so it would be nice to apply a workaround to be able to make it work with the View-primitive as well! 🙂
If someone has any pointers to what direction we could go here, that would be great!

I could use this feature in a project that I'm working on right now. Is there anything I can help with to move this along?

I could use this feature in a project that I'm working on right now. Is there anything I can help with to move this along?

I've paused this a bit @rudolfs, since I'm not sure how this will align itself with the new API https://github.com/revery-ui/revery/issues/489
When working on the Hackernews-example I've resorted to doing something like this:
module InteractableText = {
  type state =
    | Idle
    | Hover
    | Active;

  type action =
    | Idle
    | Hover
    | Active;

  let component = React.component("InteractableText");

  let make =
      (
        ~children: list(React.syntheticElement),
        ~hoverStyles=[],
        ~activeStyles=[],
        ~style=[],
        ~text,
        (),
      ) =>
    component(hooks => {
      let (state, dispatch, hooks) =
        Hooks.reducer(
          ~initialState=Idle,
          (action, _state) =>
            switch (action) {
            | Idle => Idle
            | Hover => Hover
            | Active => Active
            },
          hooks,
        );

      let currentStyle =
        switch (state) {
        | Idle => style
        | Hover => Style.merge(~source=style, ~target=hoverStyles)
        | Active => Style.merge(~source=style, ~target=activeStyles)
        };

      (
        hooks,
        <Text
          onMouseOut={_ => dispatch(Idle)}
          onMouseOver={_ => dispatch(Hover)}
          onMouseDown={_ => dispatch(Active)}
          style=currentStyle
          text
        />,
      );
    });

  let createElement =
      (~children, ~hoverStyles=[], ~activeStyles=[], ~style=[], ~text, ()) =>
    make(~children, ~hoverStyles, ~activeStyles, ~style, ~text, ());
};

Gotcha. Thanks for the snippet @lessp!

Closing in favour of a hook-based approach e.g.: https://github.com/revery-ui/revery/pull/868
I think this is my first PR in Revery. They lure you in...

authors: Akin909 lessp rudolfs

repo: revery-ui/revery


text:
No LICENSE

Could you please add a LICENSE? It's not clear if this is licensed under the APL like the library, or something different.

@Arachnid thanks for spotting this! The APL license has been included.

Would you consider a more liberal option? As it's example code, it'd be great to be able to use this as a starting point for an app that uses your library, without having to license our own apps indefinitely under APL.

Sure! Let's make it MIT!

repo: revtel/react-native-nfc-rewriter


text:
Adding initial documentation to readme

resolves #1

Thanks for the review. I've amended the fix and will merge the PR.

repo: rewe-digital/composer


text:
inside an partial expression resulting error

If there is a #(hash) inside an partial expression (e.g {{>#partialName}} the binder crashes ("Reached end of template before block expression was closed").
This is not happening in js library, so templates written for client side binding, might not work in server!
thanks

Thanks, can you provide a failing test case?

Please find the attached test example, hope it helps you to understand the problem in a better manner :+1:

Am I correct that this "Partial Block" feature is currently not supported @rexm? See "Partial Blocks" on this page http://handlebarsjs.com/partials.html

@huysentruitw I am pretty sure that's correct - the partial block syntax probably wont work right now.

Partial block support included in the 1.8.0 release now live on NuGet

authors: darani73 huysentruitw rexm