Introduce a new WiFi manager

Introduce a new WiFi manager to support general-purpose full functional
Wi-Fi control plane, including both STA and SoftAP mode.
- Service-orientation, modular design, general purpose
- Dedicated state machine for each mode,
  which has the knowledge of the Wi-Fi status
- Support OPEN/WPA-PSK/WPA2-PSK
- Support RTT
- Support delete station and blacklist function of SoftAP
- Support configuration saving
- Provide blocked APIs to simplify the process of asynchronous actions
- Support multiple clients
- POSIX compliant
- Easy to extend & maintain

This manager provides another option for offload Wi-Fi devices.

The new Wi-Fi manager goes with Unisoc UWP566x Wi-Fi driver.(https://github.com/zephyrproject-rtos/zephyr/pull/15014)

Codecov Report

Merging #15022 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #15022   +/-   ##
=======================================
  Coverage   52.92%   52.92%
=======================================
  Files         309      309
  Lines       45268    45268
  Branches    10451    10451
=======================================
  Hits        23956    23956
  Misses      16544    16544
  Partials     4768     4768

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 195195a...518d2da. Read the comment docs.

@jukkar

Most of this stuff is generic and should be added to subsys/net/l2/wifi/wifi_{mgmt|shell}.c files.

Yes, this new WiFi Manager is for general purpose, and can be used by other WiFi vendors.
Meanwhile, it's a dedicated module, and has no relation with existed network management.
Perhaps it's the time to create a new subsystem for WiFi.

shell part looks ok.

Can you approve or dimissis your request for changes @jarz-nordic ?

Something to think about (piggy backing on @jukkar comment) is whether we want to consider a common WiFi interface. The existing WiFi management assumes the underlying WiFi basically has a complete offload capability of AP/STA modes while this PR appears to implement the STA/AP mode up in the host (which is useful). So should we consider a normalized/common WiFi interface for the application layers to use where offload can be optionally used for devices that support it or use the code here to implement the various modes?

Something to think about (piggy backing on @jukkar comment) is whether we want to consider a common WiFi interface. The existing WiFi management assumes the underlying WiFi basically has a complete offload capability of AP/STA modes while this PR appears to implement the STA/AP mode up in the host (which is useful). So should we consider a normalized/common WiFi interface for the application layers to use where offload can be optionally used for devices that support it or use the code here to implement the various modes?

Yes, the WiFi management does well for the offload WiFi devices.I've ever tried to adapt our WiFi device for it before. However, it has no knowledge of the WiFi status and leaves the synchronization problem to the users. Let's take the auto-connect scenario for example. If you want the WiFi to auto-connect the specified AP once the board is powered on, at least two operations (scan and connect) will be necessary. Using WiFi management, you will need to use a synchronous mechanism to wait for scan done before issuing connect, which is inconvenient obviously. Furthermore, considering the scenario of multiple clients, you are manipulating WiFi through shell command while the auto-connect program is running in the background. The confliction between the two clients will be inevitable if there is no WiFi state machine. Therefore I develop the new WiFi manager which can handle the problems mentioned above.

Any plans for supporting the enterprise security modes?

Any plans for supporting the enterprise security modes?

Well, it depends on the user's requirement.
Through WPA Enterprise is important for WiFi, I'm not sure whether it is necessary for IoT devices.
Besides, lots of EAP methods need to be implemented due to IEEE 802.1x standard. This will consume much more memoy and let the WiFi manager become hostap perhaps.

I'm not fully aware of all of the capabilities of these offloaded modules but it seems like they manage most of connection. I like what you are presenting here because it starts to enable into Zephyr more of the WiFi functionality that would be needed for platforms where there is WiFi IP but it isn't an offload like we currently have. Eventually, I would like to see Zephyr have something similar to what Linux has with an upper/lower MAC abstraction that would also need the layer you are presenting here.
My comment for normalizing the interfaces is mainly a desire to have a common configuration/management interface for WiFi that supports various levels of off-loading.

There is some interesting functionality added here, and glad to see the introduction of a WiFi control API.
Along the lines of the comments by @jukkar and @dleach02, I'm trying to see how existing NET_OFFLOAD or SOCKET_OFFLOAD WiFi drivers would work with this.
This PR introduces a separate subsystem, and so (naturally) duplicates some of the existing functionality found around current WiFi drivers based on struct net_wifi_mgmt_offload:

WiFi driver apis:   scan, connect, disconnect, ap_enable/ap_disable APIs and NET_EVENT_WIFI_ commands already defined in include/net/wifi_mgmt.h - can that be leveraged/extended?
WiFi Shell:   subsys/net/l2/wifi/wifi_shell.c: - can this be extended as well?
WiFi API:   wifi_register_<*>_notifier() - can this leverage existing net_mgmt subsystem?
WiFi API:   wifi_sta_<>/wifi_ap_<> apis - If a NET_OFFLOAD driver is configured in the system, could these APIs be made to vector to those drivers - it would be nice to have a public API for them too.

Also, on SoftAP:  Is the plan for this to support WiFi provisioning in the future?
That could be interesting, as currently each vendor has their own method (though some vendor's methods may be more secure, if the passwords are negotiated via the offload chip and stored in secure flash).

There is some interesting functionality added here, and glad to see the introduction of a WiFi control API.
Along the lines of the comments by @jukkar and @dleach02, I'm trying to see how existing NET_OFFLOAD or SOCKET_OFFLOAD WiFi drivers would work with this.
This PR introduces a separate subsystem, and so (naturally) duplicates some of the existing functionality found around current WiFi drivers based on struct net_wifi_mgmt_offload:

WiFi driver apis:   scan, connect, disconnect, ap_enable/ap_disable APIs and NET_EVENT_WIFI_ commands already defined in include/net/wifi_mgmt.h - can that be leveraged/extended?

As previously mentioned, I've ever tried to adapt our WiFi device for WiFi management before. However, those APIs aren't blocked APIs, and expose both WiFi commands (scan, connect, disconnect) and corresponding events to the users instead. The users have to handle synchronization by themselves. Moreover, it can't support multiple clients without synchronous mechanism and state machine. I can't see any possibility to leveraged/extended.

WiFi Shell:   subsys/net/l2/wifi/wifi_shell.c: - can this be extended as well?
WiFi API:   wifi_register_<*>_notifier() - can this leverage existing net_mgmt subsystem?

The whole WiFi management is just a bundle of net_mgmt hooks, and has no control logic at all. In contrast, the intention of introducing the WiFI manager is to provide a general purpose and dependent subsystem for WiFi control plane with full function including blocked APIs and status machine. I think the question is what kind of WiFi management does Zephyr need.

WiFi API:   wifi_sta_<>/wifi_ap<_> apis - If a NET_OFFLOAD driver is configured in the system, could these APIs be made to vector to those drivers - it would be nice to have a public API for them too.

The WiFi manager only cares about the control plane and has nothing to do with the data plane. Hence it can absolutely support NET_OFFLOAD drivers.

if the passwords are negotiated via the offload chip and stored in secure flash).

Yes, the WiFi manager will be able to handle l2 packets, even IEEE 802.1x in the near future if the memory footprint is not a problem.

stale, closing. Reopen when there are updates...


WIP_error_pages

WIP
Resolves #123
Main changes are in the routes, controllers, views and application.css files
No tradeoffs or dependencies.
I haven't done any tests to this too, until design approved
Thanks
Admir

Hooray, a PR! :tada:
For easy reference, here's a link and screenshot for the 404 page (right now, all the error templates show the same thing):

This isn't about the design, but it's something I'm concerned about: since this uses the main app layout, what happens if something in the navbar (for example) throws a server error? The error page won't be able to display–does it have a fallback? Is it worth using the application layout (which can throw errors) instead of the static page?

@admir23 Hi! Are you still working on this issue? If not, I can mark it "help wanted".
Any thoughts/question on my concerns with using the application layout for errors?

@leesharma Hi! I'm still working on it, but you can mark it "help wanted" if it's urgent.
I'm still researching on this, so I will let you know if I have any questions :)

@admir23 Sure thing, good luck with the research!  :)

I'm going to close this PR since there haven't been any new commits for a few months. Let me know if it should be reopened!


[admin] Publish

Docs Build status updates of commit ff06e42:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/docs-ref-autogen/excel/excelscript/excelscript.autofilltype.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.range.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.rangeborder.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.rangefill.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.rangeformat.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/docs-ref-autogen/excel/excelscript/excelscript.worksheet.yml
:white_check_mark:Succeeded
View (office-scripts)

docs/sample-scripts/excel-scripts.yaml
:white_check_mark:Succeeded

generate-docs/json/excel/snippets.yaml
:white_check_mark:Succeeded

generate-docs/tools/API Coverage Report.csv
:white_check_mark:Succeeded

generate-docs/tools/Office Sample Coverage.osts
:white_check_mark:Succeeded

generate-docs/tools/coverage-tester.ts
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


GraphQL schema suggestions

As part of reviewing the GraphQL schema, I thought some aspects were slightly confusing as detailed below.
Nullable fields on Contents
The fields value, metadata and hash are optional for the type Contents. This reflects that a particular key could be either present or not, but I suggest this should rather be reflected by returning null rather than "empty" Contents object.
In practice, this means instead of returning this JSON ...
{
  "someContentsField": {
    "key": "key/not/present",
    "value": null,
    "metadata": null,
    "hash": null
  }
}

... return this JSON instead:
{
  "someContentsField": null
}

Suggested diff in SDL terms:
 type Contents {
-  hash: String
+  hash: String!
   key: String!
-  metadata: String
-  value: String
+  metadata: String!
+  value: String!
 }

