Add content preview in notifications

Fixes https://github.com/near/near-discovery/issues/583.
Based on design specifications:
https://www.figma.com/file/Cm6qATC1CpK9nUrKgx5K3U/Notifications?type=design&node-id=1-15248&mode=design&t=MdgBWoskxRaQuyj1-4

Added styles to banner buttons.
Added styles to the See all button in the notification tab.
Added notification content preview.
Replaced the Turn on/off button with switcher on the notification settings page.

LGTM! I left the last comment which doesn't block the preview of notifications so feel free to address it in separate PR

hey @shelegdmitriy Just a heads up, our new branch protection rules require that all conversations be resolved before. PR can be merged, so if you don't want that comment to block this PR please resolve it.

LGTM! I left the last comment which doesn't block the preview of notifications so feel free to address it in separate PR

hey @shelegdmitriy Just a heads up, our new branch protection rules require that all conversations be resolved before. PR can be merged, so if you don't want your open conversations to block this PR please resolve them.

Yeah, I know that. @erditkurteshiSQA feel free to resolve that comment by your own


Depth First Search added to PathFinding Algorithm

PathFinding Algorithms added to the MainMenu and DFS added

Screen Flickering Issue resolved in Rat_in_the _Maze.py and Knights_Tour.py

I have gone through this pull request. There are certain bugs that needs to be fixed before merging this pull request. I ll let you know the details of it over a telephone conversation.
Major improvement seen in terms of readability of Code. Good Job.

All the desired changes proposed by @karan236  are made.

Everything seemed fine to me. All the raised issues are fixed.
You can merge it with master.


Incorporate multiple or complex geometries

https://opengeometadata.org/docs/ogm-aardvark/geometry

to do: create a fixture

Need to support:

Simple bounding box: "ENVELOPE(-111.1, -104.0, 45.0, 40.9)"
Bermuda Triangle: "POLYGON((-80 25, -65 18, -64 33, -80 25))"
Split bounding box for Alaska: "MULTIPOLYGON (((-179.3 51.1, -129.9 51.1, -129.9 71.5, -179.3 71.5, -179.3 51.1)),((172.3 51.2, 179.9 51.2, 179.9 53.1, 172.3 53.1, 172.3 51.2)))"

We can use RGeo's wkt_parser to validate POLYGON and MULTIPOLYGON:
poly = "POLYGON((-80 25, -65 18, -64 33, -80 25))"
parsed = RGeo::Cartesian::Factory.new().parse_wkt(poly)
=> #<RGeo::Cartesian::PolygonImpl:0x64c8 "POLYGON ((-80.0 25.0, -65.0 18.0, -64.0 33.0, -80.0 25.0))">

But! RGeo does not recognize the ENVELOPE syntax:
bbox = "ENVELOPE(-18.6,52.3,37.17,-35.3)"
parsed = RGeo::Cartesian::Factory.new().parse_wkt(bbox)
=> Unknown type tag: "envelope". (RGeo::Error::ParseError)

Here is a fixture that we could use: https://github.com/OpenGeoMetadata/geobtaa/blob/main/aardvark/797ddf9a-41ae-4525-90e4-4238ea09079b.json
Not sure if the multipolygon syntax is correct yet; still testing


docs(wrapper-array): add is warning

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[x] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[x] It's submitted to the dev branch.
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] All tests are passing: https://github.com/vuejs/vue-test-utils/blob/dev/.github/CONTRIBUTING.md#development-setup
[ ] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

Cool... you know Chinese/Japanese and French? I don't know Chinese or French, so I can't exactly review this. I'll find someone who can, though.

Cool... you know Chinese/Japanese and French? I don't know Chinese or French, so I can't exactly review this. I'll find someone who can, though.

Haha, I don't know Chinese / Japanese and French either, because the content changed here is the same in other documents, and I copy it directly


[4.0] KeyPaths: Add support for optional chaining/forcing components.

Explanation: Adds support for optional chaining and force-unwrapping components in keypaths, part of the original proposal that didn't make it into the first Swift beta.
Scope: New feature
Issue: rdar://problem/31768715
Risk: Low, additive feature work that should not disturb existing code.
Testing: Swift CI

@swift-ci Please test

@slavapestov Does this look OK for 4.0?


Update README.md

missing an equals in the sample code

Ticket

Closes PAS-XXX

Description

Shape

Screenshots

Checklist
I did the following to ensure that my changes were tested thoroughly:

__

I did the following to ensure that my changes do not introduce security vulnerabilities:

__

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

Hi @StevenTCramer,
Thank you very much for taking the time to contribute! Would you be able to sign the 'Contributor License Agreement' so I can merge your pull request?


How to identify wallet's current account and chainId ?

I'm developing a decentralized application (dApp) that integrates with the Metamask wallet. After establishing a connection, I can obtain the current chainId and account details, and also subscribe to 'accountChanged' and 'chainsChanged' to keep these details updated.
However, I'm encountering a problem when the app is closed and restarted. I'm unsure how to determine the account and chainId that the wallet is currently using, because the event subscription doesn't activate when the Web3App initializes for the first time.
Here's why it's necessary: Let's say I connect to the account eip155:5:address, but then my wallet switches to eip155:1:address or eip155:1:other_address. Now, if I want to send a message request for signing from my dApp, the wallet app won't show the sign message popup unless I specify the current chainId and address of the wallet app.
Hence, I need this information to alert users to switch to the correct chainId and account address.
I'm using metamask for experimental

@mthinh
https://docs.metamask.io/wallet/reference/eth_chainId/
in WalletConnect V1 I used eth_chainId to get current chain from metamask
and wallet_switchEthereumChain method to switch chain
but right now there are bugs related to switch chain method in Metamask github so I am not sure if it is fully functional in latest version

@AmjadKhan2k18 do you have issue link ? can you share me ?

@mthinh  here it is  https://github.com/MetaMask/metamask-mobile/issues/6655

Not sure if I have anything else to input here.
Sounds like ethereum just needs codified methods for you to fetch the current chain info and request it be changed if necessary.
Closing as complete.


[BUG] Nordic CMake Generating Build Files hangs after C compiler identification

Describe the bug
I am trying to use CMake to generates build files for the Nordic Demo but the process is stucked just after the C compiler identification.
System information

Hardware board: nrf52840-dk
IDE used: none
Operating System: Windows 10
Code version: 20210526_Archive-24-gf8a1fda60
Project/Demo: MQTT_BLE_TRANSPORT_DEMO

Expected behavior
Build files should be generated
Screenshots or console output
cmake -DVENDOR=nordic -DBOARD=nrf52840-dk -DCOMPILER=arm-segger -DAFR_ENABLE_ALL_MODULES=1 -DAFR_ENABLE_TESTS=0 -DAFR_TOOLCHAIN_PATH="C:\Program Files\SEGGER\SEGGER Embedded Studio for ARM 5.50a\gcc\arm-none-eabi" -S ..\amazon-freertos\ -B . -G"Unix Makefiles"
-- The C compiler identification is GNU 10.2.1

Steps to reproduce bug
Try the same procedure on Windows ?
Additional context
I trued different version of Segger Arm Compiler 64 and 32bit, latest 5.50a but also 5.32a anb 4.42b

Hi @dtony,
I setup the windows environment as the getting start guide and it looks it works. I have cmake version of 3.17.2 and Segger Embedded Studio v5.50a windows 64-bit. The command I used is cmake -DVENDOR=nordic -DBOARD=nrf52840-dk -DCOMPILER=arm-segger -DAFR_ENABLE_ALL_MODULES=1 -DAFR_ENABLE_TESTS=0 -S . -B ./build -G"Unix Makefiles" -DAFR_TOOLCHAIN_PATH="C:\Program Files\SEGGER\SEGGER Embedded Studio for ARM 5.50a\gcc\arm-none-eabi" which is build from root of amazon-freertos. But I tried build from the outside folder as your command and it also works...
›

Regards,
Ming

I just downlgraded to CMake 3.17.2 and it works ! It is probably a bug in most recent release of CMake thank you for pointing me in the right direction.

Cool, that's Great!


OutOfMemoryException when exporting anchors

When using the Sharing components, OutOfMemoryException is thrown by ImportExportAnchorManager. I just simply modified the Holograms 240 example to include my own content. Are there any workarounds to this?
The logs are below.
OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Collections.Generic.List`1.set_Capacity(Int32 value)
   at System.Collections.Generic.List`1.EnsureCapacity(Int32 min)
   at System.Collections.Generic.List`1.InsertRange(Int32 index, IEnumerable`1 collection)
   at ImportExportAnchorManager.WriteBuffer(Byte[] data)
   at UnityEngine.VR.WSA.Sharing.WorldAnchorTransferBatch.InvokeWorldAnchorSerializationDataAvailableDelegate(SerializationDataAvailableDelegate onSerializationDataAvailable, Byte[] data)
   at UnityEngine.VR.WSA.Sharing.WorldAnchorTransferBatch.$Invoke18(Int64 instance, Int64* args)
   at UnityEngine.Internal.$MethodUtility.InvokeMethod(Int64 instance, Int64* args, IntPtr method)
(Filename: <Unknown> Line: 0)

OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Collections.Generic.List`1.ToArray()
   at ImportExportAnchorManager.ExportComplete(SerializationCompletionReason status)
   at UnityEngine.VR.WSA.Sharing.WorldAnchorTransferBatch.InvokeWorldAnchorSerializationCompleteDelegate(SerializationCompleteDelegate onSerializationComplete, SerializationCompletionReason completionReason)
   at UnityEngine.VR.WSA.Sharing.WorldAnchorTransferBatch.$Invoke17(Int64 instance, Int64* args)
   at UnityEngine.Internal.$MethodUtility.InvokeMethod(Int64 instance, Int64* args, IntPtr method)
(Filename: <Unknown> Line: 0)

Can you reproduce this outside of Holograms 240?

You can try to repro with this test scene as well:
https://github.com/Microsoft/HoloToolkit-Unity/blob/master/Assets/HoloToolkit/Sharing/Tests/Sharing.unity

@meng-hui I ran the sharing scenes today without any issues. Maybe I'm missing something - @meng-hui any more details on what content you added?

Please reopen with more information if you see this again.


CET stopped working suddenly

All of a sudden Cyber Engine Tweaks doesn't work anymore like the game updated without any patches or something and i even tried to verify the game and still it doesn't work. The mod worked today around 5 am but it didn't work around 7:30 am this morning

They released a dumb patch with the same version name...


Please allow use of M365 Direct Send in custom SMTP config

Is your feature request related to a problem? Please describe.
Hi team - I have another issue with SMTP set up - can you please offer an option for no authentication?  We use M365 and we can use the smarthost from any email address with our domain even that is has no mailbox (https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-mu[…]application-to-send-email-using-microsoft-365-or-office-365) the modal for adding an SMTP config unfortunately doesn't allow us to move on without entering credentials.
Describe the solution you'd like
An option to use no authentication as a start (with a list of IPs that are sending OneUptime email so I can populate my SPF record)

Fixed: https://github.com/OneUptime/oneuptime/commit/27f5f96ba99dc15a092fa95e138426b4d2efe6d3


Re-do VMI aliases from scratch

Since the move to 16.04, or the move to PHP7, or the move to Drush 8, VMI aliases have ceased working altogether.
Consolidating concerns from #43 and #44, where perf was worse and sometimes it failed outright.
As such, it may just be worth revisiting the concept of VMI aliases from scratch.

turns out we didn't have to re-do it from scratch. Just had to switch from <IP_ADDRESS>:2222 to <IP_ADDRESS>:22. Done.
Looks like we may need to do some sneaky stuff to flip between which version of PHP CLI to use, but for now it's un-broken.


panic when linting multi file library

version: latest | compiled: 2023-05-25 12:24:36 CEST
🔗 https://quobix.com/vacuum | https://github.com/daveshanley/vacuum

 INFO  Linting against 42 rules: https://quobix.com/vacuum/rulesets/recommended
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x18 pc=0x104f548c8]

goroutine 369 [running]:
github.com/pb33f/libopenapi/datamodel/high/base.(*SchemaProxy).BuildSchema(0x105712000?)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/base/schema_proxy.go:111 +0x18
github.com/pb33f/libopenapi/datamodel/high/base.(*SchemaProxy).MarshalYAMLInline(0x14000758c98?)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/base/schema_proxy.go:170 +0x1c
github.com/pb33f/libopenapi/datamodel/high/base.(*DynamicValue[...]).MarshalYAML(0x1057d8a60)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/base/dynamic_value.go:66 +0x26c
github.com/pb33f/libopenapi/datamodel/high/base.(*DynamicValue[...]).MarshalYAMLInline(...)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/base/dynamic_value.go:100
github.com/pb33f/libopenapi/datamodel/high.(*NodeBuilder).AddYAMLNode(0x14000676180, 0x14000218500, 0x1400047e050)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/node_builder.go:523 +0xd58
github.com/pb33f/libopenapi/datamodel/high.(*NodeBuilder).Render(0x14000676180)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/node_builder.go:262 +0x35c
github.com/pb33f/libopenapi/datamodel/high/base.(*Schema).MarshalYAMLInline(0x14000759501?)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/base/schema.go:483 +0x40
github.com/pb33f/libopenapi/datamodel/high/base.(*Schema).RenderInline(0x8?)
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi@v0.8.2/datamodel/high/base/schema.go:470 +0x1c
github.com/pb33f/libopenapi-validator/schema_validation.validateSchema(0x140001c8000, {0x0, 0x0, 0x0}, {0x1056a3560, 0x140001ae210})
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.7/schema_validation/validate_schema.go:62 +0x80
github.com/pb33f/libopenapi-validator/schema_validation.(*schemaValidator).ValidateSchemaObject(0x1400081e000?, 0x17a?, {0x1056a3560?, 0x140001ae210?})
	/Users/dmitry/go/pkg/mod/github.com/pb33f/libopenapi-validator@v0.0.7/schema_validation/validate_schema.go:50 +0x3c
github.com/daveshanley/vacuum/parser.ValidateNodeAgainstSchema(0x140006977b8?, 0x14000056900?, 0x20?)
	/Users/dmitry/go/pkg/mod/github.com/daveshanley/vacuum@v0.1.4/parser/json_schema.go:222 +0x254
github.com/daveshanley/vacuum/functions/core.validateNodeAgainstSchema(0x140001983a0?, 0x140001230e0, {0x140002f2480, 0x140007694a0, {0x1056b38a0, 0x14000802790}, {0x1056fd820, 0x14000197470}, 0x1400030af00, 0x14000122140, ...}, ...)
	/Users/dmitry/go/pkg/mod/github.com/daveshanley/vacuum@v0.1.4/functions/core/schema.go:95 +0x58
github.com/daveshanley/vacuum/functions/core.Schema.RunRule({}, {0x140002220e0, 0x1, 0x12e222bc8?}, {0x140002f2480, 0x140007694a0, {0x1056b38a0, 0x14000802790}, {0x1056fd820, 0x14000197470}, ...})
	/Users/dmitry/go/pkg/mod/github.com/daveshanley/vacuum@v0.1.4/functions/core/schema.go:67 +0x7b4
github.com/daveshanley/vacuum/motor.buildResults({0x140007694a0, 0x140001220a0, {0x1057d1b48, 0x14000132c30}, 0x140007a7a28, 0x140004d1370, 0x1400000e018, 0x1400030af00, 0x14000122140, 0x0, ...}, ...)
	/Users/dmitry/go/pkg/mod/github.com/daveshanley/vacuum@v0.1.4/motor/rule_applicator.go:393 +0x5a0
github.com/daveshanley/vacuum/motor.runRule({0x140007694a0, 0x140001220a0, {0x1057d1b48, 0x14000132c30}, 0x140007a7a28, 0x140004d1370, 0x1400000e018, 0x1400030af00, 0x14000122140, 0x0, ...})
	/Users/dmitry/go/pkg/mod/github.com/daveshanley/vacuum@v0.1.4/motor/rule_applicator.go:317 +0x34c
created by github.com/daveshanley/vacuum/motor.ApplyRulesToRuleSet
	/Users/dmitry/go/pkg/mod/github.com/daveshanley/vacuum@v0.1.4/motor/rule_applicator.go:248 +0xc18
gmake: *** [Makefile:63: liblint] Error 2

I can try to make minimal reproduction sample. Out spec is quite large, it will take some time.

# yaml-language-server: $schema=https://json-schema.org/draft/2020-12/schema

# Validations: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-00
# JSON Schema: https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00

openapi: 3.1.0
info:
  title: API
  version: "1.0.0"
  description: This specification describes API

servers:
  - url: https://api.server.test/v1

tags:
  - name: tag1-tag
  - name: tag2-tag
  - name: tag3-tag
  - name: tag4-tag
  - name: tag5-tag

# For components structuring see: https://swagger.io/docs/specification/components/
components:

  # You can place any object here that is not suppose to be included in the endpoints.
  # Good example could be NVState/PackML data types.
  schemas:
    NVAlarm: # UA spec type
      type: object
      required:
        - id
        - value
        - category
        - timeEvent
        - timeReset
        - active
      properties:
        id:
          type: integer
          format: int32
        value:
          type: integer
          format: int32
        category:
          type: integer
          format: int32
        timeEvent:
          type: integer
          format: int32
        timeReset:
          type: integer
          format: int32
        active:
          type: integer
          format: int32

@daveshanley  This essentially crashes it. But you comment out all tags section, then everything works.

I ran the spec through the v0.1.6 branch of vacuum (which uses the soon to be released v0.9.0 version of libopenapi).
I can't reproduce the issue, the spec runs fine, without any modification.
If you could try the same, it should confirm a fix - however I didn't fix this bug in particular. I just can't reproduce it using the latest bits.

Try this again with v0.1.6

Heh. I still can. Maybe it has something to do with how i install or arch.
I install using go install with specific version.
And i have M1.
I'll try to debug it.

It is reproducible also in GH ci we have.

Ok. i Nailed. It. It has something to with ruleset

description: Recommended rules for a high quality specification.
documentationUrl: https://quobix.com/vacuum/rulesets/recommended
rules:
    component-description:
        category:
            description: Documentation is really important, in OpenAPI, just about everything can and should have a description. This set of rules checks for absent descriptions, poor quality descriptions (copy/paste), or short descriptions.
            id: descriptions
            name: Descriptions
        description: Component description check
        formats:
            - oas3
            - oas3_1
        given: $
        howToFix: Components are the inputs and outputs of a specification. A user needs to be able to understand each component and what id does. Descriptions are critical to understanding components. Add a description!
        id: component-description
        recommended: true
        resolved: true
        severity: warn
        then:
            function: oasComponentDescriptions
        type: validation
    description-duplication:
        category:
            description: Documentation is really important, in OpenAPI, just about everything can and should have a description. This set of rules checks for absent descriptions, poor quality descriptions (copy/paste), or short descriptions.
            id: descriptions
            name: Descriptions
        description: Description duplication check
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Descriptions are only useful, if they are meaningful. If a description is meaningful, then it won't be something you copy and paste. Please don't duplicate descriptions, make them deliberate and meaningful.
        id: description-duplication
        recommended: true
        severity: info
        then:
            function: oasDesqcriptionDuplication
        type: validation
    duplicated-entry-in-enum:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: Enum values must not have duplicate entry
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Enums need to be unique, you can't duplicate them in the same definition. Please remove the duplicate value.
        id: duplicated-entry-in-enum
        recommended: true
        severity: error
        then:
            function: duplicatedEnum
        type: validation
    info-description:
        category:
            description: The info object contains licencing, contact, authorship details and more. Checks to confirm required details have been completed.
            id: information
            name: Contract Information
        description: Info section is missing a description
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $.info
        howToFix: The 'info' section is missing a description, surely you want people to know what this spec is all about, right?
        id: info-description
        recommended: true
        resolved: true
        severity: error
        then:
            field: description
            function: truthy
        type: validation
    no-$ref-siblings:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: $ref values cannot be placed next to other properties (like a description)
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: $ref values must not be placed next to sibling nodes, There should only be a single node  when using $ref. A common mistake is adding 'description' next to a $ref. This is wrong. remove all siblings!
        id: no-$ref-siblings
        recommended: true
        severity: error
        then:
            function: refSiblings
        type: validation
    no-ambiguous-paths:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Paths need to resolve unambiguously from one another
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Paths must all resolve unambiguously, they can't be confused with one another (/{id}/ambiguous and /ambiguous/{id} are the same thing. Make sure every path and the variables used are unique and do conflict with one another. Check the ordering of variables and the naming of path segments.
        id: no-ambiguous-paths
        recommended: true
        resolved: true
        severity: error
        then:
            function: ambiguousPaths
        type: validation
    no-eval-in-markdown:
        category:
            description: Validation rules make sure that certain characters or patterns have not been used that may causeissues when rendering in different types of applications.
            id: validation
            name: Validation
        description: Markdown descriptions must not have `eval()` statements'
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Remove all references to 'eval()' in the description. These can be used by malicious actors to embed code in contracts that is then executed when read by a browser.
        id: no-eval-in-markdown
        recommended: true
        resolved: true
        severity: error
        then:
            function: noEvalDescription
            functionOptions:
                pattern: eval\(
        type: validation
    no-http-verbs-in-path:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Path segments must not contain an HTTP verb
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: When HTTP verbs (get/post/put etc) are used in path segments, it muddies the semantics of REST and creates a confusing and inconsistent experience. It's highly recommended that verbs are not used in path segments. Replace those HTTP verbs with more meaningful nouns.
        id: no-http-verbs-in-path
        recommended: true
        severity: warn
        then:
            function: noVerbsInPath
        type: style
    no-script-tags-in-markdown:
        category:
            description: Validation rules make sure that certain characters or patterns have not been used that may causeissues when rendering in different types of applications.
            id: validation
            name: Validation
        description: Markdown descriptions must not have `<script>` tags'
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Remove all references to '<script>' tags from the description. These can be used by malicious actors to load remote code if the spec is being parsed by a browser.
        id: no-script-tags-in-markdown
        recommended: true
        resolved: true
        severity: error
        then:
            function: noEvalDescription
            functionOptions:
                pattern: <script
        type: validation
    oas2-anyOf:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: '`anyOf` was introduced in OpenAPI 3.0, cannot be used un OpenAPI 2 specs'
        formats:
            - oas2
        given: $
        howToFix: You can't use 'anyOf' in Swagger/OpenAPI 2 specs. It was added in version 3. You have to remove it
        id: oas2-anyOf
        recommended: true
        severity: error
        then:
            function: oasPolymorphicAnyOf
        type: validation
    oas2-api-host:
        category:
            description: The info object contains licencing, contact, authorship details and more. Checks to confirm required details have been completed.
            id: information
            name: Contract Information
        description: OpenAPI `host` must be present and a non-empty string
        formats:
            - oas2
        given: $
        howToFix: The 'host' value is missing. How is a user supposed to know where the API actually lives? The host is critical in order for consumers to be able to call the API. Add an API host!
        id: oas2-api-host
        recommended: true
        severity: info
        then:
            field: host
            function: truthy
        type: style
    oas2-api-schemes:
        category:
            description: The info object contains licencing, contact, authorship details and more. Checks to confirm required details have been completed.
            id: information
            name: Contract Information
        description: OpenAPI host `schemes` must be present and non-empty array
        formats:
            - oas2
        given: $
        howToFix: Add an array of supported host 'schemes' to the root of the specification. These are the available API schemes (like https/http).
        id: oas2-api-schemes
        recommended: true
        severity: warn
        then:
            field: schemes
            function: schema
            functionOptions:
                forceValidation: true
                schema:
                    items:
                        minItems: 1
                        type: string
                    type: array
                    uniqueItems: true
        type: validation
    oas2-discriminator:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: discriminators are used correctly in schemas
        formats:
            - oas2
        given: $
        howToFix: When using polymorphism, a discriminator should also be provided to allow tools to understand how to compose your models when generating code. Add a correct discriminator.
        id: oas2-discriminator
        recommended: true
        resolved: true
        severity: error
        then:
            function: oasDiscriminator
        type: validation
    oas2-host-not-example:
        category:
            description: The info object contains licencing, contact, authorship details and more. Checks to confirm required details have been completed.
            id: information
            name: Contract Information
        description: Host URL should not point at example.com
        formats:
            - oas2
        given: $.host
        howToFix: Remove 'example.com' from the host URL, it's not going to work.
        id: oas2-host-not-example
        recommended: true
        severity: warn
        then:
            function: pattern
            functionOptions:
                notMatch: example\.com
        type: style
    oas2-host-trailing-slash:
        category:
            description: The info object contains licencing, contact, authorship details and more. Checks to confirm required details have been completed.
            id: information
            name: Contract Information
        description: Host URL should not contain a trailing slash
        formats:
            - oas2
        given: $.host
        howToFix: Remove the trailing slash from the host URL. This may cause some tools to incorrectly add a double slash to paths.
        id: oas2-host-trailing-slash
        recommended: true
        severity: warn
        then:
            function: pattern
            functionOptions:
                notMatch: /$
        type: style
    oas2-oneOf:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: '`oneOf` was introduced in OpenAPI 3.0, cannot be used un OpenAPI 2 specs'
        formats:
            - oas2
        given: $
        howToFix: You can't use 'oneOf' in Swagger/OpenAPI 2 specs. It was added in version 3. You have to remove it
        id: oas2-oneOf
        recommended: true
        severity: error
        then:
            function: oasPolymorphicOneOf
        type: validation
    oas2-operation-formData-consume-check:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: 'Operations with `in: formData` parameter must include `application/x-www-form-urlencoded` or `multipart/form-data` in their `consumes` property.'
        formats:
            - oas2
        given: $
        howToFix: When using 'formData', the parameter must include the correct mime-types. Make sure you use 'application/x-www-form-urlencoded' or 'multipart/form-data' as the 'consumes' value in your parameter.
        id: oas2-operation-formData-consume-check
        recommended: true
        resolved: true
        severity: warn
        then:
            function: oasOpFormDataConsumeCheck
        type: validation
    oas2-operation-security-defined:
        category:
            description: Security plays a central role in RESTful APIs. These rules make sure that the correct definitionshave been used and put in the right places.
            id: security
            name: Security
        description: '`security` values must match a scheme defined in securityDefinitions'
        formats:
            - oas2
        given: $
        howToFix: When defining security definitions for operations, you need to ensure they match the globally defined security schemes. Check $.securityDefinitions to make sure your values align.
        id: oas2-operation-security-defined
        recommended: true
        resolved: true
        severity: error
        then:
            function: oas2OpSecurityDefined
        type: validation
    oas2-parameter-description:
        category:
            description: Documentation is really important, in OpenAPI, just about everything can and should have a description. This set of rules checks for absent descriptions, poor quality descriptions (copy/paste), or short descriptions.
            id: descriptions
            name: Descriptions
        description: Parameter description checks
        formats:
            - oas2
        given: $
        howToFix: All parameters should have a description. Descriptions are critical to understanding how an API works correctly. Please add a description to all parameters.
        id: oas2-parameter-description
        recommended: true
        resolved: true
        severity: warn
        then:
            function: oasParamDescriptions
        type: style
    oas2-schema:
        category:
            description: Validation rules make sure that certain characters or patterns have not been used that may causeissues when rendering in different types of applications.
            id: validation
            name: Validation
        description: OpenAPI 2 specification is invalid
        formats:
            - oas2
        given: $
        howToFix: The schema isn't valid Swagger/OpenAPI 2. Check the errors for more details
        id: oas2-schema
        recommended: true
        severity: error
        then:
            function: oasDocumentSchema
        type: validation
    oas2-unused-definition:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: Check for unused definitions and bad references
        formats:
            - oas2
        given: $
        howToFix: Orphaned components are not used by anything. You might have plans to use them later, or they could be older schemas that never got cleaned up. A clean spec is a happy spec. Prune your orphaned components.
        id: oas2-unused-definition
        recommended: true
        severity: warn
        then:
            function: oasUnusedComponent
        type: validation
    oas2-valid-schema-example:
        category:
            description: Examples help consumers understand how API calls should look. They are really important forautomated tooling for mocking and testing. These rules check examples have been added to component schemas, parameters and operations. These rules also check that examples match the schema and types provided.
            id: examples
            name: Examples
        description: Examples must be present and valid for operations and components
        formats:
            - oas2
        given: $
        howToFix: Examples are critical for consumers to be able to understand schemas and models defined by the spec. Without examples, developers can't understand the type of data the API will return in real life. Examples are turned into mocks and can provide a rich testing capability for APIs. Add detailed examples everywhere!
        id: oas2-valid-schema-example
        recommended: true
        severity: warn
        then:
            function: oasExample
        type: validation
    openapi-tags:
        category:
            description: Tags are used as meta-data for operations. They are mainly used by tooling as a taxonomy mechanism to build navigation, search and more. Tags are important as they help consumers navigate the contract when using documentation, testing, code generation or analysis tools.
            id: tags
            name: Tags
        description: Top level spec `tags` must not be empty, and must be an array
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Add a global 'tags' object to the root of the spec. Global tags are used by operations to define taxonomy and information architecture by tools. Tags generate navigation in documentation as well as modules in code generation.
        id: openapi-tags
        resolved: true
        severity: warn
        then:
            field: tags
            function: schema
            functionOptions:
                forceValidation: true
                schema:
                    items:
                        minItems: 1
                        type: object
                    type: array
                    uniqueItems: true
        type: validation
    oas3-api-servers:
        category:
            description: Validation rules make sure that certain characters or patterns have not been used that may causeissues when rendering in different types of applications.
            id: validation
            name: Validation
        description: Check for valid API servers definition
        formats:
            - oas3
        given: $
        howToFix: Ensure server URIs are correct and valid, check the schemes, ensure descriptions are complete.
        id: oas3-api-servers
        recommended: true
        severity: error
        then:
            function: oasAPIServers
        type: validation
    oas3-operation-security-defined:
        category:
            description: Security plays a central role in RESTful APIs. These rules make sure that the correct definitionshave been used and put in the right places.
            id: security
            name: Security
        description: '`security` values must match a scheme defined in components.securitySchemes'
        formats:
            - oas3
            - oas3_1
        given: $
        howToFix: When defining security values for operations, you need to ensure they match the globally defined security schemes. Check $.components.securitySchemes to make sure your values align.
        id: oas3-operation-security-defined
        recommended: true
        resolved: true
        severity: error
        then:
            function: oasOpSecurityDefined
            functionOptions:
                schemesPath: $.components.securitySchemes
        type: validation
    oas3-parameter-description:
        category:
            description: Documentation is really important, in OpenAPI, just about everything can and should have a description. This set of rules checks for absent descriptions, poor quality descriptions (copy/paste), or short descriptions.
            id: descriptions
            name: Descriptions
        description: Parameter description checks
        formats:
            - oas3
            - oas3_1
        given: $
        howToFix: All parameters should have a description. Descriptions are critical to understanding how an API works correctly. Please add a description to all parameters.
        id: oas3-parameter-description
        recommended: true
        resolved: true
        severity: warn
        then:
            function: oasParamDescriptions
        type: style
    oas3-host-trailing-slash:
        category:
            description: The info object contains licencing, contact, authorship details and more. Checks to confirm required details have been completed.
            id: information
            name: Contract Information
        description: server URL should not contain a trailing slash
        formats:
            - oas3
        given: $.servers[*]
        howToFix: Remove the trailing slash from the server URL. This may cause some tools to incorrectly add a double slash to paths.
        id: oas3-host-trailing-slash
        severity: warn
        then:
            field: url
            function: pattern
            functionOptions:
                notMatch: /$
        type: style
    oas3-schema:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: OpenAPI 3 specification is invalid
        formats:
            - oas3_1
        given: $
        howToFix: The schema isn't valid OpenAPI 3.1. Check the errors for more details
        id: oas3-schema
        recommended: true
        severity: error
        then:
            function: oasDocumentSchema
        type: validation
    oas3-unused-component:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: Check for unused components and bad references
        formats:
            - oas3
            - oas3_1
        given: $
        howToFix: Unused components / definitions are generally the result of the OpenAPI contract being updated without considering references. Another reference could have been updated, or an operation changed that no longer references this component. Remove this component from the spec, or re-link to it from another component or operation to fix the problem.
        id: oas3-unused-component
        recommended: true
        severity: warn
        then:
            function: oasUnusedComponent
        type: validation
    # oas3-valid-schema-example:
    #     category:
    #         description: Examples help consumers understand how API calls should look. They are really important forautomated tooling for mocking and testing. These rules check examples have been added to component schemas, parameters and operations. These rules also check that examples match the schema and types provided.
    #         id: examples
    #         name: Examples
    #     description: Examples must be present and valid for operations and components
    #     formats:
    #         - oas3
    #         - oas3_1
    #     given: $
    #     howToFix: Examples are critical for consumers to be able to understand schemas and models defined by the spec. Without examples, developers can't understand the type of data the API will return in real life. Examples are turned into mocks and can provide a rich testing capability for APIs. Add detailed examples everywhere!
    #     id: oas3-valid-schema-example
    #     recommended: true
    #     severity: hint
    #     then:
    #         function: oasExample
    #     type: validation

    # operation-description:
    #     category:
    #         description: Documentation is really important, in OpenAPI, just about everything can and should have a description. This set of rules checks for absent descriptions, poor quality descriptions (copy/paste), or short descriptions.
    #         id: descriptions
    #         name: Descriptions
    #     description: Operation description checks
    #     formats:
    #         - oas3
    #         - oas3_1
    #         - oas2
    #     given: $
    #     howToFix: All operations must have a description. Descriptions explain how the operation works, and how users should use it and what to expect. Operation descriptions make up the bulk of API documentation. so please, add a description!
    #     id: operation-description
    #     recommended: true
    #     resolved: true
    #     severity: warn
    #     then:
    #         function: oasDescriptions
    #         functionOptions:
    #             minWords: "1"
    #     type: validation
    operation-operationId:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Every operation must contain an `operationId`.
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Every single operation needs an operationId. It's a critical requirement to be able to identify each individual operation uniquely. Please add an operationId to the operation.
        id: operation-operationId
        recommended: true
        severity: error
        then:
            function: oasOpId
        type: validation
    operation-operationId-unique:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Every operation must have unique `operationId`.
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $.paths
        howToFix: An operationId needs to be unique, there can't be any duplicates in the document, you can't re-use them. Make sure the ID used for this operation is unique.
        id: operation-operationId-unique
        recommended: true
        resolved: true
        severity: error
        then:
            function: oasOpIdUnique
        type: validation
    operation-operationId-valid-in-url:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: OperationId must use URL friendly characters
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $.paths[*][*]
        howToFix: An operationId is critical to correct code generation and operation identification. The operationId should really be designed in a way to make it friendly when used as part of an URL. Remove non-standard URL characters.
        id: operation-operationId-valid-in-url
        recommended: true
        resolved: true
        severity: error
        then:
            field: operationId
            function: pattern
            functionOptions:
                match: ^[A-Za-z0-9-._~:/?#\[\]@!\$&'()*+,;=]*$
        type: validation
    operation-parameters:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Operation parameters are unique and non-repeating.
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $.paths
        howToFix: Make sure that all the operation parameters are unique and non-repeating, don't duplicate names, don'tre-use parameter names in the same operation.
        id: operation-parameters
        recommended: true
        resolved: true
        severity: error
        then:
            function: oasOpParams
        type: validation
    operation-success-response:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Operation must have at least one `2xx` or a `3xx` response.
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Make sure that your operation returns a 'success' response via  2xx or 3xx response code. An API consumer will always expect a success response
        id: operation-success-response
        recommended: true
        resolved: true
        severity: warn
        then:
            field: responses
            function: oasOpSuccessResponse
        type: style
    operation-tag-defined:
        category:
            description: Tags are used as meta-data for operations. They are mainly used by tooling as a taxonomy mechanism to build navigation, search and more. Tags are important as they help consumers navigate the contract when using documentation, testing, code generation or analysis tools.
            id: tags
            name: Tags
        description: Operation tags must be defined in global tags.
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: This tag has not been defined in the global scope, you should always ensure that any tags used in operations, are defined globally in the root 'tags' definition.
        id: operation-tag-defined
        recommended: true
        resolved: true
        severity: warn
        then:
            function: oasTagDefined
        type: validation
    operation-tags:
        category:
            description: Tags are used as meta-data for operations. They are mainly used by tooling as a taxonomy mechanism to build navigation, search and more. Tags are important as they help consumers navigate the contract when using documentation, testing, code generation or analysis tools.
            id: tags
            name: Tags
        description: Operation `tags` are missing/empty
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Operations use tags to define the domain(s) they are apart of. Generally a single tag per operation is used, however some tools use multiple tags. The point is that you need tags! Add some tags to the operation that match the globally available ones.
        id: operation-tags
        recommended: true
        resolved: true
        severity: warn
        then:
            function: oasOperationTags
        type: validation
    path-declarations-must-exist:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Path parameter declarations must not be empty ex. `/api/{}` is invalid
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $.paths
        howToFix: Paths define the endpoint for operations. Without paths, there is no API. You need to add 'paths' to the root of the specification.
        id: path-declarations-must-exist
        recommended: true
        resolved: true
        severity: error
        then:
            function: pattern
            functionOptions:
                notMatch: '{}'
        type: validation
    path-keys-no-trailing-slash:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Path must not end with a slash
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $.paths
        howToFix: Paths should not end with a trailing slash, it can confuse tooling and isn't valid as a path Remove the trailing slash from the path.
        id: path-keys-no-trailing-slash
        recommended: true
        resolved: true
        severity: warn
        then:
            function: pattern
            functionOptions:
                notMatch: .+\/$
        type: validation
    path-not-include-query:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Path must not include query string
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $.paths
        howToFix: Query strings are defined as parameters for an operation, they should not be included in the path Please remove it and correctly define as a parameter.
        id: path-not-include-query
        recommended: true
        resolved: true
        severity: error
        then:
            function: pattern
            functionOptions:
                notMatch: \?
        type: validation
    path-params:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Path parameters must be defined and valid.
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Path parameters need to match up with the parameters defined for the path, or in an operation that sits under that path. Make sure variable names match up and are defined correctly.
        id: path-params
        recommended: true
        resolved: true
        severity: error
        then:
            function: oasPathParam
        type: validation
    paths-kebab-case:
        category:
            description: Operations are the core of the contract, they define paths and HTTP methods. These rules check operations have been well constructed, looks for operationId, parameter, schema and return types in depth.
            id: operations
            name: Operations
        description: Path segments must only use kebab-case (no underscores or uppercase)
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Path segments should not contain any uppercase letters, punctuation or underscores. The only valid way to separate words in a segment, is to use a hyphen '-'. The elements that are violating the rule are highlighted in the violation description. These are the elements that need to change.
        id: paths-kebab-case
        recommended: true
        severity: warn
        then:
            function: pattern
            functionOptions:
                match: ^(/[a-z][a-z0-9-_]+)+(@[a-z])?$
        type: validation
    typed-enum:
        category:
            description: Schemas are how request bodies and response payloads are defined. They define the data going in and the data flowing out of an operation. These rules check for structural validity, checking types, checkingrequired fields and validating correct use of structures.
            id: schemas
            name: Schemas
        description: Enum values must respect the specified type
        formats:
            - oas3
            - oas3_1
            - oas2
        given: $
        howToFix: Enum values lock down the number of variable inputs a parameter or schema can have. The problem here is that the Enum defined, does not match the specified type. Fix the type!
        id: typed-enum
        recommended: true
        resolved: true
        severity: warn
        then:
            function: typedEnum
        type: validation

This is ours

I will re-run this again asap.

This is how we run it: vacuum lint -d -r ruleset-recommended.yaml lib/typelib.yaml

OK, I have found the problem. It's actually a super deep issue in the most complex part of the entire stack. Schemas.
For some reason the Items property is being set when it should not, it's being set with no values, so when the renderer tries to evaluate the schema by rendering it, it's exploding when it reaches the 'not set, but still exists' Items value.

Try v0.1.7

@bitomaxsp bump^^

Maaan :) it's fixed with 0.1.7
Thanks a ton

Fixed in v0.1.7


add setting to plsql syntax file to disable procedure folding

PLSQL syntax folding can run too long on large files that ommit optional syntax (procedure end block names).
This commit adds a variable setting that turns off syntax folding for procedures.

ping @lee-lindley

ah sorry, I got that wrong. You are already the runtime file maintainer 🙈

PLSQL syntax folding can run too long on large files that ommit
optional syntax (procedure end block names).

Using exists() does not work well.  Better:
if get(g:, "plsql_disable_procedure_fold", 0)

Then the user can disable it with:
let g:plsql_disable_procedure_fold = 1
--
ARTHUR:  Be quiet!
DENNIS:  Well you can't expect to wield supreme executive power just 'cause
some watery tart threw a sword at you!

The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I'll include it, thanks.


How to provide multilingual support

Text preprocessing might be very language-dependent.
It would be great for Texthero to offer text preprocessing in all different languages.
There are probably two ways to support multilanguage:
from texthero.lang import hero_lang

from texthero import hero
hero.config.set_lang("lang")

We might have also cases where the dataset is composed of many languages. What would be the best solution in that case?
The first question we probably have to solve is: does different languages requires very different preprocessing pipeline and therefore different functions?

For Asian languages (Chinese, Japanese...),  word segmentation is an essential step in preprocessing. We usually remove non-textual characters in corpus, making them looks like naturally written texts, and segment the text with NLP tools. Its difference to the current texthero.preprocessing.clean is that we need to keep punctuation and digits to make sure the correctness of word segmentation, then we proceed to the following steps. Despite the difference, these steps can be done by language specific functions and custom pipelines, e.g.
from texthero import preprocessing
from texthero import nlp
import texthero as hero
hero.config.set_lang("cn")

custom_pipeline = [preprocessing.fillna,
                   preprocessing.remove_non_natural_text,
                   nlp.word_segment,
                   preprocessing.remove_stopwords,
                   ...]
df['clean_text'] = df['clean_text'].pipe(custom_pipeline)

Seems hero.config.set_lang("lang") can work properly and avoid redundant codes.

Just used Texthero for the first time yesterday. Pipeline for preprocessing seems fine, except for stopwords. A solution like @AlfredWGA mentioned would be very much appreciated inside hero. i.e. building and running a custom pipeline. In my case, I would only need to change the stopwords function

Just used Texthero for the first time yesterday in Portuguese. Pipeline for preprocessing seems fine, except for stopwords. A solution like @AlfredWGA mentioned would be very much appreciated inside hero. i.e. building and running a custom pipeline. In my case, I would only need to change the stopwords function

Hey @Jkasnese , if you read there in the getting-started, you will see that you can define your own custom pipeline:
from texthero import preprocessing

custom_pipeline = [preprocessing.fillna,
                   preprocessing.lowercase,
                   preprocessing.remove_whitespace]
df['clean_text'] = hero.clean(df['text'], custom_pipeline)

Is that what you were looking for?

For Asian languages (Chinese, Japanese...), word segmentation is an essential step in preprocessing. We usually remove non-textual characters in corpus, making them looks like naturally written texts, and segment the text with NLP tools. Its difference to the current texthero.preprocessing.clean is that we need to keep punctuation and digits to make sure the correctness of word segmentation, then we proceed to the following steps. Despite the difference, these steps can be done by language specific functions and custom pipelines, e.g.
from texthero import preprocessing
from texthero import nlp
import texthero as hero
hero.config.set_lang("cn")

custom_pipeline = [preprocessing.fillna,
                   preprocessing.remove_non_natural_text,
                   nlp.word_segment,
                   preprocessing.remove_stopwords,
                   ...]
df['clean_text'] = df['clean_text'].pipe(custom_pipeline)

Seems hero.config.set_lang("lang") can work properly and avoid redundant codes.

Great!

Just used Texthero for the first time yesterday in Portuguese. Pipeline for preprocessing seems fine, except for stopwords. A solution like @AlfredWGA mentioned would be very much appreciated inside hero. i.e. building and running a custom pipeline. In my case, I would only need to change the stopwords function

Hey @Jkasnese , if you read there in the getting-started, you will see that you can define your own custom pipeline:
from texthero import preprocessing

custom_pipeline = [preprocessing.fillna,
                   preprocessing.lowercase,
                   preprocessing.remove_whitespace]
df['clean_text'] = hero.clean(df['text'], custom_pipeline)

Is that what you were looking for?

Yes, I think so! Thanks! I'll check later how to pass arguments to the remove_stopwords function. It would be nice if it was possible to do something like:
custom_pipeline = [preprocessing.fillna,
                   preprocessing.lowercase,
                   preprocessing.remove_stopwords(my_stopwords),
                   preprocessing.remove_whitespace]

But I'm guessing its with kargs** right? I don't know, I'm a newbie hahaha gonna check this later. Thanks again!

You can solve it like this:
import texthero as hero
import pandas as pd

s = pd.Series(["is is a stopword"])
custom_set_of_stopwords = ['is']

pipeline = [
    lambda s: hero.remove_stopwords(s, stopwords=custom_set_of_stopwords)
]

s.pipe(clean, pipeline=pipeline)

All items in the pipeline must be callable (i.e functions).
I agree that this is not trivial. We will make sure that this will be well explained both in the docstring of the clean function as well as in the (soon to arrive) Getting started: preprocessing part. By the way, @Jkasnese, would you be interested in explaining that in the clean docstring (your comment then will appear there)?

I'd like that! Can't make guarantees though, since I'm already involved in many projects ): I'll try to do it until Saturday.
I still have some questions, which might be good since I can address them on the docstring. Should I create a new issue (since its a bit off this issue) or message you privately?

Both solutions work; either open an issue or send me an email: jonathanbesomi__AT__gmail.com

You can solve it like this:
import texthero as hero
import pandas as pd

s = pd.Series(["is is a stopword"])
custom_set_of_stopwords = ['is']

pipeline = [
    lambda s: hero.remove_stopwords(s, stopwords=custom_set_of_stopwords)
]

s.pipe(clean, pipeline=pipeline)

All items in the pipeline must be callable (i.e functions).
I agree that this is not trivial. We will make sure that this will be well explained both in the docstring of the clean function as well as in the (soon to arrive) Getting started: preprocessing part. By the way, @Jkasnese, would you be interested in explaining that in the clean docstring (your comment then will appear there)?

@jbesomi i think it is also good to add a language parameter in remove_stopwords. I've used a solution similar to your suggestion above for Spanish and Indonesian languages. We can use the stop-words library to load stop words from different languages. What do you think?

I perfectly agree with what you are proposing; i.e to permit to remove stopwords from a specific language. The only big question (and the main purpose of this discussion tab) is to understand how.
There are different alternatives:

Add a language parameter (as you were proposing)
Automatically detect the language (see #3) and remove the stopwords for such a language.
By default create a very big stopwords set that contains all stopwords of all languages. The main drawback is that one stopword in a language might not be for another one ... (👎 )

In general, I'm against adding too many arguments to functions as this makes it generally more complex to understand and use it ...
Also, something we always need to keep in mind is that, from a multilingual perspective, Texthero is composed of two kinds of functions:

Functions that should make a distinction on the Series (or cell) language type
Functions that work independently on the underline language

Only some of the preprocessing functions fall under (1) (tell me if you think that this is wrong). Such functions are for instance remove_stopwords and tokenize. It might be redundant to specify for each of these functions the language parameter, and that's why @AlfredWGA solution of having a global setting hero.config.set_lang("zh") is probably a great idea.
Your opinions?
Technically, do you think is feasible and not too complex to have a global setting for the lang at the module level?

I think @AlfredWGA's solution of having a global setting is a better idea than adding language parameter for every function as i suggested and is also more feasible.
#3 is also very interesting and might be an even better idea as it automates the process. It aligns perfectly well to Texthero's purpose of being easy to use and understand.

I found a problem of using global setting language. Some of functions cannot be applied to Asian languages, e.g. remove_diacritics, stem. Also, remove_punctuation is integrated into remove_stopwords after tokenization. When the user select a certain language to process, I think we shouldn't expose APIs that they cannot use which might lead to confusion. Any idea how to solve this?

Hey @AlfredWGA !
Apologize, what do you mean by "integrated"? (Also, remove_punctuation is integrated into remove_stopwords after tokenization)
I agree.
To probably understand better the problem, we should create a document (by opening a new issue or using Google doc or similar) and for different languages make a list of necessary functions. Presumably, except for some functions in preprocessing (i.e remove_diacritics  for Asian languages, ...), all other functions will be useful for all languages.
Once we have this, it will be easier to see how to solve the problem. Hopefully, we will notice some patterns and we will be able to classify languages together that share a common preprocessing pipeline. Do you agree?
Then, a simple idea might be to have a select items menu in the API page that will let the user show only the relevant functions for the given language. This coupled with the getting-started tutorials in all different languages (or kinds of languages) should reduce the confusion.
What are your thoughts?

Hey @AlfredWGA !
Apologize, what do you mean by "integrated"? (Also, remove_punctuation is integrated into remove_stopwords after tokenization)
I agree.
To probably understand better the problem, we should create a document (by opening a new issue or using Google doc or similar) and for different languages make a list of necessary functions. Presumably, except for some functions in preprocessing (i.e remove_diacritics  for Asian languages, ...), all other functions will be useful for all languages.
Once we have this, it will be easier to see how to solve the problem. Hopefully, we will notice some patterns and we will be able to classify languages together that share a common preprocessing pipeline. Do you agree?
Then, a simple idea might be to have a select items menu in the API page that will let the user show only the relevant functions for the given language. This coupled with the getting-started tutorials in all different languages (or kinds of languages) should reduce the confusion.
What are your thoughts?

Sorry for the confusion. The default pipeline for preprocessing Chinese text should look like this,
def get_default_pipeline() -> List[Callable[[pd.Series], pd.Series]]:
    return [
        fillna,
        remove_whitespace,
        tokenize,
        remove_digits,
        remove_stopwords
    ]

Punctuations and stopwords should be removed after tokenization (as they might affect the word segmentation results). We can put punctuations into the list of stopwords and remove them together using remove_stopwords, therefore a series of remove_** might be unnecessary.
In this case, if we use hero.config.set_lang("lang"), how can we make unnecessary functions invisible when user call hero.**? On the other hand, from texthero.lang import hero_lang can import only necessary functions for a certain language.

Hey @AlfredWGA, sorry for the late reply.
I agree that a series of remove_* might be unnecessary. On the other hand, someone might just need to apply remove_punctuation for some reasons and in that case such function might be handy.
Regarding the tokenize, what you say is super interesting. For you to know, in the next version, all representation functions will require as input a TokenSeries (a tokenized series).
In the case of preprocessing, if we consider Western language, the actual approach is that the tokenization is done once at the end of the preprocessing phase. remove_punctuation and remove_stopwords do not necessarily require to receive as input an already tokenized string as we might just apply string.replace:
The main reason until now we are not requiring preprocessing functions to receive a tokenized series as input is for performance. For example, remove_punctuation is using str.replace+ regex. I assumed that this was faster than iterating over every token and remove the ones that are punctuation.
For Asian Language, tokenization should be strictly done before applying remove_*? If yes, I'm fine re-consider this and having that the first task consists of tokenizing the Series. As we aim for simplicity and unification, it would not make sense to have two different approaches for different languages (when it exist a universal solution)
One more thing regarding what you were proposing (remove_*):
As an alternative to multiple remove_* we might have a universal function remove(s, tokens) that remove all tokens from the (tokenized) Series. Then, we might provide through a module or something similar, such collections of tokens:
from tokens import stopwords
from tokens import punctuation
from tokens import ...

s = pd.Series([...])
s = hero.tokenize(s)
hero.remove(s, stopwords.union(punctuation).union(...) )

Looking forward to hearing from you! 👍

For Asian Language, tokenization should be strictly done before applying remove_*?

From my perspective, yes, except for some strings that won't interfere word segmentation (urls, html tags, \n and \t, etc.).
TokenSeries and a tokens module is a great idea. If we implement that , the clean for Asian languages can be like this,
from texthero.lang import hero_cn as hero

[hero.preprocessing.fillna,
hero.preprocessing.remove_whitespace,
...,
hero.preprocessing.tokenize,
hero.remove(s, hero.stopwords.union(punctuation).union(...) )]

Then the cleaning process among Western and Asian seems unified. What do you think?

Sounds good!
We might call the tokens module collections or something similar:
from texthero.collections import stopwords
from texthero.collections import punctuation
...

Yes, TokenSeries seems a promising idea. @henrifroese is working on it. If you are interested have a look at #60.
@AlfredWGA How do you suggest we proceed, in relation on how you plan to contribute.

I'll start implementing texthero.lang.hero_cn to make all functions support Chinese. If #60 is completed I'll refactor the code to accommodate this feature. Is that OK?

OK!


Safe method for multiple mutable references to components from Query

What problem does this solve or what need does it fill?
It is sometimes useful/easier to have mutable access to the same component of many different entities at once.
What solution would you like?
Two new methods for Query, a default and one for a component. Example:
fn get_many_mut<'a, Q: WorldQuery, F: WorldQuery>(
    entities: impl IntoIterator<Item = Entity>,
    query: &'a mut Query<Q, F>,
) -> Result<Vec<<Q::Fetch as Fetch<'a>>::Item>, MultiEntityQueryErr>
where
    F::Fetch: FilterFetch,
{
    let mut unique = HashSet::default();
    let mut iter = entities.into_iter();
    if iter.by_ref().all(|x| unique.insert(x)) {
        let mut result = Vec::with_capacity(unique.len());

        for entity in iter {
            match unsafe { query.get_unchecked(entity) } {
                Ok(item) => {
                    result.push(item);
                }
                Err(err) => {
                    return Err(MultiEntityQueryErr::QueryEntityError(err));
                }
            }
        }

        Ok(result)
    } else {
        Err(MultiEntityQueryErr::DuplicateEntities)
    }
}

Just a quick implementation I've already written, not necessarily the best. Originally I used const generic arrays to avoid heap allocation too - but depends on use case.
What alternative(s) have you considered?
Have users implement it themselves using the existing unsafe Query methods, like above, and worry their use of unsafe will cause issues.

This functionality is definitely valuable; see #2010 for another version of how this might look, and check out the Relations RFC that inspired it.
As a stop-gap, #1763 provides a limited but very commonly useful version of this functionality.

See #2276 for more thoughts on the API design here.


Build errors

Debian (testing) and Opensuse (Leap 42.1), 64-bit, give build errors for both versions (0.4 and 0.5) of Julia. Any tips on resolving these? TIA.
==============================================[ ERROR: LibGit2 ]===============================================

LoadError: failed process: Process(`curl -f -o /home/vi/.julia/v0.5/LibGit2/deps/downloads/v0.21.2.tar.gz -L https://github.com/libgit2/libgit2/archive/v0.21.2.tar.gz`, ProcessExited(77)) [77]
while loading /home/vi/.julia/v0.5/LibGit2/deps/build.jl, in expression starting on line 47

