Stick icons in a static dir away from the build

@timbl, I hope this resolves the icon issues some have been seeing.
Icons now live in a static/icons directory, which is distributed as part of the npm package, which lets package consumers self-host those icons if they wish to.
In the long term, I don't think we should be using GitHub as a CDN for icons, but this should resolve issues once it merges and once the gh-pages branch is fast-forwarded to master.
There should be no reason to track the lib directory in git.

Thanks for adding this, I've been having issues getting the icons to display lately.

Gentle bump on this.  Did we decide whether to merge?

Hey @melvincarvalho thanks for the reminder. I floated it by @timbl but we didn't reach a decision. He had an idea to serialize the SVG icons within a JS module rather than serve each icon separately.
I think we should merge this to unbreak icons for the time being and then explore one of the other options as a follow-up item.

When changing where icons are mounted it is important to leave them in the old place for a while as they will still be referenced from old code.
If we have to move them then maybe we should dedicate a URI which we can support indefinitely, like   solid.mit.edu/dist/  or   w3.org/somewhere...

I have a few ideas here. A starting point is to decouple the CDN from the resource paths. A basic implementation looks like:
const cdn = base => path =>
  [base.replace(/(\/)$/, ''), path.replace(/^(\/)/, '')].join('/')

const githubIcons = cdn('https://linkeddata.github.io/solid-ui/static/icons/')
const iconPath = githubIcons('noun_144.svg') // => https://linkeddata.github.io/solid-ui/static/icons/noun_144.svg
// or
const myCdn = cdn('https://mycdn.biz')
const icon = myCdn('static/icons/noun_144.svg')
const picture = myCdn('static/img/this_does_not_exist_but_could.jpg')

At this point the library can support a sort of cdn dependency injection. Every call to a function which requests static assets from a CDN has an optional argument, defaulting to, e.g., cdn('https://cdn.w3.org/solid'). The problem with this approach is that anyone using their own CDN would have to pass the cdn function around everywhere.
A better approach, I think, is to have a global variable for the CDN, and expose it during the build process using a tool like webpack. Here's an example of this type of strategy.
Then our code can look like this:
// in cdn.js
export default function cdn (path) {
  // SOLID_UI_CDN is templated at build time
  const cdnBaseUrl = SOLID_UI_CDN || 'https://cdn.w3.org/'
  return [cdnBaseUrl.replace(/(\/)$/, ''), path.replace(/^(\/)/, '')].join('/')
}

// in consumer code
import cdn from './cdn'

function renderThing () {
  // ...
  const iconUrl = cdn('icons/noun_144.svg')
  // ...
}

And I agree that we should leave the icons where they are for a while during the transition.

(I agree that we are not tracking icons in li directory. They are are only in the src  directory, where they were moved to when src was set up, and babel -d src lib .  So the iconbase had already been moved from lib to src.)
Yes agree about something like that for the cdn.
Note there is something like cdn global variable, in $SolidTestEnvironment in src/iconbase.js:
  if (typeof $SolidTestEnvironment !== 'undefined' && $SolidTestEnvironment.iconBase) {
    module.exports.iconBase = $SolidTestEnvironment.iconBase;
    module.exports.originalIconBase = $SolidTestEnvironment.originalIconBase;
  } else {
    module.exports.iconBase = iconsOnGithub + '/icons/';
    module.exports.originalIconBase = iconsOnGithub + '/originalIcons/';
  }

There is a case for allowing the CDN to be overridden either before the library is called, or after, just because will vary in how they need to do this.  Here for example you can et up $SolidTestEnvironment in advance, or you can overwrite the value of UI.iconBase later...


clip finetune脚本

Hello @Weifeng-Chen! Thanks for opening this PR.

In the file fengshen/examples/ubert/example.py:

Line 13:75: E261 at least two spaces before inline comment
Line 13:76: E262 inline comment should start with '# '
Line 14:35: E262 inline comment should start with '# '

In the file fengshen/models/ubert/modeling_ubert.py:

Line 146:13: E722 do not use bare 'except'
Line 300:24: E711 comparison to None should be 'if cond is None:'

Do see the Hitchhiker's guide to code style


extend jsx-a11y/strict by default

Closes #8634
Modified the eslint configuration to extend the jsx-a11y/strict configuration by default.
By making these rules default, developers will start creating accessible web apps from the beginning and accessibility will no longer be an after thought for create-react-app devs.
I've included details on how to modify rules back to "warn" or "off" for those that choose.
Additionally, I included links to other online resources for developers to learn more about web accessibility.

Seems like the react-overlay package is failing due to the new accessibility rules. Would you like me to include the update to that package in this PR?

I hate to ping y'all directly, but can I get some feedback on this PR? Thank you! @iansu @mrmckeb @ianschmitz @petetnt

Our warn rules will error in production builds in CI. We set to warn so as not to distract too much during dev. Does that make sense?

Why would they error in production builds? Can we fix those implementations so they are more accessible?

You can read more about the behavior in production builds here: https://create-react-app.dev/docs/running-tests/#continuous-integration. The gist is any warning emitted by webpack (via ESLint in this case) is treated as an error and fails the build.
We're very careful about which rules we set to error, as they get emitted as an error to webpack and as such will cause the error overlay to appear. This is much too harsh when just trying things out as eslint errors will cause the error overlay to appear and error in console. warn allows you to be warned about the issue, but continue developing, while still throwing an error in a production build.
As such as won't be extending the strict rule set as it explicitly sets all the rules to error.
Hope that makes sense. Closing for now as it's consistent with other rules. If you feel we're missing some specific rules that should be enabled then let us know in a subsequent issue.

Im content with these rules failing production builds; at least that will deter users from shipping nonaccessible code, and that is whats most important here.


Minor. Update api doc about source update regarding auto_response_triggers and signatures. RD-22688 RD-22689 RD-22690 RD-22691

Jira Ticket :

https://jira.ringcentral.com/browse/RD-22688
https://jira.ringcentral.com/browse/RD-22689
https://jira.ringcentral.com/browse/RD-22690
https://jira.ringcentral.com/browse/RD-22691

We update API documentation for PUT /1.0/content_sources endpoint now that we give possibility to update with our API auto_response_triggers logic, signatures and content_languages.

Could you make it so that it says it is an array of object with body/language:

Same thing

should be an array of objects language/created_from_trigger/body

LGTM


ci: added feature request issue form

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows Conventional Commits
[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Refactoring (no functional changes, no api changes)
[x] Other... Please describe: ci

Does this PR introduce a breaking change?

[ ] Yes
[x] No

@waterplea @vladimirpotekhin please, review me)

@vladimirpotekhin ))

@vladimirpotekhin need your approve ))


Add support for Expiration Date in POST /keys

A maximum Expiration Time should be set via the config
The Server will check the Expiration Date on every POST request

Is solved, see mostly: https://github.com/ghga-de/datameta/blob/main/datameta/api/apikeys.py#L113-L142


Remove LoggerAwareTrait from Email class

I would like this considered because the Email class creates a Logger instance when it's instantiated. I'm trying to devise an EmailHandler for the Logger class which would require an instance of the Email class. I sure you can see the endless loop that is formed.
It doesn't seem like removing the LoggerAwareTrait would affect Email much. It only makes one call to the resulting logger object.  Switching that call to using the common function log_message seems a good substitute for $this->logger->log...
If this PR is merged I've got a working EmailHandler ready to go.

I think using log_message() directly is actually desirable and consistent with other libraries, as we establish logging early as a service and the helper function will always rely on that. I would like @lonnieezell or @jim-parry to take a look as well but I'm good with this change. This library's days are numbered but it would be good to have it feel at least consistent for release.


⚠ Bofrost.lu has degraded performance

In df11dd8, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2088 ms

Resolved: Bofrost.lu performance has improved in 2ae2f96 after 24 minutes.


New version of the vtk package

Still very much in progress, main work is on improving the port specs
and specifying them explicitly. vtk_classes.py is huge due to
docstrings and tons of classes.  A simple head example works!

I did a very quick toy example: https://gist.github.com/remram44/f85405f6473a326ad4a3
A priori, loading Python code is way slower (0.07s) than JSON+dynamic creation (0.03s), although loading compiled bytecode (.pyc) is faster (0.02s). But all this is very comparable, so insertion into the registry will probably be the bottleneck.

Cool, so dynamic creation should not be a problem.
The intermediate format is currently xml. We could use either json, xml, or python classes as a final representation. @dakoop worries about readability when debugging, so this will be a tradeoff between parsing speed and readability. Maybe some well-structured json would not be too bad?
If we keep the python classes where should it be stored? It will be generated the first time the package is loaded and when the vtk version changes?
Adding @dakoop's previous comments:
About the VTK wrapping, I see Rémi's point about using the intermediate representation directly. This should be ok, but will debugging suffer? Also, one thing I would then like to see is the ability to have some type of patterns/shortcuts for patching and/or extensions. For example, the matplotlib stuff has an idea of alternatePortSpecs that are used to define two versions of a port (one scalar, one list); those dictate both a second port spec and logic for handling this in the compute method. Also, should we then look to have the XML mirror the registry specifications? (My vote: yes, but need to have some way to instrument extensions--second intermediate?) Should this go into the schema? (My vote: probably yes but wouldn't spend too much time on this).

@dakoop are you suggesting a common XML(or json?) for all wrappers where there is a core that specifies e.g. name/function/inputs/outputs and an extension section that specifies things like alternatePortSpecs?
Extensions could be passed to the registry but is it not easier to add it to the dynamically created module? Is that what you mean by the XML mirroring the registry specifications?
For patching, does this mean adding/removing/changing/correcting things in the intermediate representation using different patterns? This should be easy to code by hand but we could have methods for doing common tasks?