Relationship between Node and Contents
The relationship between the types Node ("folders") and Contents ("files") are not clear to me right now. The type Node has fields value and metadata similar to Contents, which makes it "file-like". I think we should either:
Option 1: Collapse types
The types Node and Contents could be collapsed into a single type. This would probably require adding a new field kind: TreeKind!, where TreeKind is an enum of NODE and CONTENTS.
Suggested diff in SDL terms:
-type Contents {
-  ...
-}

-union Tree = Contents | Node

+enum TreeKind {
+  NODE
+  CONTENTS
+}

-type Node {
+type Tree {
  hash: String!
  key: String!
  metadata: String
  tree: [Tree!]!
  value: String
+  kind: TreeKind!
}

(the above diff includes renaming Node to Tree)
This is the simplest approach and somewhat mirrors the types in OCaml, where "files and folders" are not clearly differentiated either IMHO 😛 I don't find it particularly clean though, and I'm concerned it will lead to suboptimal client code.
Option 2: More clearly disambiguate
We could more clearly disambiguate between "folders" (Node) and "files" (Contents). To pursue this option, I think we should remove the fields value and metadata from Node. This requires changing the type of the field Node.get to Tree rather than Node to reflect it could be either a “file or folder”.
Suggested changes in SDL terms:
 type Node {
-  get(step: Step): Node
+  get(key: Key!): Tree
   hash: String!
   key: String!
-  metadata: String
   tree: [Tree!]!
-  value: String
 }

If we pursue this approach, I think we should also consider how to make the following fields and their types more consistent:
type Branch {
  get(key: Key!): String
  get_tree(key: Key!): [Contents!]
  get_all(key: Key!): Contents
  ...
}

type Node {
  get(key: Key!): Tree
  ...
}

Changes in this PR
The changes in this PR include:

Making fields on Contents non-nullable.
Implementing option 2 (disambiguation) by removing fields value and metadata from Node and changing the type of the field Node.get.
Getting rid of the scalar type Step, which was only used in a single instance, which I found inconsistent.
The source type of Node is not changed (tree * key), but the semantics change: the tree is now fully resolved to the actual subtree, and the key is only part of the source type to support the key field.

@zshipko, I fixed the issue you pointed out and added another suggestion:
type query {
-  branches: [String!]!
+  branches: [Branch!]!
  ...
}

What do you think of that?

That seems reasonable to me. I will do one more round of testing then merge this if everything looks good!


DBZ-3556 Reduce database round-trip for LOB handling

https://issues.redhat.com/browse/DBZ-3556

Hey @TAregger, is that along the lines of what you had in mind?

Yes looks good. Should we consider moving the method somewhere else (e.g. OracleValueConverters), as it not depending on a database connection anymore?

Yes looks good.

Thanks!

Should we consider moving the method somewhere else (e.g. OracleValueConverters)

Yes, good idea; OVC is the only place where this method is called, so I made it private too. Thanks all!


How to write a custom component which inherit props from an existing one?

What problem does this feature solve?
for example, in react, I can define a custom input component like this:
function MyInput(props: React.PropsWithChildren<React.HTMLProps<HTMLInputElement>> & {
  foo: string
}) {
  const [value, setValue] = useState('')
  const onChange = useCallback((e: React.ChangeEvent<HTMLInputElement>) => {
    console.log(props.foo)
    setValue(e.target.value)
  }, [])
  return <input {...props} value={value} onChange={onChange} />
}

What does the proposed API look like?
Vue.HTMLProps

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

by the way, I can use Omit<React.HTMLProps, 'value', 'placeholder'> to filter out props

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

by the way, I can use Omit<React.HTMLProps, 'value', 'placeholder'> to filter out props

You can use $attrs to passthrough, for example, https://codepen.io/hcysunyang/pen/abBoRpQ, also check out https://v3.vuejs.org/guide/component-attrs.html#attribute-inheritance

checked the example but it's not written by typescript and MyInput is a plan object without props type definition...

So, what are you really asking? is it about the pass-through props? or about TS type?

So, what are you really asking? is it about the pass-through props? or about TS type?

So, what are you really asking? is it about the pass-through props? or about TS type?

with ts I can get both type definition(for auto completion) and props inherition

So, what are you really asking? is it about the pass-through props? or about TS type?

with ts I can get both type definition(for auto completion) and props inherition

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

FunctionalComponent is exactly what I need! but I receive compile error
TS2304: Cannot find name 'InputHTMLAttributes'.
should I import @types/react into a vue project?

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

FunctionalComponent is exactly what I need! but I receive compile error
TS2304: Cannot find name 'InputHTMLAttributes'.
should I import @types/react into a vue project?

import it from vue:
import { InputHTMLAttributes } from 'vue

import it from vue:
import { InputHTMLAttributes } from 'vue

import it from vue:
import { InputHTMLAttributes } from 'vue

it works! thank you

import it from vue:
import { InputHTMLAttributes } from 'vue

it works! thank you

you can also do this:
import { FunctionalComponent } from 'vue'

const MyInput: FunctionalComponent<InputHTMLAttributes & { foo?: string}> = (props) => {
  return <input {...props}/>
}

const el = <MyInput foo="str" autofocus  />

使用 defineComponent 的时候怎么做呢？


FINERACT-1103 - Resolve org.eclipse.persistence.exceptions.EntityMana…

https://issues.apache.org/jira/browse/FINERACT-1103

I will just self merge this.

@xurror I just reviewed this (today only; I'm way behind..) and raised a Q about it in FINERACT-1103.


Duplicate symbol between GCM and GPG

I know duplicate symbol is a recurrent issue but this one is particular or a least my knowledge in iOS dev do not help me.
I used to use GooglePlayGames (GPG) in my final application and GoogleCloudMessaging (GCM) in my SDK but today for some reason things started to explode (idea: Due to the last GCM update but I can't get the old version)
Considering the last version of GCM in my SDK, I have:
Podfile
pod 'Google/CloudMessaging' # Nothing special...

Output
$ pod update
Update all pods
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
...
Installing GGLInstanceID (1.1.5)                 # Dependencies
Installing Google (1.3.2)                        # relative to GCM
Installing GoogleCloudMessaging (1.1.2)
Installing GoogleIPhoneUtilities (1.1.1)
Installing GoogleInterchangeUtilities (1.1.0)
Installing GoogleNetworkingUtilities (1.0.0)
Installing GoogleSymbolUtilities (1.0.3)
Installing GoogleUtilities (1.1.0)
...
Generating Pods project
Integrating client project

And in my final application:
Podfile
pod 'GooglePlayGames' # Nothing special...

Output
$ pod update
Update all pods
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
...
Installing GoogleAppUtilities (1.0.0)           # Dependencies relative
Installing GoogleAuthUtilities (1.0.1)          # to GPG
Installing GooglePlayGames (5.0)
Installing GooglePlusOpenSource (1.7.1)
Installing GoogleSignIn (2.4.0)
...
Generating Pods project
Integrating client project

When I build my final application, this is the error I have (explicit but I don't find any solution...)
duplicate symbol _OBJC_CLASS_$_GIPLocale in:
/Users/Path/To/App/Pods/GoogleIPhoneUtilities/Libraries/libGIP_Locale.a(GIPLocale.o)
/Users/Path/To/App/Pods/GooglePlayGames/gpg-cpp-sdk/ios/gpg.framework/gpg(GIPLocale.o)

As far as I understand, I have GIPLocale twice which makes me have duplicate symbol. And if we take a look at the Pods concerned, one belongs to GPG and the other to GCM.
I tried a lot of things but with no success. This can easily be reproduce with an empty project and adding both dependency inside the same Podfile. Note that ENABLE_BITCODE has to be disabled.
Am I doing something wrong ?

Ahh interesting, this is a weird edge case. We didn't know GooglePlayGames is also using a similar internal library. This would require a fix from our end (a new lib) which prevents the symbol clashing. I'm not sure how PlayGames uses the internal code but one thing you can try is to manually remove the libGIP_Locale.a stuff for GCM and just try using the play framework one. Maybe linker will be able to resolve the GCM stuff.

Thanks for the feedback !
I tried to delete libGIP_Locale.a and indeed, I can build successfully but my app crashes when I'm initializing GCM ([GGLInstanceID tokenWithAuthorizedEntity:scope:options:handler])
[GIPLocale legalDocsLanguageForPreferences:]: unrecognized selector sent to class 0x100aa7f90

So I guess I'll have to wait for a real fix. Do you have any idea when it will be ?

I'm not sure about the timeline. But if you want you can swizzle the method implementation at runtime and provide some abstract value. You might have to track it a bit down but that should theoretically work.

I would also be definitively interested in a such fix :+1:

Has there been a resolution to this issue yet?  I'm running into the same issue.

Any resolution? I ran into similar issue, with GoogleIPhoneUtilities(GIPLocale.o) and FirebaseRemoteConfig(GIPLocale_4247f43f917706697450b0e33acc9bbf.o).


Add disable class to wfm-fab

We found a use case for wfm-fab button that needed a disable class.

I had a look and i can not find a example of a disabled FAB in the google material guidelines
https://material.io/guidelines/components/buttons-floating-action-button.html
However, there are disabled FAB´s in all the material design libs - angular material, materialize...

In the styleguide right now we say this:

IMO i think the button should be hidden until such time that it can be used, i think it goes against the point of the FAB to disable it since it should be the one thing on the page the user should want to logically click - if there is some action or requirement the user needs to fulfill then THAT is the primary action and should be obvious and promoted

I vote to close this one and make another PR after we have talked more about how to refactor the fab -
Talking points:

make the floating button able to float https://github.com/Teleopti/styleguide/issues/242
provide a 'non fab colored icon button (NFCIB)' option
allow that 'NFCIB' to be disabled

Here is a suggestion on how to solve this https://github.com/Teleopti/styleguide/pull/247
For the main fab, i think we should hide it until such time that it is possible to use. if there is something else on the needs doing before clicking it - its not the primary action.
Later when the fabs will float https://github.com/Teleopti/styleguide/issues/242 having a disabled button permanently on screen is really annoying (think on phones) :)
For mini fabs in the view, use these icon buttons with colored backgrounds. that can indicate states and be disabled


generate static examples without api call [apm appveyor cdnjs clojars gem librariesio npm uptimerobot]

Having chewed over the discussion in issue #1700 and drafted a few ideas, here is one possible solution:
If we use the service class internals to produce the example from an object and split the handle() function into 2:

One function which fetches data
One function which formats it as on object that can be consumed by _makeBadgeData()

then it becomes easier to format an example value consistently with the real badge behviour without making any API call. If we seperate concerns correctly, this should minimise the scope for our examples to 'drift' or require a lot of maintenance.
In most cases, what we're doing fits cleanly into that pattern. In the cases where we are doing something more complicated, we can write a more complex handle() function, elect not to return a staticExample object and just return a dynamic previewUrl as before. If we come up with a solution that addresses the common pattern, that allows us to make an improvement over where we are now.
The one downside is that the examples obviously don't reflect reality. This will probably cause some confusion:

.. but this is a problem if we implement the suggestion in issue #1700 in any way. It is not inherent to this implementation.
Thoughts? I've picked one simple example here to demonstrate, but if this approach seems sensible I can have a look at updating the examples for other badges we've already refactored, adding tests, etc..

Warnings

:warning:

This PR modified services/cdnjs/cdnjs.js but not services/cdnjs/cdnjs.tester.js. That's okay so long as it's refactoring existing code.

Messages

:book:

:sparkles: Thanks for your contribution to Shields, @chris48s!

  Generated by :no_entry_sign: dangerJS

Hey @chris48s, thanks for picking this up. I really like this approach. Separating the formatting from the fetching is a smart way of separating concerns. For the current purpose it helps keep the preview badge appearances in sync. It also makes the badges more testable, more flexible, and probably easier to refactor. It enables smarter caching of service data, too.
I took a long pass through another WIP on the NPM badges, which are among the more complicated badges, and tried to get a nice feeling between the subclasses and superclasses while trying to keep a reasonably tight grip on the indirection. My work is tackling adjacent concerns, but the abstraction lines up nicely.
I wonder if we should push the abstraction up into BaseService. Almost all of our badges are doing fetch + render. That would allow the expression of these examples to be a little bit cleaner. I'll leave a few comments inline and open a PR with the work I did on NPM.

Cheers for having a look at this and providing comments. I like the improved terminology fetch() and render() you've suggested.
Since you've started generalising some of these ideas into the base classes in #1743 I think it is better to park this temporarily and I'll pick this up and rebase onto master once that is in. I think that will be better than trying to work on the 2 in parallel.

Its taken a while to circle back to this one. I've updated just the one service for now as an example, but if we're happy with the tradeoffs here I'll have a look at updating the other new-style services to use static examples as well.

I've added tests and made a couple of minor tweaks.
Also, having reflected on this, I think the issue described in the first post is alleviated if we make the examples more obviously 'fake' by using placeholder values (like we already do with some badges) instead of showing a wrong badge value for a real library/repo etc. I think that is less confusing
Apart from that the main thing I've done is added static examples to existing badges. This should now cover everything we've refactored so far except for:

NPM Type Definitions (lets review this in the context of #1897)
Node - This one is different from all the other because the render() function is async, so I've ignored this one for now.

Is there an heroku version up with the placeholders?
Or could you update the graphics in the first post?

now that most of the examples will be placeholders: sometimes it's not completely clear how to fill out the URL, and seeing a complete working example could help a lot with that. Do you think we should keep the other examples alongside, and render them in the UI as a list of example URLs (i.e. not as live badges)?

Yeah I had a similar thought. I think it will be cluttered to show both in the 'list' view. What about if we show it in the modal dialog?

@tooomm - I've just done a staging deploy at https://shields-staging-pr-1740.herokuapp.com/ if you want to have a look. Note this is likely to change in light of above comments. The list of services where I've changed the examples is in the PR title

I've had a go at implementing these suggestions. I've changed the terminology a bit to make things clearer, so we now have:

PlaceholderUrl/Uri for the version with placeholders e.g: /npm/dw/:package.svg
ExampleUrl/Uri for the concrete example e.g: /npm/dw/localeval.svg
PreviewUrl/Uri for the static (or live) image we will actually show

For the moment in the case where we have an ExampleUri I've just added ExampleUri as a bit of text on the modal dialog. Do you have any feedback on how/where to present this? Should we actually render the badge as well as just showing it as a text example?

also preview is back up at https://shields-staging-pr-1740.herokuapp.com/

Do you have any feedback on how/where to present this? Should we actually render the badge as well as just showing it as a text example?

In the scope of this PR, I think the way you have it is great. I'd suggest one tweak, which is to place each URL on its own line, for easy copying and pasting.
Down the line we could have it so there are fields you can fill in with the values, and when you click on an example it resets the fields to match the example… 🙏
I don't think a live badge is necessary. I'd be cool with a live link that lets you click to preview, though again, I don't think it's essential.

This is great!

I'd suggest one tweak, which is to place each URL on its own line, for easy copying and pasting.

Isn't it already like that..?

Do you mean somewhere else?

That's the spot I mean.
When I triple-click the line, it selects "Example:" too:

Oh, perhaps a better option would be to wrap the link in ClickToSelect as we're doing with the code inputs on this tab. Then a single click would select it, ready for copying.

Failures are the same issue as https://github.com/badges/shields/pull/1934#issuecomment-415143911
There's now some other badges that have been added/changed with dynamic examples that will want converting to static example. I think that's:

appveyor tests
npm type defs
wercker

but the rest of the comments should be addressed now

If you cheat and remove librariesio you could merge this.

We're only cheating ourselves ;)
I'm not going to have a chance to work on this for a few days so lets get the core stuff in now and we can continue noodling on the remaining details.

This is live.


PR - Improving DOCS + telegram plugin

New documentation examples about creating strategies.
Fixing telegram plugin so mobile devices can call the methods using upper or lower case (now its case-insensitive). When using mobile phone devices, the first input was always upper case and the robot could not identify the requested command. Now this has been fixed.

Awesome, could you quickly fix the comment in the strategy example?

Done! :)
2017-07-31 15:24 GMT-03:00 Mike van Rossum<EMAIL_ADDRESS>
Awesome, could you quickly fix the comment in the strategy example?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/askmike/gekko/pull/901#issuecomment-319154126, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEftI9pOVOrEhRMpRtCM9sOZDky0GBNJks5sThvfgaJpZM4OoqWg
.

Great, thanks :)

Hey Mike, wouldn't it be good to merge the docs into stable?
That might reduce some issues requests.

It is already merged into stable, but as a rule, all PRs (some hotfix
exceptions) need to to into develop first :)
On 31 Jul 2017 21:54, "raffus"<EMAIL_ADDRESS>wrote:

Hey Mike, wouldn't it be good to merge the docs into stable?
That might reduce some issues requests.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/askmike/gekko/pull/901#issuecomment-319193356, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7MD06UjzOq_5h_o0ffqSK9dbMx7bmqks5sTj71gaJpZM4OoqWg
.


Static libraries generated by NCEP_bufr cannot be linked correctly with GNU compiler

Labels:
Bug
Description:
When using GNU compiler 12.1 on Linux and ARM64 machines to compile NCEP_Shared v1.2.0, the static library NCEP_bufr_r4i4 generated by @NCEP_Shared/NCEP_bufr/CMakelists.txt cannot be correctly linked to combfr.x and combfrd.x, with the following errors:
Undefined symbols for architecture arm64:
  "_arallocc_", referenced from:
      _openbf_ in libNCEP_bufr_r4i4.a(openbf.F.o)
  "_cbbw", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cbbw)
  "_cbelem", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cbelem)
  "_cbmnem", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cbmnem)
  "_cbscl", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cbscl)
  "_cbsref", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cbsref)
  "_cbunit", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cbunit)
  "_cdmnem", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cdmnem)
  "_cdseq", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_cdseq)
  "_cpmstabs_", referenced from:
      _ireadmt_ in libNCEP_bufr_r4i4.a(ireadmt.F.o)
  "_ibfxyn", referenced from:
      _nummtb_ in libNCEP_bufr_r4i4.a(nummtb.c.o)
     (maybe you meant: ___moda_mstabs_MOD_ibfxyn)
  "_idefxy", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_idefxy)
  "_idfxyn", referenced from:
      _nummtb_ in libNCEP_bufr_r4i4.a(nummtb.c.o)
     (maybe you meant: ___moda_mstabs_MOD_idfxyn)
  "_ndelem", referenced from:
      _stseq_ in libNCEP_bufr_r4i4.a(stseq.c.o)
     (maybe you meant: ___moda_mstabs_MOD_ndelem)
  "_nmtb", referenced from:
      _nummtb_ in libNCEP_bufr_r4i4.a(nummtb.c.o)
     (maybe you meant: ___moda_mstabs_MOD_nmtb)
  "_nmtd", referenced from:
      _nummtb_ in libNCEP_bufr_r4i4.a(nummtb.c.o)
     (maybe you meant: ___moda_mstabs_MOD_nmtd)
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
make[3]: *** [bin/combfr.x] Error 1
make[2]: *** [src/Applications/NCEP_Paqc/combine_bfr/CMakeFiles/combfr.x.dir/all] Error 2
make[1]: *** [src/Applications/NCEP_Paqc/combine_bfr/CMakeFiles/combfr.x.dir/rule] Error 2
make: *** [combfr.x] Error 2

