Purpose of MultiCurve representation of spaces?

What is the purpose of the MultiCurve representation of AbstractSpace in LOD 2 and 3? How would the boundary of such a representation be expressed using AbstractThematicSurface (note that AbstractThematicSurface does not have a point representation)?
Is this meant to model curve-like attachments of a space (like the antennas of a building)? Then I would prefer a dedicated feature type for such attachments with an appropriate geometry representation. And the MultiCurve representations should be removed from AbstractSpace.

The purpose of the MultiCurve representation of AbstractSpace is not exactly as you assume in the second part of your comment. It is meant to model city objects whose geometries typically are geometrically abstracted by curves. Examples would be BuildingInstallations like an antenna of a building or a tree trunk.
Since these things also occupy space in the real world (even if they might be very thin), they need to be semantically modeled as Spaces. However, an appropriate geometry representation could be just a Curve or MultiCurve.
I would agree, that if somebody wants to represent an antenna on a building, it should not just be geometrically added as an additional Curve to the geometric representation of the building space, but should be added as a dedicated BuildingInstallation feature (which then only uses the Curve representation).
It is true that for a Curve representation no dedicated boundary (like a Surface or Point) can be represented. But this is also true for the LOD0 representation of a Space, which could be just a single Point (that also has no boundary).


Remove paragraph element and styles

Fixes

Fixes #125  by @annatuma
Description

This removes paragraph element and all its styles.
It also removes it from the footer stories and definition components.

Type of PR
This PR is a refactor.
Checklist:

[x] My pull request has a descriptive title (not a vague title like "Update index.md").
[x] My pull request targets the master branch of the repository.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.

Legal
By submitting this PR, I agree to abide by the terms of the Developer
Certificate of Origin.

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

@chidexebere can you also delete the corresponding tests in tests/unit/elements/Paragraph.spec.js?

@chidexebere can you also delete the corresponding tests in tests/unit/elements/Paragraph.spec.js?

done

@chidexebere the Netlify deployment broke. Try running the build:documentation command locally and debugging the build.


Bed file in 2 bedsets - will it work in re-uploading?

What if same bedfile was in encode and geo bedset. Will it add it to both of the bedsets. Investigate it!

If bed file is not rewritten, then it will be added to a new bedset, thereby bedfile can be in few bedsets, and there is no bug. e.g. https://bedbase.org/bed/182fc0fba864921e480107a7488d2ce2


Set Up on Browser

I would like to use this library. How do I set it up to use it on the browser? Do I have to download something?

You need to install it and require it in your JavaScript files:

Install:

npm i aspect.js --save

Require:

import * as aop from 'aspect.js';

// ...

I'm still having an issue, do you think that this is the right way to use it on  the browser?

I'm getting 'unexpected *' as an error

Make sure you are using a tool like Webpack or transpile your code with TypeScript in order to make it work in the browser.

Sorry for disturbing again but how can you bundle a folder with Webpack? All I found were methods to bundle JS files and not folders and for aspect.js I require the whole folder aspect.js.

I would like to use this library for my dissertation and I currently need this asap

I managed to bundle the code into one big Javascript file by using browserify. Then I'm including the bundled file in the html file as a module and I'm getting The requested module does not provide an export named 'default'. Any help would be appreciated


URL bar doesn't work

Typing in the top URL bar produces random copies of text. Regressed during UI refactor.

It was apparently not a regression in UI refactors. Still needs to be fixed or replaced!


[Autocomplete] Add popupIndicator to componentsProps object

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
The Autocomplete prop componentsProps can be used to add props to clearIndicator but not popupIndicator. This should be added to the object to allow for consistency when overriding styles.
Examples 🌈
Implementation should be identical to clearIndicator props override.
Motivation 🔦
We are using MUI as a base for a component library with different designs. We would like to be able to specify size: small for both the clearIndicator and popupIndicator. Due to this inconsistency, we had to manually duplicate the small IconButton styles in the Autocomplete style overrides.

Sounds great, would you like to create a PR for it?


Hide credentials in mount command

This fix changed the API so we hides values of mount options that are credentials.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3289/
Test PASSed.

@gpang PTAL. Thanks!

Thanks @gpang! I replied to the comments and added a test.
I am not aware of other places we leak credentials. Do you have any idea where to look at?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/3417/
Test PASSed.

@bf8086 I am not aware of other leakage, but it is unclear what else uses mount options. Is there a way to make the credentials hidden by default, and have a separate mechanism for getting access to the real values? I'd imagine only a few places really need the credentials (UFS creation, worker)?
I'm wondering what we can do to prevent leaking the values in the future.

@gpang At API level there are 3 APIs expose UFS options: getMountTable, get(Display)MountPointInfo and getUfsInfo. Only getMountTable is exposed in client RPC and is currently used by mount command. get(Display)MountPointInfo is used by web UI. Both APIs are hiding credentials. getUfsInfo is the only API gives the actual credentials but it is only exposed in master-worker RPC interface.
For a more secure solution, we will need to refactor how we store credentials internally and never store it unencrypted. That will help preventing the future leaks. I would still like to get this change in first so we don't have to block 2.0 release on this security concern. I can create a tracking issue for the refactor work.

alluxio-bot, merge this please


Proposal: Versioned build-artifacts/ directory