@rexissimus, if we have a standard intermediate representation (json/xml), my argument is that it should mirror the registry schema (which defines db classes for packages, module descriptors, and port specs). The matplotlib xml representation differs from the registry schema because it contains items that affect the automated compute method construction as well as the structure of the package. Such items are useful for patching as well; it is much easier for me to create an alternatePortSpec than to make manual changes to both the module inputs/outputs and compute method. Note the matplotlib package requires compute methods that are not simple maps from input ports -> input parameters and output values -> output ports. Thus, for that package (and perhaps others), I would need extensions to the proposed intermediate representation that would allow rules that impact both the specification and the compute method. Or, I could use a secondary intermediate specification where those edits could be made and the compute methods updated. In either case, we need some way to specify what the compute method should look like in the intermediate representation. The compute methods can be specified by recipes that are templates (perhaps mako which I've used elsewhere in the code).

With dynamic wrapping you can still do that. The compute method would be shared, like gen_module_ufunc. The alternatePortSpec would be stored as an extension and used for both specification and as input to the compute method when the module is dynamically created. I just don't see the advantages of your way?

@rexissimus, I am missing something---is there a proposed architecture that should be linked to this PR? Could you clarify what "my way" is; is this the matplotlib/vtk wrapping method? I am fine building off of the VTTools or other infrastructure, and the main concern I have with dynamic generation is debugging. I also want to make sure that whatever is adopted is general enough to work for something like the matplotlib wrapping. Some questions:

What do you mean by the compute method being shared? What happens if I want to specify different compute methods for different types of modules?
What do you mean by an extension---is there a proposed extension syntax?
How does debugging work for dynamically created compute methods?

I meant the way you want to make the intermediate representation similar to the registry schema. I am trying to understand how that would work.

In VTTools one compute method is created for each module, but you could also use a single compute method that uses the intermediate module representation (stored in a module attribute) to figure out which inputs/outputs to use and which function to execute. I am not sure which method would be preferred. To make the compute method less complex you could have different compute methods fir different types of wrapped modules.

With extension I mean how non-standard attributes are stored in the intermediate representation. Actually, | am not sure there would be many standard attributes except e.g. name and namespace. The function/class to execute can be specified in different ways, and ports can be specified in more complex ways like with the "AlternatePortSpec".

I am not sure debugging would be a problem since you still have an explicit compute method. It would just be the same for a group of modules, but you could look at the attributes to figure out which one it is?

Ok, I think I see your point now after working with the code. The intermediate representation should mirror the registry so that it is easy to see what the final module will look like. Patching will affect both the specification and the shape of the final compute method that would have to be specified by some kind of extension.

@dakoop I would also point out I have been thinking about how to coerce matplotlib to fit in better with a the functional nature of VT (which involves an Axes class which doesn't add the artists to it's self so you can collect them all and then add them en-mass to an Axes is the last plotting step instead of collecting code to be run) which will make the mapping of input/output ports much closer to args/return values.


settings: Fix various issues with list_render and its callers

The first few commits here are ready.  The big "Clean up initialization" commit toward the end is the only thing that's a bit risky.

The last commit seemed to work for me after some testing.
@ryanreh99 FYI; it'd be awesome if you did some manual testing on this change as well to confirm that all of our "settings" pages with tables still sort properly after this commit.

I also opened https://github.com/zulip/zulip/issues/14559 to track a bug I noticed while testing this.

Hi, I think there is a bug related to list_render objects which doesn't have sort functionality (and which has already been created).
For example, if we change the the notification settings from the stream edit page, no data is shown for the stream_specific_notifications table.
I also tested this out by commenting out the following lines:
diff --git a/static/js/attachments_ui.js b/static/js/attachments_ui.js
index 97ac3f6144..20c0f730eb 100644
--- a/static/js/attachments_ui.js
+++ b/static/js/attachments_ui.js
@@ -92,10 +92,10 @@ function render_attachments_ui() {
             },
         },
parent_container: $('#attachments-settings').expectOne(),
-        init_sort: ['numeric', 'create_time'],
+        /*init_sort: ['numeric', 'create_time'],
sort_fields: {
mentioned_in: sort_mentioned_in,
-        },
+        },*/
});

And the attachments table does not show the updated data after a new attachment has been uploaded.
@showell could you please confirm this?

@ryanreh99 Thanks for the report and sorry for the inconvenience.  I'm gonna revert that last commit--there was a bit of miscommunication on how well I had tested it.  After I revert the commit, there will still be some bugs when you use the form the second or third time, but those will be the old bugs.


Reqwest Client (Tokio 1.0 support)

Fixes #82
Fixes #90
Description
Using reqwest over surf has a few advantages:

it has already update to tokio 1.0, which has been out there for 6 month now
it's less of a dependency hell than surf

However, I've kept the existing surf-based feature flags for those that really need async-std compatibily.
Some notes:

I've bumped the MSRV from 1.45 to 1.46 so that the socket2 dependency compiles
I've made it a hard error if both surf and reqwest features are enabled. We could prioritize one over the other, however, that would make the #[cfg] statements more complex. Also, there are other error messages than my custom ones, which could be suppressed but would add more complexity.

Checklist

[x] Formatted code using cargo fmt --all
[x] Linted code using clippy cargo clippy --all-targets --all-features -- -D warnings - I didn't introduce those warnings
[x] Updated README.md using cargo readme -r influxdb -t ../README.tpl > README.md
[x] Reviewed the diff. Did you leave any print statements or unnecessary comments?
[x] Any unfinished work that warrants a separate issue captured in an issue with a TODO code comment

I think there's only the <dyn> fixes missing

@Empty2k12 As I mentioned before, these dyn-related warnings have not been introduced by me or this PR. They have been introduced by the Rust compiler and are present in the code on the master branch as well. Since there is no warningless version of the master branch, I had no choice but to use your warning-"infested" code on the master branch as a base for this PR.
I've asked you before if you want me to do a separate PR to fix those warnings, and suggested to just remove the offensive function, as it just calls another public function and nothing else. Your only reply was Gute Frage.

I think there's only the <dyn> fixes missing

@Empty2k12 As I mentioned before, these dyn-related warnings have not been introduced by me or this PR. They have been introduced by the Rust compiler and are present in the code on the master branch as well. Since there is no warningless version of the master branch, I had no choice but to use your warning-"infested" code on the master branch as a base for this PR.
I've asked you before if you want me to do a separate PR to fix those warnings, and suggested to just remove the offensive function, as it just calls another public function and nothing else. Your only reply was Gute Frage.

If this is the only thing keeping this from being merged I think it might make sense to just add it to the PR. I think tokio 1.x support is essential.

If this is the only thing keeping this from being merged I think it might make sense to just add it to the PR. I think tokio 1.x support is essential.

If @Empty2k12 could decide if he wants the API to promote <dyn Query>::raw_read_query (which IMHO looks ugly) or replace it by ReadQuery::new (which exists today and does exactly the same) I'm happy to make the required changes.


Fix #5182 Switch From Mapbox to MapLibre

Description (required)
Fixes #I5182
What changes did you make and why?
Migrated from Mapbox to MapLibre
Tests performed (required)
Tested {build variant, e.g. ProdDebug} on {name of device or emulator} with API level {API level}.
Screenshots (for UI changes only)
Need help? See https://support.google.com/android/answer/9075928

Note: Please ensure that you have read CONTRIBUTING.md if this is your first pull request.

Meanwhile any idea why the unit tests testOnMapReady and testShowDetail fail?

I am getting this crash:
03-23 19:49:07.328 26593 26593 E AndroidRuntime: java.lang.IllegalArgumentException: Could not find layer Outdoor
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.mapbox.mapboxsdk.maps.Style.getPredefinedStyle(Style.java:1430)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at fr.free.nrw.commons.nearby.fragments.NearbyParentFragment.lambda$onViewCreated$2$NearbyParentFragment(NearbyParentFragment.java:319)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at fr.free.nrw.commons.nearby.fragments.-$$Lambda$NearbyParentFragment$LW_iO-h3e6OvgddLCQ2oE4vXWAc.onMapReady(Unknown Source:2)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.mapbox.mapboxsdk.maps.MapView$MapCallback.onMapReady(MapView.java:1322)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.mapbox.mapboxsdk.maps.MapView$MapCallback.initialised(MapView.java:1308)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.mapbox.mapboxsdk.maps.MapView.initialiseMap(MapView.java:203)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.mapbox.mapboxsdk.maps.MapView.access$800(MapView.java:65)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.mapbox.mapboxsdk.maps.MapView$6.run(MapView.java:355)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at android.os.Handler.handleCallback(Handler.java:942)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:99)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:201)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:288)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:7884)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
03-23 19:49:07.328 26593 26593 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)

Deleting the app's data solved the crash.
Maybe a kind of migraton is needed?

I can consistently crash by switching from dark mode to light mode in the app's settings menu and coming back to the map. Can you reproduce?

@Ayan-10 I'm able to reproduce the issue. Still trying to figure out what could be the root cause since I'm using Mapbox's predefined style for "Dark" just like "Outdoors" and "Streets".
MapLibre offers us the option to use Mapbox Configuration so I continued with it to maintain consistency. I checked the URL being called for the Dark Style and it is "mapbox://styles/mapbox/light-v10" which is consistent with that being called in the case of mapbox-sdk.

Great, no more crash in Contributions now.
However, in addition to the visual issues reported by Ayan, I observe a crash in Explore: tap any picture, then tap the pen icon at the right of the latitude/longitude:
03-24 14:56:06.218 27280 27280 E AndroidRuntime: java.lang.RuntimeException: Unable to start activity ComponentInfo{fr.free.nrw.commons/fr.free.nrw.commons.LocationPicker.LocationPickerActivity}: android.util.AndroidRuntimeException: requestFeature() must be called before adding content
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3641)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3778)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:101)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:138)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2303)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:106)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:201)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:288)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:7884)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: Caused by: android.util.AndroidRuntimeException: requestFeature() must be called before adding content
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at com.android.internal.policy.PhoneWindow.requestFeature(PhoneWindow.java:402)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at fr.free.nrw.commons.LocationPicker.LocationPickerActivity.onCreate(LocationPickerActivity.java:147)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.Activity.performCreate(Activity.java:8341)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.Activity.performCreate(Activity.java:8320)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1417)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3622)
03-24 14:56:06.218 27280 27280 E AndroidRuntime: 	... 12 more

If possible, would you mind using normal push instead of force-push, unless really necessary? Thanks! :-)

@nicolas-raoul Could you please check if the issue still persists?
Meanwhile, I'm trying to fix the dark mode issue.

The crash is not occurring for me anymore.

No crash anymore indeed, thanks!

@Ayan-10 I Just pushed some changes for the "About" and "Settings" screens on dark mode. Please let me know how to get to the 3rd screen with achievements and leaderboard. I can apply a similar fix and test.

To see achievements, you must be logged-in, tap the app's hamburger menu, then tap the cup icon with your usename at the top of the menu.
I will test this branch from now, thanks!

UI that appears bright in dark mode:

Achievements
Leaderboard (right tab next to achievements)
Review, also known as Peer Review, accessible from the hamburger menu
Background of the upload wizard, when the picture does not take the full space (not sure whether this works in master, so no need to worry if not related to your PR)

I'm able to sign up and create an account on the app. I've been able to log in via web but not through the app. Do we have a dummy account created whose credentials I could use?