I observed this error occurs on both:

on a arm64 macbook with the gnu compiler 12.1-pre-r1.
on a Linux server (with Intel chips) with the gnu compiler 12.1.0 .

Causes & Solution:
the bufr src included in v1.2.0 seems to align to v11.3.2 under NCEP-buflibs. GNU compiler needs the compiling definition DYNAMIC_ALLOCATION instead of STATIC_ALLOCATION for processing C files.
Effects after correction:
After correction, the lib NCEP_bufr_r4i4 after using DYNAMIC_ALLOCATION

can be linked correctly to generate combfr.x,
is linked to my PrepBUFR decoder, and tested with my own datasets. The result shows the generated lib can correctly read out bufr data:

(cda_suite) [cda@measures1 bufr_utils]$ ./validate_build.sh
================================================================================
                  SYNOPSIS OF PREPBUFR DECODER using BUFRLIB
                              by TAKEMASA MIYOSHI
--------------------------------------------------------------------------------
 TOTAL NUMBER OF READ-IN RECORDS:    370686
 TOTAL NUMBER OF WRITTEN RECORDS:    301945 (levels/variables separately)
--------------------------------------------------------------------------------
  ADPUPA  AIRCAR  AIRCFT  SATWND  PROFLR  VADWND  SATEMP  ADPSFC  SFCSHP  SFCBOG
    1370       0    1468  117085     327    1580       0  108483   12804       0
   99576       0    1514   95648   12312   13432       0   49393   18264       0