Proposed Change
Introduce a directory within elm-stuff/build-artifacts/ for the current version of elm-make.
Current Example:
elm-stuff/build-artifacts/elm-lang/core/2.1.0
With Proposed Change:
elm-stuff/build-artifacts/0.15.1/elm-lang/core/2.1.0
Motivation
This would improve two situations.
The first situation is what happens when you upgrade to a new version of elm-make, which is that building the same project yields this error:
Error reading build artifact elm-stuff/build-artifacts/elm-lang/core/2.1.0/Array.elmi
    The file was generated by a previous build and may be outdated or corrupt.
    Please remove the file and try again.

This has the unfortunate consequence of making non-breaking upgrades like 0.15 to 0.15.1 break your build despite being backwards-compatible.
The second situation is when you want to switch back and forth between multiple versions of elm-make on the same system. This can happen when you are in the process of upgrading to a new version of elm-make with breaking changes, but still need to periodically switch back in order to work on your existing production code that is not upgrade-ready yet.
The only real drawback of this proposed change appears to be that it would take up more disk space than the status quo. Of course, if that becomes a problem, you can always delete unused version directories.

Based on the initial discussion of this in https://github.com/elm-lang/elm-make/issues/30 this seems like a nice route to go. It is unclear when I will be able to do this, and the scope of this change is such that it'd make for a nice contribution!

@evancz it looks like you can just update one line?
packagesDirectory =
    stuffDirectory </> "packages" </> V.toString version V.elm

@dnalot It would cost @evancz less time if you actually tried that change to see if that's it. If it is, then you open the pull request and you get the kudos. If it isn't you can look into it more, or drop it.

I followed up on the mailing list. I would've but my environment isn't set up. I.e. I no Haskell.

@rtfeldman Remove the Help Wanted label?

Done!


Adapt cookie banner for GDPR

Check https://github.com/gnosis/safe-react/issues/1715
I couldn't check the behaviour when running it as a desktop app. Could someone check it?
Feel free to update or merge this PR whenever you consider.
Thanks!

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/volta/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/volta/app