I guess you have found out that the app has two flavors, beta and prod, matching https://commons.wikimedia.beta.wmflabs.org and https://commons.wikimedia.org.
We usually use prod even for development, unless we need to perform test uploads.

Sorry I noticed a few more places with bright elements in dark mode:
Upload wizard license selection step:

Upload wizard location selection step:

Upload wizard first step:

Custom picker:

Hamburger menu → Feedback:

Nearby location alert:

Upload Wizard Media License - Working on it
Upload Wizard Location Selection Step - Looks the same in master
Upload Wizard First Step - Working on it
Custom Picker - Working on it
Feeback - Looks the same in master
Nearby Location Alert - Unable to verify this.


(CloudFrontToS3): defaults - use cloudfront function instead of lambda@edge for response security headers

Use https://github.com/aws-samples/amazon-cloudfront-functions/blob/main/add-security-headers/index.js for the response security header configuration default instead of lambda@edge
Use Case

See https://github.com/aws-samples/amazon-cloudfront-functions#overview for why this is an improved approach.
Proposed Solution

Replace the default lambda at edge function with the following cloudfront function https://github.com/aws-samples/amazon-cloudfront-functions/blob/main/add-security-headers/index.js
Other

[ ] :wave: I may be able to implement this feature request
[ ] :warning: This feature might incur a breaking change

This is a :rocket: Feature Request

We agree - we already have an internal task looking at making this replacement! :-)

Great to hear @biffgaut!

@biffgaut can you confirm that the function would be appended to any user defined functions in defaultBehavior.functionAssociations ?

One more request 😄 ... that the CSP header values be configurable as mentioned in https://github.com/aws-samples/amazon-cloudfront-functions/tree/main/add-security-headers#add-http-security-headers

Important: Adjust the CSP policy to your specific needs.

Same goes for X-Frame-Options  and X-XSS-Protection, though if this is out of scope for the insertHttpSecurityHeaders option, one can  merely disable the option and copy paste and adjust https://github.com/aws-samples/amazon-cloudfront-functions/blob/main/add-security-headers/index.js to suit one's needs.

Hitendra Nishar is looking at this on our end, I've pinged him to ensure he sees your notes. Our primary goal is to not break existing code, but adding additional optional props is possible.

I'm not sure if this should be a separate issue, but it would be great to be able to leverage CloudFront Functions for re-writing vanity URLs (such as example.com/about or example.com/about/) to reference a valid key when fetching via the REST API from S3 as required when using CloudFront Origin Access Identity.


Automation account errors

Am I missing or need to configuration anything else when running from an Azure Automation account?
Thanks
Warning
Failed adding PivotTable 'P0': Cannot index into a null array.
Failed adding chart for pivotable 'P0': Cannot bind argument to parameter 'PivotTable' bec
Failed adding PivotTable 'P4': Cannot index into a null array.
Failed adding chart for pivotable 'P4': Cannot bind argument to parameter 'PivotTable' because it is null.

Hello, the Excel file is being created?
All the required permissions were added?
All the required modules were installed?
Is this a large environment?


Links in Tab Group Color On Focus and Off Focus

In a previous iteration of Tidy, the links in a Tab Group would brighten up if your mouse focused on the tab group and dim down on off-focus.
Can we bring this feature back?

Personal pref is for this commit => 14238aae3bd50636ed09d12262f17498736124d7

Fixed in 2.12.1


get /studies/studyDbId/germplasm plus  GET /studies/germplasm?studyDbId=

As discussed in #369 there is a need to have /studies?studyDbId=
But then what about all the /studies/studyDbId/germplasm|observationUnit|observationVariable|... calls ?
We could have the following solution:
/studies/germplasm|observationUnit|observationVariable?studyDbId={studyDbId}
What do you think ?
We are evaluating the impact on some of our tools.

ping @mbuy @aliceboizet @bilalelhoudaigui

In BrAPI V2.0 I've tried to address this by mostly removing nested call structures.
So /studies/{studyDbId}/germplasm is replaced with /germplasm?studyDbId={studyDbId} and all similar calls follow this pattern (observations, observationUnits, observationVariables, etc)
This allows for more flexibility without loss of functionality, and it better aligns the response objects. So /germplasm will return the same type of objects whether or not you filter by studyDbId.
Thoughts?


Update Buttons.md

Should display "btn2 is checked" instead of btn1, like on the later example.

Thank you 🙏


feat(setting): only show setting page for a connected user wallet

refs #247

There's also the NodeStatusBar that leads to the settings page. Since we're hiding the settings page entirely, we could just hide the node status in the sidebar.

done https://github.com/akash-network/console/pull/295/files#diff-5dd4aa7a833b73576cfe9e9019748d150105bbb832dae13a062e6c9bb68e8f83R190


Initial try at InputGroup

It’s a scope I uploaded the emotion-bootstrap to npm. FavisionLLC is my
LLC. No need to link any more.
I’ll fix the other stuff.
On Sat, Jul 21, 2018 at 6:11 PM Benny Anderson<EMAIL_ADDRESS>wrote:

@hafabenny commented on this pull request.
Testing with Storybook:
The new Input Group - Buttons/Dropdowns story is returning an error:
"Class constructor Example4 cannot be invoked without new"
Running the "npm test" command returns errors:
/emotion-react-bootstrap/stories/input-group.stories.js
150:22 error Must use destructuring state assignment
react/destructuring-assignment
150:22 error Use callback in setState when referencing the previous state
react/no-access-state-in-setstate
156:25 error Must use destructuring state assignment
react/destructuring-assignment
156:25 error Use callback in setState when referencing the previous state
react/no-access-state-in-setstate
166:2 error HTML entities must be escaped react/no-unescaped-entities
176:21 error Must use destructuring state assignment
react/destructuring-assignment
203:21 error Must use destructuring state assignment
react/destructuring-assignment
229:2 error HTML entities must be escaped react/no-unescaped-entities
In lib/input-group/input-group-addon.js
https://github.com/bwarner/emotion-react-bootstrap/pull/22#discussion_r204212110
:

@@ -0,0 +1,54 @@
+import React from 'react';
+import PropTypes from 'prop-types';
+import { cx } from 'emotion';
+import {

inputGroupAppend,
inputGroupPrepend,
+} from '@farvisionllc/emotion-bootstrap';

what is @farvisionllc? short name for npm?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bwarner/emotion-react-bootstrap/pull/22#pullrequestreview-139259358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnrl381IjabaaZqWUsq8WuIyhQTn_4Iks5uI6cMgaJpZM4VZhNL
.


add topology field and report NUMA node of device

In order to allow the pod scheduling to be topology-aware, we need to
report the NUMA node that each device is associated with.

This is the plugin side of the work being done in kubernetes to add a Topology Manager.  The corresponding API change in Kubernetes is tracked under https://github.com/kubernetes/kubernetes/pull/74423

Note...I just copied the api.pb.go and api.proto files from the kubernetes master branch.  If this is not the proper way to do this please let me know.

Hi @cbf123 thanks for the PR. We use go vendor with glide to manage dependencies for this project. Copy pasting dependencies inside the vendor don't work. In fact, the device plugin apis dependencies( v1beta1/api.pb.go) are already included in the project. All you need to do is update the glide with correct version/refs. Since the Topology manager is not fully merged yet, we do not have a commit id to update the vendor. This is why we decided to wait  until the upstream k8s is ready for this feature.

@ahalim-intel Hi, thanks for the info.  The device plugin API change merged a couple weeks ago, doesn't that give a commit id?  Or do we need to wait for the complete feature?

@ahalim-intel Hi, thanks for the info. The device plugin API change merged a couple weeks ago, doesn't that give a commit id? Or do we need to wait for the complete feature?

Can you find that commit id and I can give it a try locally.

Thanks for the reviews, I think I've addressed all the issues.
Also, I checked the pkg/kubelet/apis/deviceplugin/v1beta1 and pkg/kubelet/apis/pluginregistration/v1 subpackages of kubernetes and the only change in the new git commit ID is the addition of the new topology field.

Added some tests.

It looks like I need to do a "glide update" or equivalent for the APIs pulled in from Kubernetes.  What's the proper way to do this?  If I run "glide update" it ends up changing a whole bunch of unrelated stuff which causes "make test" to break in areas I didn't touch.
Also, I guess I shouldn't be specifying the commit ID in the glide.lock file manually, but rather should be putting it in the glide.yaml file?   How does that work when "k8s.io/kubernetes" isn't a git repo?

It looks like I need to do a "glide update" or equivalent for the APIs pulled in from Kubernetes. What's the proper way to do this? If I run "glide update" it ends up changing a whole bunch of unrelated stuff which causes "make test" to break in areas I didn't touch.
Also, I guess I shouldn't be specifying the commit ID in the glide.lock file manually, but rather should be putting it in the glide.yaml file? How does that work when "k8s.io/kubernetes" isn't a git repo?

After adding the current version you need to run glide update -v.  This may result in updating other dependencies as well and not guaranteed to work. Sometime you may need to update other dependencies version too. It's tricky to get a common versions of package that one or more packages depend on.
One other concern I have, once we update the K8s api version will device plugin be compatible with older version of K8s? Have you tested the device plugin with this changes with an older version of kubelet?

One other concern I have, once we update the K8s api version will device plugin be compatible with older version of K8s? Have you tested the device plugin with this changes with an older version of kubelet?

I have not tested it with an older version of kubelet.  It should just ignore the unknown field, right?

In the most recent iteration I updated glide.yaml to the kubernetes commit that updated the device plugin API, ran "glide update -v" and then backed out all the vendor changes except the kubernetes ones.  Hopefully this is acceptable.

we should verify and confirm that this works with current kubernete version before merging.

One other concern I have, once we update the K8s api version will device plugin be compatible with older version of K8s? Have you tested the device plugin with this changes with an older version of kubelet?

I have not tested it with an older version of kubelet. It should just ignore the unknown field, right?

I tried with v1.15.2, it works fine.
Version details:
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:23:26Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T09:15:22Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

In the most recent iteration I updated glide.yaml to the kubernetes commit that updated the device plugin API, ran "glide update -v" and then backed out all the vendor changes except the kubernetes ones. Hopefully this is acceptable.

I also did a local glide update -v with this PR applied, it results in a different glide.lock with other packages(exclude kubernetes pkg) being pinned to newer commit versions.
I think the vendor pkg should be ok for this PR as long as binary build passes. we could do another glide update to bring latest code from other depend pkgs.
One minor comment is if there will be additional update on this PR, would you please split glide update and real code change in separate commits?