===============================================================================================================

===============================================[ BUILD ERRORS ]================================================

WARNING: LibGit2 had build errors.

 - packages with build errors remain installed in /home/vi/.julia/v0.5
 - build the package(s) and all dependencies with `Pkg.build("LibGit2")`
 - build a single package by running its `deps/build.jl` script

This code is old, obsolete and not really maintained. It's part of base in 0.5.

please add prominently to the top of the README that this is in Base.

I don't know if anyone other than Jake has commit access here.


Add LiteLLM

a simple & light 100 line package to call OpenAI, Azure, Cohere, Anthropic API Endpoints

Hope this works @gaocegege

Thanks for your contribution! 🎉 👍


Consistent use of docker compose

docker compose is used everywhere except these few lines where we switch to docker-compose. This PR just cleans that up so the same command is called everywhere.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.4 out of 8 committers have signed the CLA.:white_check_mark: ImJeremyHe:white_check_mark: nomaxg:white_check_mark: sveitser:white_check_mark: tbro:x: godzillaba:x: gzeoneth:x: PlasmaPower:x: tsaheeYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @tbro ! that would be a great progress. But had some updates so some conflicts here.


If the default value of the parameter is set, why set the type that allows the default value? Is it unnecessary?

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
    class B(BaseModel):
        a: str = None
        b: int = 2

    model = B(a=None, b="111")
    print(model.dict())

