added a setup.sh in the global dir of the project

closes #22
changes made added a Setup.sh file in the main dir of the project

run the file in macOS or Linux
chmod +x ./Setup.sh
then ./Setup.sh
this will setup the application and add the local mongo URL to the .env file
and start the frontend
For macOS/Linux: you can start the server by moving into the server folder
and just doing npm start

For Windows:

Open Command Prompt (CMD) or PowerShell

Navigate to the main directory of the project where Setup.sh is located

Run the following commands:

- `.\Setup.sh`

- This will setup the application and add the local MongoDB URL to the .env file and start the frontend

To start the server, navigate to the server folder in Command Prompt or PowerShell

Run the command: npm start

Hey @Sahilll15, I have added some changes for this PR.
Try to resolve this so that this PR is merged.

@abhijeetnishal have a look!!

@abhijeetnishal have a look!!
Hey @Sahilll15, I am merging this PR now. You can also update in readme about the script.

@abhijeetnishal have a look!!
Hey @Sahilll15, I am merging this PR now. You can also update in readme about the script.

okay


metadata query functionality

Extends #111
Purpose:

Querying metadata from delta-sharing directly without using the rest_client.py
Keeping Table origin information in metadata query results (e.g. for processing in data catalogs, etc.)

Implemented:

2 functions in Sharing client (list metadata in table, list metadata for all tables)
Changes to rest client classes (QueryTableMetadataResponse, QueryTableVersionResponse, ListFilesInTableResponse) in order to have table origin information in the responses
updates to tests.

Signed-off-by: Stefan Salzl<EMAIL_ADDRESS>

Thanks for the contribution. Adding a new metadata query looks good. Could you elaborate this Keeping Table origin information in metadata query results (e.g. for processing in data catalogs, etc.)? If you pass the table object into the method, you should already know it?

@zsxwing
Sorry English is not my first language, so I might not get my point across exactly. But I'll try 😭
TL;DR:
My reasoning for adding the table class to the return value is:

A nice return value contains all the information needed for table metadata and origin
For a user of the library the convenience function query_all_table_metadata hides details away.

Long version:
When querying for the metadata, I would like to return a complete class that contains all necessary information for pushing the metadata to a data catalog, i.e.

Table origin (i.e. the Table class (containing Table name, schema, share)
Metadata information

So taking the extended return class, I can immediately push the information to a data catalog, without creating a object combining Table origin & metadata information. Everything is already in place.
This is especially important for the query_all_table_metadata function, where you don't query for a specific table but you ask for all tables. If you do not return the table in the response, you lose the table origin information. Then you either stuck with doing something like

querytablesmetadata = [self.query_table_metadata(table=table) for table in tables] or
running list_all_tables after running query_all_table_metadata

Thus, the query_all_table_metadata function would be completely pointless.
P.S: I have also added a small convenience function for querying version history as well.

Hi @zsxwing
Did you have time to look at my answer? Thanks!


[SIL] Add flag to SILFunction to indicate async.

Includes boilerplate to parse and print as well as to serialize and deserialize.

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - cdc95208e9a891016d2f02dba9e1c8072cce176b

Build failed
Swift Test OS X Platform
Git Sha - cdc95208e9a891016d2f02dba9e1c8072cce176b

@swift-ci please test

@swift-ci please test

@swift-ci please test windows

@swift-ci please test

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - d5ad8069b88986b0b6198ca9e524c7252f2dfc25

Build failed
Swift Test OS X Platform
Git Sha - d5ad8069b88986b0b6198ca9e524c7252f2dfc25

Build failed
Swift Test Linux Platform
Git Sha - d5ad8069b88986b0b6198ca9e524c7252f2dfc25

@swift-ci please test windows


First pass at printing out debug info if started without --lsp

Closes #1412
Example output
Running HIE(hie)
  Version <IP_ADDRESS>, Git revision 666626ede0e0bf5f1c876bd04f2a8a0cc68e7bb1 (dirty) (3534 commits) x86_64 ghc-8.6.5
Current directory:/home/alanz/mysrc/github/alanz/haskell-ide-engine/app

args:[]

Looking for project config cradle...

2020-01-01 22:41:46.396914848 [ThreadId 4] - Cabal-Helper dirs: ["/home/alanz/mysrc/github/alanz/haskell-ide-engine","/home/alanz/mysrc/github/alanz/haskell-ide-engine/app/File.hs"]
Resolving dependencies...
Build profile: -w ghc-8.6.5 -O1
In order, the following would be built (use -v for more details):
 - hie-plugin-api-<IP_ADDRESS> (lib) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (lib) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (test:wrapper-test) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (exe:hie-wrapper) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (lib:hie-test-utils) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (exe:hie) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (test:unit-test) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (test:plugin-dispatcher-test) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (test:dispatcher-test) (configuration changed)
 - haskell-ide-engine-<IP_ADDRESS> (test:func-test) (configuration changed)
Cradle:Cabal project

@bubba Perhaps, but until very recently (and not yet in a tagged release) we have always used the "--lsp" flag.
Also, this mimics what ghcide does, and I would rather maintain compatibility there.

@alanz We will need to update the README and vscode-hie-server for this, they currently do not contain the --lsp flag

Should we undo this then, or change the flags as @bubba suggested?

@fendor I updated the vscode client to include the --lsp flag again, I think we should let this stand, for now.

What about the other clients? Should update them somehow, too?

To my knowledge vscode and emacs-lsp are updated. Not sure what others need it, we should see reports if it is a problem.
Luckily it is just a few days within a release, so they should be supporting the non-master stuff too. Maybe.


pip install tries to upgrade django to 1.7

In a django 1.6 project - virtualenv with django already installed -, pip install django-debug-toolbar tries to install django >= 1.7.
I understand that current version requires django >= 1.7 so it's the "expected" behaviour but as far as I'm concerned a django app forcing django version update is neither expected nor  right - it should either ask for confirmation or refuse to install with a clear message if a django version < 1.7 is already installed (don't know wether pip / setuptools etc allow for such a behaviour tough).

Can you submit a patch?

I would have if I was a bit more fluent with python packaging (very limited experience here sorry).... As I mentionned, I don't even know if it's actually technically possible to do something like this.
But anyway : the best fix AMHA would be to plain remove the requirement on django 1.7 and clearly document which django version is supported (I know the information is there - I found it browsing the tags on github and finally installed 1.3.2 - but it's not obvious on readthedoc).  That's what most django apps do FWIW, debug_toolbar is the first one I've met that tried to update my django install.
My 2 cents...

The dependency seems to have been added as a side-effect of an unrelated change in https://github.com/django-debug-toolbar/django-debug-toolbar/commit/eacf116d61f0e3f47a7c581275a18b3aec8548b1#diff-2eeaed663bd0d25b7e608891384b7298L15.
I'm OK with dropping it.

pull request submitted, build ok.

I don't see any problem here. In the setup the line telling that Django debug toolbar want's Django >= 1.7 must stay. This is the dependency. Pip is clever and try to install dependencies (for that reason we use PIP and not downloading packages manually and executing python setup.py install on them).
@BrunoDesthuilliers If your project is not ready for django 1.7 (which is current minor supported version not only from django-debug-toolbar but from Django itself) then you need to use requiements.txt with your packages and versions to which it depends and to put django-debug-toolbar==1.3.2 because this is your dependency.
I will vote this issue to be marked as "invalid".

@vstoykov  I'm sorry but I have to disagree here. An add-on should in no way try to upgrade the host framework's version - which is the responsability of the project's maintainer - specially when this add-on is supposed to be a developper-only tool (I could eventually see the point for a full-blown CMS or E-Commerce application and even then...). FWIW django-debug-toolbar is the very first django app I've seen that behave that way - the others only document which django version each release supports, and break if you install them on an unsupported one, and as a Django dev that's what I expect.
And yes, switching to 1.3.2 is what I did (obviously). The issue here is not with the current django-debug-toolbar version not supporting django 1.6 but with it wanting to upgrade django not caring if it breaks my whole project.

django-debug-toolbar do not try to install newer version of Django. PIP is installing it because it sees that this is requirement which is not satisfied (this is how PIP works).
When you install package and then when you run your project something fails you start wondering where is the problem - in your code, in the 3th party app code or something else. You can submit an issue because you think that something is broken until you realize that you are trying to use unsupported version.
On the other hand when you install a package and it tries to upgrade some other package (mainly Django) you now know that obviously you are trying to use latest version of something which do not support your older version of Django.
Your not seeing many (or other) packages to depends on Django 1.7 or greater right now because a lot of 3th party packages are trying to achieve greater backward compatibility and support Django versions to 1.4 or even lower.
Probably the main problem is that support for lower versions of Django was dropped so soon (only 5 days after end of life of Django 1.4 the previous LTS), but the approach how it was done was right.
A proper solution for the situation is probably more precise documentation about installing django-debug-toolbar on different versions, and advice for upgrading to newer Django.
@BrunoDesthuilliers  I have one suggestion to you. Youse dev_requirements.txt or requirements_dev.txt or something similar to describe all dependencies not needed for production bot only for development. This will be easier for you and your colleagues.
@aaugustin I have one suggestion to you also. Think more before dropping support of older Django versions. I don't say that all Django versions from the beginning of time need to be supported, but still only 5 days after end of life it's to soon.

@vstoykov  I have one suggestion for you too : don't assume that peoples who disagree with you and state they are not packaging experts are noobies needing guidance ;)  Oh and I didn't wait for your "suggestion" to separate dev requirements from prod's requirements either - believe it or else but it's not exactly my first Python project (nor the first Django one).
The code stating that latest django-debug-toolbar requires django >= 1.7 is in django-debug-toolbar's code, so yes practically speaking it actually is django-debug-toolbar that asks pip to upgrade django.
You can sample other django reusable apps - I just had a look at a couple ones from one of my project's requirements - and very few (actually 2 out of 8) mention Django in the the setup.py requires or install_requires. Not enough for statistical evidence tough...   Now wether it's a "good practice" or not is debatable but as far as I'm concerned I fail to see how someone installing a django app in a project's venv would expect the app to work without django anyway. What I do not know is if there's a way to tell pip to refuse to install or issue a warning instead, which would make much more sense.
This being said you might be right about the point that the root problem here is dropping support for older Django versions a tad too soon and not clearly documenting supported versions.

@vstoykov I've spent days on end discussing and thinking about how to handle backwards incompatible changes and version upgrades in Django and its ecosystem. Please don't assume that I made this change on a whim.
When a Django version no longer receives security support, it's very damaging to the community to maintain support for it in a popular application such as the debug-toolbar because it implies that it's reasonable to keep running it and that implication comes from people who are supposed to know what they are doing. (That's just one reason)

Let's get back to the original topic.
In general pluggable Django applications don't make Django a requirement because it's fairly obvious that they only work with Django. There's no use case for doing pip install django-debug-toolbar and exepecting it to install (or upgrade) Django.
The desirable behavior here is to warn the user if an incompatible version of Django is installed. Forcing the upgrade of Django is one way to warn but perhaps not the best one. Aborting the installation would work as well. Silently proceeding sounds bad -- because the app will crash immediately.

@BrunoDesthuilliers Ok I accepts your advice and I will try to not judge people too early :).
About listing django as requirement in pluggable django applications if it says only Django yes it's obvious and unnecessary, but adding version is good approach. It explicitly says which versions are supported.
For developer executing  pip install django-debug-toolbar it's obvious that he/she do not want to upgrade Django right now but when this was happening this means that the code base is really out of date and eventually insecure and probably now is the time to think for upgrade.
There always a way for a workaround and print some warning on screen or even break but:

If you missed that your django version are updated automatically, probably you will miss the warning message also.
If install process breaks because of dependancy, why we use setuptools and pip and not distutils.

Probably for the current situation there is no "best" solution because the problem is not in django-debug-toolbar setup but in handling python packages at general. How given package which as plugin to bigger system can describe his compatibility and package manager (pip or easy_install) to handle this accordingly. This is not related to Django ecosystem but to all python packages in general.
P.S.
Now most of the django plugins probably do not include requirement to Django because they do not want to mess with broken situation in Python packagin.
P.S.
@BrunoDesthuilliers @aaugustin Sorry if my words are offending you or I sound little more rude. It was not intentional. English is not my native language and probably some times I use inappropriate words.

@vstoykov No problem, I guessed so :-)

@vstoykov  no offense, and English is not my native language either so I can well understand how difficult it can be to convey the exact intention sometimes ;)
@aaugustin @vstoykov Yes indeed there might be something about Python's packaging ecosystem that doesn't quite cut it when it comes to "plugin" packages - as I said I'm far from an expert at Python packaging -, and if then yes that's a more general issue and no there's no obvious best solution here.
As a side note: one shouldn't assume that it's the developper that needs to be reminded that upgrading to a supported & more secure Django release would be a good thing - when the stakeholder don't want to pay for an upgrade despite your warnings, then you don't upgrade, period.
Now thinking about the whole thing: if the readme contained a clear mention of which Django version is required for the current debug-toolbar release I would not have tried a pip install on this release so I would not have been surprised by the install trying to upgrade Django.
I've been actually surprised yesterday when I found out that at least a couple other django apps I use had requirements on Django version and then wondered why I never had any issue with this before (and I've been using Django and virtualenv for years on tens of projects).  Then I remembered how many times I've been thru the process of read the readme, notice the Django version requirement, scroll thru the past releases to find the latest one matching my project's django version and explicitely install this one.
To make a long story short; at least part of the solution might be more on the doc side than on the technical one ;)