--------------------------------------------------------------------------------
  SPSSMI  SYNDAT  ERS1DA  GOESND  QKSWND  MSONET  GPSIPW  RASSDA  WDSATR  ASCATW
       0       0       0       0       0       0     838     155    5903  120673
       0       0       0       0       0       0       0       0   11806       0
--------------------------------------------------------------------------------
  OTHERS
       0
       0
================================================================================
-------------------------------------------------------
check difference for time step: t-3
 fnin, nobs=t-3.dat       19050
 fnin2, nobs2=t-3.dat_test       19050
 rdiff=   9.99999978E-03
 total error #=           0
-------------------------------------------------------
check difference for time step: t-2
 fnin, nobs=t-2.dat       20077
 fnin2, nobs2=t-2.dat_test       20077
 rdiff=   9.99999978E-03
 total error #=           0
-------------------------------------------------------
check difference for time step: t-1
 fnin, nobs=t-1.dat      102671
 fnin2, nobs2=t-1.dat_test      102671
 rdiff=   9.99999978E-03
 total error #=           0
-------------------------------------------------------
check difference for time step: t
 fnin, nobs=t.dat      116746
 fnin2, nobs2=t.dat_test      116746
 rdiff=   9.99999978E-03
 total error #=           0
-------------------------------------------------------
check difference for time step: t+1
 fnin, nobs=t+1.dat       18250
 fnin2, nobs2=t+1.dat_test       18250
 rdiff=   9.99999978E-03
 total error #=           0
-------------------------------------------------------
check difference for time step: t+2
 fnin, nobs=t+2.dat       18953
 fnin2, nobs2=t+2.dat_test       18953
 rdiff=   9.99999978E-03
 total error #=           0
-------------------------------------------------------
check difference for time step: t+3
 fnin, nobs=t+3.dat        6198
 fnin2, nobs2=t+3.dat_test        6198
 rdiff=   9.99999978E-03
 total error #=           0

@mathomp4 I will submit a PR for this later today. Thank you!

@gmao-cda We do have:
https://github.com/GEOS-ESM/NCEP_Shared/blob/e0d738dc7487d6d7568ee73d3237e992877b71e8/NCEP_bufr/CMakeLists.txt#L383C12-L385
are you saying we also need:
   target_compile_definitions (${this} PRIVATE $<$<COMPILE_LANGUAGE:C>:DYNAMIC_ALLOCATION>)

as well?

@mathomp4 Yes!
Need to change the following line
https://github.com/GEOS-ESM/NCEP_Shared/blob/e0d738dc7487d6d7568ee73d3237e992877b71e8/NCEP_bufr/CMakeLists.txt#L378
to
if (CMAKE_C_COMPILER_ID MATCHES Intel)
    target_compile_definitions (${this} PRIVATE $<$<COMPILE_LANGUAGE:C>:STATIC_ALLOCATION>)
elseif (CMAKE_C_COMPILER_ID MATCHES "GNU")
    target_compile_definitions (${this} PRIVATE $<$<COMPILE_LANGUAGE:C>:DYNAMIC_ALLOCATION>)
endif ()

This change shall not change the flags related to Intel compiler.

okay. I think that is doable. I can make a PR if that's easier. Up to you!

okay. I think that is doable. I can make a PR if that's easier. Up to you!

Thank you very much Matt! I will make a PR from local, so it's doable for me. Thank you for teaching me how to use cmake efficiently!


V1.x fix recvmmsg on musl libc

This fixes the recvmmsg on musl libc by zeroing the struct msghdr when preparing the structures for recvmmsg.
Closes: #3416

Landed in 2fbfa035...d5ed7f12, thanks Ondřej.


Upgrade LAC to latest version of DIBBs

Now that we have released an updated version of the FHIR converter we want to deploy it to LAC. To do this we need to open and merge a PR on the LAC repo that:

Increments the DIBBs version
Adjusts ReadSourceData to use the new ELR template

Acceptance Criteria:
GIVEN the new FHIR converter image
WHEN LAC runs a deployment
THEN the new image is deployed
GIVEN the LAC cloud environment has the new version of the FHIR converter deployed
WHEN the pipeline processes and ELR
THEN the new ELR template is use to convert to FHIR.

PR opened on the LAC repo


Preference View

Description

Preference Tab View
New Tabs

Releated Issue
#146

Checklist (for drafts):

[X] I read and understood the contributing guide as well as the code of conduct
[X] My changes generate no new warnings
[X] My code builds and runs on my machine
[X] Review requested

Screenshots (if appropriate):

https://user-images.githubusercontent.com/46642225/159716191-8377f288-16ab-42ea-b210-a396c4cee8c9.mp4
Use keyboard change themes
https://user-images.githubusercontent.com/46642225/159904218-1c27025e-2629-4af7-80d6-31ac83ce1e01.mp4

Looks good,
Isn’t it beter (maybe in the future), to make the previews dynamic instead of images.
This can be useful it a user uses a custom theme.

To be honest, I think we are getting a little ahead of ourselves with this PR. I am happy to merge it for now when ready, but we ultimately need to first have a plan regarding #34. I really appreciate the effort here in this PR but until we have a plan, it may end up overriding the work done here which no one wants. It's not your fault, we should have mentioned this earlier on.

For appearance, instead of macOS wallpaper, we need a simplified illustration of the application and code similar to this

I really like how Nova has done their theme selector, the thumbnails are simple and their settings react to your system appearance, very flexible.
https://user-images.githubusercontent.com/806104/160252252-ecebda7e-2967-4ef2-8009-1924a06289b6.mp4

In our theme preference pane, I would have a checkbox, a tabset, and then a "More Themes" button. In the tabset, there are three tabs - "Window", "Editor", and "Terminal". When the checkbox is clicked, A light mode and dark mode toggle appears so that users can select light mode settings and dark mode settings.
By default if their currently selected theme supports the opposite appearance mode, it is automatically chosen. For example, if there is a High Contrast theme that offers a light version and a dark version and the user is in dark mode and they select "Automatically change theme based on system appearance", High Contrast Light will automatically be used for light mode because they have previously selected High Contrast Dark while in dark mode.

The theme preference pane might look something like this without the left sidebar category selector...

In our theme preference pane, I would have a checkbox, a tablet, and then a "More Themes" button. In the tabset, there are three tabs - "Window", "Editor", and "Terminal". When the checkbox is clicked, A light mode and dark mode toggle appears so that users can select light mode settings and dark mode settings.
By default if their currently selected theme supports the opposite appearance mode, it is automatically chosen. For example, if there is a High Contrast theme that offers a light version and a dark version and the user is in dark mode and they select "Automatically change theme based on system appearance", High Contrast Light will automatically be used for light mode because they have previously selected High Contrast Dark while in dark mode.

We don’t need a window theme tab now. We only have three window themes. If we add this tab the view will become ugly.

So which theme picked we choose?
The system one or nova one.
If we have a lot of themes, system one may be a good choice.

Something like this...

Something like this...

I think we don’t need to put terminal tab in the theme. Maybe the execution tab is the best. Because it is more related to execution.

Something like this...

So how can people choose auto themes?

For appearance, instead of macOS wallpaper, we need a simplified illustration of the application and code similar to th

fixed

Something like this...

So how can people choose auto themes?

You would check the “automatically change theme based on system appearance” checkbox.
If you notice, in the first mock up that check box is unchecked. When it is uncheck there is only one preview thumbnail to the right. When it is checked there are two thumbnails to the right. One for light, one for dark. When the light thumbnail is selected, you are selecting the theme below that will be applied when the system is in light mode. When the dark thumbnail is selected at the top right, the user can then select the dark theme to use when the system is in dark mode. The thumbnails at the top act as tabs to make a selection for each mode.