The type of A is str and the default value is None. Is it possible to allow the type of A to be None by default?
Affected Components

[X] Compatibility between releases
[X] Data validation/parsing
[X] Data serialization - .model_dump() and .model_dump_json()
[X] JSON Schema
[ ] Dataclasses
[ ] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

@jaxonister,
Not sure if I understand your question entirely. Much of the value from pydantic comes from the fact that specifying type annotations for fields in a model allows for reliable data validation and serialization.
You can read more about optional fields in V2 here: https://docs.pydantic.dev/latest/migration/#required-optional-and-nullable-fields.
The table in that section of the docs should answer your questions about what is required / not required when specifying a field with a default or a field that is optional.


Fix a changed boto3 documentation URL

The URL about multiprocessing is now at https://boto3.amazonaws.com/v1/documentation/api/latest/guide/resources.html#multithreading-or-multiprocessing-with-resources
Title
A URL to a paragraph in the boto3 docs changed. This PR fixes a mention of that URL in the code comments of s3.py.
Motivation
As I was debugging performance issues, I came across this, so I figured I would fix it.

Thank you!


Reconciliation > action > "Match all filtered cells to…" should have an error message

Reconciliation action "Match all filtered cells to…" is service-dependent, but with no UI guidance about how it works. I have only seen it work with Wikidata.
Current Results
The other services just say "searching" indefinitely. Frequently it will say "searching" until I switch tabs, and when I switch back, the "searching" bar will disappear.
Expected Behavior
Preferably, an error message should indicate that "The service does not support this feature."
If not possible, the search should bring up an error message after X seconds of failed searching. But ideally users should not make repeated attempts before they determine the operation won't work for the chosen service.
Maybe we can create a "Supports searching" column on the test bench page (https://reconciliation-api.github.io/testbench/) and put a link to that in the UI, to help users to determine whether their chosen service supports the operation.
Screenshots

Versions
OpenRefine 3.4

The "supports searching" column already exists in the testbench, it is "Suggest entities".
I think the UI should simply offer a bare text field for the identifier when the service does not support suggesting entities.
The testbench is still a prototype so I would not link to that from the tool.

Maybe we can create a "Supports searching" column on the test bench page ..., to help users to determine whether their chosen service supports the operation.

There's no need for this. The information is available in the manifest published by the reconciliation service. The UI just needs to make use of the information.

@tfmorris Hi Tom, I'm confused.  Can you provide more detailed information?  When you say "manifest" that is published.  Where can I see a few of those manifests for the services listed on the testbench?


Support ESFeatures in Scala.js

ScalaJSModule currently supports the useECMAScript2015 settings.
Nowadays Scala.js offers support for multiple ESVersion.
In the official Sbt plugin they are set inside an object called ESFeatures that contains other settings.
This PR tries to mimic the Scala.js API.
It is a breaking change, since overriding the old useECMAScript2015 doesn't have any effect anymore.
How deprecate overriding useECMAScript2015
Since we can't derive ESFeatures from useECMAScript2015, I can't use the same deprecation mechanism as testFrameworks. What I did instead is to define a private boolean var in ScalaJSModule called overriddenUseECMAScript2015 that is first set to true. It is then set to false by the default implementation of useECMAScript2015 which calls back the new esFeatures. Before fastOpt and fullOpt I call a private checkDeprecations task, which calls useECMAScript2015() and then checks the overriddenUseECMAScript2015. If it was overridden then the value remains true and it fails the task with an error message; otherwise it finds false and continues with the build.

@lolgab You may want to look into JavaModule.bspCompileClassesPath, where I've implemented a override detection for the compile target.
https://github.com/com-lihaoyi/mill/blob/f0358b923b0da3829e9aff636a59e245f0d400a0/scalalib/src/JavaModule.scala#L274
Once we known we have an overridden deprecated target, we can issue a warning message and also use the value to derive the new target, otherwise we can just go with our defaults.


Issue assignee's cant see their assigned issues in the Dashboard/Issues screen

Not sure if there needs to be a row added to issue_user for assignees.. Currently there is not.

Duplicate of #69?

@linquize No it isn't. This concerns the listing of issues in the users dashboard.

There is a «Assigned to you» link at Issues screen.
I guess, it's a good idea to show assigned issues at Dashboard like at Jira.

This was actually reported as a bug, and is partially fixed in develop branch.  I will close this and open a more accurate issue.


HTTP Firehose with Basic Authentication

Description
I'd like to propose adding the ability to use URIs that require a basic authentication header to the existing HTTP Firehose. I envision a Firehose that works for both depending on what is provided in the ingestion spec.
One potential implementation: If the client adds credentials to the ingestion spec (new json key:value pairs in the ioConfig), then they will be supplied as a header to the specified URIs. If no credentials are in the ingestion spec, then no authentication header is added to the request.
Motivation
My org would like to leverage the HTTP Firehose to ingest select files with Native ingestion rather than using hadoop batch ingestion and the overhead that comes with that. However, the API to access the files over the network requires basic authentication.
We implemented the change ourselves to an older version of Druid (0.11.0) and it works great with no breaking changes to firehose users connecting to an insecure endpoint. We plan on upgrading our clusters soon and will need this functionality before the upgrade.
I'm willing to take a crack at it as well, if there is some consensus around it being a feature that committers would accept.

Great! This feature looks useful to me.

Fixed in #7145.


Add missing targets

Scope & Purpose
Without this change it not possible to
make -j arangodb
./scripts/unittest

[ ] :hankey: Bugfix
[ ] :pizza: New feature
[ ] :fire: Performance improvement
[ ] :hammer: Refactoring/simplification

Checklist

[ ] Tests

[ ] Regression tests
[ ] C++ Unit tests
[ ] integration tests
[ ] resilience tests

[ ] :book: CHANGELOG entry made
[ ] :books: documentation written (release notes, API changes, ...)
[ ] Backports

[ ] Backport for 3.10: (Please link PR)
[ ] Backport for 3.9: (Please link PR)
[ ] Backport for 3.8: (Please link PR)

Related Information
(Please reference tickets / specification / other PRs etc)

[ ] Docs PR:
[ ] Enterprise PR:
[ ] GitHub issue / Jira ticket:
[ ] Design document:

I was not even aware that this target existed.
I suppose this change is fine (how many people use make arangodb?)
In the future there might be an argument to have the default target really build everything to do with arangodb  and have a target that builds the tests?


Add Release and Debug build options

At the moment, we are only building CCL with one set of flags intended for a Release build. It would be useful to be able to build CCL in Debug mode, which enables debug information and removes optimizations.

Angpow4CCL may need to be made aware of this change.


Optimize: test small numbers up to 31417

Codecov Report

Merging #16 (76638c4) into main (754a250) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #16   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            6         6
  Lines          269       263    -6
  Branches        83        83
=========================================
- Hits           269       263    -6

Flag
Coverage Δ

unittests
100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/pseudoprimes/constants.py
100.00% <100.00%> (ø)

src/pseudoprimes/lucas.py
100.00% <100.00%> (ø)

src/pseudoprimes/miller_rabin.py
100.00% <100.00%> (ø)

src/pseudoprimes/pseudoprimes.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Update plugin.xml

Update CocoaPods-Specs repo. The previous one has been removed long ago.

Thanks for raising this issue @UzverNumber47, fixed in v1.1.1 - https://github.com/AppLovin/AppLovin-MAX-Cordova/releases/tag/release_1_1_1.


Colorful Rays!

More default colors for drawing!
The current list of default colors seems a little limited in choice. Raylib should have the whole rainbow!
It's also nice to have these within the library, so you don't have to redefine a bunch of common colors.

@Alex-Velez I'm afraid this is too much for raylib, uneeded for most users and pollutes the raylib header.
Still, it's an interesting piece of work and maybe it could make into portable rcolors.h header to be added to raylib-extras users interested on it.

I'm closing this PR, feel free to send a new PR to raylib-extras/extras-c for rcolors.h.


Refactoring the event setting processing

Minor refactoring.

I'm curious, what's the motivation behind a new supports module?

Thanks for fast reply.
If add the passive option.
That's because I thought that keep to simple components file by placing one of the logic if it can use the external.

Fixed an error in the server-side rendering. (eb66649)

That looks good. Thanks 👍 .

Thanks!


Issue with missing tsconfig.json

We made a change to jsonconfig.json. Added checkJs: true
{
  "compilerOptions": {
    "experimentalDecorators": true,
    "checkJs": true,
    "target": "ESNext"
  },
  "include": ["**/*", "../../../../.sfdx/typings/lwc/**/*.d.ts", "../../../../types/*.d.ts"]
}

Unfortunately, it is now looking for tsconfig.json
Error: Command failed: node_modules/sfdx-cli/bin/run scanner:run     --pmdconfig="ruleset.xml"      --format json     --target "temporary"     --outfile "sfdx-scanner-findings.json"
 ›   Warning: sfdx-cli update available from 7.192.2 to 7.194.1.
WARNING: We're continually improving Salesforce Code Analyzer. Tell us what you think! Give feedback at https://research.net/r/SalesforceCA
ERROR running scanner:run:  We couldn't find 'tsconfig.json' in the current directory '/home/runner/work/salesforce-job-scope-review/salesforce-job-scope-review'. Switch to a directory that contains 'tsconfig.json' or specify the current directory with the --tsconfig flag.

Can you share your .yml file? it looks like you might be missing the tsconfig input variable.

Closing this due to inactivity


Service for creating new-style component and index templates in v7.8

Hi, first of all thank you for this package, it is so much nicer to use than the official client. Amazing work.
I noticed that there seems to be no way to add a component template?
There is a service for adding an index template though.
Which version of Elastic are you using?
[X] elastic.v7 (for Elasticsearch 7.x)
[ ] elastic.v6 (for Elasticsearch 6.x)
[ ] elastic.v5 (for Elasticsearch 5.x)
[ ] elastic.v3 (for Elasticsearch 2.x)
[ ] elastic.v2 (for Elasticsearch 1.x)
Please describe the expected behavior
Ability to create a index and component templates in v7.8 clusters. See new template docs for v7.8:
https://www.elastic.co/guide/en/elasticsearch/reference/7.8/index-templates.html
Please describe the actual behavior
Component / Index template service does not exist
Any steps to reproduce the behavior?

Sorry, I just realized that component templates are new in v7.8 and AWS only supports up to v7.7. So looks like I won't be using component templates after all (darn).
Feel free to close this issue or leave it open since it would be a nice feature to add eventually.

Looks similar to #1393, so I will close this.

New index template APIs should be done with #1393. Component template APIs are #1414.


added possibility to set a max and min amount of items in the array f…

Implemented what was described in this issue
https://github.com/measuredco/puck/issues/326
the code will disable delete/add buttons once the specified limit is reached
it will also swap the default icon for the alert-circle icon

Fixed the min, max example for the hero buttons
removed use of AlertCircle
ran yarn format
added some documentation for use of min, max

Let me know if there is anything else needed.
I've never used prettier before got a bunch of changed files only commited the files I've touched, hope that was correct

Ran yarn format :)


