Tracking: Stable 1.0

A list of things that need doing before 1.0 can be released as stable. This list will grow as we become aware of more things or remember outstanding issues.
API
General

[ ] Consider whether ParserSealed is necessary (perhaps doc(hidden) is sufficient for semver? Should we take a 'it's your fault if you don't read the docs' perspective?)
[ ] The sync feature is broken. When enabled, it adds extra Send/Sync constraints to trait object parsers like recursive, thereby making it non-additive.
[ ] Consider IterParser API overhaul from #425
[ ] Reconsider inclusion of the lexical crate (apparently it has soundness issues and is unmaintained?)

Combinators

[x] Merge map_*, try_map_*, foldl_* and foldr_* combinators into one (see #537).
[ ] Implement pratt parser combinator

[x] Prefix unary
[x] Postfix unary
[x] Infix binary
[ ] Dynamic building of parsers (i.e: accept a Vec<Operator> or something of the sort, see here)

[ ] Find a solution for leaky recursive (#494 seems like a good candidate)
[ ] Give the text parsers, such as text::ident a distinct type (instead of returning an impl Parser), allowing us to propagate trait bounds through properly

Inputs

[ ] Consider implementation of CopyStream (that copies the iterator instead of caching tokens)
[ ] Consider naming of Stream: is IterParser more sensible?

Errors

[ ] Unify 'expected' and label system (i.e: the former should be a special case of the latter)
[ ] Ensure that all parsers necessarily provide at least one label (see #504 and https://github.com/zesterer/chumsky/pull/538)
[ ] Remove RichReason::Many

Extension API

[x] Initial implementation

Documentation

[ ] Final pass to check correctness of documentation (some of it is from the 0.9 days)
[ ] Nail down consistent terminology

[ ] 'token' and not 'character'/'element'
[ ] 'input' and not 'stream'/'iterator' (except when those terms are correct)
[ ] 'fatal' and 'non-fatal' errors, not 'primary' or 'secondary'

Guide

[ ] Finish writing guide sections
[ ] Final spellchecking/grammar pass

Other work

[ ] Write migration guide (a good way to go about this might be porting a non-trivial parser and noting the major issues).
[ ] Collect up all changes into the changelog (it's going to be big!)

Sad to see lexical being unsound and stale. parse_partial(&[u8]) really makes a performance difference. Can https://github.com/aldanor/fast-float-rust be considered as an alternative?

I think the parse_partial function from fast-float would work nicely with chumsky, yes (the API is pretty much identical to the one exposed by regex-automata, which we use for the regex parser). As for integer parsing: I'm less certain, although there are less complexities around integer parsing so implementing our own fast integer parser might not be too difficult.

Do I understand correctly that the list of examples not yet ported to 1.0 are those in the examples/ sub-directory that do not have an [[example]] section?

Sad to see lexical being unsound and stale. parse_partial(&[u8]) really makes a performance difference. Can https://github.com/aldanor/fast-float-rust be considered as an alternative?

lexical appears to be fixed and the maintainer is back (:

That's good to know!

Dynamic linking of parsers can be checked :)


Date issue

I've got a set of data that I've converted from cqerl as my cassandra driver to xandra.
The main issue here is that previous data using cqerl wrote dates properly, but using xandra I get negative integers in my cassandra tables. Here's an example log:
uri                                      | date       | followers
------------------------------------------+------------+-----------
 youtube␟channel␟UC_DptbqTndVt_Im3KkuIK5Q | 2017-07-20 |   2747068
 youtube␟channel␟UC_DptbqTndVt_Im3KkuIK5Q | 2017-07-14 |   2729321
 youtube␟channel␟UC_DptbqTndVt_Im3KkuIK5Q | -646381046 |   2776261
 youtube␟channel␟UC_DptbqTndVt_Im3KkuIK5Q | -646381051 |   2776260

The last two rows are from today, the other two are with the cqerl driver.
The code that writes the dates looks like this:
  def insert(uri, count) do
    statement = "INSERT INTO #{@keyspace}.#{@table_name} (uri, followers, date) VALUES (?, ?, ?);"

    Xandra.execute(get_conn(), statement, [{"text", uri}, {"int", count}, {"date", DateTime.to_unix(DateTime.utc_now())}])
  end

Any ideas?

Hey @jeremytregunna, it is indeed far from nice experience. Cassandra has different starting point for dates than Unix epoch. I'm working on supporting Date structs.


Sftp refactor

Not all SFTP servers support SSH connections. Updated the SFTP Uploader to work only through paramiko's SFTPClient instead of the SSHClient for connection where the SSH client is not allowed. This operation connects purely via SFTP.

This looks good to me. I haven't used Paramiko before but if it has been tested and works it is fine.


add a way to explicitly add files to the corpus

hecras needs all of teh hdf files to live one directory but using create_hdf_corpus should be able to only pick out the ones the user cares about

a solution was added in the last commit. The setup basically optionally lets you add a vector of plan "numbers" for example Ardenwood.p50.hdf is represented by 50, and the vector c(10, 20, 30) represetents all Ardenwood.pXX.hdf for XX one of 10, 20, 30


12/10/2019 PM Publish

Docs Build status updates of commit 9a4b915:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Adapt/fix changelog now that a new release was made

Summary
Triggered by https://github.com/barryvdh/laravel-ide-helper/pull/1287#issuecomment-1008344636
This brings it inline with our recently release and fixes up the entries which accumulated.
After merge, adapt the release notes for https://github.com/barryvdh/laravel-ide-helper/releases/tag/v2.11.0 accordingly

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[x] Misc. change (internal, infrastructure, maintenance, etc.)

Checklist

[ ] Existing tests have been adapted and/or new tests have been added
[x] Add a CHANGELOG.md entry
[ ] Update the README.md
[ ] Code style has been fixed via composer fix-style

Thanks!

After merge, adapt the release notes for https://github.com/barryvdh/laravel-ide-helper/releases/tag/v2.11.0 accordingly

Adapted!


ReactJS Tutorial for js-xlsx

Is there any tutorial for ReactJS? Like how import/export excel file works in ReactJS components?

We have a demo at https://github.com/SheetJS/js-xlsx/tree/master/demos/react which shows a very simple state structure using an array of arrays.  It shows import and export in the standard browser deployment, react-native, next.js, and even using Preact!

I tried it but I am getting no valid entry for cols state when importing it and displaying to the render. I want to ask what is the correct format in excel to be able the array of column objects displayed properly in the table in render() ?

This is my example data of array of objects:

kio tryrty ###
fghfgh
gfhgfh

Have you fixed this?


more elegant implementation of sumOption in eventually monoid

This should be more efficient as it avoids materializing lists and batching.
It will also make batching in other places more predictable.

Sorry my bad, git foo on cmd line broke stuff and closed all of these

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[BUG] commentMessage is not supported in the community

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Created a new connection
Closed & used saved credentials to log back in
Etc.

Expected behavior
A clear and concise description of what you expected to happen.
Environment (please complete the following information):

Is this on a server?
What do your connectOptions look like?
Do you have multiple clients on the same IP?
Are you using a proxy?

Additional context
Add any other context about the problem here.

What is the bug? Which error? Why did you mark it as [BUG]?

Apa bug-nya? Kesalahan apa? Mengapa Anda menandainya sebagai [BUG]?

proto expected

Jjj

Huh??

Huh??

Bang sepuh lewat

Huh??

Gimana bang cara send commentMessage


After the read thread is started, the write operation is performed.  In this case, the write delay is very high, up to 70+ms

The serial port type is RS232

write thread :
for (;;) {         int ret = mSerial.readBytes(recvBuffer, sizeof(recvBuffer), 10, 1000);         if (ret < 0) {             LOGE("read data error. ret = {}", ret);             return -1;         }         if (ret == 0){             continue;         }         mDataHandler(recvBuffer, ret);     }
write function:
int SerialManager::send(const void *data, int len) {     if (!mSerial.isDeviceOpen()) {         return 0;     }     int ret = mSerial.writeBytes(data, len);     return ret; }

I don't understand your problem. Can you explain what is our issue?

I don't understand your problem. Can you explain what is our issue?

I don't understand your problem. Can you explain what is our issue?


Can't ./gradlew bundleRelease because of this plugin. The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead.

Configure project :react-native-receive-sharing-intent
The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead.

@ajith-ab

It would be fixed on new Version


[5.1.0-test.1] Connected components don't re render after state update

I gave a first try to the new beta and I can see some problems (unless I should make some changes).
The components that are connected to the store via connect don't get updated (they don't re render). While debugging I can see that the function mapStateToProps gets called correctly (and I can see the changes) after the action but the component doesn't re-render hence it doesn't show the new values.
I hope it could help

Thanks.  Can you put together an example reproducing the issue?

Closing, as the problem was probably due to an internal change of mine. Will re-open if I can understand the issue

My guess is that getDerivedStateFromProps usage pattern is incorrect. Lack of comparisons in it is concerning. The tests probably don’t catch it because they’re not using 16.4 yet.
It’s worth reading https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html and applying that information to latest changes.

(In referring to React Redux implementation, not your application code)

@gaearon is correct. The current implementation calls gDSFP when props change, and then the updater changes the state, which causes gDSFP to re-run, which finds that the state is the same, which sets shouldComponentUpdate to false, and nothing re-renders.
so we have:
props change -> getDerivedStateFromProps -> runUpdater -> setState(props, shouldComponentUpdate: true) -> getDerivedStateFromProps -> runUpdater -> setState(shouldComponentUpdate: false) -> shouldComponentUpdate -> returns false
because of this, react-redux can't store the derived props in state and shouldn't be using gDSFP at all. Instead, I think that Connect should be managing the 2 possible mutations independently. The store subscription can simply update the state to the new store state to force a re-render check, and we run updater in shouldComponentUpdate to retrieve the derived props from the new props and the store state. Once the derived props have been generated, we can store them to use in render().
As I'm relatively unfamiliar with the internals of react-redux, I have a fix in a fork, but I'm working on making existing tests pass before making a pull request.
I have one question regarding one of the tests. in connect.spec, in test should pass state consistently to mapState I see that we have a case where batched updates don't actually trigger a store change before subscriptions are updated. Specifically:
      // The store state stays consistent when setState calls are batched
      ReactDOM.unstable_batchedUpdates(() => {
        store.dispatch({ type: 'APPEND', body: 'c' })
      })
      expect(childMapStateInvokes).toBe(2)

Why is it expected that child mapStateToProps would be called? In this case, the props and the state remain unchanged. It seems to me that this test is wrong. Before I change this, I wonder if the experts could weigh in? Shouldn't we only run mapStateToProps to generate derived props when either (1) the connected component's props change or (2) the store's state is changed? Not on (3) when any action is dispatched? My assumption here is that mapStateToProps is always a pure function, but maybe I'm missing something?
Thanks in advance

Hi Team,
Can you please send unit test cases if you have already with you on Redux
using Jest + Enzyme.
Actions and reducer and components.
Please help me.
Regards,
Venky.
On Sunday, June 24, 2018, Emanuele<EMAIL_ADDRESS>wrote:

I gave a first try to the new beta and I can see some problems (unless I
should make some changes).
The components that are connected to the store via connect don't get
updated (they don't re render). While debugging I can see that the function
mapStateToProps gets called correctly (and I can see the changes) after
the action but the component doesn't re-render hence it doesn't show
the new values.
I hope it could help
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/reduxjs/react-redux/issues/965, or mute the thread
https://github.com/notifications/unsubscribe-auth/AY2h_qRdupXSmIpBA34SkAFTWe54Faiyks5t_o1GgaJpZM4U05LI
.

--
Regards,
Venkaiah Kagga

@cellog : thanks for the research and the PR!  I'm off on a vacation atm, but I've been meaning to take a day to try pushing some of the React-Redux work forward.  No guarantees on a timeline, but this is definitely now on my list to look at.
It looks like that test was added to fix #86 .  At that point, React-Redux still had problems with connected children.  The classic example is a connected list with connected list items, and if you deleted the data for a list item, the list item's mapState would run before the parent re-rendered and potentially explode because the data it needed was no longer in the store.  This was resolved in v5 by enforcing top-down subscription behavior.  It does look like the test has been tweaked some over time as a couple other assumptions have changed.  To be honest, though, I'm not entirely sure what the test is actually proving in relation to batching, especially since it's only dispatching once inside the unstable_batchedUpdates() call.  @gaearon , @epeli , can either of you comment on that?
Per your questions at the end, here's the expected sequence when an action is dispatched as of v5:

Root reducer runs
Subscriber functions all run, which includes a separate subscriber callback for each connected component instance.
Each connect callback checks to see if prevStoreState === currentStoreState.  If they're the same, it assumes that the action did not result in store state updates, and bails out.
Assuming the root state has changed, connect then calls your mapState function, and does a shallow equality check on the returned object to determine if a re-render is needed.

Sequence in this test:

Action is dispatched, state is updated
Parent mapState runs, parent re-renders
Child still exists, child mapState runs, return value is an empty object, no need to re-render

So sure, I'd expect the child's mapState to have executed once for that one action, but I'm not sure what that proves.

I'm travelling at the moment and unable checkit for a week or so as don't remember it on top of my head. I'll check on this when I'm home again.

FYI, I don't think instance properties are async-unsafe. In the memoization example:
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization
class Example extends Component {
  // State only needs to hold the current filter text value:
  state = { filterText: "" };

  // Re-run the filter whenever the list array or filter text changes:
  filter = memoize(
    (list, filterText) => list.filter(item => item.text.includes(filterText))
  );

  handleChange = event => {
    this.setState({ filterText: event.target.value });
  };

  render() {
    // Calculate the latest filtered list. If these arguments haven't changed
    // since the last render, `memoize-one` will reuse the last return value.
    const filteredList = this.filter(this.props.list, this.state.filterText);

    return (
      <Fragment>
        <input onChange={this.handleChange} value={this.state.filterText} />

{filteredList.map(item =>
{item.text}
)}

      </Fragment>
    );
  }
}

The recommended approach uses an instance variable filter
So that is not an issue.

FYI, I don't think instance properties are async-unsafe.

Instance properties can be tricky to get right.
Function bindings are okay. (In fact they're often necessary!) But be wary of any this references (other than this.setState) inside of your bound functions, because they might hold stale values (if the component has been rendered but not yet committed, or if an error occurred while rendering).
Other instance properties can be okay as well, although I would suggest avoiding them when possible. If you look at our create-subscription package, for example, you'll see that we use a couple of instance variables in it. The key here is to only update these values from a commit phase lifecycle (componentDidMount or componentDidUpdate) to ensure they are correct.
Does this clarify? I can elaborate if not.

@bvaughn : thanks, that helps.  I think I have two general points of concern:

instance variables not being updated properly due to the render phase re-running multiple times with alternate values
memoization logic not memoizing right for the same reason

@cellog : based on those comments, I'm not sure that the current PR code is valid.  Don't have any specific suggestions atm, though.

@bvaughn : lemme expand on that a bit and see if you have any suggestions.
connect has always implemented shouldComponentUpdate.  Unfortunately, it's not just a question of whether the incoming "own props" from a parent have changed - there's the results of mapState and mapDispatch, which could be dependent on ownProps, and the user could have customized how those results should be merged together as well.
In connect v4, we set and instance flag in cWRP to indicate that props had changed, and the Redux store subscription callback set a similar flag and basically called this.setState({storeState}).  From there, sCU was just:
      shouldComponentUpdate() {
        return !pure || this.haveOwnPropsChanged || this.hasStoreStateChanged
      }

In v5, we moved all the heavy lifting on the comparisons out into separate memoized selectors (homegrown, no use of Reselect).  The core logic can be seen here: https://github.com/reduxjs/react-redux/blob/3e53ff96ed10f71c21346f08823e503df724db35/src/connect/selectorFactory.js#L74-L84
We then re-run this giant selector in both the Redux store callback and, up until now, in cWRP.  Those both update the selector, and it spits out a boolean that gets used in shouldComponentUpdate, as well as the resulting new combined props for the wrapped component.
What I'm concerned about is that it looks like having the selector get run multiple times during the render phase would cause its memoization to be wrong.  It would be saving references to "unused" versions of ownProps, and that would cause incorrect determinations of whether to re-render.
In a sense, the selector really is a gigantic instance variable, as it's both an instance variable and stateful internally.
The only idea that's coming to mind at the moment is if we were to somehow split up the selector logic to separate out the "has something changed?" and "save the results" steps.

I think the short version of the question is:
How can we calculate props for our child component and prevent unnecessary renders of the child component? React-redux does it before sCU currently

Also of some interest (although quite a ways away and very much breaking): facebook/react#13216

instance variables not being updated properly due to the render phase re-running multiple times with alternate values

You shouldn't update instance values from render phase lifecycles. This is why my post above said to only update these values from a commit phase lifecycle (componentDidMount or componentDidUpdate) to ensure they are correct.
So long as you're following this rule, re-running render multiple times should not cause any improper updates.

What I'm concerned about is that it looks like having the selector get run multiple times during the render phase would cause its memoization to be wrong.

Not sure I follow here either. Why would calling a memoized function multiple times cause anything to be wrong? Presumably, the function would return the memoized value unless the input changed– in which case it would recalculate.
In an async app, you might want a cache size that's larger than one– so you low and high priority updates don't unnecessarily bust your cache– but I don't see where multiple calls implies incorrectness, provided you aren't updating instance properties during render phase (which you shouldn't be).

A bit of a new idea occurred to me on how to solve this. Basically, what we are looking for is a way to generate derived props and then run the complete life cycle based on those props, and only do it if they have changed.
And we just learned the safest place to do this is post-render or in render itself. So we need a way to run shouldComponentUpdate after render, and the most useful one would do what PureComponent does, but with the generated props.
So what if we made connect 2 components? The first would simply take incoming props and incoming store state, and call mSP to generate derived props. It would do this every time, and then pass the result to its child, a "middle man" PureComponent-based component. The component would only update on props changing, and so we could simply put updateChildSubs() in the componentDidUpdate() of the child. That component would have as its child the WrappedComponent.
This way, no funny business is needed with instance variables, and we are fully async safe.
If this indeed seems viable as a solution to @bvaughn (from cursory read) I can whip up a sample and see if I can get all the existing tests to pass with it.

Yes, the current source misuses gDSFP, that is clear. The issue I see is that the subscription example you linked to ONLY uses the data from the external source. the rest of the props are not used in deriving state. React-redux uses both props and the external data from the redux store to derive props.
I'll see if I can turn these abstract words into code on another branch, it should make it easier to understand what I'm trying to say. Appreciate the patience and feedback. Basically, right now, we do:
<ConnectAdvanced props={...} store=store>
 <WrappedComponent props={derivedProps} />
</ConnectAdvanced>

And we try to handle the sCU and deriving and subscriptions in the single component, which causes issues since we can't get derived props in time for sCU unless we calculate in sCU, which is not OK, as it turns out.
I'm suggesting that instead:
<GenerateDerivedProps props={...} store=store>
 <DecideWhetherToRender props={derivedProps}>
  <WrappedComponent props={derivedProps} />
 </DecideWhetherToRender>
</GenerateDerivedProps>

This way, we can use gDSFP and handle subscriptions in cDM and cDU in the GenerateDerivedProps component, which will always re-generate and pass to the DecideWhetherToRender component. This component can memoize the derivedProps, and use that in sCU to decide whether to update. Also, the cDU can contain notification of child subscriptions unconditionally, or we can do that directly in sCU if we would return false (react-redux 5.0 behavior that is missing in 5.1 test)
And, to continue, if pure option is false, then we simply don't use sCU in DecideWhetherToRender
In short, this removes the race conditions of generating derived props and using those props to decide whether to render. The race condition is that we need to store BOTH the generated props, and the store state that we used to generate them in state to work properly. That's why gDSFP and a single connecting component is unlikely to work for react-redux (as I see it).
Make more sense?

@cellog : unfortunately, I don't think that's a viable option for now. Having only one wrapper component for connect could be considered part of our API contract so far, and there's plenty of code in the wild (even if only in tests) that expects just one wrapper.
Someone else did suggest the 2-step approach in the comments of #898 (see some of the CodeSandbox links).
I may take some time tomorrow to look at this more as well.

@bvaughn : right, I was agreeing with you on the instance variables thing, and saying that our current approach violates that.
Per memoization, the problem I'm seeing is that in an async scenario, rerunning the render phase with varying values would cause the memoization to not cache hit as desired, and also effectively update an "instance variable" in the render phase.

What I'm getting from the React maintainer's comments and from the excited end-users commenting on that PR is that perhaps react-redux will work best if both subscription and dispatch is handled via React, and will resolve tearing and other async issues since React has to do that.
I'm going to abandon this PR, and temporarily use my fork or something similar in the case where I need it (docs website for ion-router) until things settle a bit.
I don't think it is wise to do a half version of the switch, the complexity is too large. I will say this is all very exciting, because React is finally going to be capable of managing state internally, which was always why redux was external: it couldn't do it properly before.

@cellog : well, we still need to come up with a resolution for our current issue.  This started with #897 and #919 , and our current goal is to patch up the existing implementation to resolve any deprecation warnings related to lifecycle methods.  Per my writeup in #950 , after that I'd like to rework the internals to use the new context API, and that would be a major version bump.
The chatter in that other issue can be ignored for now, especially around rearchitecting things to be React-centric.  We need to figure out a solution that works with our current architecture.

Well, this PR does solve the depreciation issue. So perhaps that's the answer. We know that solving async will require major surgery, so future-proofing becomes unnecessary

Per memoization, the problem I'm seeing is that in an async scenario, rerunning the render phase with varying values would cause the memoization to not cache hit as desired

Right. This is why I mentioned that you might want a cache size of > 1 so that your cache doesn't get busted in async high/low priority situations. (Don't go with an unbounded cache though, or you'll leak memory.)

and also effectively update an "instance variable" in the render phase.

Still not sure I understand this conclusion though. 😄 You'd be calculating a different value during render, which is fine, but you would not actually be updating an instance variable. (Unless your "handleNew*" methods write to the instance, which would be a problem.)

So per the last couple comments: I guess there's a question of just how async-safe we need to make 5.x.  We seem to have fixed the <StrictMode> warnings, but we're also doing stuff that <StrictMode> presumably isn't catching.  Can we get away with 5.x not being totally "safe", if we're going to try to have a 6.0 release that hopefully is different enough to fix all the concerns?
I think moving to new context in a 6.0 release is a step in the right direction, but we're probably going to run into the same issues regarding when we try to calculate props and shouldComponentUpdate flags.

The memoized selector is the instance variable, and it isn't changed. The value it returns may change, based on the input, but that's okay. 😄 It's no different than if you were computing the values inline each time, just more efficient.
The important thing is that work that's done during render doesn't somehow stick around and cause problems if that render is bailed out on before committing. In this case, it wouldn't, since the memoized selector would only return the bailed-out-on-computations if it were passed the bailed-out-on-parameters (which it shouldn't be).

So the problem is that input may change between sCU and render? When we are taking about "input" is that props/state, or are you talking external things like store state?

I've got a couple pieces floating around in my head that I think may let us solve this.
Ever since Brian posted his create-subscription package, I've felt that it looks very relevant to what we're doing over here with React-Redux.  (In fact, I specifically tried to ask Brian about this in https://github.com/reduxjs/react-redux/issues/890#issuecomment-370666906 .)  Ironically, the README says "Redux/Flux stores should use the context API instead.".  Sure, agreed, but we haven't gotten that far yet :)
create-subscription lays out a pattern of best practices for working with a non-React subscription.  We really ought to use that as our model, and make connect conform to the approach shown there.
Meanwhile, we've established that updating instance variables in the render phase is a no-no.  We also know that gDSFP will run both when the parent re-renders and when setState() has actually executed a state update.  However, note that it does not run if you use the functional form of setState() and return null.
Also important: if you pass a completion callback to setState(), it does execute regardless of whether there was an actual state update applied or not, while componentDidUpdate() only runs if there was a state update and ensuing re-render.
I threw together a quick example over at https://codesandbox.io/s/yjx19v21nz that logs out some of the differences in execution between functional setState that applies an update, vs returning null for no update.
Looking in create-subscription, I see that the subscription callback it generates immediately calls setState() with an updater function, and does the "has anything changed?" check inside:

        const callback = (value: Value | void) => {
          if (this._hasUnmounted) {
            return;
          }

          this.setState(state => {
            // If the value is the same, skip the unnecessary state update.
            if (value === state.value) {
              return null;
            }

            // If this event belongs to an old or uncommitted data source, ignore it.
            if (source !== state.source) {
              return null;
            }

            return {value};
          });
        };

The 5.1.0-test.1 release does use functional setState inside the Redux subscription callback, but note that it always returns a new state value:
      onStateChange() {
        this.runUpdater(this.notifyNestedSubs)
      }

      runUpdater(callback = noop) {
        if (this.isUnmounted) {
          return
        }

        this.setState(prevState => prevState.updater(this.props, prevState), callback)
      }

  function getDerivedStateFromProps(nextProps, prevState) {
    return prevState.updater(nextProps, prevState)
  }

function makeUpdater(sourceSelector, store) {
  return function updater(props, prevState) {
    try {
      const nextProps = sourceSelector(store.getState(), props)
      if (nextProps !== prevState.props || prevState.error) {
        return {
          shouldComponentUpdate: true,
          props: nextProps,
          error: null,
        }
      }
      return {
        shouldComponentUpdate: false,
      }
    } catch (error) {
      return {
        shouldComponentUpdate: true,
        error,
      }
    }
  }
}

Also, note that the "updater" function closes over the store, and grabs the latest Redux state every time it runs.  It also is reused as the entire implementation of gDSFP.
I haven't fully nailed this down in my head yet, but my gut says we can come up with an approach that works based on all this info.
Here's a 100% completely untested code sample that demonstrates what I'm thinking might work:
class ConnectAdvanced extends Component {
    constructor(props) {
        super(props);

        const store = props[storeKey] || context[storeKey];
        const reduxStoreState = store.getState();
        const childPropsSelector = createChildPropsSelector(),

        this.state = {
            ownProps : props,
            childProps : childPropsSelector(reduxStoreState, ownProps)
            childPropsSelector
            store,
            reduxStoreState,
        };
    }

    shouldComponentUpdate(nextProps, nextState) {
        // standard shallow equality check on props and state
    }

    static getDerivedStateFromProps(currProps, currState) {
        const {ownProps, childProps, reduxStoreState, childPropsSelector} = currState;

        if(shallowEqual(currProps, ownProps)) {
            return null;
        }

        const newChildProps = childPropsSelector(reduxStoreState, currProps);

        if(newChildProps === childProps) {
            return null;
        }

        return {
            ownProps : currProps,
            childProps : newChildProps,
        };
    }

    onStateChange = (notifyNestedSubs) => {
        const newReduxStoreState = this.state.store.getState();

        this.setState(currState => {
             const {ownProps, childProps, reduxStoreState, childPropsSelector} = currState;

             if(reduxStoreState === newReduxStoreState) {
                 return null;
             }

             const newChildProps = childPropsSelector(newReduxStoreState, ownProps);

             if(newChildProps === childProps) {
                 return null;
             }

             return {
                 reduxStoreState : newReduxStoreState,
                 childProps : newChildProps,
             };

        }, notifyNestedSubs);
    }
}

So, the key here is that we keep all the relevant info in component state, access it in both gDSFP and a setState() updater, and do checks to completely bail out of updates in both cases if necessary.
My main concern here is still the idea of the memoized selector getting called multiple times in a row in an async scenario, and thus the cache wouldn't work properly.  I think we can resolve this by making the selector not actually cache values internally.  If you look at the snippet I pasted earlier, it stores references to:

state (the Redux store state)
ownProps
stateProps (mapState result)
dispatchProps (mapDispatch result)
mergedProps (mergeProps result)

Well, the sample I just wrote up would keep ownProps, reduxStoreState, and childProps (same as mergedProps) in the connect component state.  Why not just keep stateProps and dispatchProps there too?  We can rewrite the selector to return all of the above as in a wrapper result object, put all of that into component state, and pass all of them in as arguments to the selector instead of having it memoize on them internally.  Then, we don't need to have the selector tell us if the component needs to update or not - we just run standard shallow equality checks in shouldComponentUpdate (and maybe just on state, not on props).
I'm babbling a bit here, but I think this can all work.
Thoughts?

Follow-up thought.  This relies on having the store in the component and and still subscribing there.  I don't think this would work with the POC approach I had in #898 where I switched to having <Provider> subscribe and pass down the store state via context, because the store state would only be accessible inside the <ReactReduxContext.Consumer>.  That might necessitate the double-wrapper component approach after all for v6.  (Frankly, one of the reasons I dislike the double-wrapper idea is simply because it's that many more "irrelevant" tree nodes in the React DevTools, and I'd be hesitant to go that route until there's a good way to mark components as "automatically hide this in the DevTools" or something similar.)

That's a much more nuanced usage of sets tate, it might make a difference. The only thing I immediately see is that the notification of nested subs should happen if child props doesn't update, i.e. Inside the block that returns null. In addition, if the state changes, but our child props don't change, we still need to store the changed redux state, in case a props change would cause an update to child props (we will be storing a stale copy of store state).
The first issue is fixable via doing the "componentDidUpdate should update nested subs" as the callback to setState, but then if we fix the 2nd issue, it will trigger a false update. Perhaps doing a narrower sCU that ignores the saved redux store state would solve that issue.
The pseudocode is worth un-pseudoing and seeing how it plays out.

Also relevant to 2 components is we need to use forwardRef, but that's a next step issue. Progress is yummy!
P. S. I have been toying with writing a "redux in react" just to see how hard/easy it would be to do it and transparently support the existing store enhancers. It's an interesting thought experiment, since the state being in component state means initialization of state happens in the constructor, but anything fancy would have to be in ckmponentDidMount. If I find anything relevant to the v7 talks, I'll share.
Basically, if it ends up looking simpler, it might be a better way to implement react-redux. Right now, it's looking like the connect component will only need 1 element, the wrapped component itself, because we can do all the "should we update" stuff inside the render props context consumer. Stay tuned!

@cellog : per my sandbox, the setState callback runs even if there was no state update applied (ie, the updater function returned null).  Also, I see that the callback runs after cDU. So, that looks like it should work either way, and we don't need to do the "temp-assign cDUNotifyNestedSubs" bit any more.
I'm still really not sold on any of these "Redux in React" ideas, but I'd be interested in seeing what you put together nonetheless.

I've been trying to poke at this, but I'm realizing it's a bit more complicated than I first thought.
The biggest issue is the separation between the lower-level connectAdvanced() function, where all the component behavior is implemented, and the higher-level connect() function, which has our standard default memoized selector implementation.  Overall, connectAdvanced() expects to get a selectorFactory argument, which returns a function that looks like (reduxStoreState, ownProps) => mergedChildProps.
My comments above conflated the two parts of the implementation.  I was thinking of changing connect's selector factory to return an object containing {stateProps, dispatchProps, mergedProps}, rather than directly returning mergedProps, but that would break if anyone actually calls connectAdvanced() with their own selector factory.
A quick search on Github suggests that there are a few people out there doing that, so I don't want to break that use case (especially in what's supposed to be a minor version).
I supposed it could be handled by kind of special-casing knowledge of connect's default behavior inside of connectAdvanced.  I find that conceptually annoying, but it might be necessary.
const selectorResult = selector(nextState, nextProps, otherArgs);

let childProps;
if(selectorResult.mergedProps) {
    childProps = selectorResult.mergedProps; // default connect case
}
else {
    childProps = selectorResult; // custom selector factory was provided
}

I started poking too, and although it's only been a couple minutes, most of the tests are passing. However, subscriptions are not working yet, so that's the next step.
I got my redux-in-react working, except the dev tools browser extension won't work with it because the author hard-coded in using redux's createStore instead of using the one passed to it :). So I haven't quite gotten over that stumbling block.
In any case, I'm going to try to finish poking at the subscriptions issue and get a working PR today. If you beat me to it, all is good :) I'm learning tons about both react-redux and react, which is what I wanted in the first place.

Yeah, I've got several tests failing on my end as well. Looks like it's mostly around children expecting to see updated props from parents before mapState runs.
I'll try to find a couple minutes to throw my WIP up on a branch later, and we can compare notes.

Ok, so I got it working but it's the same problem I found in the pull request I made. We can't get both props and Redux state update at the same time unless we do some dangerous caching magic.
For example, in the "should subscribe properly when a middle connected component does not subscribe" test in connect.spec if I change out the expect inside @connect for the C component to instead log the calls to mapState, I see 3 calls. The first is the initial, the second is the state update from child notification, and the third is when parent props are propagated down. Also worth noting is that setState callbacks don't trigger until the entire tree has been reconciled, so we may see a big performance hit as the whole tree renders with props changes, then the children get the new redux state, then the tree reconciles, then the next children get their redux state...
The solution could be to create a second kind of subscription, which would simply tell child components that redux is about to update, and to delay processing props until the redux update comes in. But this is inherently dangerous in an async environment.
So perhaps being 16.4-ready means the only way to do this is with the new context?
Also worth considering and perhaps more to the point: getDerivedPropsFromState behaves completely differently in 16.3 and earlier. I think that the current 5.1-test.1 should be released as a version for 16.3 and earlier, and then release a new version for 16.4+ based on the new behavior. So the 16.3 version would use the polyfill, but the 16.4+ version wouldn't.

I can't figure it out. We need a way to store the last state and pass that to getDerivedStateFromProps which is actually impossible with just 1 component.
The best solution I see is to split up into 2 components, one that manages redux state by retrieving from a Context Consumer, and passes that into the component in order to process props and redux store simultaneously. Honestly, I'm not sure there is another solution!

getDerivedPropsFromState was buggy, so we can't release code relying on that bug. React team really talked a lot about it. If no solution is possible, at this point a breaking change should be considered

Yeah, I'm see mostly the same test failures myself.  Just pushed up my WIP as https://github.com/reduxjs/react-redux/tree/5.1-rework-memoization .
As @ematipico said, 16.3 is effectively buggy, and 16.4 is out, so I see no reason to try to target 16.3.
I'm not ready to give up on this approach yet, but I agree this is awfully tricky.
If necessary, yeah, we may just have to say that there is no stopgap 5.x release, and move on to seeing what a 6.0 would look like.

One new possibility that occurred to me this morning: if we put the store in state instead of its value, it may be possible to delay updating until we know whether the parent component is updating state. It would require changing subscription updates so that if it is notifying a nested subscription, we tell it "heads up, a parent component just updated" and then it can watch and wait. If no props change comes down, it would trigger a redux update, otherwise edit could pull in redux state just in time for props. I may have time to turn this into code. It will likely break bathed redux actions, but hard to know until I write the code.

Hi all,
I am facing similar issue. I have a connected component that in some circumstances can trigger 2 updates to the store. The latter update might not actually change anything. As a result, the change in first update was not re-rendered.
props change #1 -> runUpdater -> setState(props, shouldComponentUpdate: true) ->
props change #2 -> runUpdater -> setState(props, shouldComponentUpdate: false) ->
React dropped updates from re-rendering queue
May that be a React issue instead?
Thanks

@nguyenanduong : which version of React-Redux are you using?
Also, we've already established that 5.1.0-test.1 is completely broken, and we're not going to be publishing a 5.1 release anyway, so I'm going to close this issue.

Yes, I am on 5.1.0-test.1
When is the 5.1 release is out? Which branch can I get it?
Thanks

Please DO NOT use this version.  It is entirely broken.  Revert to version 5.0.7.
As I said, we will not be releasing a 5.1 version.  We are instead working on version 6.0, which is a major internal rewrite.  See #950, #995, and #1000 for details.

Thanks, downgrading to 5.0.7 seems to work for me

@markerikson Could a note of the fact that 5.1.0-test.1 is broken be added to the releases description.
Currently, it looks like it's encouraging usage.

I eagerly upgraded, only to find that it did, in fact, break everything 😄

Hmm.  Good point.  Let's see..
Oh hey, you CAN edit release notes after the fact.  Okay, will do.  Thanks for the notice!


[AutoRelease] t2-selfhelp-2023-04-28-69883(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/4032
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=6080

issue link:https://github.com/Azure/sdk-release-request/issues/4032

/check-enforcer override


Is it possible to add YAML.FILE as a Value token?

Hi,
The stepFile feature allows the user to reference a step written in json format.
 stepFile: "${JSON.FILE:reusable_content/get_authorisation.json}"

In our usage we are writing scenarion in yaml format - but it appears that the stepFile only supports json. Is there any plan to support a YAML file value token similar to JSON.FILE?
Support for ZIP would also be something that be useful for test cases we are currently attempting to implement.

@bfarrell-ibm  what's the usecase for zip file? In stepFile we are specifying json/yaml step.

Just to clarify - the ZIP file support was not in relation to stepfiles.
A colleague has a scenario where and API call expects a zip as the payload. I don't have the exact details. He is investigating using the HttpClient could be a suitable solution.

Thanks for the PR 👍
PR merged. Pending a new version release and a Wiki page with an example.


Jio tv stopped working

Your Environment

Add-on name: [e.g. Jiotv]
Add-on version: [e.g. 2.0.0]
Kodi version: [e.g. Kodi 19]
Operating system version/name: [e.g. Windows 10, LibreElec 9.0, etc...]
Using from country: [eg. India, USA, etc...]

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See an error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Debug log

The debug log can be found from this link:

kodi.log
here is the log file

Let's hope @iMro0t fixes the issue in his spare time. In the meanwhile, you can use Samsung TV Plus addon from slyguy repository and AjayKRepo (for zee5 (has live channels), sonyliv (has live channels), voot (has live channels), hotstar and mxplayer)


An API endpoint to get information regarding the age of a user's password

Is your feature request related to a problem? Please describe.
Related to #9572
To improve the UX of the My Account app, it is important that we let the user know how secure their account is on the overview page. Since it is a good practice to change the user password frequently, it will be better if we can remind the user to change their password after a certain amount of time.
To that end, we need to know how long it has been since the password was updated.
Describe the solution you would prefer
There should be an API endpoint to give details such as when the password was last updated.

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


Support Laravel 10.x

This pull request includes changes from your build using the "Shift Workbench".
Before merging, you need to:

Checkout the shift-build-4471 branch
Review all comments for additional changes
Thoroughly test your application (no tests?, no CI?)

Don't hesitate to send your feedback to<EMAIL_ADDRESS>or share your :heart: for Shift on Twitter.

:warning: The latest version of Laravel has a dependency for phpunit/phpunit of ^9.5.10. If you would like to also upgrade your tests, you may run the PHPUnit 9 Shift for free.


Fix onion packet lock time & forward amounts and verify HTLCs

Requires https://github.com/bpfkorea/agora/pull/1682 which still seems to be timing out because of some reasons.
Please ignore the first commit.
Fixes #1683

Error relocating /usr/local/bin/agora: _D6object6Object6toHashMFNbNeZm: symbol not found

What the..

I'm rebasing the flash-layer branch against v0.x.x. I'll push that soon.


perf: :children_crossing: Use local MeiliSearch and ripgrep

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender


Revamp Gihub CI.

Signed-off-by: Zbigniew Zagorski<EMAIL_ADDRESS>Thank you for contributing to harp.gl!
Before requesting a pull request, please remember to check the following documents:

contribution guidelines
coding style

If you are adding new functionality we would highly appreciate if you can describe what is the capability you are adding and even better if you can add some examples. Please also remember to add tests for it.
CI Check
Our bots will check whether your PR can be directly integrated into the mainline. We have some internal integration tests running on the background, our bots will inform you of the next steps and someone from our team will take a look and help if needed!
And please do not forget to sign-off your commit! You can read more about DCO here. But, in short, you just need to use git commit -s or append --signoff when you are committing to the repo.
Happy contributing!

Codecov Report

Merging #1519 into master will decrease coverage by 0.16%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1519      +/-   ##
==========================================
- Coverage   60.18%   60.01%   -0.17%
==========================================
  Files         262      262
  Lines       23855    23859       +4
  Branches     5368     5370       +2
==========================================
- Hits        14358    14320      -38
- Misses       9497     9539      +42

Impacted Files
Coverage Δ

@here/harp-mapview/lib/CameraMovementDetector.ts
61.97% <0.00%> (-28.17%)
:arrow_down:

@here/harp-mapview/lib/MapView.ts
63.80% <0.00%> (-1.41%)
:arrow_down:

...here/harp-mapview/lib/text/TextElementsRenderer.ts
69.24% <0.00%> (-0.50%)
:arrow_down:

@here/harp-mapview/lib/VisibleTileSet.ts
76.32% <0.00%> (-0.26%)
:arrow_down:

@here/harp-omv-datasource/lib/OmvData.ts
11.11% <0.00%> (-0.10%)
:arrow_down:

...re/harp-mapview/lib/geometry/TileGeometryLoader.ts
59.55% <0.00%> (+0.69%)
:arrow_up:

@here/harp-mapview-decoder/lib/TileLoader.ts
78.01% <0.00%> (+2.66%)
: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 6822f8f...d76c024. Read the comment docs.


Custom endpoints ignore limit: 0 inside payload.find

Link to reproduction
https://github.com/Arctomachine/payload-bug-custom-endpoints
To Reproduce

Start dev server
Log in, go to collection items and create at least 11 items (should be 2+ pages in collection list view by default)
Make request to /api/items/get-all

Describe the Bug
Should get 1 page with all items. Instead only gets first page with 10 items
Payload Version
2.0.5
Adapters and Plugins
Webpack, mongo

Hey @Arctomachine — thanks for bringing this up. You just need to pass pagination: false, which was an undocumented Local API find method property. I've just documented it. Give that a shot and then it will work as you expect!
Thanks!

This also affects the RestAPI.
The limit=0 was working before v2. The LokalAPI fix does not resolve the issue in our case.

This also affects the RestAPI.
The limit=0 was working before v2. The LokalAPI fix does not resolve the issue in our case.
Should I open another issue for or do you want to reopen this issue, @jmikrut ?

Hey @Haliax are you sure this was working in 2.0? I believe we had this intentionally disabled because it could potentially open up the door for malicious API abuse if you have lots of records.
I do believe in any case that this should not be possible by default through REST or GraphQL.
We could add a way to enable this functionality via those APIs.
If you are interested in that, maybe open a Feature Request discussion and we could go from there?
Does that make sense?

I wanted to say that it worked before changing to v2. Sorry for the confusion.
I see your point! But on the other hand, you are still allowing requests like limit=99999.
For our use-case, it is good to have this workaround. Better would be to allow requests like that for authorized API users.
I will create a feature request for that.

Yeah, this suddenly became an undocumented breaking change for us. We relied on a graphql resolver to return the full list of documents when requested with limit: 0 and after the upgrade to v2, our list contained a fixed 10 items instead of 120. We'll fall back to Haliax' workaround with a high limit for now.


Crashes during selection

Hi, I am able to sort of reliably crash smith when faffing around with text selection then clicking at different places. However, I just realised that I am using a slightly outdated version of smith, so I will quickly verify if it still happens with the latest version and get back to you if it does.

Nah, it works perfectly, sorry for creating a fuss! Good job on smith it looks to be a very nice and simple editor so far!


Empty samples is bug？ Help Me

scare noting samples and pushed to pushgateway when a system starting，this is bug？  I'm not sure  @csmarchbanks

This is by design. The metric still exists but is empty which I believe is the correct behavior. Did anything break?


Stackoverflow Errors on recursive types

Across the Config to Blueprint compiler the current implementation leverages recursion, which breaks  whenever there are recursive types. There is no one strategy we can use everywhere to fix this.
Example
schema {
  query: Query
}

type Query {
  list: List
}

type List {
  head: Int!
  tail: List
}

tailcall start ./app.graphql

Additional Information

JsonSchema might need a bit of re-write. It doesn't support recursive types at the moment.

/bounty 350$

/attempt #758

I know it's assigned, declaring myself willing to collaborate/on the queue on this one 🤚🏽

hey @A-N-uraag  your PR is closed is there anything left ?

Opening this up for everyone to attempt.

@Rutik7066 this is your chance

@Rutik7066 already has an issue assigned to him.

assigning back to @A-N-uraag since they have work in progress on it

@tusharmath could you assign to me?

@tusharmath is this still an issue?

/attempt 758

/tip 100 @ssddOnTop


Cannot log into grafana dashboard

I cannot log into the grafana dashboard, either when running in IoT Edge or a local docker instance.
I have tried changing permissions on the grafana.db file but cannot do this (always get 'operation not permitted')
INFO[04-14|12:20:59] Request Completed                        logger=context userId=0 orgId=0 uname= method=POST path=/login status=401 remote_addr=<IP_ADDRESS> time_ms=10 size=42 referer=http://localhost:3000/login
EROR[04-14|12:21:01] Error while signing in user              logger=context userId=0 orgId=0 uname= error="failed to create auth token: attempt to write a readonly database" remote_addr=<IP_ADDRESS>
EROR[04-14|12:21:01] Request Completed                        logger=context userId=0 orgId=0 uname= method=POST path=/login status=500 remote_addr=<IP_ADDRESS> time_ms=12 size=41 referer=http://localhost:3000/login

@creationsoft please follow the tutorial Metrics Dashboard see Update the environment variables to control access to the Grafana dashboard.

Closing the issue; please reopen if there still open


Sweetalert2 not working properly on IE11 on Windows 10 Pro v1709

Fall Creators Update IE dev tools causes browser to crash when sweetalert is loaded.  I was trying to see why sweetalert was not working correctly and cannot because dev tools keeps crashing.

SweetAlert2 version?
How are you including SweetAlert2?

Ok some background we developed a system for a client and they are using Windows 7 with IE11 so we had to make a few changes for it to work for them.  I upgraded to v6.11.4 this morning and we added in a polyfill to enable it to work:

So if you go to the site on IE11 on Windows 7 or Win 10 prior to 1709 it randomly doesnt work with the sweetalerts where they are chained (it decides sometimes to work and others not).  On 1709 it does the same behaviour, but if you open the dev tools then IE11 crashes.  If I comment out sweetalert, all works fine.

For bug reports, please include a jsfiddle in order for us to be able to reproduce the issue.

JSFiddle template: https://jsfiddle.net/limon/ad3quksn/

See Contributing.md

Add jsfiddle in order to get help.


Update video window "automatically"

We should at least catch to window resize, document scroll and video element attribute changes to trigger a renderer update

After internal discussion eating a pizza we've decided not to implement this. iPhone/iPad applications are supposed to be mostly "static". In cases where the video element position/size is changed the provided function cordova.plugins.iosrtc.refreshVideos() does the work.
May be we reopen this feature in the future, but for now it has zero priority.


Rework database and collection creation for Tigris

Currently, we try to create databases and collections in too many places. We should clean that up.
Expand tigrisdb. Port CreateTableIfNotExist and insert from pg handler. Use them where needed.
Remove our own "filter" from tigrisdb.

same for database (see https://github.com/FerretDB/FerretDB/pull/887)

@AlekSi case: a few documents are inserted ("insert many") into a collection that didn't exist. The schema for the collection is created based on the first document. The second document doesn't match the schema. What should be returned in such a case? - In fact, we created a collection and inserted one doc, but then the second doc insertion failed.


fix(ccmlib/repository.py): Fixing SyntaxWarning warning log

The following code incorrect:
while attempt < 3 and ret_val != 0:
...

From Python version 3.8+, the following warning message is shown:
ccmlib/repository.py:311: SyntaxWarning: "is not" with a literal. Did you mean "!="?

More details you can find in the following link:
Why does Python log a SyntaxWarning for ‘is’ with literals?


Support IP2Location.io API

You are currently supporting 15 IP geolocation API.
I would like to introduce you the IP2Location.io API which is free (500 queries per day tokenless, or 30,000 queries per month using token upon registration).
https://www.ip2location.io
Kindly ping me if you need further assistance about the API.

Hi, thank you for bringing this to my attention.
I'll take a look and add this!


Bug: CodeIgniter Migrates And Saves an Empty Migration File Info In The Database

PHP Version
8.3
CodeIgniter4 Version
4.4.5
CodeIgniter4 Installation Method
Manual (zip or tar.gz)
Which operating systems have you tested for this bug?
Windows
Which server did you use?
apache
Database
MariaDB 10.2
What happened?
I decided to skip writing all other files I generated for migration except one. After executing the spark command to migrate the files were migrated including the empty files which I hadn't written code for and its information saved in the migration table on the database.
Steps to Reproduce
It should not save details of an empty migration file in the migration table on the database.
Expected Output
The empty files information should not be saved in the migration table on the database.
Anything else?
No response

If a migration file is present, it will be executed - that's how it was designed. We don't keep track of whether any changes were made to the database in the migration.
The whole point of using migrations is to make sure they’re executed in order.
If you want to skip some migrations for now, you can add it to another DB group (or namespace) and migrate only the default one.

Rename migration file to exclude from the search

@neznaika0 this works but when it comes to having same name used on both the file and table its not the best way of solving this problem.


Apply standard file naming

PascalCase: Files that exports something instantiable: Layer.js, Viz.js

camelCase: Files that exports something that can be used directly: util.js, geometry.js

Update developers.md with those rules

Is this consistent with the rest of the frontend stuff?
cc @ivanmalagon

No. In other projects (Builder and CARTO.js) we use kebab case: layer.js, viz.js, geometry-helpers.js, histogram-dataview-model.js.
We don't have any clue in the file naming about the chance of instantiability of the content. Is that a new trend because of ES modules?

What is the status of this ticket?

Good question @Jesus89. We discussed that the best way to approach this change is to do it little by little in our daily changes. So each time we change a file that does not follow the convention, we should change it, ideally in a separated commit. It is hard to keep track of this issue.

With that plan, I'm closing this issue. 💪


Add artifacts of image diffs on web-ui test fail

This PR allows to download the diff images from the CI machine in case of diff errors (so no SSHing into the remote CI machine is needed)

@arikmaor
I added the lowest possible retention period, is this enough?
What does cost evaluation mean?

I added the lowest possible retention period, is this enough?

👍


questions about reproduce on real ur5 robot

Hello:
@cheng-chi Thank you very much for your work. Currently, I want to reproduce the diffusion policy on the real ur5 robot, but I still have the following questions. Can you give me some advice?
1. I observed that you recorded more than a hundred demonstrations for the pushT task, and then I directly tried to use these demonstrations for training with your code. However, each epoch of training takes about 10 minutes on my computer. If it takes a long time to complete a task according to the 600 epochs in the configuration file, is this normal? What is the minimum epoch required to train a task? Because I noticed that it seems that you can train a policy in only 12 hours. My GPU is RTX3060 12G.
2. In addition, I noticed that you do not have demonstration examples for the cup-righting and spilling tasks. If I want to train a brand new task, do I only need to use the script you provided on github to perform the same operation? Are the action spaces the same for these different tasks?
Thank you and looking forward to your reply!🥺

Hi @yolo01826

The training speed does sound a little slow for me, but it's likely due to the difference of RTX3060 vs 3090s that we used. You usually only need ~200 epoch to get peak performance. The experiments in the paper are significnatly overtrained on purpuse to show that diffusion policy is not prone to overfitting even if you train for longer.
Unfortunately the data for cup and sauce spreading tasks are collected at TRI with their proprietry software infrastucture and therefore can't be open sourced. The action space is 6 DoF absolute end-effector-pose similar to what's used in robomimic experiments.


failed to parse type signature

Since upgrading recently, I've been seeing errors to parse this trivial file:
package org.ensime.indexer

import org.apache.lucene.document._

package object lucene {
  implicit class RichEntity[T <: Entity](e: T) {
    def toDocument(implicit p: DocumentProvider[T]) = p.toDocument(e)
  }

  implicit class RichDocument(d: Document) {
    def toEntity[T](implicit p: DocumentRecovery[T]) = p.toEntity(d)
  }
}

with the error
[warn] Scalariform parser error for /path/to/file.scala: Expected token RBRACKET but got Token(XML_START_OPEN,<,865,<)

the offset matches 865 is [T <: Entity] on the file on disk (I've removed a bunch of irrelevant scaladocs here).

This should have been fixed with https://github.com/daniel-trinh/scalariform/pull/73 (0.1.7), which version are you currently using?

0.1.7

actually, that might not be true. In my project definition I am using sbt-scalariform 1.4.0 so whatever it uses. We use 0.1.7 in ensime-server as a dependency.

sbt-scalariform is up to 1.5.1 now, 1.4.0 is using scalariform 0.1.6

ok, I'll change and check that, thanks! Closing for now, will reopen if I see anything else. If you could have a look at that other PR and merge that would be really fantastic.

thanks, that fixes it!

@daniel-trinh please look at https://github.com/daniel-trinh/scalariform/pull/80 and merge/release if you are comfortable.


Unable to use RequestCallEndpointChange method

Android framework version
net9.0-android
Affected platform version
.NET9.0, VisualStudioCode 1.95.3
Description
Unable to call RequestCallEndpointChange method
as-is
I tried to call RequestCallEndpointChange with argument which type isCallEndPointType, but failed with errors.

'CallEndpoint.TypeSpeaker' is obsolete: 'This constant will be removed in the future version. Use Android.Telecom.CallEndpointType enum directly instead of this field.'CS0619
Argument 1: cannot convert from 'Android.Telecom.CallEndpointType' to 'Android.Telecom.CallEndpoint'CS1503

        //     Portions of this page are modifications based on work created and shared by the
        //     Android Open Source Project and used according to terms described in the Creative
        //     Commons 2.5 Attribution License.
        [Register("requestCallEndpointChange", "(Landroid/telecom/CallEndpoint;Ljava/util/concurrent/Executor;Landroid/os/OutcomeReceiver;)V", "", ApiSince = 34)]
        [SupportedOSPlatform("android34.0")]
        public void RequestCallEndpointChange(CallEndpoint endpoint, IExecutor executor, IOutcomeReceiver callback);

should-be
RequestCallEndpointChange should support CallEndPointType argument.
Steps to Reproduce

make mobile project with Uno platform, .net 9
call Connction.RequestCallEndpointChange

Did you find any workaround?
no
Relevant log output

It looks like you are trying to use Android.Telecom.CallEndpoint as an enum (with the TypeSpeaker value) rather than using it as a class.
I think you need to create an instance of CallEndpoint and pass that to RequestCallEndpointChange:
var endpoint = new CallEndpoint ("name", CallEndpointType.TypeSpeaker, uuid);

Documentation

Thanks It works!


[BUG] contract.contractpromise.md has missing contract name in .then API examples

Describe the bug
docs/runtime-ts/classes/_contract_.contractpromise.md (is it auto-generated?) features .then() usage with a wrong number of arguments (the first argument must be contract name).
  let callbackPromise = promise.then(
     "_onItemAdded",
     requestArgs.encode(),
     2,  // Attaching 2 additional requests, in case we need to do another call
  );

The comment about the number 2 is completely misleading. It is a gas amount and it should be a much greater number, e.g. 100000.
Expected behavior
The example should work out of the box.
  let callbackPromise = promise.then(
     context.contractName,
     "_onItemAdded",
     requestArgs.encode().serialize(),
     100000
  );

:pencil: Location
https://docs.nearprotocol.com/docs/runtime-ts/classes/_contract_.contractpromise.html
BTW, the link from the navigation menu is broken (does not include .html)!

@frol fixed the example; what do you mean by the link from the navigation menu is broken?

what do you mean by the link from the navigation menu is broken?

Navigating via https://docs.nearprotocol.com/ to "ASSEMBLYSCRIPT RUNTIME (NEAR-RUNTIME-TS)" -> "ContractPromise" I get "Not found" page since the url is https://docs.nearprotocol.com/docs/runtime-ts/classes/_contract_.contractpromise while https://docs.nearprotocol.com/docs/runtime-ts/classes/_contract_.contractpromise.html works fine.

Just a quick update: There is a weird rendering issue with the actual docusaurus build step: It generates the files as folders with an index.html file inside and tries to serve that against the route. This works for all of the other subfolders except for "classes/" in the runtime section. Working on a fix.

https://github.com/nearprotocol/docs/commit/13266027e53592b314a8352cd2883fe9ba9dffd3

I still see the old examples with all the same issues (zero or two gas, and missing contract name)

https://github.com/nearprotocol/docs/commit/f04ecd090bf1999b587fcee5dca499cb0d0d302f
Thanks! Heres the fix.


Handle websites audio changes

Released in https://github.com/puddingspudding/persistent-video-volume/releases/tag/0.7.0


[WIP] Use qiskit-ibm-provider for duplicated code

Summary
Details and comments
Fixes #548

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+5.5%) to 72.258%

Totals

Change from base Build<PHONE_NUMBER>:
5.5%

Covered Lines:
2615

Relevant Lines:
3619

💛  - Coveralls

I'll close this and start another PR - there are too many merge conflicts 😅


Basic example?

Hello @Twister915. Can you make a basic usage example, how to connect etc.?

Would appreciate an example for mctokio as well.

@pixldev I managed to figure out how to use this library, I have mostly documented code in my rust-mc repo.
There is also rustcord which could also help you.


Add support for tracepoints, closes #117

LGTM after the comment above

Not really sure why the build failed here.

Added cleanup for tracepoints on Close(). Test also looks happy now.
Not sure if having strings as key is a good idea. Maybe it's better to introduce something like this:
type TracepointName struct {
  Category string
  Name     string
}

Then it can be used in parameters and as a key in map.
I started adding support for perf events and they too have category and "config", both of which are int.

Is there anything I could do to help get this merged?

Thanks @bobrik
(Tests on master failed because I'm in between updating stage1 images for the tests, pull request coming.)


CMSIS CRL Cortex M returns wrong outputs for higher float values in arm_float_to_q31.c which is under CMSIS-DSP-Source-SupportFunctions directory

For the conversion from float to q31 format, the floating-point number is scaled by the factor of 2^31. Following the scaling, the result is cast into a q63_t type (which corresponds to a 64-bit integer).
(q63_t) (*pIn++ *<PHONE_NUMBER>.0f)
Inputs that are in the range of 10^10 or higher will cause an overflow when scaled by 2^31, as the resulting value surpasses the maximum representable range of a 64-bit integer, leading to incorrect outputs.

@BhaskarsarmaP It looks like there is an hidden undocumented assumption in the code. I won't switch the implementation to double precision because it would have an impact on performances and most of the case it is not needed.
I'll update the documentation of the function to inform that if the floats are expected to be very big then it may be better to update the float array before calling this function.


feat: DEV-3132: improve Brush experience on iPad [test2]

Hi @hlomzik!
This PR was created in response to a PRs in upstream repo:

https://github.com/heartexlabs/label-studio-frontend/pull/809
https://github.com/HumanSignal/label-studio-frontend/pull/809

Closed as stale


[release-0.59] instancetype: Handle DataVolumeSourceRef without namespace when inferring defaults

What this PR does / why we need it:
As set out in issue #9431 it is valid for a DataVolumeSourceRef to not provide a namespace, the assumption being that the resource it points to is in the same namespace as the VirtualMachine.
This change handles this by switching to the namespace of the VirtualMachine when no namespace is provided by the DataVolumeSourceRef, avoiding a previous panic.
NOTE(lyarwood): conflict caused by
c09acad4db9cddf75c5b059d62c1074c40bd85ab not being present the in release-0.59 branch.
Signed-off-by: Lee Yarwood<EMAIL_ADDRESS>(cherry picked from commit 50befd593b10b6a5c2a574f12ff9c6cbd6a9674d)
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/area instancetype

/retest-required

/approve

/approve
/lgtm


Adding the R_t inference notebooks to the main branch

We wish to pull the SEIR ODE inference model onto the main branch. Here, I have uploaded the relevant notebooks and figures.

I am happy with this PR, though original maintainers (@rccreswell?) may want to take a look. But needs the issues identified in the continuous integration (#115) to be resolved first


[A11y] Sound loading progress ring can be reached using narrator, even if all sounds have been loaded

When using the item mode of narrator, users can reach the "loading sound" progressring despite all sounds having been loaded.

Can you provide repro steps? What is item mode? Sorry I'm still learning my way around a11y!

I was navigating in item mode, after going through the different sounds, eventually you reach the ProgressRing.


Fix cuda graph capture for grouped gemm

Description
Cuda graph does not work with Grouped GEMM.
The saved forward activations are corrupted before bwd_graph is replayed. Explicitly setting retain_graph=True can hold the activations and fix the issue.
Type of change

[ ] Documentation change (change only to the documentation, either a fix or a new content)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Infra/Build change
[ ] Code refractor

Checklist:

[x] I have read and followed the contributing guidelines
[x] The functionality is complete
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

/te-ci pytorch

/te-ci pytorch

/te-ci pytorch


MM-26023 Move handling of sidebar API responses to the websocket

When making requests to the server, the client that made those requests also receives the corresponding websocket events which often leads to us duplicating logic for handling the websocket event and the HTTP response. I'm going to bring this up at the dev meeting next week, but it might make sense to just handle everything in response to the websocket event to avoid duplicating effort and making the code much more complicated and difficult to follow.
Unfortunately, this does make it harder to test these, but thankfully we have the new E2E tests for that 😄
Ticket Link
https://mattermost.atlassian.net/browse/MM-26023
Related Pull Requests
https://github.com/mattermost/mattermost-webapp/pull/5924

@sudheerDev Kind reminder to review this for v5.26,

@hmhealey
Error trying doing the automated Cherry picking. Please do this manually

+++ Returning you to the master branch and cleaning up.

Manually cherry-picked onto release-5.26


Cache the images

The build-images step takes annoyingly long (e.g. for Lua that needs to build the entire gRPC library). We should to devise a strategy to cache the built images / don't build them at each run if there were no changes. Any ideas?

On the perf machine it's not so bad because I never remove them and docker can work its magic.
Generally speaking, the first idea that comes to my mind is to open an account on docker hub and push everything? Not sure how it will help the CI though, in theory it should build and push everything every time.

Yes, me as well, locally it's totally fine. Perhaps this technology or similar could be used https://github.com/marketplace/actions/build-docker-images-using-cache

Yes, me as well, locally it's totally fine. Perhaps this technology or similar could be used https://github.com/marketplace/actions/build-docker-images-using-cache

looks good!


fixes link to google analytics.js

Analytics weren't loading properly. I suspect it was because the script references //www.google-analytics.com/analytics.js instead of https://www.google-analytics.com/analytics.js

nevermind. I don't think this is an issue.


Update readme link to grammars

What behavior of the library made you think about the improvement?
The readme section on grammars reads:

All you have to do is search for "X EBNF grammar" on the web, and take a look at the Outlines Grammars repository.

The link does not work.
How would you like it to behave?
I would like the link to point to a Github repo where I can learn more.

Thanks for pointing this out.
Grammar files now reside in https://github.com/outlines-dev/outlines/tree/main/outlines/grammars
There are a few more being introduced here if you're curious https://github.com/lapp0/outlines/tree/benchmark-cfg-generation/outlines/grammars

Fantastic, thank you!


Completion Bar on top of each page in SDC to make users aware of the unanswered questions covered by the keyboard

Is your feature request related to a problem? Please describe.
As can be seen in the video, the keyboard covers up questions in a particular page. It is difficult for non-technical people to realize that there is a scroll bar that must be used to answer the rest of the questions.
Describe the solution you'd like
I was thinking that we could have a bar at the top that progresses as the questions in a page are answered. So that the instruction to first time users can be simple eg: "Answer all questions on the page until the bar is complete"
Describe alternatives you've considered
We could also have a text box that says 2 out 3 answered or 2/3 . @shelaghm Please suggest any other ideas.
https://user-images.githubusercontent.com/48797364/183082175-23eee450-768d-473c-9d7f-e4aeed7a1726.mp4
Additional context
cc: @jingtang10

@joiskash @jingtang10 I'm not sure what's the best approach here. For context, we are planning to implement a progress bar for paginated questionnaires https://github.com/google/android-fhir/issues/1523 which would behave a bit differently from the proposed solution on this issue. It might be confusing to have a progress bar that only indicates progress on one page of the questionnaire, not the whole questionnaire.
An alternative is to consider putting the back and next buttons anchored at the bottom of the questionnaire, so that users need to scroll to the bottom of the page to press next.
Another alternative is to consider adding a dialog box that appears when they press next that says something like "there's two unanswered questions/fields on this page"

actually this is not a duplicate of 1523.
@joiskash we're saying that for paginated questionnaire we have 1 progress bar on top indicating where you are amonst the pages. it would be hard and confusing to include another progress bar to indicate the scrolling status of the current page. as shelagh suggested, the best way to approach this is to make sure when you have paginated questionnaire, each page fits in the screen.

Ok but this is not an optimum solution. Considering different phone screen size , table vs mobile. Etc. This would mean created different questionnaires for different screen size. Or else the feedback that we will receive (and have received)  is that more questions can be added to a page instead of leaving it half empty.


Management of Data and JavaScript Libraries while executing Data Driven Postman Collections #3

Management of Data and JavaScript Libraries while executing Data Driven Postman Collections #3
Added data attribute and made compatible to Java 1.8

I have just noticed this is still open, looks like it was raised well before this was transferred over to me. I am going to close it down, please let me know if this is something that you still require?


Cache wallet addresses

Context
During Rafiki WW, one of the performance optimizations we found to be useful is caching assets, given we make so many requests for wallet addresses, even though they rarely change.
We should use redis for caching these.
Todo

[x] Add redis cache to walletAddressService (via createRedisDataStore, and a reasonable key expiry). Delete cache on wallet address update.
[x] Resolve any requests for assets via the assetService instead of any .withGraphFetched('walletAddress') objection calls

Note, the Redis cache was replaced in favour of the temporary local cache. The local cache stores the data for 5 seconds.


js2xmlparser is not a function

js2xmlparser is a Node.js module that parses JavaScript objects into XML.
https://github.com/michaelkourlas/node-js2xmlparser
js2xmlparser is not a function. We need to use js2xmlparser.parse

I HAVE the same problem anyone help me ?


File integrity check

Maybe it would be useful if we could expose means of assessing the integrity of a file. I can think of the following scenarios:

check if a file is correctly uploaded to S3. For this, first calculate the file's checksum using a hash function (e.g., MD5, SHA256), then compare it with S3 generated checksum. If the two hash values match, then the file is correctly upload; otherwise retry uploading the file.

Get a file's checksum without download the file (e.g., see this). A good scenario for this would checking if a local copy match S3 version, if not, then a collaborator has changed the file, hence update the local copy.

It seems boto is exposing MD5 checksum of an object, however, I guess the challenge would be to (1) ensue if/how other providers expose checksum without downloading a file/object; (2) are all the providers use common hash function for checksum?

I think this would be a really nice feature to have. There are several hurdles to overcome.

The first one is the issue that you highlighted - do all providers expose the same cheksum?:
They do appear to if the file is not chunked as far as I can see. The ETag exposes the md5 sum. However, for chunked files, it's a mixed bag: aws, azure, gce, openstack

The checksum for large, chunked objects is dependent on the chunk size, as each chunk is hashed separately. This means that the user must provide the original chunk size that was used, or no meaningful comparison can happen. This is probably not too big a deal if all objects were uploaded using cloudbridge, since we can use a fixed CHUNK_SIZE per provider. If not, we'd have to have the user provide it as a parameter. One good thing is that all the providers do appear to have a mechanism for getting the hashes of individual chunks without downloading the file, at least at first glance.

The first and second issues imply that cloudbridge must also provide a function for hashing the local file, since the hashing will be provider specific. Something like

    # Get the hash of a remote bucket object
    remote_hash = BucketObject.get_hash()

    # Compute the hash of a local file
    local_hash = BucketObject.compute_hash(local_file_path, chunk_size=some_provider_default)

    # compare
    remote_hash == local_hash?

We can avoid having to provide a local compute_hash function if we assume that the user must cache the original hash somewhere, rather than recomputing it. This would probably be desirable initially, since it would reduce complexity considerably.

The first one is the issue that you highlighted - do all providers expose the same cheksum?:
They do appear to if the file is not chunked as far as I can see. The ETag exposes the md5 sum. However, for chunked files, it's a mixed bag: aws, azure, gce, openstack

This is gonna be tricky :(

The checksum for large, chunked objects is dependent on the chunk size, as each chunk is hashed separately. This means that the user must provide the original chunk size that was used, or no meaningful comparison can happen. This is probably not too big a deal if all objects were uploaded using cloudbridge, since we can use a fixed CHUNK_SIZE per provider. If not, we'd have to have the user provide it as a parameter. One good thing is that all the providers do appear to have a mechanism for getting the hashes of individual chunks without downloading the file, at least at first glance.

Let me highlight two points: (a) I think we would better expose one checksum regardless of the file size, I guess we get one checksum for an object from S3 no matter what the size is; (b) it is a very strong assumption that the file is upload by cloudbridge. I'm assuming that cloudbridge can download any object from S3 no matter how the object was uploaded. If this assumption is correct, then we should try not to invalidate it for some functionalities (e.g., get checksum).

The first and second issues imply that cloudbridge must also provide a function for hashing the local file, since the hashing will be provider specific.

I would say it would be simpler/logical to just expose the hash key we're getting for an object from the provider, and avoid being in the job of creating such hash keys (not even at the level of a simple interface to hashlib), at least for the time being.

We can avoid having to provide a local compute_hash function if we assume that the user must cache the original hash somewhere, rather than recomputing it. This would probably be desirable initially, since it would reduce complexity considerably. However, that won't help in scenario 1 you highlighted - checking whether an object was uploaded correctly.

Similar to my previous comment, lets avoid caching checksums of uploaded/downloaded files at the cloudbridge level. I guess cloudbridge does not cache/store any attribute of uploaded/downloaded files.

(a) I think we would better expose one checksum regardless of the file size, I guess we get one checksum for an object from S3 no matter what the size is;

Even for chunked objects, I think a single checksum is exposed by the providers (That single checksum appears to be calculated by hashing the individual chunks, but we only need to care about that if we have to reproduce the hash ourselves I guess).

I'm assuming that cloudbridge can download any object from S3 no matter how the object was uploaded. If this assumption is correct, then we should try not to invalidate it for some functionalities (e.g., get checksum).

Yes, that's correct, and agree.

Similar to my previous comment, lets avoid caching checksums of uploaded/downloaded files at the cloudbridge level. I guess cloudbridge does not cache/store any attribute of uploaded/downloaded files.

I agree that checksums should not be cached by cloudbridge and nor can it, since there's no stored state. Therefore, if a cloudbridge client/user wants to compare a local file with a remote file, they must themselves maintain a cached checksum, or we must provide a mechanism for computing that checksum as far as I can see.
For the scenario where the user wants to validate that an upload has been performed with no data errors, that could be handled separately, say by providing a verify=True/False parameter in the upload function. Each provider can then do its own verification.

For the scenario where the user wants to validate that an upload has been performed with no data errors, that could be handled separately, say by providing a verify=True/False parameter in the upload function. Each provider can then do its own verification.

It would be awesome if we could implement "upload verification" internally leveraging on checksum. Such that, we compute a checksum of the file before uploading, then compare it with the provider provided checksum, then if match: return true from the upload function; otherwise: return false. Accordingly, the user does not need to know what mechanism we're using to verify integrity of the upload, but can trust the verification :)

It looks like boto is verifying each chunk already, so we may not need to do anything for AWS. Swift does the same and supports a checksum=True/False parameter to control it, but it's on by default. I'm guessing AWS and GCE are likely to be the same.

That solves the integrity verification of the uploaded file. So, we just need to inform a user (in documentation maybe) that upload verification is checksum-based. However, we are still gonna need exposing checksum of an uploaded file.


twitter profile pictures disappear

Note sure if it's because people change them or maybe twitter deletes them after a while but some people are saying their profile picture is not showing: https://nostr.directory/p/npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424
not sure if we should show twitter pfp or nostr pfp or both.

should be resolved now https://github.com/pseudozach/nostr.directory/commit/c4e99c52d34d2c39e8d1832778566943f1efbccc