Opening a new issue for the design preference tab.

Appearance option thumbnails need "Light" and "Dark" labels like in macOS system preferences. Reopen behavior and icon style should instead be select menus for better clarity.


TS2345 argument is not assignable to parameter after update to latest 2.8

TypeScript Version:  2.8.0 latest LKG from 13.03
Search Terms: TS2345, argument is not assignable to parameter
Code
class Test {
    private _canvas: HTMLCanvasElement;

    public init(): void {
        // error here
        this._canvas.addEventListener('touchstart', e => this.onTouchStart(e));
    }

    private onTouchStart(e: TouchEvent): void {
    // do stuff
    }
}

Expected behavior:
no error
Actual behavior:
TS2345: Argument of type 'Event' is not assignable to parameter of type 'TouchEvent'.
Don't see a reason why it should be a valid error.

Ah, I see it now. For some reason type for at least for touch events in lib.dom.d.ts changed to plain Event. Looks like d.ts issue

Duplicate of #22565 ?

Closing in favor of  #22565


Fixes

Here are two fixes which allows demuxer to demux more .webm files
Here are fixes:

Fix unknown IDs wasn't skipped in a few situations so demuxer lost order of bytes

Fix Element(Segment and Cluster) size unknown error.
Since https://w3c.github.io/mse-byte-stream-format-webm/#webm-init-segments Cluster and Segment can have undefined size.
It is not a full fix It's just a hack for videos which have one Segment and one Cluster. For full fix we need to rewrite this.dataInterface.offset < this.end to waiting for next element to be next Segment(0x18538067) or Cluster(0x1F43B675)

I checked and it works with multiple clusters video.
One case it didn't work for now - multiple Track elements like in video below
big-buck-bunny_trailer.webm


cleanup_snippets: use self.stdout rather than sys.stdout

The point of using these handles rather than sys.* is to support things
like this: https://docs.djangoproject.com/ja/1.9/ref/django-admin/#output-redirection
It also makes unit testing the output simpler.

Current coverage is 95.15% (diff: 100%)

Merging #81 into master will not change coverage

@@             master        #81   diff @@
==========================================
  Files            11         11
  Lines           330        330
  Methods           0          0
  Messages          0          0
  Branches         38         38
==========================================
  Hits            314        314
  Misses           15         15
  Partials          1          1

Powered by Codecov. Last update 81175e4...0bf4a75

Thank you, didn't know that.


[libshortfin] Add device_array.view

Currently only restricted to row-major dense array views.

The CI failure seems to be weird. It seems to be pointing at the array not being filled properly. @marbre Do you know if this is a CI flake?

There's nothing funny with scheduling there or anything. All synchronous code.
I'd throw an assert after the fill to verify that is working. It's all pretty new code.


Appointments list in Patients profile

Scenario
AS
A user with read access to patients and read access to appointments
I WANT
A tab on the patients profile called Appointments
SO THAT
I can quickly see the Appointments for a patient
Acceptance Criteria
GIVEN
A patient who has appointments
AND
A user with read access to patients and appointments
WHEN
I click on the appointments tab in the the patients profile
OR
access /patients/:id/appointments
THEN
I should see a list of appointments for that given patient
AND
The appointments tab should be marked as active
Related Issues
HospitalRun/hospitalrun#149
Technical Notes

Working on this. May have something soon.

Closing since this functionality was completed in #1823


Selecting answers in trick answer list has a delay

There's a delay in tapping answers in trick answer page. This is probably related to how FlatList is used and updating its state.

It's fixed in the latest dev branch


Handle the case where the glob matches exactly one file

I was running into a case with a customer where the glob was matching exactly one file and the upload was failing as a result. It looks like in the case where the glob returned exactly one file, we were assuming that there was no * in the path at all. We don't need to make that assumption.

whoops, thanks for the fix!


Add a pre process  goimports  for golang project  before  really run_string.

Is your feature request related to a problem? Please describe.
#249  #248
Describe the solution you'd like
after generate main.go,  before go run main.go, can add an optional process to use "goimports main.go", it can remove not used import.
Additional context
i wrote a litter tool gopick as  an implementation for what i mentioned in #248 .  it can really pick a
piece of go code, from a go project  except, it will have unused imports. this could be easy fix by goimports (maybe most gopher has installed) before run main.go.
And With this, go's  support will be really import level now, except some global init functions and variables that is go code's bad smell.

Nice stuff! I promise to look at it and do my best to make use of it in sniprun
Could you add a licence to the project so I can directly copy those files in sniprun? MIT or something similarly permissive would be good, since I don't want to rely on cloning a external repo at runtime

i am happy you like this.
gopick project now only usefull for little go project, it has two main disadvantage.

if project is large, because of it should cal gopls  bin,  it will take a long time to pick really usefull code, for my project it will be one or two minute.
now gopick has not concern about which function has parameters.

now i am rewriting this work in lua, because  i think it can reuse lsp server and  make it more faster so that will be more usefull for large project. when i have done this , i will add a license let you can  directly copy those files in sniprun.

indeed, 1-2 minute is long. How long does the whole project takes to compile at this point ?
Plugin-in the (supposed existing) already-running LSP server is most likely the correct design choice


SECRET_KEY gen to short

when heroku run python manage.py check --deploy is ran this error occurs
?: (security.W009) Your SECRET_KEY has less than
 50 characters or less than 5 unique characters.

Please generate a long and random SECRET_KEY, otherwise many of Django's security-critical features will be vulnerable to attack.
changing the num of ran to a larger number fixes this issue

:+1:


CLA agreement is missing

In the CONTRIBUTING.rst file there's a link to a CLA agreement that's missing.
The link is https://crate.io/community/contribute/agreements/ but it's not there.
Bye

thanks for reporting! we recently did some restructuring on our website and it seems this was forgotten. we'll fix it asap and get back to you.

the page has been re-added.

Thanks!


feat(Topology.Algebra.Valuation): add integer_isOpen

The unit ball in a valued ring is open.

bors r+

Thanks :tada:
bors merge


python310Packages.policy-sentry: 0.12.7 -> 0.12.8

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.policy-sentry is: Python module for generating IAM least privilege policies
meta.homepage for python310Packages.policy-sentry is: https://github.com/salesforce/policy_sentry
meta.changelog for python310Packages.policy-sentry is: https://github.com/salesforce/policy_sentry/releases/tag/0.12.8
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.12.8 with grep in /nix/store/13jz6j2883n5fqlzjh6byiyzbjqca6sg-python3.10-policy-sentry-0.12.8
found 0.12.8 in filename of file in /nix/store/13jz6j2883n5fqlzjh6byiyzbjqca6sg-python3.10-policy-sentry-0.12.8

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath
checkov
python310Packages.cloudsplaining
python310Packages.policy-sentry
python311Packages.cloudsplaining
python311Packages.policy-sentry

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/13jz6j2883n5fqlzjh6byiyzbjqca6sg-python3.10-policy-sentry-0.12.8 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.policy-sentry https://github.com/r-ryantm/nixpkgs/archive/989aa89d9d40c764b36d97bb312eb6e02504d7e4.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/13jz6j2883n5fqlzjh6byiyzbjqca6sg-python3.10-policy-sentry-0.12.8
ls -la /nix/store/13jz6j2883n5fqlzjh6byiyzbjqca6sg-python3.10-policy-sentry-0.12.8/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

5 packages built:

checkov
python310Packages.cloudsplaining
python310Packages.policy-sentry
python311Packages.cloudsplaining
python311Packages.policy-sentry

Maintainer pings
cc @fabaff for testing.

Result of nixpkgs-review pr 250310 run on x86_64-linux 1

10 packages built:

checkov
checkov.dist
python310Packages.cloudsplaining
python310Packages.cloudsplaining.dist
python310Packages.policy-sentry
python310Packages.policy-sentry.dist
python311Packages.cloudsplaining
python311Packages.cloudsplaining.dist
python311Packages.policy-sentry
python311Packages.policy-sentry.dist


Fix edge weight reading

Looks good! Maybe we should add a test that loads an edgelist from a file? I think that's why this wasn't caught...

Thanks Mihai. The test for file I/O only reads/writes graphs with edge weights set to 1, so this was not caught. I will make the change to the tests as well.


about database build!