Navigation

Adds a simple landing screen to the app that allows the user to choose which snippets they would like to view. So far I've just added the two pre-existing screens that host the snippets for images and brushes. It should be easy to extend this with new screens where we want to demonstrate certain snippets.

Passed here https://github.com/android/snippets/actions/runs/5669457829/job/15362202406


Describe the available DTO within the Documentation

[ ] Describe the available DTO within the Documentation

Originally posted by @StanBarrows in https://github.com/codebar-ag/laravel-docuware/discussions/3

See the README about DTO's


How to open document for the symbol under the cursor?

According to the changelog, Rust-Analyzer has a command openDocs. It should open the documentation for the symbol under the cursor.
How could I call this from emacs?

If you are using lsp-mode, you need to use the function lsp-rust-analyzer-open-external-docs for it.


implement "b3 single" header format

As discussed on https://github.com/openzipkin/b3-propagation/issues/21 and first implemented here: https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/propagation/B3SingleFormat.java https://github.com/openzipkin/brave/blob/master/brave/src/test/java/brave/propagation/B3SingleFormatTest.java
Let's support at least reading "b3" header from a single string, most commonly traceid-spanid-1
It would also be nice to support optionally writing this, especially in message providers or others with constrained environments.
Brave currently has a property like this, but its name could change with feedback:
    /**
     * When true, only writes a single {@link B3SingleFormat b3 header} for outbound propagation.
     *
     * <p>Use this to reduce overhead. Note: normal {@link Tracing#propagation()} is used to parse
     * incoming headers. The implementation must be able to read "b3" headers.
     */
    public Builder b3SingleFormat(boolean b3SingleFormat) {
      this.b3SingleFormat = b3SingleFormat;
      return this;
}