The README does point out the version requirement:

The current version of the Debug Toolbar is 1.4. It works on Django ≥ 1.7.

???
I'm afraid I missed it then :-s - and I do apologize for all the fuss,  obviously a chair/keyboard interface problem here.


allow secret injection in build when PR if Private and Checksum is good

This statement in the build doc leads me to believe that you should be able to do secret injection into the build section if a PR is for a private repo.
"Secret variables are not injected into to the build section of the .drone.yml if your repository is public and the build is a pull request."
I've set this so that .drone.yml checksum verification is required.

FWIW, I'd like to have this without having to use checksums in our private repos. Maybe that could be configurable behavior, though.

I've thought about this a bit more, and what is comes down to is there is no "safe" situation for injecting secrets into a PR.
Secrets are only secure from Read-Only users and then only if they are not allowed in PRs.
That's it, that's all the secrets are effective for.  Any user with Write access could put malicious code into the build process to write out the secrets. So at best secrets are only obfuscated from Write users - Not Secure.   If you allow secrets in a PR, a malicious Read-Only user could submit a PR to a repo with code to write out the secrets at build time.  A checksum won't help since the malicious user doesn't need to modify the .drone.yml, just whatever the build process is running.
So if you really need secrets in your in your PRs, you might as well just put them in plain-text in your repo :(

I'm going to close this PR since it would provide a false sense of security.


[to increase tree turn-around time] let participant know the schedulingPriority

could be smthg like this is tree priority number X
Liam said they are more interested in working on high-priority trees (aka trees that will complete sooner) and that's also what Ought would want ideally: have participants spend their Ought time budget on high-priority trees in order to increase the tree turn-around time
source: https://app.slack.com/client/T3L8K3NMT/CMVHF5HJ8/thread/CMVHF5HJ8-1567227911.014000

As an interim solution, would it work to simply close a workspace once I see it's non-priority, and wait a few hours before logging back in?

Yes

I would call this low depth. If there's 5 depths remaining and no sub-questions, then it's a new tree. Otherwise, it's hard to tell. A 4 depths remaining could still be high priority, but 0-2 depths remaining is likely to be high priority.


Separate and clearly document direct/transitive vendored dependencies with the help of pip-tools

The work in this PR was extracted from #4330.
Motivation
Right now it is a bit tricky to deal with the vendored packages:

The developer either have to manually pin down all the direct and transitive dependencies in vendored.txt or
There will be dependencies installed in the _vendor folder that are not listed in the vendored.txt file.

This makes it is hard to guess why they are there and to track the dependency chain...
It also make it possible for pkg_resources and setuptools to have different versions of the same vendored dependency. This is probably not nice for OS-level repackaging.

Summary of changes
The most relevant commit of this PR is b5e91c836.
It modifies tool/vendored so that:

Transitive dependencies are automatically documented
(so we don't loose track of what needs what).

This is done via pip-compile and vendored.in (direct dependencies)
==> vendored.txt. See 1a31ed107 and 20df694e3.

Instead of a case-by-case import rewrite, all vendored imports are rewritten at once

Case-by-case workarounds were kept (e.g. intentionally delayed imports)

Sync versions of vendored packages in pkg_resources and setuptools
so that it is easier for "de-vendoring" (this is done via --constraint in pip).

I also added a base_python to the tox environment intended to match the lowest version of Python supported by setuptools, so that dependency markers are solved for a more general case.
The remaining of the changes are collateral.
No attempt to remove extern was made.
If reviewing this PR I recommend checking commit-by-commit to avoid the big blob of automatic changes related to running tox -e vendor.

Closes
Pull Request Checklist

[ ] Changes have tests
[ ] News fragment added in newsfragments/.
(See documentation for details)

No attempt to remove extern was made.

I was just reviewing https://github.com/PyO3/setuptools-rust/pull/437 and trying to assess the suggestion to switch from using tomli as a real dependency to pull it from setuptools.extern (on Python versions predating tomllib).
What's your take on this situation? It seems a reasonable motivation for setuptools-rust to avoid having to pull in the additional dependency, though based on the PR here and previous discussions it's based upon, it seems that setuptools was not intending for setuptools.extern to be public...

I will close this since setuptools changed the way it process its vendored dependencies.


chore: Remove Helm chart

Fixes #487
Also removing the instructions on how to test the Helm chart locally from CONTRIBUTING.md as no longer relevant.

Is it worth working on #474 and migrating cron jobs before this?

#474 (and #478) shouldn't be a blocker - it's okay to merge this PR in the meantime. But yes, those issues need to be addressed.


Generated sources from IDL always pass arguments by const ref

Using the VSIX (2.0.190425.5) to process IDL files produces sources with declaration and definition stubs, always passing arguments by const ref. This is generally fine, unless you are authoring an async method, e.g.
namespace ns
{
    runtimeclass Settings
    {
        Windows.Foundation.IAsyncAction SetTimeUtc(Windows.Foundation.DateTime UtcTime);
    }
}

produces this header:
namespace winrt::ns::implementation
{
    struct Settings : SettingsT<Settings>
    {
        Settings() = default;

        Windows::Foundation::IAsyncAction SetTimeUtc(Windows::Foundation::DateTime const& UtcTime);
                                                                                // ^ ouch
    };
}

causing a subtle bug waiting to happen. Async functions should always pass by (const) value instead, and the generated stubs should honor this.
This seems to be somewhat related to #384, which apparently does the opposite. Maybe this is an opportunity to consolidate the source generation into a single implementation.

Thanks for the report Tim. That's a regression as it should already be doing that.


⚠ Jenkins Plugins Artifactory has degraded performance

In b3bef62, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1169 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 598536a after 53 minutes.


use of closed network connection!!

I don't know why showing this issue!!

This should be already fixed with https://github.com/projectdiscovery/interactsh/pull/531 - It's due to random eviction in the server cache


MapStateToProps shorthand syntax: Supporting factory selectors

Like #723 but supporting factory selectors... Because I'm of the opinion that the object-shorthand syntax should also support factory selectors like @jimbolla suggested in the past. 😄
cc: @gaearon, @jimbolla , @markerikson , @slorber, @timdorr

Am I right to assume that, using this shorthand, a selector could not return a function that wasn't intended to be a factory?
@connect({
  getterFnForFooState: (state) => () => state.foo
})

I would remove the factory function feature from the MR because I think it would be simpler and more easily justify the inclusion of the shorthand. If you're looking to construct selectors per component instance, you can use @connectAdvanced.

Yeah, I'm afraid I've been focusing on other tasks and not actively trying to get this (and other long-standing PRs) pushed through to completion.
I can't promise a specific deadline, but I will put reviewing this as a high priority and will do my best to get to it within the next week-ish.

Am I right to assume that, using this shorthand, a selector could not return a function that wasn't intended to be a factory?

Yes.

I would remove the factory function feature from the PR because I think it would be simpler and more easily justify the inclusion of the shorthand. If you're looking to construct selectors per component instance, you can use @connectAdvanced

That's fair, but you could also argue that in that case you could just use the normal connector:
@connect(state => ({
  getterFnForFooState: state => () => state.foo
}))

Not that I've actually ever run into a situation where I need to do that...
On the other hand I use very often factory selectors. I would find it very handy to be able to have some properties that come from a factory selector and some properties that come from a normal selector, that's a situation that I run pretty often into.

I bet it's going to be here for awhile with such a substantial change to the API.

I don't think that this is a substantial change to the API at all, since all this changes are backwards compatible. This is just a small addition to the API, just an arguably handy shorthand... The API remains the same... Notice that the changes into the documentation are minimal, that itself indicates that the API doesn't change much.
cc @pcwinters

It would be great to see this get landed - I'd love to help if there's anything remaining to be done.
I did want to weigh in against the factory properties, though:

It seems like a POLA violation, as functions are perfectly valid values for properties.
Relatedly, it's inconsistent with the existing API, which allows function values in the object returned from mapStateToProps.
The current mapStateToProps implementation already lends itself well to nested factory functions, if desired.

Well, I clearly didn't put reviewing this as a high priority, unfortunately.  Sorry :(
But, I am actually trying to review this now.  I'm not 100% familiar with the current React-Redux v5 implementation to begin with, so I'll need some time to understand how this actually changes things.

Initial thoughts:

Not immediately related to this PR: while I understand what React-Redux v5 does at a high level, I'll admit that trying to trace what's going on through the maze of internal factories is kinda painful.  Fortunately the code shouldn't be changing much going forward, but it does make it more difficult to figure out how this change affects things.

I don't think we actually have any tests related to the existing object shorthand capability for mapDispatch.  That seems like a problem.  It would be great if you could add some in this PR, or another separate PR.

I would like to see some additional tests added that cover the object shorthand case for mapState in more detail.  This PR does add a test to check the behavior of per-field factory functions in an object, but I'd appreciate having some more tests to cover the "basic" selector object behavior as well.

The documentation update needs to add more detail.  Please describe what will happen if that object of selectors is passed in, what arguments they will be called with, and how factory selectors interact with that.  We also need some examples added further down the page to demonstrate how to correctly create and pass an object of selectors as mapState.

What will this do to Flow and TypeScript type defs?  I don't use either of those myself, so I generally stay out of any of the related discussions / issues / PRs.  (To be honest, I don't even know whether the "official" TS and Flow typedefs are actually in the repo here, or in DefinitelyTyped / FlowTyped.)

@jmar777 , can you clarify what you mean by "inconsistent with the current API"?  A mapState function shouldn't be used to return functions, just data.  I suppose it's technically valid to include functions in the output of mapState, but that's not something we've encouraged, and I don't particularly remember seeing people do that.  But, even if someone is doing that, how are the factory properties "inconsistent" with the API?  The factory selectors would still be ultimately creating a "real" selector, which would then presumably be returning an actual value at that key.

I'm not ready to merge this in yet, but I think it's on the right path.  I think if we can add some more tests around both the existing behavior and the new behavior, and improve the docs appropriately, we can get this in.
Poking @jimbolla to get his thoughts on the PR.

@markerikson

can you clarify what you mean by "inconsistent with the current API"

I probably should have worded this more clearly. What I mean is that I would expect this:
connect(state => ({
  foo: 'bar',
  hello: () => console.log('world')
}))

...to be ~consistent~ equivalent to the following shorthand:
connect({
  foo: 'bar',
  hello: () => console.log('world')
})

In other words, I would expect connect({ ...someProps }) to always be equivalent to connect(() => ({ ...someProps })). Unless I'm mistaken, I believe that's how the shorthand for mapDispatchToProps() behaves as well.
I see your point that function property values aren't an intended use case, but FWIW, I've personally shoved function properties in there in cases where I didn't actually need direct access to dispatch().
Aside from introducing what I'd argue is unexpected behavior, I don't really see the benefit of property-level factory functions. From a verbosity perspective, they're essentially a tie when you have a single property:
// 54 chars
connect(state => ({
  foo: selectors.getFoo(state)
}))

// vs...

// 53 chars
connect({
  foo: state => selectors.getFoo(state)
})

...and once you get past a single property, the new shorthand syntax starts to lose badly on that front.
TL;DR: it might be a corner case, but the property level factory methods seem surprising to me, and they render the "shorthand" syntax more verbose if people were to actually use them.

@jmar777 : if you want to pass in a function, why not just pass it in as a normal prop?  <ConnectedComponent hello={() => console.log("World")} />.
The use case for the property-level factory functions here, I think, is the same as the overall factory function capability already supported by connect(): being able to create unique selector instances per component instance.  Here's the test that's added by this PR:
    it('should allow providing a factory function to mapStateToProps object', () => {
      let updatedCount = 0
      let memoizedReturnCount = 0
      const store = createStore(() => ({ value: 1 }))

      const mapStateFactory = () => {
        let lastVal, lastProp
        return (state, props) => {
          if (props.name === lastProp && lastVal === state.value) {
            memoizedReturnCount++
            return lastProp
          }
          lastVal = state.value
          return lastProp = props.name
        }
      }

      @connect({ name: mapStateFactory })
      class Container extends Component {
        componentWillUpdate() {
          updatedCount++
        }
        render() {
          return <Passthrough {...this.props} />
        }
      }

      TestUtils.renderIntoDocument(
        <ProviderMock store={store}>
          <div>
            <Container name="a" />
            <Container name="b" />
          </div>
        </ProviderMock>
      )

      store.dispatch({ type: 'test' })
      expect(updatedCount).toBe(0)
      expect(memoizedReturnCount).toBe(2)
    })

So, {name : mapStateFactory} is a selector factory function, and both instances of <Container /> get a unique selector instance.  That way, they each return the exact same values as before, and the components don't re-render.  (The more realistic use case would be looking up something along the lines of return state.items[ownProps.itemId].)

connect({
  foo: 'bar',
  hello: () => console.log('world')
})

This seems not a good idea because on every state change, the connect component would always re-render because it gets a new hello function everytime. Not sure it's

@slorber : to be honest, I'm not even sure exactly what that syntax would do.  I think, given this PR, it would be interpreted as a selector, and wind up returning a prop of {hello : undefined}.

@markerikson

if you want to pass in a function, why not just pass it in as a normal prop?

Code organization / separation of concerns, primarily. Obviously depends on the specific semantics of the component and the function in question.
@slorber

This seems not a good idea because on every state change, the connect component would always re-render because it gets a new hello function everytime.

Right - this was just a minimal example that would exhibit what I believe is surprisingly behavior. The same issue would be exhibited by, e.g.,:
const logWorld = () => console.log('world');

connect({ foo: 'bar', hello: logWorld });

@markerikson

I think, given this PR, it would be interpreted as a selector, and wind up returning a prop of {hello : undefined}.

Correct, and that's what I think would be surprising, as returning that same object from the factory function produces different behavior:
const obj = { onClick: someHandler };

// this:
connect(obj);

// ...behaves differently than this:

connect(() => obj);

At any rate, I seem to be in the minority here in expecting that objects supplied for the shorthand syntax should behave the same as objects returned from factory functions. While I appreciate the utility of property-level factory functions, inasmuch as they don't enable anything that the existing factory functions already enable, IMHO this just seems more likely to introduce unexpected behavior, and I'd advocate for the least surprisingly implementation.
/2-cents

agree with @jmar777
A simple solution that solves 90% of usecases can be merged right now without risk, until we figure out if we can support more advanced API. Honestly it's just reducing boilerplate so I'm not even sure it's so interesting to support more advanced usecases as it seems not so easy and those usecases are already enabled by more verbose syntax.
The initial simple PR I made was ready 1.5 year ago.
I feel like this feature will never get merged because the scope is too broad.
Why not reducing the scope and merging something simple now?
Is there any chance the next steps wouldn't be retrocompatible?

@slorber : I already said I'm pretty much okay with the implementation and scope of this PR, but I want to see more docs and tests added around this.  If you'd like to see this merged, you're welcome to help out with those.

@markerikson : sorry that it took me a while to get back to you on this. I've been quite busy these days. I will start working on this tomorrow... I'm hopping to address your comments by the end of this week. Thanks for your feedback!

Hi @markerikson ! Just another friendly reminder that I'm waiting for your feedback. Sorry if you find these comments annoying... I'm aware that you must be busy and that this is probably a low-priority PR, but as I said before: I don't want this PR to become stale again. Thanks!

It's on my radar, but I'm still on business travel and don't have much spare time.  I'll try to take a look at it after I get back from this trip.

I have to say, I am not a fan of this PR. the number of possibilities for what can be passed for mapStateToProps and mapDispatchToProps is already a bit like reading C++ operator overloading. Better would be to provide different versions of connect that encapsulate the flexibility, or a fluent interface that makes the expected behavior explicit and errors in development if the passed argument varies from what is expected

I do agree that connect has gotten too heavily overloaded, and there are certainly userland ways around this (primarily use of Reselect's createStructuredSelector ).
I'll leave this PR open for a bit longer, but at the moment I'm leaning towards closing it.

Hi @markerikson, can see feature this has been floating in and out of prs for last couple years.  What is the status on this pr? It would a really beneficial feature, is there anything I can do to see this in?

A quick note: in the interim, if you need this functionality, you could write a selector factory that provides it, and pass that to connect options

I'll take the bullet.


[GRIDFIELD] UX: When a gridfield filter is applied, pagination should reset to page 1

Prior to SS3.4 an attempt to filter a gridfield list could lead to the false impression of an empty result set as documented in #3590 and #5577. That was fixed in #5394, but a UX issue still exists where users may assume they are viewing the first page of results when they're actually on a deeper page, and this could lead to them having the impression that there are less results than there actually are, or that a result they are looking for doesn't exist.
Background
As long as the current page number is still valid, it is retained when a gridfield filter is applied. This means if you were viewing page 5 of 40 in a gridfield, then apply a filter, you may now be viewing page 5 of 6. The pagination buttons are a subtle UI element and may not be visible without scrolling, so the current page is not immediately obvious to users. Starting at page 1 after applying a new filter is an established convention in search that I think users expect. Combine these two factors and you have a potentially confusing user experience.
Impact
If users assume they are on the first page of results when they are not, they could scan the results list and assume a result is missing because it is not where they expect it to be according to the current filter and sort order. Also if a user tends to move to the next page of results without paying attention to the current page number, they could have the impression that there are less pages of results than there really are, and miss any pages prior to the starting one.
I can't imagine a scenario where you would want to start on anything but page 1 after applying a new filter (@dhensby and @stevie-mayhew had a similar opinion). Even if users fully understand the behaviour here and aren't getting confused, we're demanding an extra input from them to get back to page 1 after applying a filter, which could be avoided.

This is probably way more detailed than it needed to be but I wanted to keep track of it :P

This is still a problem in SS4.

It looks like the issue was solved. I've done several tests on different implementations of GridField with lists with pagination (more than 1 page) and couldn't replicate this issue.
I close this issue.


[Feature] Button to switch camera

Hello. I run the app on my phone but it display picture from front camera. After debugging I realize that I need to change https://github.com/intel-isl/OpenBot/blob/master/android/app/src/main/java/org/openbot/CameraActivity.java#L110 to 0 (LENS_FACING_FRONT) and it working fine... I don't know why front and back are reversed in my case but it could help you in future for debug the same problems.
My device is Asus Zenfone Max Pro (M2) ZB631KL, Android 9. Other cameras apps working fine.

We have not encountered this on any phone before. Thanks for opening this issue, we will keep an eye on it. I will close it for now, since I don't expect this to be a general issue.

Yep, thanks. Maybe in future it is possible to add camera switch into the settings.

Hello. I run the app on my phone but it display picture from front camera. After debugging I realize that I need to change https://github.com/intel-isl/OpenBot/blob/master/android/app/src/main/java/org/openbot/CameraActivity.java#L110 to 0 (LENS_FACING_FRONT) and it working fine... I don't know why front and back are reversed in my case but it could help you in future for debug the same problems.
My device is Asus Zenfone Max Pro (M2) ZB631KL, Android 9. Other cameras apps working fine.

tin my case also when i used my old Samsung J7 Max by default front camera opens

Hi I have a solution for that, can you kindly assign it to me ?
Sorry it will be not fully compliant with your naming rules..this time

is there an issue why it is a ToDo again ?


Port storage accounts to US Gov and other cloud for live test

The azure-sdk-for-net\sdk\formrecognizer\test-resources.json uses a predifined storage account(azuresdktrainingdata) to test. But the storage accout is only avaiable in subscription '2cd617ea-1866-46b1-90e3-fffb087ebf9b' in AzureCloud which means it is impossible for US Gov or China Cloud to access.

So we need to create a storage account with same structure as azuresdktrainingdata, but in US Gov Cloud. It will be used to test Form Recognizer service in US Gov Cloud.

@jongio for notification.

Resources are copied to storage accounts for China and US Gov clouds:
China Cloud<EMAIL_ADDRESS>US Gov<EMAIL_ADDRESS>The storage account names happen to be identical to the storage accounts in the public cloud so I think the only parameter that needs updating in ArmTemplateParameters is trainingDataResourceId... the value should be something like:
 [resourceId('<subscription_id>', 'TrainingData', 'Microsoft.Storage/storageAccounts', parameters('trainingDataAccount'))]

dup of https://github.com/Azure/azure-sdk-for-net/issues/18522


usaddress page isn't parsing anything

Hey all - I've been trying to use the form on the usaddress page with no success. It's working on the main parserator page, but no results return on the usaddress page.
usaddress page after clicking the parse button:

vs main page after clicking the parse button:

I'm using Chrome on Mac OSX 10.10.3.
Thanks!

@rcackermanCC looking in to it now!

@derekeder Woah that was scarily fast.

@rcackermanCC fixed! Thanks for letting us know.


feat(shared-data, protocol-designer): return latest pipette model def f…

…rom pipetteName and add max flow rates
closes AUTH-243 AUTH-245
Overview
Sorry this should really be 2 PRs but realized I needed the shared-data changes in order to properly test the protocol-designer changes.
This PR does 2 things:

refactor the shared-data pipette v2 specs util to return the latest pipette model version definition that exists if it is given a pipette name. Spoke with Seth and Andy about this and they said that the first model version (3.0, 2.0, etc) are prototypes so we shouldn't use them.
wire up max flow rates in PD using the uiMaxFlowRate key

Test Plan

create a flex or ot-2 protocol. Make sure you choose a flex or GEN2 pipette. Add a transfer or mix step and click on the flow rate input field. It should render the flow rate modal. See that the max flow rate is properly wired up.
review the util in shared-data and make sure the logic makes sense

Changelog

modify the flow rate field to use i18n strings and add a test for it and use the max flow rate from the pipette def key
modify the logic in the pipette spec v2 util to return the latest pipette model version given a pipette name

Review requests
see test plan
Risk assessment
low

not an issue but it's a little bit un-user-friendly since the default is 3.78 but we don't allow users to use 1 decimal place.
For the error message, A max of 1 decimal places is allowed
maybe One decimal place is allowed is enough?
@ecormany any thought on the above error message?

I don't think we should restrict the number of decimals entered, since the Python API doesn't. Any valid float between the mix and max for the pipette–tip combo should be fine. I just tested this on 2.17:
    p50.flow_rate.aspirate = 1.23456
    p50.aspirate(50, plate['A1'])

which simulates as Aspirating 50.0 uL from A1 of NEST 96 Well Plate 200 µL Flat on slot A1 at 1.23456 uL/sec

There are a few e2e test errors. But the changes look to me.

@koji oops good catch! i didn't notice


Do not require registers to be passed to GPIO configuration functions

ref: #37

For anyone curious like me, the generated assembly looks like this (building the toggle.rs example while having into_push_pull_output() annotated with #[inline(never)]):
Old Version (231c9592508d85d72e4f54b5f408d42546184ea4)
08000d8a <stm32f3xx_hal::gpio::Pin<Gpio,Index,Mode>::into_push_pull_output::h647ca225cf9e2a43>:
 8000d8a:	f241 0000 	movw	r0, #4096	; 0x1000
 8000d8e:	2201      	movs	r2, #1
 8000d90:	f6c4 0000 	movt	r0, #18432	; 0x4800
 8000d94:	6801      	ldr	r1, [r0, #0]
 8000d96:	f362 619b 	bfi	r1, r2, #26, #2
 8000d9a:	6001      	str	r1, [r0, #0]
 8000d9c:	6841      	ldr	r1, [r0, #4]
 8000d9e:	f421 5100 	bic.w	r1, r1, #8192	; 0x2000
 8000da2:	6041      	str	r1, [r0, #4]
 8000da4:	4770      	bx	lr

New Version (6aba91b76ca13559f77e913ba5b9edd1c281bcf2)
08000d8a <stm32f3xx_hal::gpio::Pin<Gpio,Index,Mode>::into_push_pull_output::h5da17e05f75fc27c>:
 8000d8a:	b5d0      	push	{r4, r6, r7, lr}
 8000d8c:	af02      	add	r7, sp, #8
 8000d8e:	f241 0400 	movw	r4, #4096	; 0x1000
 8000d92:	f44f 5100 	mov.w	r1, #8192	; 0x2000
 8000d96:	f6c4 0400 	movt	r4, #18432	; 0x4800
 8000d9a:	1d20      	adds	r0, r4, #4
 8000d9c:	2200      	movs	r2, #0
 8000d9e:	f000 f809 	bl	8000db4 <volatile_atomic_bic_or>
 8000da2:	4620      	mov	r0, r4
 8000da4:	f04f 6140 	mov.w	r1, #201326592	; 0xc000000
 8000da8:	f04f 6280 	mov.w	r2, #67108864	; 0x4000000
 8000dac:	e8bd 40d0 	ldmia.w	sp!, {r4, r6, r7, lr}
 8000db0:	f000 b800 	b.w	8000db4 <volatile_atomic_bic_or>

08000db4 <volatile_atomic_bic_or>:
 8000db4:	e850 3f00 	ldrex	r3, [r0]
 8000db8:	438b      	bics	r3, r1
 8000dba:	4313      	orrs	r3, r2
 8000dbc:	e840 3300 	strex	r3, r3, [r0]
 8000dc0:	2b00      	cmp	r3, #0
 8000dc2:	d1f7      	bne.n	8000db4 <volatile_atomic_bic_or>
 8000dc4:	4770      	bx	lr

With a critical-section
Just for fun I also added a critical section to the function (the version from the master branch) to see how this would look in comparison (not a full implementation of the concept):
08000d8a <stm32f3xx_hal::gpio::Pin<Gpio,Index,Mode>::into_push_pull_output::h647ca225cf9e2a43>:
 8000d8a:	b5d0      	push	{r4, r6, r7, lr}
 8000d8c:	af02      	add	r7, sp, #8
 8000d8e:	f000 f825 	bl	8000ddc <__primask_r>
 8000d92:	4604      	mov	r4, r0
 8000d94:	f000 f818 	bl	8000dc8 <__cpsid>
 8000d98:	f241 0000 	movw	r0, #4096	; 0x1000
 8000d9c:	2201      	movs	r2, #1
 8000d9e:	f6c4 0000 	movt	r0, #18432	; 0x4800
 8000da2:	6801      	ldr	r1, [r0, #0]
 8000da4:	f362 619b 	bfi	r1, r2, #26, #2
 8000da8:	6001      	str	r1, [r0, #0]
 8000daa:	6841      	ldr	r1, [r0, #4]
 8000dac:	f421 5100 	bic.w	r1, r1, #8192	; 0x2000
 8000db0:	6041      	str	r1, [r0, #4]
 8000db2:	07e0      	lsls	r0, r4, #31
 8000db4:	bf18      	it	ne
 8000db6:	bdd0      	popne	{r4, r6, r7, pc}
 8000db8:	e8bd 40d0 	ldmia.w	sp!, {r4, r6, r7, lr}
 8000dbc:	f000 b806 	b.w	8000dcc <__cpsie>

08000dc8 <__cpsid>:
 8000dc8:	b672      	cpsid	i
 8000dca:	4770      	bx	lr

08000dcc <__cpsie>:
 8000dcc:	b662      	cpsie	i
 8000dce:	4770      	bx	lr

08000ddc <__primask_r>:
 8000ddc:	f3ef 8010 	mrs	r0, PRIMASK
 8000de0:	4770      	bx	lr

The source diff
diff --git a/src/gpio.rs b/src/gpio.rs
index 0cfdac95e670..d15c5b9eeeaa 100644
--- a/src/gpio.rs
+++ b/src/gpio.rs
@@ -395,14 +395,17 @@ where
     }

     /// Configures the pin to operate as a push-pull output pin
+    #[inline(never)]
     pub fn into_push_pull_output(
         self,
         moder: &mut Gpio::MODER,
         otyper: &mut Gpio::OTYPER,
     ) -> Pin<Gpio, Index, Output<PushPull>> {
-        moder.output(self.index.index());
-        otyper.push_pull(self.index.index());
-        self.into_mode()
+        cortex_m::interrupt::free(|_cs| {
+            moder.output(self.index.index());
+            otyper.push_pull(self.index.index());
+            self.into_mode()
+        })
     }

     /// Configures the pin to operate as an open-drain output pin

I hope this provides some insight into how the different approaches compare.  It would be interesting to calculate the WCET as well (for the code where that is possible).

They were a bit of chatting around how to test this, before applying these ergonomic improvements overall in the embedded-hal meeting ~ a month ago: https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$J63pKvA9WeSSGtQZQkqFKH-xzk0gXfjEJIIDEAvjRmU?via=matrix.org&via=privacytools.io&via=mozilla.org
I have not given it much thought since then, but maybe someone has some ideas.
I want to push https://github.com/stm32-rs/stm32f3xx-hal/pull/212 a bit forward, to have a better reference point. Maybe I'll find some time this week to add a few more (hopefully all relevant gpio tests).

#212 is now merged and v0.7.0 is released. This would introduce a major, but really wanted change. I would be more confident, that we write some tests for this change, so that we can be more confident, that this is really working (and also atomic and concurrency safe)

Updated to prepare asm! stabilization in 1.59.

I haven't looked into this PR in a while, but it seems this is a huge improvement on ergonomics. Also, I have not followed up on any benchmark proposal, we should do before merging this, but in any case, let's push this forward, when 1.59 is released!

Hey, this is conflicting with #316 with will probably will introduce much work on this PR again.
I just wanted to ask if you have time to adjust to these changes. I'm willing to pick this up if I find time myself if that's okay for you :)


Support driver models with read paths (e.g. Dropbox or Google Drive)

It would be nice to be able to support some drivers with more complex requirements (i.e., because the storage provider doesn't provide the ability to pre-determine the URL for a file).
These drivers would require that the gaia hub be invoked on the read path -- so if we want to support something like this, we need a "read-path" gaia driver type. For this spec, I'd propose a get endpoint:
GET /read/

Which will return the data (or, in an ideal world, a 301, but I think that these kinds of backends wouldn't typically have CORS headers set).

@kantai mind providing a quick update here on the work (ongoing or otherwise), and perhaps the proposed driver model and API?
Also, I've added this to the "Expand storage driver support" project but see @jcnelson also added it earlier to "User-selectable Gaia Storage". My sense is that it's not exactly required to support user-selectable storage, is it?

This is more closely aligned with "Expand storage driver support."

Yep -- this is more in the "expand storage driver support", which may ultimately play a part in making running a gaia hub more user-friendly.


Fix image test image2d_from_buffer_positive

This test is failing in case when extensions cl_ext_image_requirements_info is not supported and cl_khr_image2d_from_buffer is supported. In function get_image_requirement_alignment there is macro run GET_EXTENSION_FUNC with function clGetImageRequirementsInfoEXT. Then test should check if extension cl_ext_image_requirements_info is supported

This change looks reasonable. We would like to test and confirm.

Merging as discussed in the October 11th teleconference.


Migrated SettingsBase to OwlCore.Storage

Before we can merge this, we need to fix our CI. OwlCore.Remoting uses Fody, which can only be compiled by MSBuild on Windows. Further, the tests can be very flaky on certain machines.
We'll be splitting OwlCore.Remoting (and maybe a few others) into separate packages, and turning OwlCore into a meta-package of sorts.
Then we can merge this and make a release.


runtime chunk content is different from build to build, but source code has not changed

Bug report

What is the current behavior?
When I run two builds from the same git commit hash on different linux machines - it provides me almost the same output, except runtime chunk
Example:
// first run on machine_1 in CI
runtime.29356d8efe45cd19.bundle.ru.js
metrika.6dc696f23ae55bfc.bundle.css
metrika.94f2d9bc1bb519d8.bundle.ru.js
vendor.8c9ddbe5319ab05b.bundle.css
vendor.661550bb09edd434.bundle.ru.js
touch.39e720bafce5952c.bundle.css
touch.4c907c11d1c25525.bundle.ru.js

// second run on machine_2 in CI
runtime.af9dee425cfdb58c.bundle.ru.js
metrika.6dc696f23ae55bfc.bundle.css
metrika.94f2d9bc1bb519d8.bundle.ru.js
vendor.8c9ddbe5319ab05b.bundle.css
vendor.661550bb09edd434.bundle.ru.js
touch.39e720bafce5952c.bundle.css
touch.4c907c11d1c25525.bundle.ru.js

As you can see, all hashes are the same, except runtime.
But they don't differ significantly:
https://www.diffchecker.com/Szw487ot
just two variables swap their names - l to f and f to l
If the current behavior is a bug, please provide the steps to reproduce.
config:
{
    mode: 'production',
    optimization: {
        runtimeChunk: 'single',
        removeAvailableModules: true,
        minimizer: [
            new TerserPlugin({
                terserOptions: {
                    format: {
                        comments: false,
                    },
                },
                extractComments: false,
            }),
        ],
    },
}

What is the expected behavior?
content should be equal from build to build

Other relevant information:
webpack version:  5.10.3
Node.js version: 12.19.0
Operating System:
Additional tools:

webpack-cli: 4.2.0
terser-webpack-plugin: 5.0.3, the same as in webpack

I realize that if I change config to:
{
    mode: 'production',
    optimization: {
        runtimeChunk: 'single',
        removeAvailableModules: true,
        minimizer: [
            new TerserPlugin({
-                terserOptions: {
-                    format: {
-                        comments: false,
-                    },
-                },
                extractComments: false,
            }),
        ],
    },
}

All works fine...

I guess the real content hashing hides the real problem. Could you set optimization.realContentHash: false and compare it again.

And maybe also try with minimizing disable optimization.minimize: false

Also check you don't have other minimizers or maybe you have minimizer inside plugins

I guess the real content hashing hides the real problem. Could you set optimization.realContentHash: false and compare it again.

I will try, but I compare real files:

But they don't differ significantly:
https://www.diffchecker.com/Szw487ot
just two variables swap their names - l to f and f to l

@rifler if you can create reproducible test repo, I can look at the problem

if my assumption turns out to be true, there will be more differences then. I think even the filenames of the css files differ

You are right, with disabled realContentHash and minimize there are more differences - all in css files. But content of that files are the same.
We use array of configs (for each lang) and I realize, that we are instantiating Terser and MiniCssExtractPlugin once for all configs instead of instantiating for each config separately.
But after fixing it nothing changes - css hashes still were different.
After that I update mini-css-extract-plugin from 1.3.6 to 1.3.9 and it looks like everything has been fixed. I think it was fixed in https://github.com/webpack-contrib/mini-css-extract-plugin/issues/701

Still facing issue, but instead of css files I am seeing diff in chunk names.
Have disabled minimize and realContentHash.
If I enable both of them, I only see the runtimeChunk hash changing.
Can you guide me as to what might be causing this issue ?
Webpack version: 5.74.0
Additional information: Using NextJs framework inside a monorepo.

@saurishkar Only js files wash changed? can you look at content, it was changed (and what is changed)?

@alexander-akait Yes, only js chunks' hashes got changed even though there were no changes in code.
Also, this is random. If I trigger the build again for the same commit on the same system, the hashes get changed for different chunks so the chunks that are being modified is not consistent as well.

@saurishkar sounds weird, do you have the latest version of NextJs? Maybe a bug on their side...

@alexander-akait I am using Next 12.3.4.
On further debugging, I found out that the chunks which were getting modified was due to the sourcemapUrl being updated at the last of that file 🤦🏽♂
So, looks like the sourcemapping is modifying the file causing the webpack chunk to eventually change.
I disabled the sourcemaps to check if it changes anything but surprisingly the hash id's still gets modified on successive builds.
When I dived in deeper to check the actual content, this time to another surprise, I found them to be identical !
😄
It seems weird why the hash ids will be changing even though the content now is identical 🤔
Any suggestions ?

I think I will have to check with NextJs team as well as when I downgrade Next to 12.1.0, this problem seems to go away 🥲

@saurishkar

It seems weird why the hash ids will be changing even though the content now is identical thinking
Any suggestions ?
I think I will have to check with NextJs team as well as when I downgrade Next to 12.1.0, this problem seems to go away smiling_face_with_tear

Yeah, sounds like a bug in NextJs, without code hard to say what is wrong, I think better to open an issue in NextJs repo

On further debugging, I found out that the chunks which were getting modified was due to the sourcemapUrl being updated at the last of that file 🤦🏽♂

Just idea, do you have extra \n (\r\n) after sourcemapUrl (try to use hex editor to see all character)

Just idea, do you have extra \n (\r\n) after sourcemapUrl (try to use hex editor to see all character)

Sure, will try to check this out.

@saurishkar
did you find the source of the problem?

@romanlex Unfortunately I wasn't able to exactly pinpoint but it was something to do with the loaders being used in webpack.
I overcame this by keeping a single consistent build across my multi server deploys and uploading the build assets on a external storage like s3 so that even if the hashId changes, the information is not lost for the older files.


0.5.16

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)
[x] 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.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin rerender

@conda-forge-admin rerender

@conda-forge-admin rerender

ok @joezuntz I'll leave the rest to you. You are back to a normalish compile error.

Thanks so much for all your work on this @beckermr!


<Lottie/Lottie.h> not found for ios

i want to run my project for xcode but it tell me  Lottie/Lottie.h' file not found    help me ? thank
lottie-react-native": "^2.5.0"
"react-native": "0.53.3",

Can you try uninstalling and reinstalling Lottie again? I would follow this process:
unlink lottie-ios
unlink lottie-react-native
clean the build
clean the build folder
close XCode
remove node modules
reinstall node modules
relink the 2 lotties

thank you，I'll try it

@xmw1992 Are you using XCode beta?


Opacity keyframe error

When adding opacity keyframes starting with zero and repeating another zero, opacity always starts with 1 on play

I will try to test it.

i found a problem.

Where?

opacity is not zero. it is undefined.
i will fix it.

Thanks

I believe the same thing happens with rotation

I would like to collaborate, how to proceed?

@danielmalencar
I have a plan for collaborate system.
I am preparing to apply CRDT Sytem that is Yorkie(https://github.com/yorkie-team/yorkie)
So I am refactoring editor command  for collaborate system.

@danielmalencar
Currently, the editor is making it alone.
I am trying to make a function that can go to simultaneous editing by applying the CRDT system internally.
I am currently refactoring for that.
Do you have any features you want in the editor?

I would just like you to leave the timeline working 100%, first of all

There is an error in the timeline when adding a rotate keyframe

@danielmalencar
I fixed a rotate issue.
Please test it.
Thank you.

Now its works. Thank you

When adding opacity keyframes starting with zero and repeating another zero, opacity always starts with 1 on play

But this problem with opacity remains

@danielmalencar
There was a bug in css output. Thanks for letting me know
I fixed it now, so try again

Now it's working. But why the bug tag? What's not working?

It's just a sign that you fixed the bug. Do not worry too much. ^^


'add-podeauthaccess' is not recognized as a name of a cmdlet

Describe the Bug
Add-PodeAuthAccess is missing from module
Steps To Reproduce
import-module pode
get-command add-podeauthaccess
Get-Command: The term 'add-podeauthaccess' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Expected Behavior
Add-PodeAuthAccess should be present in Pode 2.9.0
Screenshots
If applicable, add screenshots to help explain your problem.
Platform

OS: Windows 10
Browser: n/a
Versions:

Pode: 2.9.0
PowerShell: 7.3.9

Additional Context
I'm sure I must be missing something... I used Pode a few years ago but am struggling to set up authorization in IIS by following the new documentation as it looks like one or more functions are missing.
Pode was installed from PowerShell Gallery but I have also tried downloading the latest release from Github and importing the module directly (both show as version 2.9.0)

Hi @goldpaint,
The method you're after is Add-PodeAccess, where are you seeing it as Add-PodeAuthAccess? 🤔

Hi @Badgerati
I now can't find where I got this from! Very confusing.
I did find a mention of it here - https://github.com/Badgerati/Pode/issues/992#issuecomment-1678004748 - but I guess it must have changed since.
Can only assume I stumbled upon some old documentation somewhere but can't for the life of me find it now.
Apologies for wasting your time and thanks for pointing me in the right direction - everything is working perfectly now using Add-PodeAccess


[Docs]: Improve documentation for possible table structures

Similar Issues

[X] Before filing, I have searched for similar issues.

Description
There's a few different table structures that are accepted now. In particular, keymaps accept several different structures. They're all documented, but not super well. I see two main problems.

The documentation that is there is too wordy. We need cold hard API documentation, with types. Honestly I'm considering rewriting parts in Teal so I can add static types and use a documentation generator for this.

There needs to be a brief overview of the power of what you can do with legendary.nvim closer to the top of the README.md

@tsyroid @olimorris thoughts and input always appreciated.

Probably also separate docs for table structures vs. helper functions, currently they're kinda both covered in the same section.

Mat (et al),
Thanks for including me in this dialogue.
I’ll respond to this request for comment, but it’ll take me a day or two.
I’m currently neck-deep in converting all my existing keymaps to legendary
format. Wish I had caught this wave earlier, but it was clearly not to be.
But hopefully I’ll be  able to offer some transitory feedback in the
meantime…
Once I’m “there” (functional), I’ll go back over the existing documentation
and help where I can.
Best,
/tom
On Apr 5, 2022 at 17:01:17, Mat Jones @.***> wrote:

Probably also separate docs for table structures vs. helper functions,
currently they're kinda both covered in the same section.
—
Reply to this email directly, view it on GitHub
https://github.com/mrjones2014/legendary.nvim/issues/106#issuecomment-1089547460,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGTYGURNXQZMNS2FGP3VTLVDTH43ANCNFSM5SUHTFWA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Teal type definitions for the vim global: https://github.com/teal-language/teal-types/tree/master/types/neovim

Now that we've got Teal types, we should look into a way to auto-generate some stuff from the Teal types. The Teal types are more accurate than the existing annotations were.

Define “some stuff” :smirk:
No, let’s back up a peg. What kinda functionality do you want to add to
Legendary that is not yet present?
(With the above in hand, “some stuff” will should magically unveil
itself to me)
On Apr 11, 2022 at 09:38:15, Mat Jones @.***> wrote:

Now that we've got Teal types, we should look into a way to auto-generate
some stuff from the Teal types. The Teal types are more accurate than the
existing annotations were.
—
Reply to this email directly, view it on GitHub
https://github.com/mrjones2014/legendary.nvim/issues/106#issuecomment-1095284350,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGTYGTWV4QDMWPT2DKM23LVERIPPANCNFSM5SUHTFWA
.
You are receiving this because you were mentioned.Message ID:
@.***>

What I want ideally is for the table structures to be "self-documenting", that is, when the Teal types change, it auto-generates new documentation on the table structures for each type. Basically the whole "Table Structures" section of the README.md can/should be "self-documenting" from the Teal types.
I'm not sure what kind of type information compiled Teal gives at runtime, if it gives the record definition we could use Lua to generate the docs, if not we'll have to build in some functionality to Teal somehow or parse the Teal source.

TJ has a project with a Lua docgen module 👀
https://github.com/tjdevries/tree-sitter-lua/tree/master/lua/docgen

Another tool that could help
https://github.com/numToStr/lemmy-help

I’d talk to the author.
If you look at his mini.nvim help file (which I’ve spent a fair amount of
time in), you’ll see he has headers.
https://github.com/echasnovski/mini.nvim/blob/main/doc/mini.txt
On Apr 21, 2022 at 05:44:33, Mat Jones @.***> wrote:

Additionally, ability to add headings (module identifiers) would be nice.

You can install it that way I suppose. Not the way he intended it (I don’t
think). I have in the past simply plucked out the module I needed, dropped
it into lua/modules and called it from init.lua.
Not the point, though. Sorry, I got my turds wisted because I happed to
have the mini.doc open at the time.
Ask the author of lemmy-help (num2Str) if there's an easy way to parse in
headers. I see he doesn’t eat his own dog food though (at least not at this
time); most of his help files for the apps he’s written are  markdown.
On Apr 21, 2022 at 08:15:22, Mat Jones @.***> wrote:

The thing I do not like about mini.nvim is it's basically like 20
different plugins packaged as a single plugin.
—
Reply to this email directly, view it on GitHub
https://github.com/mrjones2014/legendary.nvim/issues/106#issuecomment-1105362602,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGTYGWJ7CQTCHMRWJP3XITVGFWIVANCNFSM5SUHTFWA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yup we're chatting about it in this issue https://github.com/numToStr/lemmy-help/issues/1

That issue's had a PR merged! Going to start on this soon.

Got decent API documentation generation in #140 but I need to figure out how/where to insert them into doc/legendary.txt.

You can view how the docs will be generated by running make api-docs. Currently it just prints the docs to the terminal.

I guess my shortly wasn’t shortly enough.
Just pulled and sync’d. Not there now. My HEAD/master is at 77b7bc3.
Any idea what commit I need to be on to see this? I’d also like to see your
Makefile code for this action.
On Apr 27, 2022 at 06:00:38, Tom Syroid @.***> wrote:

Nice. I’ll have a look shortly.
On Apr 27, 2022 at 05:53:03, Mat Jones @.***> wrote:

You can view how the docs will be generated by running make api-docs.
Currently it just prints the docs to the terminal.
—
Reply to this email directly, view it on GitHub
https://github.com/mrjones2014/legendary.nvim/issues/106#issuecomment-1110963867,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGTYGSQQCC3VCTWDC5Y2VTVHE2C7ANCNFSM5SUHTFWA
.
You are receiving this because you were mentioned.Message ID:
@.***>

You can grab the branch and look at the diff from the PR: https://github.com/mrjones2014/legendary.nvim/pull/140
git checkout matjones/106-improved-docs

Sorry. Found it. Didn’t know you had a branch happening.
On Apr 27, 2022 at 10:57:43, Tom Syroid @.***> wrote:

I guess my shortly wasn’t shortly enough.
Just pulled and sync’d. Not there now. My HEAD/master is at 77b7bc3.
Any idea what commit I need to be on to see this? I’d also like to see
your Makefile code for this action.
On Apr 27, 2022 at 06:00:38, Tom Syroid @.***> wrote:

Nice. I’ll have a look shortly.
On Apr 27, 2022 at 05:53:03, Mat Jones @.***> wrote:

You can view how the docs will be generated by running make api-docs.
Currently it just prints the docs to the terminal.
—
Reply to this email directly, view it on GitHub
https://github.com/mrjones2014/legendary.nvim/issues/106#issuecomment-1110963867,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGTYGSQQCC3VCTWDC5Y2VTVHE2C7ANCNFSM5SUHTFWA
.
 I particularly like how you set things up to test. Makefile ->
output to CLI to see what’s happening.
On Apr 27, 2022 at 11:10:05, Mat Jones @.***> wrote:

You can grab the branch and look at the diff from the PR: #140
https://github.com/mrjones2014/legendary.nvim/pull/140
git checkout matjones/106-improved-docs
—
Reply to this email directly, view it on GitHub
https://github.com/mrjones2014/legendary.nvim/issues/106#issuecomment-1111325661,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGTYGRDTMK5SRSNAX373WDVHF7H3ANCNFSM5SUHTFWA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Note to self: document the issue linked above ☝


Develop

Status
READY
Description
Develop into main

Updated the documentation (imports of credentials)
Updated schemas for config
Added params in GeneratedParams
Updated examples

Impacted Areas in Library
Examples, schemas, documentation

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

28 of 28 (100.0%)  changed or added relevant lines in 6 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.009%) to 96.224%

Totals

Change from base Build<PHONE_NUMBER>:
0.009%

Covered Lines:
1886

Relevant Lines:
1960

💛  - Coveralls


Do not use Google's reCAPTCHA

Having Google's reCAPTACHA on multiple websites is one of the ways google use to track everyone around the web. Would be great to avoid that, there are alternatives.

@locness3 reCAPTCHA is the most prominent, full-featured, versatile, adaptive, and accessible Captcha library available.  You have no evidence that Google is tracking users.  Yes, reCAPTCHA detects if a user has a Google account or not, but by having one in the first place you're giving up a certain amount of privacy.   I understand you're a fan of decentralized tech, and that's fine, but there's no such thing as complete anonymity on the Internet.  Why sacrifice a good UX?  Ideoxan already uses Material Icons hosted on Google's servers.

We use reCAPTCHA solely due to the fact that it was the most prominent, well documented, cheapest, and easiest to use captcha service available at the time. It was suggested by one of our contributors to help mitigate spam. If you have questions regarding your privacy, please see our Privacy Policy and Google reCAPTCHA's Privacy Policy. Information collected, analyzed, or otherwise distributed among 3rd parties is outlined in these documents. While we respect your concern about privacy, this website is focused on programming, not tracking its users.
However, that being said, if you have any other alternatives that are free, easy to use, and is less privacy invasive, then by all means please feel free to offer suggestions.

You have no evidence that Google is tracking users.
I don't completely agree with that.

Though, hCaptcha seems to be a great alternative.

You have no evidence that Google is tracking users.

I don't completely agree with that.
Though, hCaptcha seems to be a great alternative.

I'll take a look at it.

Captchas are no longer used on the new website, so, this is no longer and issue. Cloudflare's reaction to botted requests along with other server-side security measures should be enough to mitigate botted attacks.


Font awesome v5

I was unable to install font awesome v5, and thus override the version of the theme (v4). Either have to find a solution to override it, or directly modify the theme (which is less desirable).

v5.13 is used but the name convention is the one of v4.

https://shiny.rstudio.com/reference/shiny/1.6.0/icon.html
https://stackoverflow.com/questions/55163719/r-shiny-how-to-use-fontawesome-pro-version-with-the-icon-function


Tabs demo from Angular material website doesn't work with ngAnimate 1.4.2

The Tabs Demos displayed on https://material.angularjs.org/latest/#/demo/material.components.tabs are made using v1.3.15 of all angular package. Using 1.4.2 will introduce strange animation during tab switch. The tab content height will transition to 0 during tab-switching and then take back its expected height.
This is the original codepen exemple, but with dependencies upgraded to 1.4.2:
http://codepen.io/anon/pen/waXmMO

hm, still happens with latest snapshot.
/cc @matsko @ThomasBurleson

This appears to be fixed with latest changes in master: https://github.com/angular/material/commit/cc8130cf377e5a353e967d2bacc5bd56d3aef975

Do you happen to know what was the cause of this bug?

Still broken (with lastest master Angular Material and Angular 1.4.3:

Open http://localhost:8080/#/demo/material.components.tabs
Then navigate to Dialogs (clicking on the Dialog demos in SideNav) http://localhost:8080/#/demo/material.components.dialog

This SHA https://github.com/angular/material/commit/31bb1210a6fbb08dafc015a00db4105d7bb60980 appears to resolve this issue. This is a workaround, I believe, to perhaps a subtle issue with ngAnimation.
ngAnimate appears to be transitioning/animating elements regardless of scope.$destroy(). Have not confirmed more yet. Ask @robertmesserle for more details.

@Bebop182 @ThomasBurleson is this issue still relevant? I tried testing against the original but it looks like it works just fine.

Nope, just tested the whole thing, the issue was solved on both side. Tab animation is now properly working with:

Angular-Material 0.10.0 and Angular.js 1.4.4.
Angular-Material 0.10.1 and Angular.js 1.4.2.

P.S. 1.4.5 is out: https://code.angularjs.org/1.4.5/

Use that one instead since it fixes the issues with requestAnimationFrame.


Print correct path in success message

1. Why is this change necessary?
Using the bin/console sw:generate:migrations command displays a different filepath than generated in reality.
2. What does this change do, exactly?
Removes an unnecessary dirname call.
3. Describe each step to reproduce the issue or behaviour.

bin/console sw:ge:migr --plugin Foo bar
See:

   [OK] Generated file
      "/home/vagrant/www/shopware/custom/plugins/Foo/Resources/1-bar.php"

git status
See:

On branch 5.6
Your branch is up-to-date with 'origin/5.6'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        custom/plugins/Foo/Resources/migrations/1-bar.php

Alternative Route

bin/console sw:ge:migr bar
See:

   [OK] Generated file
      "/home/vagrant/www/shopware/_sql/1337-bar.php"

git status
See:

On branch 5.6
Your branch is up-to-date with 'origin/5.6'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        _sql/migrations/1337-bar.php

4. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/SW-23956
Please use this issue to track the state of your pull request.

Thanks for your contribution! :blue_heart:


⚠ Jenkins Plugins Artifactory has degraded performance

In 3a98326, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1296 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 5c12d56 after 25 minutes.


Path resolution for browser style import

There are some use cases that use tsc to emit ESModule that runs in the browser directly. Currently, TypeScript is not friendly to browser style import environment like browser and deno.
There are some main problems when using TypeScript in those environments:

[ ] 1. Import .ts, .tsx file is a type error (PR: #35148)
[ ] 2. Emitted code does not contain the .js extension name (PR: #35148)
[ ] 3. Can not emit file with .mjs extension name (PR: #35148)
[ ] 4. Can not handle the type resolution for URL import finely
[x] 5. Should treat folder import (import './src' => import './src/index.ts') as type error in some environments
[ ] 6. Should treat import without extension name (import './src' => import './src.ts') as type error in some environments

1. Import .ts, .tsx file is a type error
Related issues: #30076
This happens in the deno. Deno will not try to resolve implicit extension name when handling imports.
import "./file";

This import is invalid for deno and browser.
In browser we have to write import "./file.js"; which is valid in the type checker.
In deno we have to write import "./file.ts"; which is invalid in the type checker. TypeScript reports An import path cannot end with a '.ts' extension. Consider importing './file' instead
#35148 introduce a change that importing a .ts or a .tsx file is no longer a type error. Importing .d.ts is still a type error.
2. Emitted code does not contain the .js extension name
Related issues: #16577, #30076
When tsc is used to emit ESModule for browsers, the extname is not added. Now one can write import './file.js' to refer to file.ts, that behavior is strange in the semantic.
#35148 introduce a new compilerOption called --emitExtension. With this option, TypeScript will replace the .ts or .tsx extension name for relative imports.
import "./file";
import "./file2.ts";
import "./file3.tsx";
// with --emitExtension .mjs
// result to
import "./file";
import "./file2.mjs";
import "./file3.mjs";

3. Can not emit file with .mjs extension name
Related issues: #30076, #18442
In Node.js, there is a discussion about how to migrate to ES Module, a solution requires all ES Module files have to have a .mjs extname. There is no way to emit such code by tsc now.
#35148 introduce a new compilerOption called --emitExtension. With this option, TypeScript will emit the code with the specified extension name.
There are lots of different solutions that requires different extension name for js file like .es, .mjs, .es.js so TypeScript maybe should not restrict the possible value of --emitExtension with a enum.

--emitExtension must start with . and can not be .d.ts

when using --jsx preserve, --emitExtension must be .jsx

src
    index.ts
    index2.ts
    index3.ts
# with --emitExtension .mjs
# will emit
dist
    index.mjs
    index2.mjs
    index3.mjs

4. Can not handle the type resolution for URL import finely
Related issues: #28985, #19942
In browser and deno, import from a "package" is different from the node style.
// browser
import lodash from<EMAIL_ADDRESS>
// deno
import { serve } from<EMAIL_ADDRESS>
Currently there is no way to let TypeScript automatically map the URL to another place like @types/* or $DENO_DIR/deps/https/deno.land/*
The current path can map a simple pattern of import module specifier to another place, but in the URL style import, a more flexible way to map the URL is required.
Proposal
(maybe add a new moduleResolution: browser)
Add a new urlPaths that allows to map from a RegExp to a local path. It will NOT effect the emitted code. Just a way to find the type definition for those URLs.
Example:
{
  "compilerOptions": {
    "urlPaths": {
      "https://unpkg.com/(.+?)@.+?/.+": "./node_modules/@types/$1",
      "https://deno.land/(.+?)@v.+?/(.+?)/(.+)": "$DENO_DIR/deps/https/deno.land/*"
    }
  }
}

This rule map<EMAIL_ADDRESS>to @types/lodash-es
Map<EMAIL_ADDRESS>to $DENO_DIR/deps/https/deno.land/std/http/server.ts.
$DENO_DIR is an environment variable.
By default, on Windows, it's ~\AppData\Local\deno\deps\https\deno.land\std\http\server.ts.
By default on Linux, it is ~/.deno/deps/https/deno.land/std/http/server.ts.
5. Should treat folder import (import './src' => import './src/index.ts') as type error in some environments
*: Folder import is supported only in moduleResolution: node
The folder import is only supported in Node.js and some bundle tool, browsers and deno doesn't support it.
Proposal
Add a flag --noFolderImport to ban the folder import.
6. Should treat import without extension name (import './src' => import './src.ts') as type error in some environments
The implicit extension name is only supported in Node.js and some bundle tool, browsers and deno doesn't support it.
Proposal
Add a flag --noImplicitExtensionName to ban the implicit import.

There are 6 problems when tsc is used with browser native ESModule or deno. The first one to the third one is fixed by #35148.
I have interest to do the 4 to 6. But I should make sure TypeScript team will accept those.

Also there is no way to configure auto-import to always prepend '/' to absolute path.
This import(which VSCode produces) is not supported in browsers:
import {utils} from 'utils.js'
this is supported:
import {utils} from '/utils.js'

Also there is no way to configure auto-import to always prepend '/' to absolute path.
This import(which VSCode produces) is not supported in browsers:
import {utils} from 'utils.js'
this is supported:
import {utils} from '/utils.js'

Relative import may be enough

.mjs is a second-class citizen now.  Node.js 13.2 just released with unflagged module support and it's possible to enable ESM package-wide by using "type": "module" in its package.json.  No need for .mjs.
But that said... extensionless imports are a problem.  That issue used to just be limited to the browser (and deno), but the default mode in Node 13.2 turns out to be to require the extension for all file-based imports.  --emitExtension looks like just what the doctor ordered for that, but it should probably also add the extension for imports without one, too.  Otherwise life is about to get a lot harder for TS devs once ESM in Node starts really taking off.
https://nodejs.org/api/esm.html#esm_customizing_esm_specifier_resolution_algorithm

I think the default behavior of TSC should be to emit valid JavaScript.  At the moment, especially with the NodeJS 13.2 change, TypeScript will emit invalid JavaScript by default.
// valid typescript
import { Foo } from './foo'
new Foo()
// emitted javascript
import { Foo } from './foo'; // invalid in browser and NodeJS!
new Foo();

// invalid typescript
import { Foo } from './foo.ts' // invalid in TS
new Foo()
// emitted javascript
import { Foo } from './foo.ts'; // invalid in browser and NodeJS!
new Foo();

If the user is targeting ES modules, an extension should be included by default.  Otherwise, the default behavior of TSC will be to generate invalid JS which goes against the ethos of TypeScript.

Relevant reading: https://github.com/microsoft/TypeScript/issues/35589


[Feature Request] Allow response viewer plugins to interact with insomnia engine

The idea is to create a way for a response viewer plugin to interact with insomnia engine and be able to generate request, populate request body or headers.
I initially thought about creating plugins for hypermedia formats where the current request caries information about how to perform subsequent interaction. The HAL format, for example, has a defined link attribute indicating navigation possibilities from current resource and the HAL forms format deliver a structure of the body that should  be submitted.

@gschier I create a simple POC in my fork (https://github.com/osvaldopina/insomnia in feature/plugin-response-viewer-api) and a test plugin (https://github.com/osvaldopina/ResponseViewerTestPlugin, https://www.npmjs.com/package/response-viewer-test-plugin) that renders a react component that allow the user to change the request url, method and send a request. The goal is just to show a possible path to extend the insomnia plugins by allowing them to not only render specific media type but to interact with the insomnia engine.

Thanks @osvaldopina! Sorry I haven't been very active on this issue. I will dedicate some time to look at your fork today.

@osvaldopina I just took a look. I like it. I think it doesn't add much but it will allow people like yourself to at least start heading down the right path (like you said).
I really want to get the custom response viewer API into the app soon (hopefully the next release). I think it can probably be merged in it's current state, even if it's not fully complete.


Make it work with current version of npm audit

@wilgert Thanks for the PR.
I was thinking let's use npm audit --json and use the json to find this.
That will be much simpler and avoid future breakages like this.

That's indeed a better approach. Shall I implement it and create a new PR or do you want to do it yourself?

@wilgert Please go ahead and implement.
I am happy to merge and do a release.

This one can be closed as i have created a separate PR: #7


Improve text in "Summary" step of single publication/dataset workflow

Describe the improvement
Replace "Next steps" with "Are you ready to publish?"
When you are not ready to publish, you can save your dataset/publication as draft using the "Save as draft" button and continue later from Overview page. Alternatively, you can click on one of the sections below to complete your submission.
When you are ready to publish, click the "Publish to Biblio" button. Your dataset/publication will be available in Biblio. The dataset/publication will undergo a bibliographic review process by the Biblio team. A reviewer of the Biblio team will contact you in case any changes are needed.

add message that they should not forget to add full text, access level, author membership, etc?


Make base and TypeScript templates consistent

Adding changes to the TypeScript template to be consistent with the base JavaScript template.

Thanks!

No problem!

I think we definitely need to look into how to manage this better in future, thanks all.


Utilize "prefers-color-scheme" to set default theme

Many users set their light/dark mode theme in their operating system.
By using prefers-color-scheme, we can set the default site theme to match with the expected theme.
Windows 10/11, macOS, Android, iOS, and many Linux distributions all support this functionality

Oh, apologies - it seems that this is currently supported on first page load. However, on subsequent page refreshes (even if manually not set), it doesn't change.
Might be nice to have detection to see if manually set or not


Let base be stretchable in width to accommodate wide attachments

Looking at the new reference image, it may be that this is actually only desirable for a subset of symbols. For arrows it seems very sensible, but for = it looks weird.
cc: @Enivex due to https://github.com/typst/typst/issues/1304#issuecomment-1723261507

Looking at the new reference image, it may be that this is actually only desirable for a subset of symbols. For arrows it seems very sensible, but for = it looks weird.
cc: @Enivex due to #1304 (comment)

I'd argue that this should be opt-in regardless. Perhaps through something like stretch().

@laurmaedje Introduced stretch(); please see the reference images.

@mkorje Thanks for the review!

I'm not sure if there exists any glyph that have both horizontal and vertical variants, which would cause problems then.

I can't really think of a glyph where that would make sense. I feel like the hstretch/vstretch naming doesn't feel Typst-y, so I'd prefer to avoid it.

Me neither, though I guess there's nothing stopping a font from including such things for a glyph. It wouldn't hurt then to have an axis parameter (or something like that) which is auto, just in case (but this is probably overkill).
And yeah I agree that it isn't very Typst like. Adding the word horizontal or vertical felt too verbose and I couldn't think of a nice shortening of both words.

Is there anything blocking this?

Hi - I became a bit busy recently so I'm fine with someone taking this work and create a new PR (hence the drop in my recent PR counts). I could come back to this later if that's not already done. Also, is a 0.12 release imminent?

I'd be happy to continue on this PR's work. It'd be nice to get this into 0.12.

Closing in favor of https://github.com/typst/typst/pull/5030. Thanks all!


decimal formatting fixes #12345

Q
A

Is bugfix?
yes

New feature?
no

Breaks BC?
no

Tests pass?
yes

Fixed issues
#12345

Merged, thank you!


Provide Ecto.Repo.prepare/2

It will be called with query + options, allowing developers to customize queries before they are sent to the repository. For example, one can use this for setting up a query prefix based on some configuration, before reaching the database.
@Dania02525 and @reset would this be useful in your experience with prefixes? /cc @Tica2

@josevalim yes, this is something that I've implemented myself as a nice way to interact with setting prefixes

Anything we can do to make prefixing easier I'm all for.  The current incarnation works but is a bit clunky IMO. Are you thinking this would replace something like this:
results = Model
      |> Ecto.Queryable.to_query
      |> Map.put(:prefix, "foo")
      |> Repo.all

With something like this:
results = Repo.prepare(Model, prefix: :foo) |> Repo.all

?

@Dania02525 There are a couple ways we could leverage it.

The first one is by passing it as an option:
defmodule MyRepo do
  use Ecto.Repo

  def prepare(query, opts) do
    %{prefix: prefix} = query = Ecto.Queryable.to_query(query)
    %{query | prefix: prefix || opts[:prefix]}
  end
end

And use it as:
Repo.all query, prefix: "foo"

We could automatically load it behind the scenes:
defmodule MyRepo do
  use Ecto.Repo

  def prepare(query, opts) do
    %{prefix: prefix} = query = Ecto.Queryable.to_query(query)
    %{query | prefix: prefix || Apartmentex.prefix_or_raise!}
  end
end

And use it as:
Repo.all query

If we think 1. is enough then we don't even need prepare/2. We can support the option directly in Ecto.

I kinda prefer the first one as its a little more explicit, even if a little repetitive in some use cases.  What do you think @reset @Tica2 ?

If in Model we have prefix: then we need a way to change.
If we replace "tentant" prefix with "tentant_999" this is valabil for all models that use "tentant" prefix.
This mean I need a way to say on global to do that. In repo module or conf:
tentant: &Multitenancy.current/0

Second problem to solve is a way to add dinamic repo (add dinamic database).
If new client create account+domain, app create new database and client is ready to
use the app, no need to define new Repo.
Look like a pool of repos.
Thinking ...
Easy here,  I will come back with code examples ...

@Tica2 prepare/2 would allow you to use something global. I don't want to have something global with Ecto out of the box because it is somehow a bad practice. But I want developers that know what they are doing to be able to achieve it. The question is: is global really necessary?

@josevalim In your next example what is opts ?
we have a lot of functions: Repo.all/2 Repo.one/2 ...
I think, with example with process state we don't need opts.
# Based on domain/prefix/user find tenant
Multitenancy.set_current(tenant)

defmodule MyRepo do
  use Ecto.Repo

  def prepare(query, opts) do
    query
     |> Ecto.Queryable.to_query
     |> build_prefix(Multitenancy.get_current)
  end
end

@josevalim for me PERFECT

The options is for other things people may want to extend the query with. :)

I can start working on it ?

Yes, please!


Fix init test failure with updated devfile versions in the staging registry

What type of PR is this:
/kind bug
/area testing

What does this PR do / why we need it:
Due to recent additions of devfile version to the Go devfile stack in the Staging registry, fetch the latest version returns a different value than expected. To avoid test failure due to this, we change the way the version is verified.
This change is causing failures in nightly jobs.
Which issue(s) this PR fixes:

Fixes #
PR acceptance criteria:

[ ] Unit test

[x] Integration test

[ ] Documentation

How to test changes / Special notes to the reviewer:

/close
#6789 offers a better solution.