Hi,
I used the following command to build database:
hgtector database -o /disks/node2_RAID6_60TB/database/hgtector --default
But while downloading the data, the script crashed with the following error:
Database building started at 2023-07-05 21:15:36.623397.
The default protocol is selected for database building.
The program will download all protein sequences of NCBI RefSeq genomes of bacteria, archaea, fungi and protozoa, keep one genome per species, plus all NCBI-defined reference and representative genomes.
Using local file taxdump.tar.gz.
Reading NCBI taxonomy database... done.
Total number of TaxIDs: 2514661.
Using local file assembly_summary_refseq.txt.
Reading RefSeq assembly summary... done.
Total number of genomes: 315511.
Genome categories: archaea, bacteria, fungi, protozoa
Downloading genome list per RefSeq category...
Using local file refseq_archaea.txt.
archaea: 1568
Using local file refseq_bacteria.txt.
bacteria: 297241
Using local file refseq_fungi.txt.
fungi: 544
Using local file refseq_protozoa.txt.
protozoa: 96
Done.
Traceback (most recent call last):
File "/opt/biosoft/miniconda3/envs/hgtector/lib/python3.8/site-packages/pandas/core/indexes/base.py", line 3653, in get_loc
return self._engine.get_loc(casted_key)
File "pandas/_libs/index.pyx", line 147, in pandas._libs.index.IndexEngine.get_loc
File "pandas/_libs/index.pyx", line 176, in pandas._libs.index.IndexEngine.get_loc
File "pandas/_libs/hashtable_class_helper.pxi", line 7080, in pandas._libs.hashtable.PyObjectHashTable.get_item
File "pandas/_libs/hashtable_class_helper.pxi", line 7088, in pandas._libs.hashtable.PyObjectHashTable.get_item
KeyError: '# assembly_accession'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/biosoft/miniconda3/envs/hgtector/bin/hgtector", line 96, in
main()
File "/opt/biosoft/miniconda3/envs/hgtector/bin/hgtector", line 35, in main
module(args)
File "/opt/biosoft/miniconda3/envs/hgtector/lib/python3.8/site-packages/hgtector/database.py", line 131, in call
self.retrieve_categories()
File "/opt/biosoft/miniconda3/envs/hgtector/lib/python3.8/site-packages/hgtector/database.py", line 368, in retrieve_categories
self.df = self.df[self.df['# assembly_accession'].isin(asmset)]
File "/opt/biosoft/miniconda3/envs/hgtector/lib/python3.8/site-packages/pandas/core/frame.py", line 3761, in getitem
indexer = self.columns.get_loc(key)
File "/opt/biosoft/miniconda3/envs/hgtector/lib/python3.8/site-packages/pandas/core/indexes/base.py", line 3655, in get_loc
raise KeyError(key) from err
KeyError: '# assembly_accession'

Is your problem solved? I have the same problem.

Hi,
I've got the same issue. It is due to a space line 368 of the database.py script (self.df = self.df[self.df['# assembly_accession'].isin(asmset)] should be self.df = self.df[self.df['#assembly_accession'].isin(asmset)]).
One workaround is to make a first attempt, once it failed:

chmod u+w download/assembly_summary_refseq.txt
sed -i "s/#assembly_accession/# assembly_accession/g" download/assembly_summary_refseq.txt (or edit the 2nd line with a text editor like notepad++)
re-run (with the same -o directory)

Best,
Jean