Is the intention to introduce a new io.opencensus.trace.propagation.TextFormat implementation that extracts the b3 header (or tracestate header with "b3" prefix) and injects the b3 header?

the b3 single header was indeed to be designed as both a top-level header and also a tracestate entry for when it is necessary to carry data present in b3, but no longer in the traceparent spec (such as before-the-fact sampling instructions b3=0, or the parent id)

@adriancole I provided two potential implementations. #1989 introduces a new TextFormat implementation and #1990 modifies the existing B3Format. The former extracts b3 from the single format as well as injects it in the same format. The latter extracts b3 from either the single or multi formats but only injects data in the multi format. Can you comment on which one most closely matches the intention of this issue?

@IOs you are awesome btw. thank you for the help

not sure if github is case-sensitive @l0s ^^

I think in general there will be some tension about tracestate and b3. I'm not sure the responsibility for parsing tracestate should be in the b3 class. My original thought on how tracestate works is that handlers are registered per state name. This might be more flexible than having b3 responsible for parsing tracestate. That said priority will still be of issue. The more flexible system will just fallback to tracestate (which has b3 registered) upon a higher level parse fail.

@adriancole that makes sense. I can remove the tracestate handling from the b3 TextFormat. A traceparent / tracestate format can delegate to other formats as necessary. Should I add more robust traceparent / tracestate handling as part of this issue or a separate one?
Also, did you have thoughts on which approach is more appropriate, a new TextFormat for "b3 single" or a modification to the existing B3Format?