@germartinez how is the behavior for existing users? What I mean is the following:
When checking the banner update for the landing page (https://gnosis-safe.io/) I had the following experience:

Before the update: I had previously accepted all cookies
Now the update happened.
The customer support cookie wasn't set, I had to accept it again.

For the landing page that's ok like this I think, however for the web app, would it be possible to make sure that the existing cookie is migrated properly, i.e in case users accepted all cookies before, that both customer support and analytics checkmark/cookies are set?

@germartinez how is the behavior for existing users? What I mean is the following:
When checking the banner update for the landing page (https://gnosis-safe.io/) I had the following experience:

Before the update: I had previously accepted all cookies
Now the update happened.
The customer support cookie wasn't set, I had to accept it again.

For the landing page that's ok like this I think, however for the web app, would it be possible to make sure that the existing cookie is migrated properly, i.e in case users accepted all cookies before, that both customer support and analytics checkmark/cookies are set?

@tschubotz the cookie used has the properties:

"acceptedNecessary": always true if the user accepted the cookie banner at least once in the past
"acceptedAnalytics": the old value will be kept after the update
"acceptedIntercom": false by default after the update (this did not exist before the update), meaning that the banner will be displayed for everyone who wants to use Intercom. It will only be displayed when clicking the fake Intercom button.

I guess you are saying that "acceptedIntercom" should be equal to the old value of "acceptedAnalytics" (which acted as an "accept all" check). However, the same cookie is shared between the landing page and the app and now that the landing page is already deployed, does not make sense to set "acceptedIntercom" with the same value of "acceptedAnalytics". For this a new different cookie should have been created (before the landing page deployment) setting the values depending on the old ones.

@tschubotz the cookie used has the properties:

"acceptedNecessary": always true if the user accepted the cookie banner at least once in the past
"acceptedAnalytics": the old value will be kept after the update
"acceptedIntercom": false by default after the update (this did not exist before the update), meaning that the banner will be displayed for everyone who wants to use Intercom. It will only be displayed when clicking the fake Intercom button.

I guess you are saying that "acceptedIntercom" should be equal to the old value of "acceptedAnalytics" (which acted as an "accept all" check). However, the same cookie is shared between the landing page and the app and now that the landing page is already deployed, does not make sense to set "acceptedIntercom" with the same value of "acceptedAnalytics". For this a new different cookie should have been created (before the landing page deployment) setting the values depending on the old ones.

I guess you are saying that "acceptedIntercom" should be equal to the old value of "acceptedAnalytics" (which acted as an "accept all" check)

exactly

However, the same cookie is shared between the landing page and the app and now that the landing page is already deployed, does not make sense to set "acceptedIntercom" with the same value of "acceptedAnalytics"

So for users that have been on the landing page since the update, I get it, they are "lost". However, what about users that haven't been on the landing page since the update? i.e. they were just on the web app? Would it not make sense to still set acceptedIntercom=acceptedAnalytics so we cover those ones at least?

I guess you are saying that "acceptedIntercom" should be equal to the old value of "acceptedAnalytics" (which acted as an "accept all" check)

exactly

However, the same cookie is shared between the landing page and the app and now that the landing page is already deployed, does not make sense to set "acceptedIntercom" with the same value of "acceptedAnalytics"

So for users that have been on the landing page since the update, I get it, they are "lost". However, what about users that haven't been on the landing page since the update? i.e. they were just on the web app? Would it not make sense to still set acceptedIntercom=acceptedAnalytics so we cover those ones at least?

@tschubotz You are right, those can be covered.
Done

@tschubotz You are right, those can be covered.
Done

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/volta/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/volta/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

It looks good to me.
Accept all creates all cookies
Accepting individual checkboxes just adds the ones you selected
If you don't accept analytics it seems that there is no way to undo that (you never have the option to accept those again)
If you click the intercom icon without accepting the intercom cookies the banner shows up again and a warning message indicates that you must accept the cookie to use the intercom.
The cookies being accepted and added:

If you don't accept analytics it seems that there is no way to undo that (you never have the option to accept those again)

What do you mean there's no way to undo that? While we won't bug users again, they can always go to their cookie preference via the bottom bar. And there they can accept the analytics cookie, right? @francovenica

Ok, bad use of words. What I meant is that for the intercom there is a big red button on the side that will open the popUp with a warning saying that you have to accept the cookies for the intercom, but for analytics there is no obvious button to accept them.
Yes the preferences opens the modal, but at plain sight it doesn't look that the preference button is for that.
Now this opens another can of worms. If you accepted everything the first time, and then you click "preferences" and decide to uncheck everything and accept you can still use the intercom and the GA cookies are still there, so unchecking the checkboxes seems to do nothing.
Check everything the 1st time.
In the console > application > cookies you see the cookies enabled for GA, intercom and the necessary ones
Open preferences
Uncheck everything and click "Accept selection"
Reload the page
The cookies are still there

Ok, bad use of words. What I meant is that for the intercom there is a big red button on the side that will open the popUp with a warning saying that you have to accept the cookies for the intercom, but for analytics there is no obvious button to accept them.
Yes the preferences opens the modal, but at plain sight it doesn't look that the preference button is for that.

Got it, thanks for the explanation. I think that's fine!

Now this opens another can of worms. If you accepted everything the first time, and then you click "preferences" and decide to uncheck everything and accept you can still use the intercom and the GA cookies are still there, so unchecking the checkboxes seems to do nothing.

Hmm, well this sounds like it's not how it's supposed to be. Once the user unchecks the "analytics" check box and hits "Save selection", there should not be any GA tracking happening anymore. Same for Customer support and Intercom cookies.
Or does the tracking still stop and but we just don't have any influence on the cookies?

Or does the tracking still stop and but we just don't have any influence on the cookies?

This is something I thought about, maybe the cookies are still there but not tracking anymore. Still, if the intercom still opens that means that at least that cookie is still working
@germartinez maybe you can give us more insight on this?

Hi, I was following your instructions and there is a bug. Apparently I only tested this:

Open Intercom (not allowed) > Banner opened > Accept all > Open Intercom > OK
Open banner > disabled only Intercom > Accept selection > Open Intercom (not allowed)

This works. However, as you said, it doesn't when disabling all the checkboxes at once. So this does not work:

Open banner > disabled all  > Accept selection > Open Intercom (allowed, but it shouldn't)

In the step number 2, Intercom is shutdown like this: https://github.com/gnosis/safe-react/pull/1814/files#diff-12ffa7be52ce3f2a6eddacfc3e989e9425b05afbbb9707af0fd6a0af50964369R34 and the cookies are removed.

Regarding Google Analytics cookies:
It looks like the value is not updated when the analytics checkbox is enabled or disabled (you can see how the value of the Intercom cookie changes in real time with the dev console opened). However, if you reload the cookie dev panel, it works.
Or if you check the state in the dev console, then close it, enable/disable the analytics and accept, and finally open the console again to check that the value has changed.
For some reason is not updated when you are looking at it.

I've unchecked the cookies in the analytics popUp and tried: reloading the page, reloading just the console, closing/opening the console, and the cookies remain there. Same number, same expiration date....

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

The cookies for the intercom now disappear if uncheck in the preferences panel
The cookies for GA are still there, no matter how much I reload the page or the console. What we should do about this?
Is this snapshot I already uncheck and accepted the selection, reloaded the list of cookies in the console and the page itself.

The cookies for the intercom now disappear if uncheck in the preferences panel

I can confirm. I didn't know I had to reload the cookies.

The cookies for GA are still there

@francovenica Have you tried manually deleting them? And then check if they re-appear? For me the GA cookie doesn't show up at all actually.

This works. However, as you said, it doesn't when disabling all the checkboxes at once. So this does not work:
3. Open banner > disabled all  > Accept selection > Open Intercom > Works (it should not work)

@germartinez for me, in that case Intercom doens't work but the banner is opened again 🤔

What we should do about this?

I mean, the expected behavior is quite clear:

Whenever the customer support box is accepted -> set intercom cookie
Whenever the customer support box is notaccepted -> no intercom cookie
Whenever the analytics box is accepted -> set GA cookie
Whenever the analytics box is not accepted -> no GA cookie

Is it not possible to implement it that way? :)

@tschubotz If you clear the site store then the cookies are out, but is not something that a regular user will do

@tschubotz If you clear the site store then the cookies are out, but is not something that a regular user will do

yea, totally, I was just thinking that the cookie isn't even set anymore upon accepting. That's at least how it is for me. Hence I'm asking whether they reappear for you after manual deletion

@tschubotz when I check this PR I get consistent behaviour with checks except in 1 case.
When you accepted Google Analytics once, and then you change your mind, Google Analytics cookies aren't deleted. The app doesn't send more custom events, but I'm not sure that Google stops fetching other user information

yea, totally, I was just thinking that the cookie isn't even set anymore upon accepting. That's at least how it is for me. Hence I'm asking whether they reappear for you after manual deletion

Ok, I checked again and it no, they don't show up again. The thing is that they won't show up again even if you have the checkbox enabled.
So:
Check the checkbox Analytics and accept selection
Delete the cookies manually
The cookies won't show up even if you reload the page /reload the cookie list in the console

When you accepted Google Analytics once, and then you change your mind, Google Analytics cookies aren't deleted. The app doesn't send more custom events, but I'm not sure that Google stops fetching other user information

hm. I mean we some how tell the GA sdk to stop tracking, right? I guess then that's all we can do for now. The more proper fix would be to not rely on GA anymore in the future ;)

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app

hm. I mean we some how tell the GA sdk to stop tracking, right? I guess then that's all we can do for now. The more proper fix would be to not rely on GA anymore in the future ;)

Before any page or event tracking data is sent to Google, there is a condition checking if the current checkbox is enabled or not. Even if the cookies are still there, if the checkbox is disabled, google won't receive the tracking data.
However:

The app doesn't send more custom events, but I'm not sure that Google stops fetching other user information

The app doesn't send more custom events, but I'm not sure that Google stops fetching other user information

I'm surprised that there is no way to really stop GA from the code. But I mean if that's true, then there's no way for us.
Would something like this work? https://developers.google.com/analytics/devguides/collection/analyticsjs/user-opt-out

As the value added by this PR overcomes the issue with not deleting GA cookies when user tries to uncheck after having accepted at least once and regarding that after this change we programmatically prevent sending events anyway we are going to merge this PR and open a ticket with advanced edge cases

Travis automatic deployment:
https://pr1814--safereact.review.gnosisdev.com/rinkeby/app


Clarify EXTRACT semantics in tests

Need to clarify some of the EXTRACT tests ported from partiql-lang-kotlin related to:

Output type for extracted date/time part values.

partiql-lang-kotlin uses decimals

Default values for extracting date parts from time values (e.g. EXTRACT(YEAR FROM TIME '12:34')) -- NULL, MISSING, or some default

partiql-lang-kotlin defaults to erroring in legacy mode, missing in permissive

Default values for extracting time parts from date parts (e.g. EXTRACT(HOUR FROM DATE '2020-01-01')) -- NULL, MISSING, or some default

partiql-lang-kotlin defaults to 0. in both typing modes

This may also warrant a spec issue.

Regarding 1., Output type for extracted date/time part values the SQL specs have varied descriptions for what type is to be used for extracted values.

SQL:2011 states:
The declared type of <extract expression> is an implementation-defined exact numeric type. If <primary
datetime field> specifies SECOND, then the scale is implementation-defined; otherwise, the scale is
0 (zero).

where an exact numeric type is defined as follows:
The data types NUMERIC, DECIMAL, SMALLINT, INTEGER, and BIGINT are collectively referred
to as exact numeric types.

So from SQL:2011, it appears to be implementation-defined.

SQL:1992 states:
<extract expression> (see Subclause 4.5.3, "Operations involving
            datetimes and intervals") operates on a datetime or interval
            argument and returns an integer.

but later states:
<extract expression> operates on a datetime or interval and returns
         an exact numeric value representing the value of one component of
         the datetime or interval.

and
If <extract expression> is specified, then

            Case:

            a) If <datetime field> does not specify SECOND, then the data
              type of the result is exact numeric with implementation-
              defined precision and scale 0.

            b) Otherwise, the data type of the result is exact numeric
              with implementation-defined precision and scale. The
              implementation-defined scale shall not be less than the spec-
              ified or implied <time fractional seconds precision> or <in-
              terval fractional seconds precision>, as appropriate, of the
              SECOND <datetime field> of the <extract source>.

I'm not sure if PartiQL should define the output type on its own or define it to be an implementation detail. To get around this, we can define the EXTRACT tests to assert on the result in the statement using the PartiQL = operator.
For example a test as follows:
{
  ...
  statement:"EXTRACT(YEAR FROM DATE '2023-04-13')",
  assert:{
    ...
    output:2023
  }
},

could be rewritten to:
{
  ...
  statement:"EXTRACT(YEAR FROM DATE '2023-04-13') = 2023",
  assert:{
    ...
    output:true
  }
},

This is test rewrite is captured in: https://github.com/partiql/partiql-tests/pull/84.

Regarding 2, the SQL specs don't discuss EXTRACT with a date part on a time value. Intuitively it may make sense to give an error in strict mode and MISSING in permissive mode. The strict mode behavior is what other databases seem to do (e.g. postgresql, mysql). For now, these test will be included in the conformance tests.
Regarding 3, the SQL specs don't discuss EXTRACT with a time part on a date value. We could give a default time (or implicitly cast the date to a timestamp). This behavior doesn't seems as clear as some databases give an error while others assume the default. For now, these tests will be omitted from the conformance tests.


notifications from FSAC

this reenable the websocket to fsac /notify for push notifications
enabled also in devMode
works with https://github.com/fsharp/FsAutoComplete/pull/242 who reenable
the /notify and a sample push of an hello info response
but with corrent fsac (without /notify) doesnt generate errors, so afaik can be merged.
Later, the consumers should check better the type of response, as usual

closing, in favor of https://github.com/ionide/ionide-vscode-fsharp/pull/643


Fix #91 - Added elapsed time for Init, Deploy & Undeploy commands

Added the elapsed time functionality to Init, Deploy and Undeploy commands. The time displayed is similar to the build output command

Thanks!


Code for Issue 2566

Have you read the Contributing Guidelines on Pull Requests?
Yes I have
Description
In response to #2566
Added the code for the problem of the "time taken to rot all oranges" in python.
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
I have implemented this code in Python

Will you review this code @HarshCasper


Apple Sign In dialog jumps

Describe the bug
https://user-images.githubusercontent.com/6481741/140525765-7e385d23-0526-48b8-92fb-8bf87bad2e9d.MP4
My code looks like:
            SignInWithApple.authorize({
                clientId: environment.apple.clientId,
                redirectURI: environment.apple.redirectURI,
                scopes: environment.apple.scope // email name
            })

To Reproduce
Steps to reproduce the behavior:

Open application
Click 'Sign in with Apple' button
Click 'Continue' button

Expected behavior
It should not jumps. I'm moving an app from Cordova IONIC, I don't have this jump behaviour in the same app with IONIC Native plugin.
Smartphone (please complete the following information):

Device: iPhone X, XS, Xr
OS: iOS
Version 15.1

Same behaviour here. You can also see it in a commercial app (which is not related to me) here: https://apps.apple.com/ca/app/i-lave-u-le-pressing-mobile/id1506610696

Guys, is there exists any solution/workaround for this issue?

Any updates?

Any updates?

I've now seen this in many apps (not sure if all) including non-Ionic and non-Capacitor apps, and it's being discussed in non-Ionic/Capacitor-specific venues too (https://developer.apple.com/forums/thread/693381). May simply be an iOS bug.


Security middleware initialization fails with operation without medthodDoc.

Other middleware initialization in if block begins in L.130.
      if (methodDoc &&
          allowsMiddleware(apiDoc, pathModule, pathItem, methodDoc)) {// add middleware

Security middleware is initialized out of the block.

dang.

Fixed in v0.20.2


TS impl

So far:

structure
did creation
key generation
compression
tests
dht publish and read / en/decoding to DID documents

exciting to see!

Not sticking to DNS packet codec is a mistake. You should take my word for it because the code you are using is already what I started with and moved from[1].
DIDs are awful anyway, but if you have to do it, put in a TXT record[2], giving up on DNS semantics for DIDs is just as unwise as all the time and money spent on ION despite my repeated advice against it.
[1] https://github.com/Nuhvi/pkarr/commit/4fd7e717dfec57264445576b6ebfeea2f5d28d79
[2] https://gist.github.com/Nuhvi/443b7dc066b6f5e9236adfb99b241939

We know for a fact that domains are useful and pretty much the closest thing to a source of sovereignty in the web architecture, taking it to the next level with TLDs that are self-issued and censorship-resistant is useful regardless of what data you put in it.
From TTLs, to the wide support in every browser and operating system to the fact that DNS Packets simply do "service endpoints" better with A, AAAA, and CNAME, and that is infinitely more supported than DIDs, it is irresponsible to consciously decide to forgo all of that for no reason other than NIH, especially when the NIH is one of the pillars of the Internet!

@decentralgabe A big benefit you will get out of the gate, is using Pkarr's implementations in JS and in Rust, and knowing that they follow best practices and have a certain performance profile.
You are betting that implementing a good DHT client is easier and faster than conforming to DNS resource records.


WIP: Type updates

This PR is for Issue #997
I'm having some issues narrowing down the test failures. I am also seeing a large number of output errors while running make test. Hoping some of you more familiar with the codebase could help me narrow down the cause of the issues. I apologize in advance for the large number of changes in this PR. What I thought would be a small change turned into a very large project, touching a lot of the existing code. Thanks in advance!

Can one of the admins verify this patch?

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "type_updates" git@github.com:grantleehoffman/notary.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842353337744
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Will fix the signed commits now

Haven't had a chance to check out the cause of the errors yet, but I do think that metadata store should be updated to take RoleName instead of string
type MetadataStore interface {
	GetSized(name string, size int64) ([]byte, error)
	Set(name string, blob []byte) error
	SetMulti(map[data.RoleName][]byte) error
	RemoveAll() error
	Remove(name string) error
}

This interface is pretty ubiquitous so that's not the smallest change.

@ecordell Thanks the feedback. I was starting to get a bit uneasy with the number of changes as I dug deeper. I decided to try to limit the number of changes I was making to make it manageable to review. I'll go ahead and continue changing out all of the gun and roles strings for the entire project.

Agreed with @ecordell. Let's keep it to straight type changes here but hit all of them. Even if it's long that's still pretty easy for us to review. We can do separate PR for changes like the Name -> RoleName field change suggested.

:+1:

Still having issues with test TestUpdateSucceedsEvenIfCannotWriteExistingRepo client/client_update_test.go:143

jenkins, test this please

I'm not sure why GH is showing your branch as adding things unrelated to your change that are already in the master branch. Can you try a rebase against master and see if that clears those items out?

I think I've addressed all of the current PR comments. Please take another look when you have the time. Thanks!

@grantleehoffman The only thing left I can see is the MetadataStore interface (and the types that satisfy it)

@ecordell I was staying away from it for now, I believe @endophage suggested doing the name -> RoleName change in another PR. I can start working on the MetadataStore Interface if everyone is in agreement or we can create a new PR for that change.

I need to dig into MetadataStore some more. My instinct was that it was always a generic data store but taking a brief look, it may be specific enough that it should be bound to the role types. I'll get back to you.

It looks like FilesystemStore should implement MetadataStore, this starts to get messy as we are dealing with files and roles.

FilesystemStore is definitely an implementer of MetadataStore. I think for now lets just leave the entire storage package untouched. We need to possibly do some more refactoring in there because MetadataStore implementers are also used for key storage. That was part of a big DRY-ing out of our storage code I did last year because we had two very overlapping sets of storage objects.

@endophage @ecordell So it sounds like refactoring MetadataStore should be done in a different PR, since we can't make the changes we need to make to MetadataStore without touching Storage.

Yep, and post refactoring, it think it probably won't make sense to push the RoleName type into the storage package as the interfaces will become more clearly generic.

Ok sounds good. Let me know if you see any other outstanding changes that need to be made.

This is ready to merge on my end. Looks like it just needs the yubikey test to run, is there a way to start this test?

jenkins, test this please

Unfortunately our yubikey ci job is having some infra issues, so it won't work.  So one of us will be jenkins for now until it comes back up.  :)
`go test` commands that will be run:

	go test -tags pkcs11 -race -covermode atomic -coverprofile cmd/notary/coverage.pkcs11.txt -coverpkg github.com/docker/notary/storage,github.com/docker/notary,github.com/docker/notary/version,github.com/docker/notary/trustmanager/yubikey,github.com/docker/notary/cryptoservice,github.com/docker/notary/tuf/utils,github.com/docker/notary/server/snapshot,github.com/docker/notary/tuf,github.com/docker/notary/server/storage,github.com/docker/notary/tuf/data,github.com/docker/notary/server,github.com/docker/notary/client,github.com/docker/notary/trustmanager,github.com/docker/notary/passphrase,github.com/docker/notary/utils,github.com/docker/notary/tuf/signed,github.com/docker/notary/trustpinning,github.com/docker/notary/client/changelist,github.com/docker/notary/server/handlers,github.com/docker/notary/server/timestamp,github.com/docker/notary/tuf/validation,github.com/docker/notary/server/errors,github.com/docker/notary/cmd/notary,github.com/docker/notary/storage/rethinkdb github.com/docker/notary/cmd/notary
	go test -tags pkcs11 -race -covermode atomic -coverprofile trustmanager/yubikey/coverage.pkcs11.txt -coverpkg github.com/docker/notary/storage,github.com/docker/notary,github.com/docker/notary/trustmanager,github.com/docker/notary/passphrase,github.com/docker/notary/tuf/signed,github.com/docker/notary/tuf/utils,github.com/docker/notary/trustmanager/yubikey,github.com/docker/notary/tuf/validation,github.com/docker/notary/tuf/data github.com/docker/notary/trustmanager/yubikey

Results:

ok  	github.com/docker/notary/cmd/notary	123.668s	coverage: 63.2% of statements in <24 dependencies>
ok  	github.com/docker/notary/trustmanager/yubikey	18.690s	coverage: 23.6% of statements in <9 dependencies>

Yubikey tests 👍
(I tried to also push coverage to codecov, but I think I'm doing it wrong to get it counted)

It looks like CircleCI had an issue downloading an artifact

I gave it a kick

I'll have a chance to do final review of this tomorrow

👍 yubikey tests pass
`go test` commands that will be run:

	go test -tags pkcs11 -race -covermode atomic -coverprofile cmd/notary/coverage.pkcs11.txt -coverpkg github.com/docker/notary/storage,github.com/docker/notary,github.com/docker/notary/version,github.com/docker/notary/trustmanager/yubikey,github.com/docker/notary/cryptoservice,github.com/docker/notary/tuf/utils,github.com/docker/notary/server/snapshot,github.com/docker/notary/tuf,github.com/docker/notary/server/storage,github.com/docker/notary/tuf/data,github.com/docker/notary/server,github.com/docker/notary/client,github.com/docker/notary/trustmanager,github.com/docker/notary/passphrase,github.com/docker/notary/utils,github.com/docker/notary/tuf/signed,github.com/docker/notary/trustpinning,github.com/docker/notary/client/changelist,github.com/docker/notary/server/handlers,github.com/docker/notary/server/timestamp,github.com/docker/notary/tuf/validation,github.com/docker/notary/server/errors,github.com/docker/notary/cmd/notary,github.com/docker/notary/storage/rethinkdb github.com/docker/notary/cmd/notary
	go test -tags pkcs11 -race -covermode atomic -coverprofile trustmanager/yubikey/coverage.pkcs11.txt -coverpkg github.com/docker/notary/storage,github.com/docker/notary,github.com/docker/notary/trustmanager,github.com/docker/notary/passphrase,github.com/docker/notary/tuf/signed,github.com/docker/notary/tuf/utils,github.com/docker/notary/trustmanager/yubikey,github.com/docker/notary/tuf/validation,github.com/docker/notary/tuf/data github.com/docker/notary/trustmanager/yubikey

Results:

ok  	github.com/docker/notary/cmd/notary	113.518s	coverage: 63.3% of statements in <24 dependencies>
ok  	github.com/docker/notary/trustmanager/yubikey	18.492s	coverage: 23.6% of statements in <9 dependencies>

Hey @grantleehoffman, I hope you don't mind I pushed the remaining cleanup. We're starting to line up some feature updates and I want to get this merged first rather than asking you to rebase and deal with the changes we're making. You can see my commit for the final stuff I did, it's largely in line with the things I pointed out previously, though I also really didn't want the internals of MemoryStore to know about RoleNames so I tweaked the constructor there (and in doing that uncovered a test that was relying on side effects of shared mutable state so that got fixed too).
cc @ecordell you might want to review my final commit
cc @cyli @riyazdf @HuKeping given I now have skin in this PR, could one of you at least review my final commit.

I think circleci needs a kick again

jenkins, test this please

Having some CI issues, but once that's fixed LGTM on green.

Once Jenkins is green I'll manually merge this. I want to test there are no conflicts/breaking changes that will result from the merge before pushing master. This is so large it's possible that non-overlapping (and therefore non-conflicting) but interdependent changes may have occurred.

jenkins, test this please

@grantleehoffman thanks for sticking with this, we're very happy to have this merged :-)


Autoformat using Black. Also fix a few style complaints (trailing whitespaces)

Fixes #1489 (kinda)

Black is very popular, so many will be familiar with it.
It is good at minimizing diffs
It is very opinionated (the only config I've added is the line length), so there should be minimal discussion about how to configure it
IMO it strikes a good balance between keeping the code nicely formatted (and PEP8 compliant) without making it unnecessarily long.

Here's a comparison of various formatters https://medium.com/3yourmind/auto-formatters-for-python-8925065f9505
As the next step, we could (should) increase the number of rules covered by flake8 (probably switching to ignoring the few rules that we dont like instead of enabling a few favourite ones. something like --ignore E501,W503,E701,E731,E741,E712,E402,F401).

Nice!
Does this also get checked by travis so we stop PRs that don't comply?

Nice!
Does this also get checked by travis so we stop PRs that don't comply?

Yup!

@heyman Any thoughts on this? I hope you like it. I know it pollutes the git history a little but not using consistent formatting is, imo, not really an option in the long run either.

It's been discussed before, and my opinion hasn't changed. In many cases I think Black reduces readability, and I don't see much real benefit from it.
There's a lot that can be said about Black. Some people like it, others dislike it. I fall into the second camp.

If the changes in this PR are from Black, then it's still a massive improvement, no?

@heyman What are your objections to Black specifically? If there is a better formatter out there then lets talk about it.
 For readability, diffs, etc.

@cyberw IMO Black decreases readability in more cases than it increases it (obviously depending on what code base you apply it to).
I don't think having 100% consistent formatting is an end in itself. Here are two examples from the very first file of this PR's diff:

This first one might be a matter of taste, but I don't like the extra indentation for the tuple.

This one I find objectively worse. Splitting the arguments on different lines makes sense both because we're joining on a \n which will make the output go on different lines, and also because the inner "\n".join(rows) is more hidden in the one-line version.

Here are a few others (I don't have the time to go through the whole diff):

In these cases the lines were made intentionally short, in order for the example to fit well on the https://locust.io website (see the "With HTML parsing" example). Obviously Black - or any other auto formatter - can't know that which is also the problem with autoformatters IMO. There are contextual circumstances that's impossible to write automatic rules for.

Another example where context matters. To a human I think the non-Black version is much better.

Another very minor one (and arguably a matter of taste). To me the grouping makes sense (they are imported from different modules), but understandably not to an auto formatter.

Same here. The grouping of the short hand parameter with the long version makes sense, but it's (close to) impossible for an autoformatter to know that.

 For readability, diffs, etc.

I can't see why diffs would be any worse unless you start changing the formatting for pieces of code that is unrelated to your change (which is the actual problem in that case IMO). When it comes to readability, I'm all for changing the formatting of a piece of code that you find hard to read.

@cyberw IMO Black decreases readability in more cases than it increases it (obviously depending on what code base you apply it to).

I dont think you've actually given it much of a shot. If you use Black integrated in your editor for more than 30 minutes I can almost guarantee you will fall in love with it (if you were talking about yapf, which is ridiculously generous with line breaks and has other issues, I might understand what you're talking about)

I don't think having 100% consistent formatting is an end in itself. Here are two examples from the very first file of this PR's diff: ...

I kind of agree with your examples, those are special cases where the auto formatter can't know the reasons for doing particular formatting. But I dont think they are significantly worse after formatting.
Having consistent formatting (Black's or some other tools) improves code readability. While a perfect manual formatting might be a little better than what an automated tool can do but that is not really an option...

In these cases the lines were made intentionally short, in order for the example to fit well on the https://locust.io website (see the "With HTML parsing" example). Obviously Black - or any other auto formatter - can't know that which is also the problem with autoformatters IMO. There are contextual circumstances that's impossible to write automatic rules for.

Actually that was not Black, that was me :) Black does not format comments and I'll be happy to revert that change.

 For readability, diffs, etc.

I can't see why diffs would be any worse unless you start changing the formatting for pieces of code that is unrelated to your change (which is the actual problem in that case IMO). When it comes to readability, I'm all for changing the formatting of a piece of code that you find hard to read.

Diffs are primarily worse because formatting is based on the programmers preference (so there might be inadvertent changes, like with @max-rocket-internet 's issue), but also because Black does neat things like consistently inserting a comma after the last entry in a line-separated list (so that if you add an item there is no diff on the last entry)
I think the only reason to not implement any kind of autoformatting is if you consider Locust to be mostly finished and its git history more important than ease of future improvements.

I'm 100% for any tool to help clean up the formatting and everything in this PR is an improvement IMO. Perhaps could we merge this and then if @heyman wants to use another tool or change the settings then that can come later?

Being able to do git blame easily is a good thing, but I dont think it is worth keeping badly formatted code.

This is Github, you can get a super nice UI showing the history of any file so IMO the point about git history is moot.
This project has over 10k stars, it's 2020, let's make this project reflect this 🙏 😃

Neutral solution could be using pylint - it is also very popular, configurable, and there are no risks with auto-formatting since all errors & warnings must be fixed manually.

Neutral solution could be using pylint - it is also very popular, configurable, and there are no risks with auto-formatting since all errors & warnings must be fixed manually.

We're already using flake8/pycodestyle (albeit with ridiculously permissive settings). I like pylint myself, but I think this is a separate topic.

I think the only reason to not implement any kind of autoformatting is if you consider Locust to be mostly finished and its git history more important than ease of future improvements.

I actually feel the opposite. I use the git history all the time when trying to understand existing code while working on a code base (Locust included). If I knew that I didn't plan to do any future development on it, I wouldn't really care about the git history.

This is Github, you can get a super nice UI showing the history of any file so IMO the point about git history is moot.

The history will be obfuscated on Github as well. For whitespace changes you can partly work around it by manually adding the w=1 parameter to a lot of Github URLs (though last I checked there were pages on Github where that wasn't supported). Other formatting changes will obfuscate the git history on Github just as with other git tools.

@heyman Is there anything we could do to fix formatting then?
To me, it feels like you have resisted every significant change suggested by someone other than yourself in the last year (removing mandatory TaskSets, dropping py2 support, constant RPS target, reintroducing request/iteration count target, default to zero wait time, etc). This is very frustrating for me.
I get that Locust is your baby and you care a lot about it. But is it possible that this is another one of those cases you might be a little too resistant to change?
IMHO, the best tool/open source project is not the one that never breaks (and definitely not the one that has a perfect git log), but the one that strikes a balance between robustness & evolution.
I'll be happy to discuss alternative approaches to solving the current formatting mess, but it seems you don't want to do anything at all...

@cyberw

To me, it feels like you have resisted every significant change suggested by someone other than yourself in the last year (removing mandatory TaskSets, dropping py2 support, constant RPS target, reintroducing request/iteration count target, default to zero wait time, etc). This is very frustrating for me.

I find that statement a bit unfair. There has been quite a few significant changes apart from the proposed ones you listed that has been merged, and for the issues you listed I think I've given reasonable arguments to why I have been hesitant. Regarding the removal of the mandatory TaskSets I think we ended up with a much better solution than the one originally proposed.
With that said, I do think it's reasonable for a fairly mature open source project to have an initially sceptic approach to large changes. I think it has benefited Locust, and I think it has made projects such as Django successful in the long run.

I get that Locust is your baby and you care a lot about it. But is it possible that this is another one of those cases you might be a little too resistant to change?

I don't agree with the way you've framed the question, but it's definitely possible that adopting auto formatting using Black would be net positive for Locust.

I'll be happy to discuss alternative approaches to solving the current formatting mess, but it seems you don't want to do anything at all

I've yet to be convinced that there is a huge problem with not having a 100% formatting consistency. Apart from people's editors autoformatting files they touch (which might be solvable with a .editorconfig file?) I just can't see the big benefit of using an autoformatter, but i can see drawbacks which I've already described here (as well as in #759 and #113).
In the end I really think it comes down a lot to personal preference when it comes to using auto formatters. The best argument for me so far would be to never have to have this argument again :).

Also, if we were to adopt Black, maybe it would be worth waiting for a stable Black version to be released? It would include this which would at least fix one of the issues I have have with the Black formatting.

I've yet to be convinced that there is a huge problem with not having a 100% formatting consistency.

Having perfect consistency is not the issue, having reasonable consistency is. I dont know a of a good way to keep any kind of consistency without using some kind of opinionated auto formatter (except using an opinionated linter & doing it manually but that is much more work)

In the end I really think it comes down a lot to personal preference when it comes to using auto formatters. The best argument for me so far would be to never have to have this argument again :)

Haha... If that tips the scale, I'll take it ;)

Also, if we were to adopt Black, maybe it would be worth waiting for a stable Black version to be released? It would include this which would at least fix one of the issues I have have with the Black formatting.

Yea, a fix for that would be nice. Looking at pypi, it seems all Black-releases are pre-releases so I wouldnt wait for a stable one (I think this is intentional, but I dont know why they do it)
Unfortunately (and this worries me a little now) there hasnt been a release since October 2019. Maybe we should hold back a little and see if the project has fallen asleep... we dont want to start using Black just to have to switch to something else later on.

Hmm. The issue you mentioned is actually supposed to work in 19.10b0 (according to the comments in the issue at least). What is the case you are seeing? Maybe I just need to add a trailing comma?

What is the case you are seeing? Maybe I just need to add a trailing comma?

This one, for example:

What is the case you are seeing? Maybe I just need to add a trailing comma?

This one, for example:

Ok, yea, looking closer at the conversation in the issue I see that nested collections is not yet fixed. Not sure if it will be fixed any time soon, but I guess we could hold off for a while if a fix for that would help convince you that the change is "net-positive".

I'll close this for now. But once magic commas for nested collections are fixed, I'll be back :)