Hello @jeankeller @jiyanhan @mengli2022 , thank you for reporting and finding solution to this issue. It is because NCBI has updated their assembly summary table format. I updated the code to reflect this change (#125 ). You may update HGTector using the following command and the problem should be solved.
pip install --force-reinstall --no-cache-dir git+https://github.com/qiyunlab/HGTector.git


Add link to shiny future blog post

When I went to check on some details of the shiny future purpose, I eventually found that the blog post was very useful, but wasn't linked on the shiny future index page. This is just a suggested addition :shrug:

Thanks!


deprecate R.converge

R.lift covers all my uses of R.converge.
> R.converge(R.subtract, [R.inc, Math.sqrt])(9)
7
> R.lift(R.subtract)(R.inc, Math.sqrt)(9)
7

Is R.converge only necessary to support non-unary "transformation" functions?

LGTMt. This still works:
R.converge(R.subtract, [R.multiply, R.add])(4, 3); //=> 5
R.converge(R.subtract, [R.multiply, R.add])(4)(3); //=> 5
R.lift(R.subtract)(R.multiply, R.add)(4, 3); //=> 5
R.lift(R.subtract)(R.multiply, R.add)(4)(3); //=> 5

This looks fantastic!  Once stated, it seems obvious, but I've been thinking about this one and useWith a lot, and didn't manage to come up with it.
I'd like to spend a little time looking at the various uses I've had for converge, but I'm not coming up with any cases in the abstract that this wouldn't cover.

I like this :+1:
The only issue it that to those unfamiliar with the applicative functor instance for functions it isn't obvious how this works.

Would you like to open a pull request for this, @benperez?

I actually didn't see this until now. lift won't respect context or variadic functions for branching functions at the moment. We could special case it in R.liftif it's important to keep that behavior. Let me know what you guys think.

I don't enjoy thinking about variadic functions. ;)

Variadic functions are always a problem.  But I think we need to make a decision about respecting context.  I've always been of the mind that as long as it's reasonably easy to do and doesn't get in the way of anything else, continuing to respect context was a good practice.
But @asaf-romano pointed out in #1592 that this has been broken for a while.  (I'm not sure, but I'm guessing it was broken during @scott-christophers performance enhancements in @1512.)  We've received no complaints about this at all.  @asaf-romano only noticed it because a line of existing code looked odd.
Perhaps its time to put a stake in ground and say that we won't try to support this any further.  It's almost certainly a pretty unusual user who uses Ramda to build methods for her OO API.  Should we just stop catering to that?

The only interesting use case I see for preserving context is pseudo-decorators set on a singleton object; something like this:
const MessagesService = {
    BASE_URL: "...",

    initialize: once(function()
    {
    }),

    getMessages: memoize(function(msgId)
    {
    }),

    someSwitch: cond([
       [..., funciton() { return this.(...) }],
       [..., funciton() { return this.(...) }],
       [..., funciton() { return this.(...) }]
    ])
}

The cond case is something easy to give up on, but the first two are a tough call.

The only issue it that to those unfamiliar with the applicative functor instance for functions it isn't obvious how this works.
I had to read the source code to see how it worked; you need to know that R.lift uses R.ap, which has special support for functions' .apply method. This seems to go beyond what the documentation says R.lift is capable of supporting, ie:
an Array or other object that satisfies the FantasyLand Apply spec.

I think the fact that dispatching, which is a big part of fantasy-land and this library requires use of the this keyword, we should probably take the stance that ramda functions should always respect context. You could go a step further and say that all ramda functions that accept functions will evaluate those functions in the same context that they are called in.
This may not affect the API of ramda functions but it will certainly—for better or worse—affect their implementations. I would be in favor of deprecating converge and adding a code branch in lift specifically designed for functions (it respects context).

Dispatching is an orthogonal concern.  When we dispatch, the context that we would have been preserving is lost anyway.
The context that we would preserve would be the sort of thing that you can see in _curryN or _pipe, where functions that alter functions often maintain the this supplied to them, so that they might be used as OO methods when necessary.
The trouble is that many other functions could be used as methods too, but we've only taken this care for the ones that specifically return functions, not the ones that, because of the autocurrying, also could return functions which might be used as methods.
For instance, this doesn't work:
var region = {
  tax: 0.06,
  adjustPrices: map(function(val) {
    return (1 + this.tax) * val;
  })
};

region.adjustPrices([5, 10]); //=> Error: Cannot read property 'tax' of undefined

because the relevant line of map doesn't preserve context:
    result[idx] = fn(functor[idx]);

If we replaced that with
    result[idx] = fn.call(this, functor[idx]);

Then we would get the expected behavior.
But it's far from clear that we would want to do that across all of Ramda's functions.  That's part of the reason that I'm leaning toward removing it.  Part of it is simply that it's always been on spec.  No one has ever requested it.  Now that it's been broken for a while, no one has complained that it's missing.
Dispatching works differently.  Since we are actually calling a method on an object, the existing context is necessarily lost.

Thanks for the clarification on the state of dispatching versus normal context @CrossEye, the distinction is now clear in my mind.
Given that ramda is already so inconsistent about respecting context, I say we just scrap it as a requirement altogether. At the end of the day, if the user wants to use context internally in functions which accept functions, he or she can always simply bind any necessary context to the function itself.

Scrapping context is cool with me, too, if it significantly improves performance. Anyway, back to the original topic – converge vs. lift ;)
I feel like I can almost understand how one can replace the other – something to do with the Apply spec. If converge is actually entirely replaceable with lift, it would be really cool if the documentation mentioned how lift can be used with functions instead of just arrays (if I'm making even the least bit of sense here...).

Agreed.  A lot of the docs that delegate to the user types really need some work.  I think we simply still don't quite know how to do that well.  I thought I remembered that the lift / liftN docs had Maybe examples; shows what I know.

In the interest of moving this along, I'll open a PR tonight to deprecate converge and revamp the docs for lift and liftN to include info and examples for functions. If we don't settle on deprecating converge then we can at least improve the docs for lift.

@benperez - like the way sanctuary describes lift - just thought I'd mention it as you're revamping docs.

@benperez: That would be really awesome. It's like @paldepind says:

The only issue it that to those unfamiliar with the applicative functor instance for functions it isn't obvious how this works.

The way lift is described in Sanctuary probably makes sense, but needs mo' words for the uninitiated.

Can lift also replace useWith, btw?

Can lift somehow also replace useWith, btw?

I can't see how, but nothing would surprise me at this point!

In the interest of moving this along, I'll open a PR tonight to deprecate converge

(( :bell: ))
Sorry for being pushy, but i would like to get 0.20 out the door and would like to include deprecating converge as part of it. lmk if you'd rather that i just go ahead and add the tag.

Sorry for being pushy, but i would like to get 0.20 out the door

No worries, the PR with the deprecated tag is https://github.com/ramda/ramda/pull/1649. I can update the docs for lift in another PR.

I would be helpful if the documentation for how converge can be replaced by lift were in place before the deprecation.

@dalgard I might be wrong but I think that 0.20 will just include a deprecation tag in the docs, R.converge won't actually be removed from ramda until 0.21.

I would be helpful if the documentation for how converge can be replaced by lift were in place before the deprecation.

I agree. Failing that, we should explain the converge → lift translation in the upgrade guide.

ok will proceed with just deprecation notice then

So R.juxt is currently implemented as R.converge(Array.of). How do you do that with lift?

I have not been pushing for this, partly because I knew I'd never done my due diligence on the compose -> lift change on my own.  But I think the question from @asaf-romano makes this much more interesting.
Does someone have as convenient a way to implement juxt that come anywhere close to the expressive elegance of converge'(Array.of)?

@asaf-romano thanks for bringing this up, the use of converge in the definition of juxt highlights something that we'd need to consider in a lift based formulation of converge.
R.juxt = _curry1(function juxt(fns) {
  return converge(_arrayOf, fns);
});

depends on supporting variadic functions in both arguments to converge. _arrayOf and the elements of fns are both variadic. This presents a challenge when trying to lift a function to act on other functions.
As I mentioned much farther up the chain, we're going to have to add a special case implementation of R.liftN for functions if we want to continue to support type signatures like:
R.converge :: (*ARGS, ELLIPSIS* -> z) -> [(*ANOTHERARGS, ANOTHERELLIPSIS* -> x1), (*YETANOTHERARGS, YETANOTHERELLPISIS* -> x2), FREEELLIPSIS] -> *ONEMOREARGS, ONEMOREELLIPSIS* -> z

I personally find these kinds of variadic functions very hard to reason about in real code and to me this difficulty grows dramatically when we're talking about higher-order functions that accept, combine, and return variadic functions.
I'm personally in favor of moving away from variadic functions in higher-order functions in ramda but I also understand that this is JS, so a lot of other people might not see things that way. There are a couple different options for handling them in lift if we choose to support them.

The issue isn't only with variadic functions. converge did a couple more things with its focus on functions:

It set the arity based on the input functions.
it curried the resulting function

I used to really dislike converge for some reason, but over time, and especially after it was changed to take the combined functions as a list, I realized that my only problem with it is its name. I'd rather go with something like combine.
I think it's somewhat unrealistic to expect users to use lift this way. The abstraction is just a little over the top, too far away from the lamda you're trying to write:
var combine = converge;

var copyAtoB = combine(assoc("b"), [prop("a"), identity]); // {"a": 1, "b": 1}
copyAtoB({ a: 1 });

var copyAtoB_L = lift(assoc("b"))(prop("a"), identity); // {"a": 1, "b": 1}
copyAtoB_L({ a: 1 })

@asaf-romano, your example can also be written in terms of a couple of nifty combinators:
//    C :: (a -> b -> c) -> b -> a -> c
const C = f => y => x => f(x)(y);

//    S :: (a -> b -> c) -> (a -> b) -> a -> c
const S = f => g => x => f(x)(g(x));

S(C(R.assoc('b')))(R.prop('a'))({a: 1});
// => {a: 1, b: 1}

I'm not trying to offend my coworkers that much ;)

@davidchambers may be of interest for you. I just ported data.aviary.birds (a collection of combinators) to js. https://github.com/fantasyland/fantasy-birds (documentation not finished)
It also contains C and S cardinal and starling.

Neat project, @stoeffel! Also, I'm excited to see Transcribe being used in the wild. :)

Neat project, @stoeffel! Also, I'm excited to see Transcribe being used in the wild. :)

Glad you like it! Transcribe is awesome. The only thing missing is using it for more than one files. (btw sorry for going of topic :blush: )

@stoeffel: That's great!

OK, so to me converge as it currently stands has 3 problems:

Accepts a variadic function as its first argument
We can't know how many functions are supposed to be supplied as input transforming functions until the user actually supplies how many he or she wants. This is a source of ambiguity since we're mixing the type of the function with the data passed into it.
Accepts functions with different lengths in its second argument
The length of the resulting function is determined by scanning through the functions passed in and taking the max length. Again we're mixing types and data. I think having functions in a pipeline which operate on multiple arguments can be useful, but I'd rather see a more methodical approach like the one proposed by @scott-christopher in this thread.
Context
It seems like it's already been established in this thread that this isn't something we care to support in this function anymore.

We can eliminate all of these problems by reshaping converge functionality to be much simpler and easier to reason about. It seems like @CrossEye has always made the point that we shouldn't let implementation concerns dictate API. It seems strange to let the implementation of R.juxt dictate the API for R.converge.

Responding from the bottom up:

It seems strange to let the implementation of R.juxt dictate the API for R.converge.

Absolutely.  But I'm not quite sure what @asaf-romano meant to say.  That elegant little chunk is not the current implementation of juxt; perhaps it's better than our current one, perhaps not, but it did a good job of demonstrating that lift(fn)(f1, f2, ...) is not a drop-in replacement for our current converge(fn, [f1, f2, ...]).

We can eliminate all of these problems by reshaping converge functionality to be much simpler and easier to reason about.

We can, but we need to decide whether we want to.  We have not hit 1.0, so we can feel free to change API as we like, but we also have to decide when to break continuity, and for what reasons.

(3.) ** Context**
It seems like it's already been established in this thread that this isn't something we care to support in this function anymore.

Agreed, this can just go.  It's never shown its worth, and no one has ever really asked for it.

(2.)  Accepts functions with different lengths in its second argument
The length of the resulting function is determined by scanning through the functions passed in and taking the max length. Again we're mixing types and data. I think having functions in a pipeline which operate on multiple arguments can be useful, but I'd rather see a more methodical approach like the one proposed by @scott-christopher in this thread

I'm not quite sure what you're suggesting by "mixing types and data"  What we're doing is unifying the following sorts of signatures into one:
(a -> b -> d) -> [(e -> a). (e -> b)] -> (e -> d)
(a -> b -> c -> d) -> [(e -> a). (e -> b), (e -> c)] -> (e -> d)
(a -> b -> c -> d) -> [(e -> f -> a). (e -> f -> g -> b), (e -> c)] -> (e -> f-> g -> d)

Now its certainly arguable that this is far too much for one function, but by the same token that we wouldn't want to use the juxt implementation to drive an API change to converge, is the same not true about using lift to determine what we want this to be?  This is only coming up in the context of replacing the current implementation with a more elegant one.

(1.) Accepts a variadic function as its first argument
We can't know how many functions are supposed to be supplied as input transforming functions until the user actually supplies how many he or she wants. This is a source of ambiguity since we're mixing the type of the function with the data passed into it.

Part of the somewhat uncomfortable dynamic of Ramda is the interplay between "functional library" and "for Javascript developers".  In Javascript variadic functions are a normal part of how one works.  Configuring converge with a variadic combining function does feel very much in the spirit of the language.

Thanks for the thorough and thoughtful reply @CrossEye.

I'm not quite sure what you're suggesting by "mixing types and data" What we're doing is unifying the following sorts of signatures into one:

The problem with a lot of ramda's type signatures is that they don't actually represent types, they represent the way that types change based on the data passed into functions.
The signature for converge:
(x1 → x2 → … → z) → [(a → b → … → x1), (a → b → … → x2), …] → (a → b → … → z)

As you nicely point out, this is a description of many different "types":
(a -> b -> d) -> [(e -> a), (e -> b)] -> (e -> d)
(a -> b -> c -> d) -> [(e -> a), (e -> b), (e -> c)] -> (e -> d)
(a -> b -> c -> d) -> [(e -> f -> a), (e -> f -> g -> b), (e -> c)] -> (e -> f-> g -> d)

The problem is that the second arguments—[(e -> a), (e -> b)], [(e -> a), (e -> b), (e -> c)], and [(e -> f -> a), (e -> f -> g -> b), (e -> c)]—aren't really types. [(e -> f -> a), (e -> f -> g -> b), (e -> c)] is a list containing 3 functions that have 3 different types, that's what I mean by data. Furthermore, the type of the returned function is dependent on what functions (data) you pass in the second argument. It's impossible to represent the type of the function a priori because it's behavior is to change it's type based on the data passed into it.

In Javascript variadic functions are a normal part of how one works

I'm unconvinced by this. Variadic functions are supported in Javascript and are even frequently used, but they're by no means necessary or even more expressive than simply using lists for arguments.

I wrote:

But I'm not quite sure what @asaf-romano meant to say. That elegant little chunk is not the current implementation of juxt.

But I was confused.  That is what's in HEAD.  I was looking at 0.19.1, which has a different implementation.  I actually merged Asaf's changes, so I should remember this.  :smile:

.> The problem with a lot of ramda's type signatures is that they don't actually represent types, they represent the way that types change based on the data passed into functions.
I think we start to veer into philosophical grounds here.  What makes something a type?  It would be easy enough to argue the same way that :: (a -> b) -> f a -> f b doesn't represent anything on its own except for a vaguely connected group of types such as :: (Number -> String) -> [Number] -> [String] and :: (Rectangle -> Number) -> Maybe Rectangle -> Maybe Number.
But it's clear enough that that the current converge does represent something meaningful:
converge(f, [g1, ..., gn]) ≍ (a1, ... ak) => f(g1(a1, ... ak), ... gn(a1, ... ak));

There is plenty of room to argue that this should be simplified, that, for instance k should be fixed at 1, or n at 2.  I absolutely love the arrow approach @scott-christopher is discussing.  But the current version has shown itself to be a useful function, and we do need to consider what we'd give up in restricting it.

In Javascript variadic functions are a normal part of how one works

I'm unconvinced by this. Variadic functions are supported in Javascript and are even frequently used, but they're by no means necessary or even more expressive than simply using lists for arguments.

I don't mean to imply that one cannot live without them.  I mean that the substantial majority of Javascript developers do in fact use them.  My dividing line for Ramda has been pretty simple.  It has seemed a good thing to remove variadic functions from Ramda, and they're almost all gone.  But Ramda should still work well with users' variadic functions, since this is a library designed for Javascript programmers and not for Haskell programmers slumming it in JS.
If you're really looking to do something closer to Haskell in JS, you're sure to end up disappointed: you'll never really know that the function supplied really accepts Rectangles and returns numbers, and without some really expensive run-time checks, you won't know until quite late that the list supplied contains only Rectangles.  So, while Ramda does try to be much more principled that many other JS libraries, it does not try to overcome the basic nature of the language.  If a user wants that, she should probably try PureScript, ClojureScript, Elm, or at least TypeScript or Flow.

If you're really looking to do something closer to Haskell in JS, you're sure to end up disappointed: you'll never really know that the function supplied really accepts Rectangles and returns numbers, and without some really expensive run-time checks, you won't know until quite late that the list supplied contains only Rectangles

To me, this issue is less about "doing haskell in JS" and more about principled programming. Ramda already takes all sorts of positions that are at odds with the majority of "Javascript developers"—no mutation, well defined input and output types, avoiding optional arguments, etc. These principles might come from Haskell, Clojure, or elsewhere but I think they're motivated by writing better Javascript, not "slumming it" in an inferior language. Of course it's possible to write Javascript that does all of those things that ramda rejects and still works as intended, but as you've mentioned, Ramda is simply choosing to take a more principled approach. Given that vanilla Javascript let's the user do pretty much whatever he or she want, Ramda's main guiding principle strikes me as "addition by subtraction", which is a good thing.
The fact that variadic functions fall on the wrong side of that principle strikes me as a little arbitrary, but I can still respect that you've chosen to put a stake in the ground.
Having said all that, maybe this abstraction is a bit too much of a jump for ramda as a library. If the requirements of having nice things (more general abstractions) conflict with what currently makes converge really powerful to most users, then we should probably revert its deprecation.

Ramda already takes all sorts of positions that are at odds with the majority of "Javascript developers"—no mutation, well defined input and output types, avoiding optional arguments, etc. [ ... ] Of course it's possible to write Javascript that does all of those things that ramda rejects and still works as intended, but as you've mentioned, Ramda is simply choosing to take a more principled approach. Given that vanilla Javascript let's the user do pretty much whatever he or she want, Ramda's main guiding principle strikes me as "addition by subtraction", which is a good thing.

I don't think I've been well able to articulate what is for me a very clear dividing line.  Ramda should be quite principled.  We don't mutate your data.  We don't have optional arguments.  Our functions are more strictly typed.
But we don't take a particular stand on what you do.  If you want to pass to reduce a function that mutates the accumulator, we simply don't care.  If the first function you pass to pipe contains optional parameters, it might be odd, but it's your lookout.  If you are passing different-arity functions to converge, you get a function which might seem strange to me, but if it works for you, that's fine.
This has been my personal view for a long time.  I don't know if it's the correct guideline for the larger community, and perhaps its time to figure that out.

@CrossEye: I think your view can work for the larger community, too.

This variant of using lift does no longer work since v.0.22
R.lift(R.subtract)(R.multiply, R.add)(4, 3); //=> 5

Test in v.0.21
Test in v.0.22
Is there a way to achieve the same result in current version of Ramda?

I guess, this change in behaviour was caused by this PR https://github.com/ramda/ramda/pull/1741.

That's interesting, and I didn't ever notice it.
I still often think in terms of converge, and then try to decide if I can use lift instead.  This is probably not a good habit, but converge (and useWith) can really become habit-forming.  Now that I'm always working in ES6 environments, point-free is much less of a concern, since arrows make for simple lambdas in JS.  And I use these functions much less.
Do you see any problems that lift doesn't do this anymore?

@CrossEye it's totally tangential to the overall discussion, but I haven't really felt that the main benefit with point-free programming is the more compact code, which may be how you think about it as you say, fat arrows do a reasonable job of replacing it. Some other benefits may be:

not using lambda expressions, and therefore not using bindings (symbol names) so the thing is less domain dependent
of course, names can be simply a and b but in this case there's even less value with using a lambda expression - it doesn't give the code reader an intuition of what the variables are, eg. unitPrice and quantity
using point-free is a way for structuring code into a graph, where for example a converge or useWith is a node, and its arguments are nodes too; entire programs can be written this way, while the use of lambdas breaks this graph property (the graph property can be useful if one writes a program that transforms a point-free program)

Having said all these, maybe it reflects my interest in knowing more about the actual benefit of point-free programming. For I used it quite a bit and found drawbacks, at least with current JavaScript browsers and IDEs:

(superficial) it's easier to put in a debugger statement or set a Dev Tools breakpoint on a line in a {...} function body than doing the same with point-free - having to wrap around a thing, cutting, inserting some tap()-like thing, and placing the cut thing into it, esp. that ramda etc. don't like/use variadic HOFs - and forget about Dev Tools breakpoints (yes I find it incredibly useful to see values; if someone doesn't, I'm interested in learning how one can wean)
(deep) I found that code refactored into a point-free style looked compact and elegant, but (for me) harder to understand, presumably due to lower redundancy compared to domain-specific names in lexical bindings in lambdas, whether the code was written by an (excellent) coworker or by me the previous day
(deeper) for some reason, nontrivial point-free code was rigid for me to refactor, if the use case changed and some previous assumption stopped being valid, or the requirements changed slightly - it often required a quite elaborate refactoring that ended up in a fairly different shaped new point-free code, so it felt to me that point-free is more brittle than code with lexical bindings

I'm interested in other viewpoints on this, whether similar experiences or on the contrary, maybe with some advice.

@monfera:  Thanks for the feedback.
I agree that there are other advantages to using point-free as well as a number of drawbacks.  I'm interested in the idea of a graph of functions.  Do you get practical benefits from this?  Do you use particular tools to manipulate or view such a graph?
As to the drawbacks you mention, I don't really have the debugger issue.  Much of my point-free code is in pipe/compose chains, where it's easy to add a tap, even one that contains a debugger statement.  But I don't step through code all that often.
The second two are related, I believe.  If it's harder to understand, it's harder to refactor.  And probably vice versa as well.
What I think gains back some readability is to always use type signatures on one's code.  This often makes it easy to assemble function chains mechanically.
For the sort of refactoring you describe, I will usually write new functions and only then see if I can simply rename my old ones or in some other way reuse them.  In other words, when I have substantial reworking to do, I tend to rewrite rather than anything that might generally be called refactoring.  But having a good test suite means that I can still call it refactoring if anyone asks!  :smile:

@CrossEye yes, tap is easiest to add in pipe/compose esp. that they're still variadic; all other nodes of interest would need to be wrapped around eg. by
const breakpoint = originalNode => compose(tap(d => {debugger; return d}), originalNode)`

and even with this, I have access to the data at a single edge, while a breakpoint in a lambda expression lets me inspect all available lexical bindings, advance the code to some other line etc. It's like taking a single snapshot through a keyhole as opposed to just opening the door. Dev Tools is great and I like having easy access to its power.
Yes there's relation between difficulty of understanding code and difficulty of refactoring. When mentioning rigidity, I assumed good understanding of both the current version and the new version. Even then, the addition of an innocent-looking piece of data, or switch to a new input format may largely change the shape and structure of the code - as you say it can be a rewrite, not a sequence of incremental code changes. You mentioned testing. Small changes often lead to different structures, therefore many functions are superseded, unit tests have to be scrapped and redone, if they're done at the granularity of individual functions and not eg. modules.
The brittleness seems to come from the fact that data paths and information representations (eg. object vs array vs tree) are "hardwired" into the code structure, while with lambda expressions, you typically have a bunch of lexical bindings and maybe bindings from outer lambdas, and you're way less restricted from referencing any of these or their parts, useful for prototyping. What just needs a local change in one specific lambda-style function will usually need a different subgraph of converge, useWith, compose, zip etc. When frustrated with this friction, I even started thinking of point-free as less declarative than lambda-style because it seemed to make it harder for me to declare my intent when I was in an exploratory mode and didn't code something that I fully understood from the outset and never needed change. Felt like freely waving a data fabric vs. having to use needlepoint to thread the data. Point-free code was less stable, small changes perturbing it significantly. I think part of the merit of declarative programming is that the "truths" you declare are efficient (in development time) to curate over time. Ended up mixing point-free with lambda style on personal projects, ie. quite a few pipe ops and even lift, but avoiding the otherwise neat useWith, converge, lens (on client projects I follow whatever is the team decision).
So all in all there's nontrivial cost (to me) when using the point-free style, maybe because my code may not be as dominated by pipe/compose as yours. This is why I'm on the lookout for the benefits that justify it.
The "graph of functions" thing is handy if you want to treat your code as data, and don't want to go through the route of entirely relying on a JavaScript parser. For example, a user of your system may customize the behavior of the application by composing functions, or you want to serialize your logic, or want to run analytics on your source code. A directed acyclic graph is also more language-neutral than full blown JS, so you can move logic between languages if need be. There are other tools that bridge over languages, eg. the Rx family (RxJS etc.) or transducer libraries, and assuming a ramda-like library or a target language with FP support, one can transfer reducer functions etc. without a major rewrite.
Ah one more thing with the graph style of coding. You can start with a single-pass implementation of whatever you work on, ie. you apply the resulting module (ie. the root node of the graph) to some value. Then maybe you replace the ramda functions you use to lifted functions that work on eg. reactive streams (observables) rather than values. The graph doesn't need to change and now it works in streaming mode rather than in batch mode.
But again, these are just my thoughts and I probably don't think of some other benefits that go with it.

But again, these are just my thoughts...

They were well-worth sharing.  Thank you.