what we do in brave is read b3 single, but only write when people
explicitly choose it.
https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/propagation/B3Propagation.java#L131
https://github.com/openzipkin/brave/blob/master/brave/src/main/java/brave/propagation/B3SinglePropagation.java

Ok great. I'll go with the modification to the existing B3Format. I'll also add a configuration parameter to support emitting b3 single.

Just want to let you guys know that I'm following this issue and I really look forward to getting my hands on it (in due time). Thanks of a lot for implementing it 👍


DAOSGCP-160 Upgrade to Rocky 8

DAOS will now be deployed with images based on Rocky Linux 8
Changes:

Reduced total number of files in images/ directory
Replaced shell scripts with Ansible playbooks
Renamed build_images.sh to build.sh
Removed hard-coded strings in Packer template
Simplified Google Cloud Build file (packer_cloudbuild.yml)
Added support for running Packer locally instead of running in Cloud Build

Signed-off-by: Mark Olson<EMAIL_ADDRESS>

Test cases verified and result mention in https://daosio.atlassian.net/browse/DAOSGCP-164


Google oauth2 Not found. Authentication passthru

I just cloned source from master and i try setting to login google. But I alway get error
Not found. Authentication passthru.
Could you please help me to fix them?
My settings.yml
omniauth:
providers:
google_oauth2:
id:<PHONE_NUMBER>3-32fplp265fhbdca2kqgs5771qbqs7stp.apps.googleusercontent.com
secret: mSPk86fEQKp_DvRj4IvsfWEg

I'm sorry. I run source in rails 5+. So it not working.
I closed my issue.


Using Relationships

Hi all,
More of a question / discussion than a issue, how are people dealing with multiple hasmany / belongs to many relationships?
Straight out of the box I generated a bunch of scaffolding based on a database I had setup, things were looking amazing but... relationships?
I have a items table which has multiple tables relating to it so for example, types, grades, materials, sizes, locations.
All these items can be bundled into one table using ->with() on the query which is all fine and well but to display this data I am having to use child rows to process data like objects and the pivot data within that object.
Is there a better way of doing this? at present the scaffolding is great but with it only being used to support 1 table edits I am going to have to spend a long time adding all the relating data in so wondered how you guys work with this sort of data?
Thanks for any insights.

@gsc89 We already have the issue in a list for relationships. But as people use relationships in various ways. It's really hard to find what kind of scaffold views we should have for each relationship.
so I have backlogged this issue for a while and we are tracking it here: https://github.com/InfyOmLabs/laravel-generator/issues/51
We are trying to find some better way to give relationships more easy and more powerful. so If you have any suggestion, please post it on that issues.

duplicate of #51