I can happily split them into two commits...I only did them as one because the last glide update was also a single commit. :)

Although it's not supported using device plugin in VM yet, but I'd like to understand how would this be useful in a VM environment, will the numa info retrieved within VM reflects the fact of VF locality? or is it not useful at all because NUMA is configured by VM provider(e.g., OpenStack) in VM spec.

In general it's not useful to report the numa_node in a VM, because there is no guarantee that the NUMA node as seen by the guest has any relationship to the underlying physical topology on the host.
As a thought experiment, consider the case where a single-NUMA-node VM is running on host NUMA node 1, and is associated with a VF from a PF located on host NUMA node 2. Within the guest there is only one NUMA node so the only thing it could report (other than -1) for the VF numa_node would be NUMA node 0...but that's clearly wrong from a host topology perspective.

Right, in the VM case. we probably don't want to use NUMA feature as:

it might report a wrong hints
NUMA affinity may already be guaranteed by infrastructure, e.g. OpenStack where VMs are created on.

It may not be a good idea to have devcie plugin detect whether it's running in a VM environment or not, would it make sense to have a switch to turn off reporting of NUMA info?

Would you please also populate numa field of pciNetDevice structure in pkg/resources/pciNetDevice.go file. It might be useful when other parts of plugin code to reference the numa info.

So in my experience, when running in a VM (even using KVM) the virtual devices report a numa_node of -1.  Does anyone know what gets reported for pci-passthrough devices?
I've updated the code to set the existing "numa" field.

Based on this it looks like if you jump through a bunch of hoops it's possible to get a VM to report numa-affinity for PCI devices.   But I think that if you jump through all those hoops it's probably because you want it to behave like a real system and therefore would want to use the reported numa_node "normally".
As such, I'm not sure we need a switch to control reporting  NUMA or not.

Based on this it looks like if you jump through a bunch of hoops it's possible to get a VM to report numa-affinity for PCI devices. But I think that if you jump through all those hoops it's probably because you want it to behave like a real system and therefore would want to use the reported numa_node "normally".

I agree with that. We tested the pci numa affinity for VMs manually using steps similar to described in above article. Most of VM providers doesn't care about pci numa affinity, but it's possible to configure by hands and if you're configuring it by hands, you're most probably know what you're doing. Even without real passthrough devices, this functionality is highly useful for kubernetes testing.

As such, I'm not sure we need a switch to control reporting NUMA or not.

Anyway, '-1' will be converted to missing Topology field in a device structure, so topology manager will ignore this devices while making decisions.

Based on this it looks like if you jump through a bunch of hoops it's possible to get a VM to report numa-affinity for PCI devices. But I think that if you jump through all those hoops it's probably because you want it to behave like a real system and therefore would want to use the reported numa_node "normally".

Assume a multi-numa VM node, if user doesn't care about numa affinity with SR-IOV device inside VM, then would it be a matter to still report numa_node info of that device?  for example, depends on topology manager policy used (best effort, restrict etc), will kubelet only schedule pods to cpus on the selected numa node(based on reported numa info from device plugin), leaving other cpus on different numa node unused ?

As such, I'm not sure we need a switch to control reporting NUMA or not.

Assume a multi-numa VM node, if user doesn't care about numa affinity with SR-IOV device inside VM, then would it be a matter to still report numa_node info of that device?

To my understanding,
If a resource doesnt care about NUMA it must not report it.
Reporting NUMA will affect Topology Hint generation by topology manager (which is a policy specific behaviour) and device allocation by device manager.

Assume a multi-numa VM node, if user doesn't care about numa affinity with SR-IOV device inside VM, then would it be a matter to still report numa_node info of that device?

@zshi-redhat
To my understanding,
If a resource doesnt care about NUMA it must not report it.

Then question is how would we allow user not reporting the numa hints. should device plugin be able to disable this report or we can just rely on kubelet config to not enable numa.

Reporting NUMA will affect Topology Hint generation by topology manager (which is a policy specific behaviour) and device allocation by device manager.

In the current implementation there is a config option for kubelet to select between "best-effort" or "strict" affinity.  With "strict" affinity it will only allow a container to run if all resources are on the same NUMA node.  With "best-effort" it will try to put them on the same NUMA node but will still allow it to start up even if resources are spread across NUMA nodes.
Personally I think it'd make more sense for the strict/best-effort flag to be set on the container rather than on kubelet.

Personally I think it'd make more sense for the strict/best-effort flag to be set on the container rather than on kubelet.

This was discussed here:
https://docs.google.com/document/d/1g5Aqa0BncQGRedSJH0TJQWq3mw3VxpJ_ufO1qokJ1LE/edit?disco=AAAADW5cXY8

In any case, I don't think we need a flag to control exporting NUMA information from the plugin. If the admin doesn't care about NUMA, they can set "best-effort" in kubelet.

Agreed. Or just not enable the TopologyManager at all.

In the current implementation there is a config option for kubelet to select between "best-effort" or "strict" affinity. With "strict" affinity it will only allow a container to run if all resources are on the same NUMA node. With "best-effort" it will try to put them on the same NUMA node but will still allow it to start up even if resources are spread across NUMA nodes.
Personally I think it'd make more sense for the strict/best-effort flag to be set on the container rather than on kubelet.
In any case, I don't think we need a flag to control exporting NUMA information from the plugin. If the admin doesn't care about NUMA, they can set "best-effort" in kubelet.

Makes sense, best-effort policy can be used if user doesn't care NUMA.

@zshi-redhat it looks like you switched to using go.mod but you kept the existing glide.lock  and glide.yaml files even though they no longer represent what's in the vendor directory.  That seems not quite right.
In any case, this patch can't be rebased due to a change in the vendor directory.  I need to rebuild it.  I assume I need to use go.mod to specify the new k8s version now?

@zshi-redhat it looks like you switched to using go.mod but you kept the existing glide.lock and glide.yaml files even though they no longer represent what's in the vendor directory. That seems not quite right.

Yes, I switched to go.mod as the glide update is not working well as seen in the PR and the update also brings latest grpc version which fixes several CVE bugs(using glide update -v doesn't resolve the dependency correctly).
I will remove glide config files in a separate patch.

In any case, this patch can't be rebased due to a change in the vendor directory. I need to rebuild it. I assume I need to use go.mod to specify the new k8s version now?

use go 1.12 version and run :

apply add topology field and report NUMA node of device commit on top of current master
export GO111MODULE=on if not set.
make build  to update the go.sum
go mod tidy : this removes unused checksum from go.sum
go mod vendor : this update the local vendor pkgs

@zshi-redhat it looks like you switched to using go.mod but you kept the existing glide.lock and glide.yaml files even though they no longer represent what's in the vendor directory. That seems not quite right.
In any case, this patch can't be rebased due to a change in the vendor directory. I need to rebuild it. I assume I need to use go.mod to specify the new k8s version now?

@cbf123 I'm removing glide files in this PR: https://github.com/intel/sriov-network-device-plugin/pull/172

@cbf123 I'm removing glide files in this PR: #172

Update:
We've decided to split out ^above PR and create separate PR to address the glide and travis-ci related changes. The glide files are removed in this PR #173

use go 1.12 version and run :
1. apply `add topology field and report NUMA node of device` commit on top of current master

2. `export GO111MODULE=on` if not set.

3. `make build`  to update the go.sum

This results in an error using go 1.12.9:
../../pkg/resources/pciNetDevice.go:66:12: apiDevice.Topology undefined (type *v1beta1.Device has no field or method Topology)
../../pkg/resources/pciNetDevice.go:66:25: undefined: v1beta1.TopologyInfo
make: *** [/home/cfriesen/devel/sriov-network-device-plugin/build/sriovdp] Error 2
I also get an error if I just try running "go get k8s.io/kubernetes":
...initial bit snipped...
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go: error loading module requirements

According to https://github.com/golang/go/issues/32776 it might be a problem with specifying k8s.io/kubernetes as a dependency:

k8s.io/kubernetes is not primarily intended to be consumed as a module. Only the published subcomponents are (and go get works properly with those).

use go 1.12 version and run :
1. apply `add topology field and report NUMA node of device` commit on top of current master

2. `export GO111MODULE=on` if not set.

3. `make build`  to update the go.sum

This results in an error using go 1.12.9:
../../pkg/resources/pciNetDevice.go:66:12: apiDevice.Topology undefined (type *v1beta1.Device has no field or method Topology)
../../pkg/resources/pciNetDevice.go:66:25: undefined: v1beta1.TopologyInfo
make: *** [/home/cfriesen/devel/sriov-network-device-plugin/build/sriovdp] Error 2
I also get an error if I just try running "go get k8s.io/kubernetes":
...initial bit snipped...
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go<EMAIL_ADDRESS>unknown revision v0.0.0
go: error loading module requirements

I hit the same issue.
I also tried to pin the latest commit of k8s.io/kubernetes and use go version 1.13, neither works.
I don't know if we need to wait until 1.16 gets released which may resolve the conflict?
Or as a temporary solution, copy the kubernetes vendor pkg manually like we did with glide and have all the build using local vendor pkgs instead of running go mod everytime.

I've opened issue https://github.com/kubernetes/kubernetes/issues/82437 to track this, because it seems like a deficiency in the core kubernetes code.

I've opened issue kubernetes/kubernetes#82437 to track this, because it seems like a deficiency in the kubernetes code.

@cbf123 hi, I chatted with @ahalim-intel yesterday and we agreed to revert the go mod support in favor of having this NUMA patch merged. Here is the revert change PR.
With above change, we will continue to use glide for vendor pkg management and hold the two PRs that try to remove glide support(https://github.com/intel/sriov-network-device-plugin/pull/173 and https://github.com/intel/sriov-network-device-plugin/pull/172) until there is a solution to add kubernetes pkg as dependency with go module.

So only the last two commits are really relevent...the third-last one was fixing up a bug in https://github.com/intel/sriov-network-device-plugin/pull/176

I've updated the code...this time I had to update all the vendor packages.  If I only included the Kubernetes changes then the self-tests ran into grpc incompatibilities.

Are there any more comments on this PR?

Tested with restricted topology manager policy + static cpu manager policy, sr-iov pod admit works as expected.
kubernetes version:
Client Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.0-alpha.0.1511+124ed02c93b868", GitCommit:"124ed02c93b868837fe9cf8f357db7d234605a73", GitTreeState:"clean", BuildDate:"2019-09-18T01:20:15Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.0-alpha.0.1511+124ed02c93b868", GitCommit:"124ed02c93b868837fe9cf8f357db7d234605a73", GitTreeState:"clean", BuildDate:"2019-09-18T01:18:03Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

/lgtm

Thanks everyone.


Project status

Are you interested in reviving this project? I'm interested in a tool that does this but isn't broken. I'm considering whether to work on a new one or whether you might be open to me revamping this one to do what it says on the tin using the current state of dependencies.

@alerque depending on what exactly you mean by "a tool that does this", you might find fontmake a suitable alternative.

Seeing as how fontmake is both faster and more correct, I don't see any point in reviving this. I had an idea a smaller footprint single-purpose tool would be better for some use cases, but since writing this have changed my mind (and indeed headed the opposite direction and written a tool with a much bigger footprint that combines existing tooling such as fontmake and others into a full blown build system).


Include/select API: How to handle nullable selection sets

Correct: ✅

Correct: ✅

Wrong: ❌

I think conditional types will be able to resolve this, e.g.:
let listing = Math.random() < 0.5;
let b: typeof listing extends true ? 1 : typeof listing extends false ? null : 1 | null;

Can you elaborate on how this is related to nullable selection sets? The selection sets are the same in both cases. I think what we need to talk about is disallowing any type that is not the boolean literal type true for select and include - so boolean and false should not be allowed.

Can you elaborate on how this is related to nullable selection sets? The selection sets are the same in both cases.

I think his point is, given a photonjs selection set including include: { listings: boolean } then the resulting type for listings should not be listings: Listing[] as is currently the case, but rather listings: Listings[] | null.

I think what we need to talk about is disallowing any type that is not the boolean literal type true for select and include - so boolean and false should not be allowed.

So, wait for a use-case requiring dynamic relation inclusion before taking on support for that? I can see how that makes sense if 1) there are no known use-cases and 2) it makes the implementation more complicated.

Interesting, now I understand the request. Not sure yet if we want to support that, as it breaks a bit the assumption of having compile-time safety and knowning at compile time, which queries are being done.
It's a product discussion to be had.
If we want to go with that, it's not a bug, but an additional feature, as in the listings: false case we would need to add a {listings: null} to the result.

having compile-time safety and knowning at compile time, which queries are being done.

What is the safety issue with listening: Listing[] | null? With such a type, the compiler guarantees that all access must be guarded with existential checks.
I see no problem. If the developer provides a dynamic selection set then that same developer has to handle the consequences of that choice in their downstream codebase. It seems reasonable to me.

it's not a bug

But we do have to change the current system, because it indeed lacks type safety right now, which seems like a bug to me. The options I've seen laid our in this thread so far:

Fix the bug: Constrain the e.g. findOne object argument such that dynamic relation inclusion is disallowed like so:
type FindOneInput = {
  include: {
    listing?: true       // <---- this
  },
  ...

Thereby making turning this into a type error:
findOne({ include: { listing: Math.random() < 0.5 } }) // ERROR

Support the feature: Enhance the e.g. findOne result type such that dynamic relation inclusions is allowed:
findOne({ include: { listing: Math.random() < 0.5 } })

// { listing: Listing[] | null, ... }

findOne({ include: { listing: false } })

//  { listing: null, ... }

findOne({ include: { listing: true } })

// { listing: Listing[], ... }

findOne({ include: {} })

// { ... }

developer has to handle the consequences of that choice
Awesome, that makes a lot of sense!

With it's not a bug I mean the following: The spec says, that only true should be allowed. That means, that you can't even provide boolean from the spec perspective.
But I agree, that we can add boolean as valid option, which gives the user more options, e.g. the Math.random() use-case.
That is probably what we should go with 👍

The spec says

Aside: I like specs :D would like to read it. Where is it?

https://github.com/prisma/rfcs/blob/new-ts-client-rfc/text/0000-new-ts-client.md#basic-queries
To be fair, we don't go in that detail in the written form, it was rather implicit knowledge / interpretation of the spec.
I talked about this with @divyenduz and he made an interesting point:
When introducing the option to allow boolean, we're making the mental model a bit more complicated, as there are then 3 states: true, false and boolean, which the user of the api needs to grasp.

we're making the mental model a bit more complicated

only for users that take on that complexity

as there are then 3 states: true, false and boolean

yep

which the user of the api needs to grasp.

Not to mention whatever weird case they have in the first place leading to boolean type.
As a user, would you expect the boolean capability to be taken away? Does support here make it more complicated for others?

If we're not sure about opening up this functionality the smallest step we can take is as mentioned before:

Fix the bug: Constrain the e.g. findOne object argument such that dynamic relation inclusion is disallowed, e.g. like so:

type FindOneInput = {
  include: {
    listing?: true       // <---- something like this
  },
  ...

Thereby turning this currently accepted expression into a type error:
findOne({ include: { listing: Math.random() < 0.5 } }) // now an error

Because whatever the spec:

To be fair, we don't go in that detail in the written form, it was rather implicit knowledge / when we wrote the spec, that was the unwritten understanding in that point.

The invariant is not currently enforced by the TypeScript types (am I wrong here?)

We will act on this when doing a bigger Photon refactoring.

Update: This is not yet implemented yet.

Hello,
we don't have plans to address in the near-term. If there is a clear demand for this capability, we will obviously be happy to revisit this and reconsider.


Add backend type to allow use of self-configured backend (via template, envs, and/or backend-config options)

Original statement provided by @andrew-sumner. Re purposing as a placeholder for enhancement

I use the artifactory backend and everything required is defined in my terraform configuration, but it seems that this task will ignore that.

As a user, I would like a backend type option that only uses backend configuration I provide (via templates, env vars, and/or backend-config options), so that I can use backend types that are not yet supported.
User will specify the actual backend type (terraform enterprise, artifactory, s3, etc) within their terraform template. This will drive how terraform knows what type to use. Then, the user will be able to provide the configuration options for the backend by specifying it within the template, as -backend-config= option in the Command Options input, and/or environment variables. Terraform allows the collective backend configuration to be split across these different locations.

@andrew-sumner
Can you provide more details about how you are configuring your backend? Is this via env vars or do you have the configuration in your templates (.tf) files? Also, can you provide either the YAML or a screen shot on how you are setting up the init task in your pipeline?
I believe you may be able to work around this by setting the backendType to local. That option will essentially run terraform init with no args. Therefore, if you have the backend configuration set via env vars or in a template, that should allow it use those.

My Terraform configuration file contains:
terraform {
  backend "artifactory" {
    username = "srv-ice-artifactory"
    url      = "https://artifactory2.company.co.nz"
    repo     = "generic-ice-terraform-local"
    subpath  = "FunctionApp/DevTT"
  }
}

On the Terraform CLI Task I have set:
Command: init
Options:  -backend-config="subpath=FunctionApp/$(Release.EnvironmentName)"  -backend-config="password=$(ARTIFACTORY_PASSWORD)"
Backend Type: local - just not sure what impact that might have...
The goal being that the state file is separated for each environment I deploy into, and stored in artifactory.
I probably could use AzureRM but our corporate standard currently is Artifactory and even that may yet change to the Terraform Enterprise backend in the future.

Using a backend type of local works as you suggested.  It's the only non-intuitive setting that I've found.
Thanks for your support and for developing this plugin!

No problem @andrew-sumner. Glad you were able to find a solution on this one as well.
I agree using local for this purpose is not intuitive. That's because local type was not originally developed for this purpose. However, this is becoming more common that people are using the local type as sort of an escape hatch, Just as you did, I have seen others use local to allow them to use a backend that isn't supported like AzureRM. I have been trying to come up with a way to re-label local to indicate this is possible.

If I understand this correctly, #125 should address this, as this is pretty much why I wanted to be able to set env vars during init stage - to allow for self-configured backends to function.

+1 to @favoretti, while the drop-down is still not intuitive, you can use local + .env file in the variables section to configure a remote backend other than Azure Storage. We probably just need to make a few adjustments on the Task UI/YAML to make this more obvious that it can be done.
I am going to leave this open for reasons above. I believe we need to add a self-configured option to the backend type drop-down and add some docs about how this is intended to be used.

I can take this one. I’ll remove deps on backendAzureRm in plan/apply if
backend is self-configured then as well if that’s ok with you.
On Thu, 7 May 2020 at 15:16, Charles Zipp<EMAIL_ADDRESS>wrote:

+1 to @favoretti https://github.com/favoretti, while the drop-down is
still not intuitive, you can use local + .env file in the variables section
to configure a remote backend other than Azure Storage. We probably just
need to make a few adjustments on the Task UI/YAML to make this more
obvious that it can be done.
I am going to leave this open for reasons above. I believe we need to add
a self-configured option to the backend type drop-down and add some docs
about how this is intended to be used.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/charleszipp/azure-pipelines-tasks-terraform/issues/43#issuecomment-625249020,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGERNQTL43EQOTSIE3BP33RQKYC5ANCNFSM4G5QCPJA
.

@favoretti please see my comments in #127 regarding the dependency you are talking about. I am fine with you adding the self-configured option in the drop-down

@charleszipp Let's do it 2-step. I just added part with withAzureRmProvider to refresh, let's get these two merged, then I'll do the self-configured overhaul, it's a bit many places to change, don't wanna have overlapping PRs live at the same time.

@favoretti will be working on a change that should accommodate this.


A way to filter out file types

Hey, I'd love a way to filter out filetypes like ".mp4" as they do not run on services I'd like to use this on. My proposal for this would be random.dog/woof?filter="mp4,png".

Done!

Could you document this feature more? I'd love to use it on my discord bot to not show .mp4 dogs

@mokingguy Just added a little bit of info on the readme.


Refacto imports

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (06b84ba) to head (6b8a487).

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #146   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            8         8
  Lines          595       595
=========================================
  Hits           595       595

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


DO NOT MERGE: Experiment with rolling back the SDK upgrades

This PR should never be merged. It's opened merely to take advantage of our CI. I want to run CI many times against OSBA as it existed prior to "The Great SDK Upgrade of 2018" in order to determine whether the upgraded SDKs are a factor in recent perceived slowness in provisioning in Azure services, most notably with deprovisioning CosmosDB and Redis.

I'm re-running CI on this each time we notice newer builds experiencing issues. My hope is to prove that all issues are unrelated to the upgraded SDKs. So far, based on just a few runs, this does appear to be the case, but I'm not confident enough in that assessment to close this yet.

I'm closing this PR. Over the last few weeks, I am quite satisfied that issues integrating with various Azure services are not more common with the newer SDK. If it's called into question again, this PR can always be resurrected, but I'm closing it for now because it's noise.


Fix issue #3 where key expiry is incorrectly propagated to keys without expiry

The test fixture I added fails without my change to decoder.go

LGTM, thanks!


Feature: function to return list of supported algorithms

Describe the problem you'd like to have solved
While implementing some configuration validation logic, which accepts a array of Algorithm values to be used with jsonwebtoken, I found that the library does not expose the values in a way that can be used at run-time.
In Typescript, we have the Algorithms type, but there is no actual array against which to validate data received from outside sources. It also does not make sense to have that array in our code where we would need to keep it in sync with the library.
Describe the ideal solution
This can be accomplished fairly easily:
export const Algorithm = ['RS256', ...];

The types in "@types/jsonwebtoken" could be easily updated so that Algorithm is a type (as it is now) and also a const array of values.
Alternatives and current work-arounds
Manually keeping the array up-to-date in our software up-to-date with the library.

PS - I am willing to code and submit a PR for this, assuming the maintainers agree that this feature is useful.

PS - I am willing to code and submit a PR for this, assuming the maintainers agree that this feature is useful.

IMHO an hardcoded array would not be a good move, as the list of supported algorithms differs between node versions.
E.g. only since v10 the crypto library supports AES-CCM algorithm (see changelog here)
If a user really wants to see a list of supported algorithms for his platform, I recommend to call crypto.getHashes() after including crypto library (see API docs here).
Hope this helps!

i will fix this issue!


Objective-C + SwiftyVK = ?

Can I use SwiftyVK in my Objective-C project? Or its impossible?

It's impossible because SwiftyVK uses swift structs, enums and tuples that can not be represented in Objective-C. You can use official VK SDK, it,s written in Objective-C.

I need macOS and iOS support, official SDK supported only iOS. Thanks for fast response.

You can write wrapper class in swift and use it from Objective-C.


Commented full solution

[x] I have read freeCodeCamp's contribution guidelines.
[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 freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

Closes #XXXXX

Hello! I just realized I have got the solutions to two challenges mixed up! Just fixed it, and thanks for the feedback!

We try to merge PRs based on who creates an acceptable PR first. There are two other PR before yours (#28499 and #34430 ) which added a solution and hints for this same challenge. If we do not hear back from the other PR soon, we will close it and merge yours instead.

Thank you! Appreciate it ✨

Congrats @InaSLew on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes and look forward to future contributions. 📝


HTML/CSS auto-indent shouldn't trigger when code is in a variable

Hi,
I use Atom to code in PHP and I often insert HTML into PHP strings.
Auto-indent shoudn't be "calculated" on HTML into the var, but on PHP since I'm writting PHP code.
Here is an example of what I'm saying. The left part is what it is actually doing. The right part is what it sould do.

@maxbrunsfeld this is related to the same issue I was pointing out here: using regexes for indentation is not very stable because it doesn't make good use of the tokenizer. In this case, e.g., the tokenizer would already have told us that the recognized regex match is inside a string, and would be ignored. This is fixed in my pull request, but I'm also thinking of completely new indent logic that uses tokens directly (rather than just using tokens to see which matches are in strings).


Missing Documentation on "classic" asyncio

📚 Documentation
It might just be me but I have a hard time finding some documentation on how to use napari with vanilla asyncio/await syntax. I am currently programming a distributed workflow platform which heavily relies on asyncio to facilitate bidirectional communication between the participating apps. I was able to interface with the QTEventloop through the "qasync"  library and the napari gui_qt() context manager, but with the release of the napari.run() pattern I am now wondering what the suggested pattern is for hooking into the event loop. Is there any documentation / examples / general direction for asyncio support?
Thank you for this amazing piece of software. It really makes my python heart beat faster!

Hi @jhnnsrs ... glad to hear you've had success with qasync!
You might actually be one of the first to use/try that ... so no, there isn't any general documentation or examples of asyncio support... but, we would love for you to perhaps submit a PR to our examples repo with what you've got! :)
From the perspective of Qt and the event loopnapari.run really isn't that different than the gui_qt() context manager was, so if you had it working before napari.run(), I'm sure we can get it working with napari.run.
gui_qt() was basically just
from napari.qt import get_app
@contextmanager
def gui_qt():
    app = get_app()
    yield app
    app.exec_()

This was a bit weird though, since the App doesn't actually need to be recreated each time... so after being called once, the context manager was really just an alias for app.exec_().  With napari.run, you can get-or-create the application with napari.qt.get_app() and napari.run() just basically calls app.exec_().
It might be helpful to get an example of how you had it working with gui_qt though.

Hi @tlambert03 , I wouldn't really call it a success just yet :D
The qasync library has sadly some quirks that render some asyncio patterns impossible, most importantly: it runs well on linux (at least in my experience), but it cannot use the Windows ProactorEventloop so running multiple processes  on Windows is not really supported. Also haven't done any benchmarking yet.
Anyhow when choosing the QSelectorEventloop as the default for Windows it seems to be running fine. Here is the relevant code, for a custom context manager that sets the event loop:
import napari
from qasync import QSelectorEventLoop
import asyncio

class async_qt:

    def __enter__(self):
       self.napari_context = napari.gui_qt()
       self.app = self.napari_context.__enter__()
       self.viewer = napari.Viewer()

       self.loop = QSelectorEventLoop(self.app) #QSelectorEventLoop for windows support
       asyncio.set_event_loop(self.loop)
       self.loop.__enter__()
       return self

    def __exit__(self, exc_type, exc_value, exc_traceback):
        task = self.loop.create_task(.....infinite task waiting for socket connections.....)
        self.napari_context.__exit__(exc_type, exc_value, exc_traceback) # Napari Blocking Call
        task.cancel()
        self.loop.__exit__(exc_type, exc_value, exc_traceback)

You do get some benefits from asyncSlots within napari. Not really sure if this is the way to go or to spin up another event loop in a separate thread. I will check it out in the meanwhile and then make a proper PR. Thanks for the great work!

Tested and works like a charm! Both linux and windows are happy.
import os

if os.name == "nt":
    from qasync import QSelectorEventLoop
    EventLoop = QSelectorEventLoop
else:
    from qasync import QEventLoop
    EventLoop = QEventLoop

Safeguard for Windows Import. As windows doesn't give any errors but just blocks indefinitely.

great!  Thanks!  if you do find time to submit a short example PR (with a comment or two on why you find the pattern useful for your work) that would be great :)

@melissawm I had a quick look at this code and I think it's not outdated i.e. the code will function as intended. However, I don't really have enough experience with the tools being used here to write an example that would be meaningful.
I'd say let's leave this open in case someone does come along with such an example!

Hi everyone, just to give a some information about that I ended up not taking the "qasync" route and would maybe advice against trying to address it in any documentation. While qasync seemed like a logical step to integrate asyncio libraries into the qt event loop (e.g. when fetching or streaming data from a webserver), it ended up causing a lot of headaches with platform specific bugs (e.g. this QtEventLoop) and completely stops you from eventually adding the widgets as napari plugins (as you can just replace the qt eventloop on runtie :D).
What works great though is running the asyncio event loop in a seperate thread and connecting the coroutines to qt signals. I have written some smaller helpers around this and could write a more modern asyncio example.

That sounds like a great thing to add to our docs @jhnnsrs! 🙏


feat(shaders) : add A8B8G8R8 shaders properties

Close #653
Thank you R* with your weird shaders :)

Anything related to texture formats is deeply pointless within Sollumz tooling, it should be removed.


nix-doc: broken

nix-doc contains a unit test that breaks on current Nixpkgs builds. As I'm not sure what the test is supposed to check for exactly and whether the breakage might have been caused by a recent update of nix (the project depends on nix-expr), I propose simply marking it as such for now.
I also opened a corresponding GitHub issue upstream: https://github.com/lf-/nix-doc/issues/24
@lf-: I thought I'd simply open this in case you'd need to invest time investigating where this breakage actually comes from. If it's an easy fix, feel free to simply close this PR :)
Description of changes
Mark the project as broken, referring to the upstream ticket.
Failing Hydra build: https://hydra.nixos.org/build/242152066
Hydra log: https://hydra.nixos.org/build/242152066/nixlog/1
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Fixed forward upstream, please don't merge this :)


chore: Update metamask api to the latest version; Polkadot Api update

@BeroBurny regarding @polkadot/wasm-crypto, the error I posted last time looks like appear regardless of the package resolution. So I removed it

LOTM.
just note that the title should be fix or feat to make this PR recognised for creating a new publication

Thank you! I updated the title


[Draft] Introduce empty partials for apps to extend views

The work done on #559 added the ability of hosting apps to use a block to wrap around TasksController#run if so they wish. That works very well in the backend, but the views won't be able to display extended/custom information managed by hosting apps. One way would be to completely rewrite the views, but what if the default views are good enough and users just wanted to inject a little piece of additional info into the engine's own views?
This draft's intent is to gather feedback on how this could be done. The suggestion here is to use empty partials that are rendered by the engine and overridden in the hosting app. I am not sure if the placement of those partials is correct or even if this is a good idea at all. The screenshot below shows how that could look like (for both displaying info from past runs and being able to input new info like the reason) when adding two additional fields (employee and reason) in the hosting app.

Depending on the feedback I will work on putting up a "real" PR for this. I understand we may need to tune the styling a little bit to accommodate this. Thanks.

This seems like a reasonable approach to me! I'm not aware of any other patterns for inserting content into engine views, and this is fairly non-intrusive 😄
The only thing I'm unsure about is whether it's really necessary to have an additional partial for extending the form (app/views/maintenance_tasks/tasks/_custom.html.erb). In this case, it's to support users being able to fill out Reason , but why not just make this an attribute on a parent Task class so that all Tasks show this in the form field that's already rendered by the gem? I understand wanting to extend the views to show info that's set by the controller (like the employee), but seems like any user-submitted info should just make use of the existing parameter support.
Curious to hear thoughts from other folks on my team -- cc @etiennebarrie @nvasilevski

but why not just make this an attribute on a parent Task class so that all Tasks show this in the form field that's already rendered by the gem?

@adrianna-chang-shopify interesting you mentioned that because it was actually my first choice (a BaseTask with a mandatory reason attribute) but I eventually dismissed it for thinking it was too hacky to extract the attribute value in order to fill the reason column 😅. Unless we don't need a separate column for that at all.
@ajkerr What do you think? Should we store the reason/notes as a separate column in the DB or keeping it in the arguments JSON is good enough for us? One might argue it's not pretty but does the job (see below).

Ah actually @promulo that's a good point that storing data in a serialized column is not the same thing as having a separate column on maintenance_tasks_run for some attribute. For data that only needs to be rendered in the UI I feel like keeping things in the arguments column would suffice, but I could see wanting to set a column that needs to be queried and thus requires an index, or a similar use case 🤔
I'll wait for other folks to chime in here -- either way, I think this PR is a good start in the right direction so feel free to mark it as ready to review 😄

Should some documentation be added to the README on how to use the custom block and view?

@ajkerr Since #559 is undocumented behavior, I assumed we'd do the same here, but maybe that was a wrong assumption. @adrianna-chang-shopify @etiennebarrie wdyt?

Since #559 is undocumented behavior, I assumed we'd do the same here, but maybe that was a wrong assumption.

Nope, that was a good assumption! Technically the Run is private API in the gem, but the change to allow Runner.run to yield the run to a block was a necessity to support this framework in Core. I think we should still consider these customization changes to be undocumented.


Store a reference to environment in session to tie its lifetime

By storing a reference to the environment, a session cannot be built in a specific way that causes segmentation faults. This forces a let binding on the environment.
Unfortunately, the fix prevents the monomorphization trick employed for with_model_from_file() which had to be merged with with_model_from_file_monomorphized(). Since this should only be called once per program, I guess the cost is not that much.
Closes #42

Codecov Report

Merging #46 (ae37d58) into master (4a02bc0) will decrease coverage by 5.04%.
The diff coverage is 21.73%.

@@            Coverage Diff             @@
##           master      #46      +/-   ##
==========================================
- Coverage   19.18%   14.13%   -5.05%
==========================================
  Files          17       18       +1
  Lines         610      962     +352
==========================================
+ Hits          117      136      +19
- Misses        493      826     +333

Impacted Files
Coverage Δ

...runtime-sys/src/generated/macos/x86_64/bindings.rs
0.00% <ø> (ø)

onnxruntime/src/session.rs
0.00% <0.00%> (ø)

onnxruntime/src/lib.rs
32.53% <41.02%> (+7.53%)
:arrow_up:

onnxruntime/src/environment.rs
89.83% <50.00%> (+8.47%)
:arrow_up:

onnxruntime/src/memory.rs
93.33% <100.00%> (ø)

onnxruntime/src/tensor/ort_tensor.rs
82.35% <100.00%> (ø)

Continue to review full report at Codecov.

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


Different color for shapes

Saw that in https://github.com/swift502/Sketchbook the physics debugger uses different colors for shapes, thought it was kinda nice. So wondering if it's something we want to add?

See solution in https://github.com/pmndrs/cannon-es-debugger/pull/19#issuecomment-961913981


bmc: fix cyclic dependency between "bmc" and "host" modules

  $ python -c 'import bmc'
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "./cluster-deployment-automation/bmc.py", line 7, in <module>
      import host
    File "./cluster-deployment-automation/host.py", line 12, in <module>
      from bmc import BMC
  ImportError: cannot import name 'BMC' from partially initialized module 'bmc' (most likely due to a circular import) (./cluster-deployment-automation/bmc.py)

Please try this with 3.11


proposal: cmd/go: add GOARM=8 for further optimization on armv7/aarch32

Currently an ARM program built by go will call runtime.udiv() for a division, in which it detect if a hardware divider is available, or use software division.
The main reason is that a hardware divider is an optional component for an ARMv7 machine. But in the real world, most ARMv7 SOC has it, such as RaspberryPi2.
GOARM=8 implies that the program will run in the aarch32 mode (ARMv7 compatible) of an arm64 machine, on which a hardware divider is a must. So

the compiler will directly generate a SDIV/UDIV for div and mod operations.
the program built with GOARM=8 can also run on ARMv7 with a HW Dividor, like RP2.

The go1 benchmark does show some improvement for directly generation of SDIV/UDIV against runtime detection.
name                     old time/op    new time/op    delta
BinaryTree17-4              20.6s ± 0%     20.5s ± 1%   -0.30%  (p=0.000 n=40+40)
Fannkuch11-4                9.31s ± 0%     9.27s ± 0%   -0.42%  (p=0.000 n=40+39)
FmtFprintfEmpty-4           297ns ± 0%     298ns ± 0%   +0.34%  (p=0.000 n=38+40)
FmtFprintfString-4          588ns ± 0%     599ns ± 0%   +1.81%  (p=0.000 n=36+40)
FmtFprintfInt-4             633ns ± 0%     637ns ± 0%   +0.56%  (p=0.000 n=40+29)
FmtFprintfIntInt-4          960ns ± 0%     953ns ± 0%   -0.71%  (p=0.000 n=40+40)
FmtFprintfPrefixedInt-4    1.05µs ± 0%    1.05µs ± 0%     ~     (p=0.194 n=35+38)
FmtFprintfFloat-4          1.95µs ± 0%    1.75µs ± 0%  -10.12%  (p=0.000 n=38+40)
FmtManyArgs-4              3.55µs ± 0%    3.42µs ± 0%   -3.68%  (p=0.000 n=40+40)
GobDecode-4                37.4ms ± 1%    37.4ms ± 1%     ~     (p=0.320 n=37+39)
GobEncode-4                34.7ms ± 1%    34.4ms ± 1%   -0.80%  (p=0.000 n=40+40)
Gzip-4                      2.06s ± 1%     2.07s ± 1%   +0.44%  (p=0.000 n=39+38)
Gunzip-4                    254ms ± 0%     254ms ± 0%   +0.16%  (p=0.000 n=40+38)
HTTPClientServer-4          823µs ± 2%     817µs ± 2%   -0.70%  (p=0.008 n=37+37)
JSONEncode-4               79.4ms ± 0%    76.0ms ± 1%   -4.23%  (p=0.000 n=32+40)
JSONDecode-4                308ms ± 0%     304ms ± 0%   -1.06%  (p=0.000 n=40+39)
Mandelbrot200-4            17.6ms ± 0%    17.6ms ± 0%     ~     (p=0.210 n=34+38)
GoParse-4                  18.9ms ± 1%    18.7ms ± 1%   -1.10%  (p=0.000 n=39+40)
RegexpMatchEasy0_32-4       500ns ± 0%     502ns ± 2%   +0.35%  (p=0.014 n=39+40)
RegexpMatchEasy0_1K-4      3.82µs ± 0%    3.82µs ± 0%   +0.15%  (p=0.000 n=40+40)
RegexpMatchEasy1_32-4       546ns ± 0%     548ns ± 1%   +0.44%  (p=0.000 n=40+40)
RegexpMatchEasy1_1K-4      4.78µs ± 0%    4.79µs ± 0%   +0.16%  (p=0.000 n=38+37)
RegexpMatchMedium_32-4      737ns ± 2%     741ns ± 3%   +0.53%  (p=0.026 n=40+40)
RegexpMatchMedium_1K-4      164µs ± 0%     162µs ± 0%   -0.72%  (p=0.000 n=39+35)
RegexpMatchHard_32-4       10.6µs ± 0%    10.5µs ± 0%   -0.86%  (p=0.000 n=40+40)
RegexpMatchHard_1K-4        316µs ± 0%     312µs ± 0%   -1.13%  (p=0.000 n=38+40)
Revcomp-4                  40.5ms ± 3%    40.8ms ± 2%   +0.85%  (p=0.001 n=40+39)
Template-4                  395ms ± 0%     387ms ± 0%   -2.07%  (p=0.000 n=40+39)
TimeParse-4                2.68µs ± 0%    2.65µs ± 0%   -1.12%  (p=0.000 n=40+40)
TimeFormat-4               5.42µs ± 0%    5.29µs ± 0%   -2.30%  (p=0.000 n=38+37)
[Geo mean]                  304µs          302µs        -0.88%

name                     old speed      new speed      delta
GobDecode-4              20.5MB/s ± 1%  20.5MB/s ± 1%     ~     (p=0.284 n=37+39)
GobEncode-4              22.1MB/s ± 1%  22.3MB/s ± 1%   +0.81%  (p=0.000 n=40+38)
Gzip-4                   9.41MB/s ± 1%  9.37MB/s ± 1%   -0.41%  (p=0.000 n=38+38)
Gunzip-4                 76.5MB/s ± 0%  76.4MB/s ± 0%   -0.16%  (p=0.000 n=40+38)
JSONEncode-4             24.4MB/s ± 0%  25.5MB/s ± 1%   +4.42%  (p=0.000 n=32+40)
JSONDecode-4             6.31MB/s ± 0%  6.37MB/s ± 0%   +1.02%  (p=0.000 n=40+35)
GoParse-4                3.06MB/s ± 1%  3.10MB/s ± 1%   +1.13%  (p=0.000 n=39+40)
RegexpMatchEasy0_32-4    63.9MB/s ± 0%  63.7MB/s ± 2%     ~     (p=0.070 n=39+40)
RegexpMatchEasy0_1K-4     268MB/s ± 0%   268MB/s ± 0%   -0.15%  (p=0.000 n=40+40)
RegexpMatchEasy1_32-4    58.6MB/s ± 0%  58.3MB/s ± 1%   -0.44%  (p=0.000 n=40+40)
RegexpMatchEasy1_1K-4     214MB/s ± 0%   214MB/s ± 0%   -0.16%  (p=0.000 n=38+37)
RegexpMatchMedium_32-4   1.36MB/s ± 3%  1.35MB/s ± 3%   -0.70%  (p=0.022 n=40+40)
RegexpMatchMedium_1K-4   6.26MB/s ± 0%  6.31MB/s ± 0%   +0.73%  (p=0.000 n=37+40)
RegexpMatchHard_32-4     3.01MB/s ± 1%  3.04MB/s ± 0%   +1.03%  (p=0.000 n=40+40)
RegexpMatchHard_1K-4     3.25MB/s ± 0%  3.28MB/s ± 0%   +1.05%  (p=0.000 n=40+40)
Revcomp-4                62.8MB/s ± 4%  62.3MB/s ± 2%   -0.86%  (p=0.001 n=40+39)
Template-4               4.91MB/s ± 0%  5.01MB/s ± 0%   +2.11%  (p=0.000 n=40+39)
[Geo mean]               17.0MB/s       17.1MB/s        +0.53%

I don't think it is a good idea to introduce another GOARM value for only two instructions and a performance gain less than 1% of geomean. I think dynamic feature detection is still better in this case. If the overhead of a runtime call is larger than we thought, we could generate the feature test and conditional branch inlined. Compared to a division operation, I don't think the overhead of a conditional branch is not acceptable.

unfortunantely, the go1 benchmark shows little improvement for a runtime check of a hardware dividor.
name                     old time/op    new time/op    delta
BinaryTree17-4              21.1s ± 1%     21.3s ± 1%  +1.30%  (p=0.000 n=40+40)
Fannkuch11-4                8.34s ± 0%     8.08s ± 0%  -3.14%  (p=0.000 n=40+40)
FmtFprintfEmpty-4           285ns ± 0%     284ns ± 0%  -0.24%  (p=0.000 n=40+34)
FmtFprintfString-4          578ns ± 0%     570ns ± 0%  -1.30%  (p=0.000 n=38+40)
FmtFprintfInt-4             613ns ± 0%     597ns ± 0%  -2.56%  (p=0.000 n=33+40)
FmtFprintfIntInt-4          915ns ± 0%     898ns ± 0%  -1.87%  (p=0.000 n=39+40)
FmtFprintfPrefixedInt-4    1.00µs ± 0%    0.98µs ± 0%  -1.16%  (p=0.000 n=38+37)
FmtFprintfFloat-4          1.86µs ± 0%    1.88µs ± 0%  +0.84%  (p=0.000 n=37+37)
FmtManyArgs-4              3.39µs ± 0%    3.36µs ± 0%  -0.84%  (p=0.000 n=40+40)
GobDecode-4                32.5ms ± 1%    33.3ms ± 1%  +2.45%  (p=0.000 n=39+39)
GobEncode-4                29.0ms ± 1%    29.1ms ± 1%  +0.48%  (p=0.001 n=36+40)
Gzip-4                      2.00s ± 2%     1.99s ± 2%  -0.47%  (p=0.019 n=40+39)
Gunzip-4                    239ms ± 0%     240ms ± 1%  +0.50%  (p=0.000 n=40+40)
HTTPClientServer-4          705µs ± 2%     729µs ± 4%  +3.52%  (p=0.000 n=35+36)
JSONEncode-4               75.4ms ± 1%    75.4ms ± 1%    ~     (p=0.845 n=36+39)
JSONDecode-4                307ms ± 5%     307ms ± 5%    ~     (p=0.407 n=39+36)
Mandelbrot200-4            16.5ms ± 0%    16.5ms ± 0%    ~     (p=0.206 n=37+40)
GoParse-4                  21.6ms ± 6%    21.7ms ± 6%    ~     (p=0.819 n=39+39)
RegexpMatchEasy0_32-4       475ns ± 0%     479ns ± 0%  +0.84%  (p=0.000 n=34+32)
RegexpMatchEasy0_1K-4      3.58µs ± 0%    3.58µs ± 0%    ~     (p=0.090 n=39+40)
RegexpMatchEasy1_32-4       515ns ± 1%     513ns ± 0%  -0.33%  (p=0.000 n=39+37)
RegexpMatchEasy1_1K-4      4.52µs ± 1%    4.47µs ± 0%  -1.10%  (p=0.000 n=40+40)
RegexpMatchMedium_32-4     32.6ns ± 0%    32.6ns ± 0%    ~     (p=0.265 n=40+40)
RegexpMatchMedium_1K-4      154µs ± 0%     153µs ± 0%  -0.68%  (p=0.000 n=37+40)
RegexpMatchHard_32-4       10.0µs ± 0%     9.9µs ± 0%  -1.30%  (p=0.000 n=32+40)
RegexpMatchHard_1K-4        299µs ± 0%     295µs ± 0%  -1.35%  (p=0.000 n=39+38)
Revcomp-4                  34.6ms ± 2%    34.5ms ± 2%    ~     (p=0.054 n=39+38)
Template-4                  518ms ± 4%     519ms ± 3%    ~     (p=0.702 n=40+38)
TimeParse-4                2.47µs ± 0%    2.49µs ± 0%  +0.77%  (p=0.000 n=39+40)
TimeFormat-4               5.06µs ± 0%    5.08µs ± 1%  +0.34%  (p=0.000 n=40+39)
[Geo mean]                  262µs          262µs       -0.17%

name                     old speed      new speed      delta
GobDecode-4              23.6MB/s ± 1%  23.1MB/s ± 1%  -2.39%  (p=0.000 n=39+39)
GobEncode-4              26.5MB/s ± 1%  26.4MB/s ± 1%  -0.48%  (p=0.001 n=36+40)
Gzip-4                   9.71MB/s ± 2%  9.76MB/s ± 2%  +0.48%  (p=0.022 n=40+39)
Gunzip-4                 81.1MB/s ± 0%  80.7MB/s ± 1%  -0.50%  (p=0.000 n=40+40)
JSONEncode-4             25.7MB/s ± 1%  25.7MB/s ± 1%    ~     (p=0.886 n=36+39)
JSONDecode-4             6.33MB/s ± 5%  6.31MB/s ± 5%    ~     (p=0.313 n=39+37)
GoParse-4                2.68MB/s ± 7%  2.67MB/s ± 6%    ~     (p=0.802 n=39+39)
RegexpMatchEasy0_32-4    67.4MB/s ± 0%  66.8MB/s ± 0%  -0.85%  (p=0.000 n=40+34)
RegexpMatchEasy0_1K-4     286MB/s ± 0%   286MB/s ± 0%    ~     (p=0.120 n=39+40)
RegexpMatchEasy1_32-4    62.2MB/s ± 1%  62.4MB/s ± 0%  +0.36%  (p=0.000 n=40+37)
RegexpMatchEasy1_1K-4     226MB/s ± 1%   229MB/s ± 0%  +1.12%  (p=0.000 n=40+40)
RegexpMatchMedium_32-4   30.6MB/s ± 0%  30.6MB/s ± 0%    ~     (p=0.126 n=40+40)
RegexpMatchMedium_1K-4   6.65MB/s ± 0%  6.70MB/s ± 0%  +0.70%  (p=0.000 n=38+32)
RegexpMatchHard_32-4     3.19MB/s ± 0%  3.23MB/s ± 0%  +1.32%  (p=0.000 n=32+37)
RegexpMatchHard_1K-4     3.42MB/s ± 0%  3.47MB/s ± 0%  +1.46%  (p=0.000 n=40+38)
Revcomp-4                73.4MB/s ± 2%  73.6MB/s ± 2%    ~     (p=0.061 n=39+38)
Template-4               3.75MB/s ± 5%  3.74MB/s ± 3%    ~     (p=0.634 n=40+38)
[Geo mean]               21.2MB/s       21.2MB/s       +0.04%

The reason why "GOARM=8" works well, is due to

the software division routine clobbers 2 extra registers.
the software division routine clobbers the input registers with the results filled.

With the "GOARM=8", the compile can fill more spilt values to the saved registers, and so the go1 benchmark improves.
So I strongly suggest adding GOARM=8, as ARM's official definition:

ARMv8 == Aarch64 + Aarch32
Aarch64 (ARM's term) == ARM64 (Go's term)
Aarch32 = ARM32 + HWDIV + some other features

GOARM=8 does not only improve division speed, but also has potential benefits (running arm32 program on a armv8 machine)

Should the results from the last comment be more impactful after the #40724 ? 🤔

I don't think it is a good idea to introduce another GOARM value for only two instructions and a performance gain less than 1% of geomean. I think dynamic feature detection is still better in this case.

I'm not sure if that's applicable here (or even possible with modern memory protection mechanisms), but in the past dynamic feature detection was sometimes implemented by patching the executable at runtime, one invocation at a time.


Why does Json.stringify return an Either?

🚀 Feature request
Current Behavior
Json.stringify is currently defined as: https://github.com/gcanti/fp-ts/blob/01b8661f2fa594d6f2010573f010d358e6808d13/src/Json.ts#L60
Desired Behavior
Coming from PureScript, I don't expect encoding a value as JSON to fail.
Suggested Solution
It seems to me rather than trying to encode any JS value as JSON, most use cases (and I could be wrong here) will be trying to encode a value that extends Json.Json. If that's the case, stringify could pretty safely be implemented as:
const stringify = <Value extends Json>(value: Value): string => JSON.stringify(value)

Of course I could be overlooking an obvious reason that the current implementation makes more sense. But if the current implementation is necessary for some cases, while the implementation suggested here would work for most, then I think it's worth providing both.
Who does this impact? Who is this for?
Maybe just me but I assume this would benefit all users as they could avoid having to deal with failure when encoding JSON.
Your environment

Software
Version(s)

fp-ts
2.16.1

TypeScript
5.1.6

JSON.stringify throws a TypeError when the value contains a circular reference or a BigInt.

JSON.stringify throws a TypeError when the value contains a circular reference or a BigInt.

BigInt doesn't extend Json though. And while I'm still learning TS, I can't figure out how to construct a self-referencing Json type without using any then casting it to Json with stringify(notJson as Json), which if you're doing, then you should expect type-errors anyway.
So without deliberately circumventing the compiler, you shouldn't be able to call the stringify function I suggested with either.


Update miniconda - change the default installation path

Move the installation to /usr/local instead of home directory (same as anaconda #32706).
After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

I think it would make more sense to set the prefix to "#{staged_path}/miniconda" and only linking the needed binarys.

@reitermarkus I have no idea which one is better, but anaconda.rb uses #{HOMEBREW_PREFIX} (anaconda.rb#L14).
All the binary files are in miniconda/bin, including the executable files of packages installed afterwards with conda. Usually people add miniconda/bin to PATH instead of symlinking some files.

Ok, let's leave it as is then, thanks!


Better error for git dependencies

Out of the box:
> uvx --with 'git+https://github.com/tox-dev/tox.git@MISTAKE#egg=tox' tox --version
Updating https://github.com/tox-dev/tox.git (MISTAKE)                                                                                × Invalid `--with` requirement
  ╰─▶ Git operation failed

while it points to git, the git dep syntax is a bit quirky and I wish a little more info could be provided...
as a regular end user, I'm left guessing whether I got git+https wrong, or org name or repo name or branch name or egg name or perhaps there's a network or credential issue.
uv-tool-uvx 0.5.1 (Homebrew 2024-11-08)

Ok, perhaps "MISTAKE" kinda gives it away, I had a typo in a feature branch name, not main or mistake.


Shrink-wrapping Viewport

Also:

ScrollView.shrinkWrap
Port Block to ScrollView.shrinkWrap where possible
Port Block to SingleChildScrollView/BlockBody where not
Remove scrollableKey from twoLevelList
Remove ScrollableViewport2
Refactor ScrollGrid to extend ScrollView to avoid code duplication
Add padding to SingleChildScrollView
More testing

Refactor ScrollGrid to extend ScrollView to avoid code duplication

Interesting!