Wrong validation of request body with integer type property

Context
I have this oas3.0 definition with request body with properties in integer type:
---
paths:
  '/inventories/{id}/update':
    summary: decrease stock operation on inventories
    put:
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                productId:
                  description: productId of this DecreaseStock
                  type: integer
                qty:
                  description: qty of this DecreaseStock
                  type: integer
            examples:
              Example 0:
                value:
                  productId: 123
                  qty: 10
              Example 1:
                value:
                  productId: 456
                  qty: 50
              Example 2:
                value:
                  productId: 789
                  qty: 150
      parameters:
        - examples:
            '1':
              value: 1
          name: id
          description: DecreaseStock name
          schema:
            type: integer
          in: path
          required: true
      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Inventory'
              examples:
                Example 0:
                  value:
                    stock: 20
                    productId: 123
                Example 1:
                  value:
                    stock: 30
                    productId: 456
                Example 2:
                  value:
                    stock: 30
                    productId: 789
          description: DecreaseStock Operation
      operationId: DecreaseStock
      summary: DecreaseStock
      description: DecreaseStock

openapi: 3.0.2
info:
  title: Inventory
  version: 0.0.1
  description: API definition of inventory
  contact:
    name: creator's name
    url: 'http://creator.homepage.address'
    email<EMAIL_ADDRESS>  license:
    name: MIT License
    url: 'https://opensource.org/licenses/MIT'
components:
  schemas:
    Inventory:
      title: Root Type for Inventory
      description: The root of the Inventory type's schema.
      type: object
      properties:
        productId:
          description: productId of this Inventory
          type: integer
        stock:
          description: stock of this Inventory
          type: integer
      example:
        productId: 1
        stock: 1
tags:
  - name: Inventory
    description: Inventory resource

Current Behavior
It returns the request validation error like this:
 $ http put  :4010/inventories/1/update  productId=456 qty=50 prefer:"validate-request=false, valid
ate-response=false"
HTTP/1.1 422 Unprocessable Entity
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Connection: keep-alive
Content-Length: 496
Date: Mon, 16 Oct 2023 18:01:18 GMT
Keep-Alive: timeout=5
content-type: application/problem+json

{
    "detail": "Your request is not valid and no HTTP validation response was found in the spec, so Prism is generating this error for you.",
    "status": 422,
    "title": "Invalid request",
    "type": "https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY",
    "validation": [
        {
            "code": "type",
            "location": [
                "body",
                "productId"
            ],
            "message": "Request body property productId must be integer",
            "severity": "Error"
        },
        {
            "code": "type",
            "location": [
                "body",
                "qty"
            ],
            "message": "Request body property qty must be integer",
            "severity": "Error"
        }
    ]

Expected Behavior
It should return the matching example with no validation errors
Possible Workaround/Solution
When I change the property types to 'string', it works.
Steps to Reproduce

save above openapi as openapi.yaml
launch mock server:

npx @stoplight/prism-cli@latest mock openapi.yaml

install Httpie with 'pip install httpie'
request the put method example

http put  :4010/inventories/1/update  productId=456 qty=50 prefer:"validate-request=false, validate-response=false"

Environment

Version used: @latest version today
Environment name and version (e.g. Chrome 39, node.js 5.4):
Operating System and version (desktop or mobile): Ubuntu
Link to your environment/workspace/project:  https://github.com/jinyoung/testmodel or you can try it inside a gitpod :
https://gitpod.io/#github.com/jinyoung/testmodel

I was suspicious myself, so I did some additional testing based on the officially obtained open API example from the Microcks:
https://raw.githubusercontent.com/microcks/microcks/master/samples/APIPastry-openapi.yaml
I tried :

launch the mock service with above openapi 3 spec:

npx @stoplight/prism-cli@latest mock https://raw.githubusercontent.com/microcks/microcks/master/samples/APIPastry-openapi.yaml

list api works well:

$ http :4010/pastry
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Connection: keep-alive
Content-Length: 378
Content-type: application/json
Date: Tue, 17 Oct 2023 00:51:50 GMT
Keep-Alive: timeout=5

[
    {
        "description": "Delicieux Baba au Rhum pas calorique du tout",
        "name": "Baba Rhum",
        "price": 3.2,
        "size": "L",
        "status": "available"
    },
    {
        "description": "Delicieux Divorces pas calorique du tout",
        "name": "Divorces",
        "price": 2.8,
        "size": "M",
        "status": "available"
    },
    {
        "description": "Delicieuse Tartelette aux Fraises fraiches",
        "name": "Tartelette Fraise",
        "price": 2,
        "size": "S",
        "status": "available"
    }
]

the get api for specific id works well too, but the expected example (the matching response would be value of 'Millefeuille') wasn't returned but the default example was returned

$ http :4010/pastry/Millefeuille
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Connection: keep-alive
Content-Length: 113
Content-type: application/json
Date: Tue, 17 Oct 2023 00:52:31 GMT
Keep-Alive: timeout=5

{
    "description": "A short description os my pastry",
    "name": "My Pastry",
    "price": 4.5,
    "size": "M",
    "status": "available"
}

the patch api returns wrong validation too. (price must be number even if I gave the 10.5 which is proper number input with httpie)

$ http patch  :4010/pastry/M
illefeuille price=10.5
HTTP/1.1 422 Unprocessable Entity
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: *
Connection: keep-alive
Content-Length: 372
Date: Tue, 17 Oct 2023 00:54:22 GMT
Keep-Alive: timeout=5
content-type: application/problem+json

{
    "detail": "Your request is not valid and no HTTP validation response was found in the spec, so Prism is generating this error for you.",
    "status": 422,
    "title": "Invalid request",
    "type": "https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY",
    "validation": [
        {
            "code": "type",
            "location": [
                "body",
                "price"
            ],
            "message": "Request body property price must be number",
            "severity": "Error"
        }
    ]
}

Hi @jinyoung, it looks like the default behavior for httpie is to pass variables as strings according to their documentation. In order to pass a body param as an integer you have to use the := syntax. So you're actually sending Prism a string and not an integer for those body params, so Prism's response is correct and expected. You can also use the --print option as outlined here to see what request you're actually sending Prism.


False positive Nextcloud dav sharing - 949110

I have a nextcloud configured nginx server with crs set up and the nextcloud exclusions enabled by setvsetvar:tx.crs_exclusions_nextcloud=1
However, when I try to click the "share" icon on any file on my nextcloud server, the URL https:/<nextcloud>/remote.php/dav/files/silur/<filename> gets matched against an evaluation anomaly as follows:
2023/01/11 16:13:12 [error] 5004#5004: *3001 [client <IP_ADDRESS>] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/opt/bunkerweb/core/modsecurity/files/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "REDACTED"] [uri "/remote.php/dav/files/silur/REDACTED"] [unique_id "REDACTED"] [ref ""], client: REDACTED, server: REDACTED, request: "PROPFIND /remote.php/dav/files/silur/REDACTED HTTP/2.0", host: "REDACTED", referrer: "https://REDACTED/apps/files/?dir=%2F&fileid=2"
Disabling the rule by Id works as a temporary solution but creates a large attack surface.

Hi @Silur, rule ID 949110 is only a blocking evaluation based on other matched rules. Can you post also other logs related to this request? Thank you.

bunker-bunker-1    | 2023/01/12 09:52:38 [warn] 57827#57827: *10311 ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?:get|post|head|options|connect|put|delete|trace|track|patch|propfind|propatch|mkcol|copy|move|lock|unlock)\s+(?:\/|\w)[^\s]*(?:\s+http\/\d|[\r\n])' against variable `REQUEST_BODY' (Value: `<?xml version="1.0"?>\x0a\x09\x09\x09<d:propfind  xmlns:d="DAV:"\x0a\x09\x09\x09\x09xmlns:oc="http:/ (947 characters omitted)' ) [file "/opt/bunkerweb/core/modsecurity/files/coreruleset/rules/REQUEST-921-PROTOCOL-ATTACK.conf"] [line "33"] [id "921110"] [rev ""] [msg "HTTP Request Smuggling Attack"] [data "Matched Data: propfind  xmlns:d="dav:"\x0a found within REQUEST_BODY: <?xml version="1.0"?>\x0a\x09\x09\x09<d:propfind  xmlns:d="dav:"\x0a\x09\x09\x09\x09xmlns:oc="http://owncloud.org/ns"\x0a\x09\x09\x09\x09xmlns:nc="http://nextcloud.org/ns"\x0a\x09\x09\x09 (536 characters omitted)"] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272/220/33"] [hostname "<IP_ADDRESS>"] [uri "/remote.php/dav/files/silur//REDACTED"] [unique_id "167351715862.942049"] [ref "o28,25v1046,669t:urlDecodeUni,t:htmlEntityDecode,t:lowercase"], client: <IP_ADDRESS>, server: REDACTED, request: "PROPFIND /remote.php/dav/files/silur//REDACTED HTTP/2.0", host: "REDACTED", referrer: "REDACTED"
bunker-bunker-1    | 2023/01/12 09:52:38 [error] 57827#57827: *10311 [client <IP_ADDRESS>] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file "/opt/bunkerweb/core/modsecurity/files/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 5)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "REDACTED"] [uri "/remote.php/dav/files/silur//REDACTED"] [unique_id "167351715862.942049"] [ref ""], client: REDACTED, server: REDACTED, request: "PROPFIND /remote.php/dav/files/silur//REDACTED HTTP/2.0", host: "REDACTED", referrer: "REDACTED"

I see now there is https://github.com/coreruleset/coreruleset/issues/3024 regarding the 921110 but it's not resolved (besides disabling the whole check on an endpoint)

SecRule REQUEST_URI "@beginsWith /remote.php/dav" \
"id:1000,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=921110
ctl:ruleRemoveById=949110"

Addig the rule above to the crs config also didn't work, the rule is catched as a warning then caught as an error with 949110.

This is not related to #3024 and seems to be already covered by rule 9508106 which is part of Nextcloud Rule Exclusions Plugin.

This is not related to #3024 and seems to be already covered by rule 9508106 which is part of Nextcloud Rule Exclusions Plugin.

Indeed that one is a different ID sorry :)
Nevertheless, disabling  921110 on the endpoint did work as a temporary solution

Just install a new plugin instead of RE package.

@jessebot Rule Exclusion package. This plugin is some kind of a new version of old RE package.

@azurit any reason why this is re-opened? This should be fixed in the plugin https://github.com/coreruleset/nextcloud-rule-exclusions-plugin/blob/b21c032d487e8d998fb5a49dcc57066acee11396/plugins/nextcloud-rule-exclusions-before.conf#L170


[Feature] Consider splitting driver dependencies

The driver bundle is one big jar containing all the drivers for every supported platform. This makes it quite large, roughly 117 MB for v1.29.0.
The "driver-bundle" artifact could be changed to be only a very small artifact with runtime dependencies for each driver and platform. This would allow users to exclude drivers and platforms they don't need. For example, if someone only needs Chromium on Windows x86-64, Maven's method of excluding dependencies could be used to reduce the download size.
So, in the future, one could have a variant of "driver-bundle" that includes only the shared parts for all drivers and depends on "driver-chromium" (with shared parts for each platform), "driver-chromium-linux" (Linux parts only), and "driver-chromium-windows" (Windows parts only). "driver-chromium-linux" may also depend on "chromium-linux-x86-64" and "chromium-linux-arm64".

We contemplated having some filters for the driver deps in the past but were not satisfied with the mechanisms that Maven provides for defining platform-specific modules. Using exclusion  in the client config sounds like an interesting alternative. It seems to be breaking what the package author assumes about the dependencies, so I'm not 100% sure we want to recommend that. I'll keep this request open to collect more feedback.
Note also that we only bundle driver binaries which include node executable and relevant playwright node.js code. All browsers are downloaded separately and only include those that are required for the host platform. See this page for more information on how playwright manages browser downloads.
For the time being you have to options to mitigate the proble:

Use preinstalled driver and configure the path via system property or
Configure playwright to use your own implementation of the Driver loader.

Thanks, I am overall happy with how Playwright works.
If you add the dependencies in "driver-bundle" as follows, then nothing changes for the users. "driver-bundle" is still sufficient as dependency and the new platform-specific dependencies are automatically loaded as transitive dependencies. The only difference is that now you have the possibility to exclude the unnecessary platform-specific dependencies. This would also be interesting for Node.js, where you have the possibility to use your own pre-installed version of Node.js since #1016. Especially in CI environments, where the images may already have Node.js, browser and drivers installed, this is a useful feature to save traffic and time.
<project>
  <parent>
    <groupId>com.microsoft.playwright</groupId>
    <artifactId>parent-pom</artifactId>
    <version>x.y.z</version>
  </parent>

  <artifactId>driver-bundle</artifactId>

  <dependencies>
    <dependency>
      <groupId>com.microsoft.playwright</groupId>
      <artifactId>driver</artifactId>
      <version>${project.version}</version>
      <scope>compile</scope>
    </dependency>
    <!-- new platform specific stuff comes here -->
    <dependency>
      <groupId>com.microsoft.playwright</groupId>
      <artifactId>driver-node-mac</artifactId>
      <version>${project.version}</version>
      <scope>runtime</scope>
    </dependency>
    <!-- new platform specific stuff ends here -->
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-engine</artifactId>
    </dependency>
  </dependencies>
</project>

The current docker image is too large, and we only need to use chrome.


Clicking on an input field should leave the cursor at the end

I think the way to go about this is, when the user enters an input field, check if the cursor is at the start and if it is place it at the end and if not leave it where it is.


HDDS-11507. Add error information to log while handling ServiceException

What changes were proposed in this pull request?
HDDS-11507. Add error information to log while handling ServiceException

Currently the log information provides a generic message with no error information when submitting purge request to Ratis fails.
This PR adds the extra error information to the log

What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-11507
How was this patch tested?
Patch was tested using unit tests

Thanks for pointing out the missing logline @aryangupta1998 , addressed the same in the latest commit.
I cross-checked other instances of ServiceException, but those are just throwing the error forward and the ones that are being logged have the error info added in the current change.
Could you PTAL?

Thanks @devabhishekpal for the fix, @aryangupta1998 for reviewing!


Spyder crashes on Windows because of non-ascii chars in working directory

From<EMAIL_ADDRESS>on 2014-12-10T12:23:51Z
Please note that reporting bugs from Spyder's help menu ("?" > "Report
issue...") will fill version details for Spyder, Python and Qt in this description for you.
What steps will reproduce the problem?

I simply run Spyder from its shortcut 2. 3.

What is the expected output? What do you see instead?
Instead of Spyder I get the attached crash window (PNG file).  When I close it, Windows tells me that "pythonw.exe has stopped working" and offers to check online for a solution or to close the program. What version of the product are you using? On what operating system? Windows 7-64, Python 2.7.8-64, Spyder 2.3.2
Please provide any additional information below
. The crash window advises me to run "python spyder --reset".  If I do that Spyder works for a while, but minimal changes in its Preferences make it crash again.
If I try to reinstall Spyder from the installer it says that Python 2.7 couldn't be found in the Registry, but it is there because Python works in interactive mode.
Attachment: spyder.png
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=2081

From<EMAIL_ADDRESS>on 2014-12-15T05:13:53Z
Hello CCordoba12,
Answers to your questions:

Simple things such as changing the the folder where Spyder should point to by default to find source files.

Even though I use special characters (Brazilian Portuguese keyboard with special characters like á, é, etc) the /account/ I use has none of those.  It's called "fausto", simple like that.  My scripts usually don't have special characters, either (I avoid them).

I've been happily using Spyder in my work (Windows machine) and home (Ubuntu) over the last year, simply love it, it beats other IDEs hands down, but I've gotten this issue lately.  Don't know what to do, because nothing has changed on my system.  This is a Windows-only issue I'm afraid.  At home, where I run Ubuntu, Spyder is working beautifully as ever.
Thanks for your reply.
Fausto

From ccordoba12 on 2014-12-12T13:46:19Z
Couple of questions:

What are the changes you try to do in Preferences before Spyder crashes again?

Labels: MS-v2.3.3 Cat-Settings

From<EMAIL_ADDRESS>on 2014-12-15T10:24:26Z
Hello,
I observed that the crash usually happens after I try to change:
Tools/Preferences/Global working directory/Startup/the following directory:
and
Tools/Preferences/Run/Working directory/the following directory:
But those may not be the root of the actual problem, it's just my guess.  I simply observed that Spyder crashed a couple of times after my trying to tweak those values.
The non-ascii characters may not be the ones to blame, either.  My computer, keyboard, regional language configuration, etc, etc, have always been the same since I installed Spyder for the 1st time.  Why only now it began to crash?
If there's any other log/config file I might send, please let me know.
As for Python 3, I for one would like to keep using Python 2.7.  Will that be possible with the new version?  Maybe the time to move to another IDE has come
(but I will certainly keep using Spyder on Ubuntu).
Fausto

From ccordoba12 on 2014-12-15T09:13:08Z
Thanks for the answers Fausto and I'm glad to hear you're enjoying Spyder.
Could you please describe exactly what preference are you changing and post here the directory name you are using for source files?
I think this problem is related to some difficulties we have to handle option values with non-ascii characters in Python 2. Our Python 3 version should work without problems though :-)

From<EMAIL_ADDRESS>on 2014-12-19T19:30:57Z
I just installed spyder on windows too (normally use Linux) and here is how I solved this issue:

The crash (in my case) was an unmet dependency for jinja2. I'm using miniconda, so "conda install jinja2" got the dependency met (though pip should also work)

the start menu shortcuts that were getting created by "conda install spyder" were creating two problems: (a) the path name in the shortcut had a forward slash instead of backward slash just before the filename (the rest of the path was correct), and (b) it was trying to start spyder in $DOCUMENTS/Python scripts, which is a directory that doesn't exist (and in my case, resides on a different drive than C:/, which can also sometimes cause problems).  I suggest starting it in C:/Users/$USER

From ccordoba12 on 2015-01-01T14:30:21Z
Thanks @-Dan for the solution but I think the problem is a bit different in this case.
@-Fausto Spyder will continue to work with Python 2 and 3 for the foreseeable future. This is just a bug.
Summary: Spyder crashes on Windows because of non-ascii chars in working directory  <span class="oldvalue"> (was: Spyder crashes on start-up.) </span>

From ccordoba12 on 2015-01-10T11:11:10Z
I can't reproduce this error, sorry.
@-Fausto: could you try to start Spyder from a terminal (i.e. cmd.exe) and post here the error you see there? Thanks
Labels: -MS-v2.3.3 MS-v2.3.4

I have exactly the same issue (Anaconda 2.1 distribution, Windows 7 32 bit, Python 2.7.4, Spyder 2.3.1).
The user name on my PC, and thus USERHOME directory both contain non-ascii characters (Russian).
This caused issues with python itself in Anaconda which I could workaround.
However, when I start Spyder from cmd.exe (or in any other way), the splash window appears and soon (after 1-2 sec) spyder crashes, cmd.exe window is closed, I don't see any errors reported.
I can change user name at home, but for my university PCs this is not an option.
Looking forward for a workaround or fix.
spyder --reset doesn't help.
Can't get to any configuration options via GUI since Spyder does not launch.

@vasily-smirnov thanks for your interest in helping us solve this problem. Your patch seems to touch parts of the Python os module, that we really can't touch.
Is it possible or you to try to come up with a solution that only touches Spyder code? Also, please open a pull request for this :-)

Ok, thanks for the input regarding os module.
I will open a pull request for spyderlib\userconfig.py only - the changes seem failsafe and worth doing.

Thanks a lot Vasily! Really waiting for it :-)
El 02/03/15 a las 02:31, vasily-smirnov escribió:

Ok, thanks for the input regarding os module.
I will open a pull request for spyderlib\userconfig.py only - the
changes seem failsafe and worth doing.
—
Reply to this email directly or view it on GitHub
https://github.com/spyder-ide/spyder/issues/2081#issuecomment-76668887.

I submitted a pull request, however because I use github for the first time, please confirm that you received it and I did it ok.

The first change was failing in case Spyder config INI did not exist. I fixed it in the second commit


PDMP Test Patients

Use Brenda as a template, overwrite with PDMP data
Remove PDMP MedicationRequests copied as EHR meds

Looks good to me.  Still in draft?

@mldorr I'd ideally like to remove any data that isn't relevant for our app from the test patients. Do we have a list of the FHIR resources that are actually triggering CDS in the app?
Not a high priority, but would make things more obvious


Leaving breakpoints while reverting from source control

Type: Bug

Open any project with having git version control.
Modify multiple lines here and there in a file.
Open source control(ctrl + shift + G).
click on the modified file.
Try to revert the change one line by one clicking the -> arrow.

This reverts the line correctly but also leaves a breakpoint.
VS Code version: Code 1.79.0 (b380da4ef1ee00e224a15c1d4d9793e27c2b6302, 2023-06-07T14:26:35.552Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Remote OS version: Linux x64 <IP_ADDRESS>-microsoft-standard-WSL2

System Info

Item
Value

CPUs
12th Gen Intel(R) Core(TM) i5-12400F (12 x 2496)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
31.82GB (16.34GB free)

Process Argv
--enable-proposed-api genuitecllc.codetogether --crash-reporter-id 67ed307f-3c1b-4b04-8b38-469f9414163e

Screen Reader
no

VM
0%

Item
Value

Remote
WSL: Ubuntu-22.04

OS
Linux x64 <IP_ADDRESS>-microsoft-standard-WSL2

CPUs
12th Gen Intel(R) Core(TM) i5-12400F (12 x 2495)

Memory (System)
15.53GB (9.15GB free)

VM
0%

Extensions (12)

Extension
Author (truncated)
Version

better-cpp-syntax
jef
1.17.2

jupyter-keymap
ms-
1.1.2

remote-containers
ms-
0.295.0

remote-ssh
ms-
0.102.0

remote-ssh-edit
ms-
0.86.0

remote-wsl
ms-
0.79.4

remote-explorer
ms-
0.4.0

material-icon-theme
PKi
4.28.0

sqlite-viewer
qwt
0.2.5

python
ms-
2023.10.0

vscode-pylance
ms-
2023.6.10

vscode-xml
red
0.25.0

(1 theme extensions excluded)

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vscaac:30438847
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
vsccc:30610678
3biah626:30602489
pyind779:30671433
f6dab269:30613381
vscrpc:30673769
pythonsymbol12:30671437
a9j8j154:30646983
showlangstatbar:30737416
vsctsb:30748421
pythonms35:30701012
a2ce3375:30757347
pythonfmttext:30731395
pythoncmv:30756943
fixhidewlkth:30730051
hidesbindicator:30760978
pythongtdpath:30739704
bgfeh915:30763804
dh2dc718:30763024
pythonnosmt12:30765603

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

https://github.com/microsoft/vscode/assets/6084022/3fcfb5fd-cb1d-4b9e-a643-ac014effc10a

/duplicate of #183400

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


Agree on a standard format for a .node-version file?

It seems like, at a minimum, this would need to support v4.5.6 and 6.7.8 - ie, static versions, both with and without the v.
It would certainly not support aliases, since a) that varies widely by version management tool, and b) the point of an "x-version" file is to target one specific version.
This raises the question, however, about io.js versions, which it should also support. Should iojs-v1.2.3 be allowed? If not, v1.2.3 would still unambiguously point to an io.js version. What about a future where there's more than the version number to target - like, "engine" or "architecture"?

I agree with the minimum of static versions and would cast a vote for treating iojs versions and node versions as one range.
Something I'd like to throw into the ring:

the point of an "x-version" file is to target one specific version.

I'd like to question this. npm's package.json dependencies field has demonstrated the power of version patterns and semantic versioning. Usually, what people want is not to run 6.1.3 forever, but e.g. run the latest version in the 6.x series. So, if .node-version only holds static versions, that would mean having to update the file in every project every time a new version is released. This is not a user experience I'd advocate, but, I look forward to hearing your opinions on this.

that would mean having to update the file in every project every time a new version is released.

That's how rbenv works, and from what I read on the documentation this accounts the same for rvm.

Although the reasoning behind it is a bit different, here is @mislav's take on why .ruby-version has to be precise: https://gist.github.com/fnichol/1912050#gistcomment-682506

The examples from https://github.com/nodejs/version-management/issues/14#issuecomment-269030366 would also mean fuzzy constraints in .node-version files are out of the question.
In classic node fashion, I would propose a JSON-structure for .node-version files:
{
  "version": "1.2.3"
}

Extensible as follows:
{
  "version": "1.2.3",
  "engine": "..."
}

On the plus side, it's extensible, it's simple and still readable. On the downside, it's a departure from how .node-version files are used currently.

Another downside, parsing JSON without node available (since version managers generally need to operate without node available, like nvm) is very difficult.

@marcelklehr package.json already provides that. The purpose of a .node-version file would be simplicity.

So, you are talking about ease of implementation. I think not having node (or any json parsing platform) available is a superficial constraint, since the user needs to install something, why can't it be a version manager that runs on node? It can be. nvs, for example, shows that.
I'm all for re-using package.json for this, but someone else said, the purpose of .node-version files is that not all environments use npm and thus have a package.json (as per https://github.com/nodejs/version-management/issues/12#issuecomment-269023427). If the purpose is to be able to easily read a file within a shell script then that's certainly the way to go. I find that purpose not convincing, though, since a version manager should work across all platforms, so choosing a programming environment less archaic than shell scripts is in order anyway.

@marcelklehr yes, and that might be a great solution. but choosing a configuration format that imposes constraints like that on which implementations work is untenable - anything we choose absolutely must work for existing solutions as well as future ones, and nvm relies on posix, where adding a JSON parser is a heavyweight requirement.

So, you're arguing, in fact a posthumous standard is necessary that works already, instead of a new standard. Fair point. I was assuming a new standard would be a good choice since a) we're trying to integrate more than just the version and b) .node-version contents are already incompatible. I don't necessarily agree that anything we choose here must work for existing solutions, but then I would rather see a new 'official' version manager than a fully backwards-compatible standard that all version managers slowly gravitate to.

How are they already incompatible?

Some version managers, some allow aliases, some don't, some treat io.js as a separate version range with its own tag, some don't, some provide fuzzy matching, some don't.

That doesn't mean they're incompatible, as long as there is a union of consistent behavior. In other words, if all accept static versions with and/or without a v prefix, then that's compatibility.

I think there's a mere intersection of consistent behavior. How would you integrate architecture and engine, then, without losing this compatibility?

Sorry, s/union/intersection, is what I meant :-)
I don't know how, that's an important question. Perhaps on a second line, since it's likely that tools currently only grab the first line of the file?
It really depends what the parsing rules are for all the current engines. They may ignore everything after the third version number grouping; they may ignore everything after the first line - or they may hard-break if any unrecognized input exists. We'll have to research it.

Bump. Where is this at? https://github.com/creationix/nvm/pull/1625 is a-waiting. :)

Just wanted to throw this in here, ps-nvm supports both .nvmrc and reads package.json's engines.node field, with full npm semver range support. Because parsing JSON in PowerShell is trivial ;)

semver is not practical for POSIX-only tools like nvm.

@ljharb would you mind expanding on that please? Curious to learn more, thanks!

@MatthewHerbst parsing semver ranges in pure posix is prohibitively complex.

@ljharb from a runtime performance perspective or the amount of code needed? There are already open-source POSIX parsers for semver (I have not verified how compliant any of them are), and they are trivial relative to say, the amount of code in nvm/nodenv.

Both, as well as cognitive overhead of needing to continually maintain the code. Someone has been making a proof of concept of doing it in nvm, and it is prohibitively large and complex.

Since we seem to have agreed that some type of complex structure is needed, what complex structures are there that aren't "as prohibitively large and complex" to parse in POSIX-only environments?
I guess what I'm trying to say is, at some point, a decision simply needs to be made. If it takes a few hundred lines of code (in a standalone library or directly in tools), that seems acceptable rather than having this issue sit another two years with no resolution. Otherwise, why not close this issue and just accept that there will be no standard for the file?

I think that we can, and should, define a small set of rules such that it's trivially parseable and also that it points to a single version. nvm already has something similar.

You could use 8.11.x or 8.11 and point to a range, without needing the full complexity of a semver range.

Yeah, for sure - I don't think full semver support is needed. Above you argue for something more flexible though:

fwiw “just one line” won’t really work, especially with different cpu architectures (32 bit, 64 bit, or future things) and JS engines (v8, chakra, spidermonkey). Whatever we decide on must be generically extensible in a backward and forward compatible way, full stop.

Maybe it would help by listing out all the things we might have to consider?
For starters, from the above we have:

The architecture you are on
The engine you are running
The version of node you want based on the above considerations

Maybe a yaml formatted file would make sense?

ugh, no, no thanks on yaml.
I like your approach for the bullet list tho. Another item is "the LTS line, if any, you're running on" as an alternative to "version" - and another is "which fork" (meaning node, io.js, ayo, or anything in the future) - and another is "standard, release candidate, nightly".

ugh, no, no thanks on yaml.

Heh :) Was just throwing out a random thought. What formats are you partial to? So, list wise then we are at:

The architecture you are on
The engine you are running
The version of node you want based on the above considerations
Fork: node, io.js, ayo, etc
Build: "standard", "release candidate", "nightly", "canary" (same as "nightly"?)

Not sure I follow on when you would specify LTS over version, since there can be multiple LTS versions out at the same time I believe?

You might want to specify "latest LTS", or "LTS argon" or "LTS boron" or "LTS carbon" etc. An LTS line isn't necessarily constrained to a single major version.

An LTS line isn't necessarily constrained to a single major version

Good point!

The architecture you are on
The engine you are running
Fork: node, io.js, ayo, etc
The LTS version(s) you want based on the above considerations
The version of node you want based on the above considerations
Build: "standard", "release candidate", "nightly", "canary" (same as "nightly"?)

Minimum requirements (so far):

Either LTS or version line must be present

It seems, from what I understand, that a consensus has been reached regarding the requirements of a .node-version file. Is there a specific format that's been agreed upon then? I'm personally partial to @marcelklehr's suggestion from earlier, where the first line is either a version or an LTS, and the only required line, then the following lines are optional key=value pairs of other things that can be specified from @MatthewHerbst's list.

Are there any conventions in use for explicitly invoking the .node-version lookup, rather than implicitly when there is not a recognised version specified with a command like install/run/use?
(In some searching I came across one mention of auto in this sort of context, and one suggestion for engine for consulting the engines field of the package.json. e.g. my-version-manager install auto)

I have read through this thread a few times over the years (!), and have a simple pragmatic proposal in mind. I'll read through thread(s) again with a proposal in mind to check it against discussion and build up a case for it. Hopefully within next week.

This discussion has been wide ranging and interesting, covering ideas for a future official version manager, for current version managers to use in the future, and for an intersection of current version manager conventions.
I found existing support for .node-version in avn, nodenev, direnv, asdf-vm, and fish-nvm.
I suggest we agree on the simplest format for .node-version, so new implementers can easily move forward, and users get the benefits.
(A simple format/intersection has been suggested a few times already, I'm having a go at explicitly pushing it! Discussions on how and what to support for the future will continue...)
I propose the portable format for .node-version is a single line with x.y.z version number.
Such as
12.13.1

In particular, these variations are not included in the portable format:

optional leading v (e.g. v12.13.1): not universally supported, not semver, and does not add functional value
partial version number (e.g. 12.13, or 12.x): not universally supported, need to agree on format, need to agree on what it means
lts et al: not universally supported, need to agree on format, need to agree on what it means

Implementations are not restricted to only accept this format. (In practice I expect most implementations pass either the whole file or the first line to their normal version parsing!)
The portable version numbers are those available from https://nodejs.org/dist with binary files included. iojs and source builds are not universally supported and not required by implementations.
Implementations with their own configuration file should use that in preference to .node-version if both are available.

There are multiple comments on explicit support for future needs, or at least leaving the door open for additions. I have deliberately not included anything explicitly, but have deliberately only specified the backwards compatible format and not prevented additions.
As for that future need, I saw the approach rvm uses with supported files: a simple inflexible shared format file (.ruby-version), and a more flexible format file (.versions.conf). Rather than adding key=value lines into .node-version, I wonder whether a new file with all key=value would be a nice separation of historical and simple specification from a more flexible format, and the flexible format can be more uniform (all key=value).

@shadowspawn I agree that we should support the simplest version of semver and any deviations from it. You can add nvs to your list of version managers which support .node-version.
I also think that there's a valid use case for supporting aliases which resolve to a valid semver, such as "lts", "latest" or "dubnium".
BTW, while I'm not affiliated with nvs in any way (beyond using it in dev and CI), I'd like to suggest endorsing it. It is:

The ONLY cross platform node version manager and works in Windows too
Already supports all the features above
Is written in JS, so could easily be bundled with node, just like npm
When invoked without arguments presents an interactive menu, which is beginner friendly
Supports auto-switching based on .node-version and environment variables
Plays nicely with CI, unlike some of the other version managers

Thanks @elektronik2k5, I have added nvs to list of existing uses (was accidentally omitted).

I believe semver allows an optional leading v.

@elektronik2k5 this group will not endorse any single version manager; it's certainly one of the known alternatives.

I believe semver allows an optional leading v.

It took careful reading prior to Semantic Versioning 2.0.0, but there is now an explicit FAQ entry here: https://semver.org/#is-v123-a-semantic-version

Is “v1.2.3” a semantic version?
No, “v1.2.3” is not a semantic version. However, prefixing a semantic version with a “v” is a common way (in English) to indicate it is a version number.

It seems like a waste of a UX opportunity to disallow the leading v, at the very least.

I deliberately proposed hardcore minimum, and the semver definition is a convenient justification.
Since the filename has version in the name,  there is perhaps less value in a v? Like "About This Mac" has "macOS Catalina Version 10.15.1".
(Full disclosure: I read the description of all the exiting implementations but didn't check the runtime, it is possible it is part of the intersection of behaviours!)

node -v includes the v, i don't find it redundant.

A counterpoint in kind:
npm -v does not include the v, I don't find it necessary.
(For interest the semver calculator allows leading v. But I will stick with promoting a minimum format to see whether it can be a minimum viable proposal.)

Just points for consideration:

npm ships with Node, but it is controlled by a corporate entity, not the foundation.
npm is not the only player (i.e. yarn, which does not use the v prefix)
npm is not technically a requirement to run node.

@elektronik2k5 this group will not endorse any single version manager; it's certainly one of the known alternatives.

Well just a month ago OpenJS Foundation added nvm as an incubator Hosted Project.
There's plenty of value in bundling a version manager with node, just like npm and npx are. Thanks to npm, every node user can manage packages and thanks to npx every node user can run executables from packages without installing them beforehand.
Both are, in my view, indispensable tools which provide considerable value to the node ecosystem and contribute greatly to DX, ease of use, beginner friendliness and maintainability.

@coreybutler Although i think your argument agrees with my preference, what ships with node is the only player that matters.
@elektronik2k5 yes, i'm aware, i'm the sole nvm maintainer and i submitted nvm to the OpenJS Foundation.

It seems like a waste of a UX opportunity to disallow the leading v

Discussing this matter for about three years isn't really making use of the opportunity either.
Why not just start with the simplest most common form? E.g. 1.2.3.

I could not tell for sure from their documentation, so I tried installing and configuring each of nvs, avn, nodenev, direnv, and asdf-nodejs. I think they do all support an optional leading v in the .node-version file! Willing to add optional leading v to proposal as supported by existing implementations, and in addition some evidence commonly supported. 😄

@coreybutler Thanks. I was using npm as a familiar example of an application, and a well known semver range parser, exploring optional leading v on version numbers. I might have given the wrong impression as was not meaning to imply npm was canonical behaviour.
I may have missed part of your point, as I didn't understand the part in brackets here?

npm is not the only player (i.e. yarn, which does not use the v prefix)

Line endings: ideally I think the "single line" .node-version should be able to have no line ending, unix line ending, or Windows line ending?
I didn't remember this when I was testing, and not sure if existing non-WIndows implementations support a Windows line-ending. It seems the Right Thing to do for cross-platform.

Prompted in part by @ljharb mention ofnode -v, I thought of a natural use case which relies on support for a leading v:
node --version > .node-version

This changes my thinking from "could do without v" to "should allow v".

We would have to mandate that any lines after the first were ignored; and we should strongly encourage always including a line ending.
I'd prefer to only support LF, not CRLF.

@shadowspawn - I was trying to point out that yarn is another popular alternative to npm. I was also under the impression the output was different from npm -v. However; having looked at it again, I believe my shell was adding a v (I've got some crazy stuff going on in my dev environment). I believe yarn's syntax actually mirrors npm's.

re CRLF
I ran node --version > foo.txt on Windows in cmd.exe, PowerShell, and git bash. All produced a file with CRLF on end. (The plain PowerShell result was tainted as it was a ucs2 file with a BOF and I am not suggesting we support that! PowerShell Core may default to bom-less utf8 according to this)
A good reason for supporting CRLF is this file is intended for cross-platform use and the ordinary user can not tell the line endings visually. The nasty situation I have personally experienced in a cross-platform team is when even after you have configured the editor to default to LF, you copy-and-paste some text from a browser and the Windows line endings are preserved when paste into your file, and defeat your configuration efforts.
Looking to node itself for a reference, I see Readline behaviour is:
The 'line' event is emitted whenever the input stream receives an end-of-line input (\n, \r, or \r\n).
I am interested in opinions from Windows and cross-platform readers. I feel like CRLF is still likely to occur? (Although getting easier to configure editors to default to LF.)

Does anyone object to me writing up a simple format for .node-version as I proposed above?
Short version: file named .node-version consisting of a single line with x.y.z version number, with optional leading v.

@shadowspawn we'd want to make sure that only the first line is looked at, so that future lines could be added in the future for other things like npm; there's alsol been a request for comment support (like v1.2.3 # this is the version we depend on for reasons, for example). Thoughts?

Seeing https://github.com/tj/n/pull/616 - now that n has released actual support for that filename, that filename is forever poisoned, and imo can never ever become a universal standard.
As such, I think this issue can be closed as a wontfix; the dream of this filename is dead.

I think the dream being dead is a little over-dramatic, since the filename was already widely used as noted in my previous comment:

I found existing support for .node-version in nvs, avn, nodenev, direnv, and asdf-nodejs.

I intend to be responsive to any consensus reached here.

None of those version managers have anywhere close to the usage of nvm, n, or nave, and I simply can't see any path now to that filename being viable.
This same thing has happened multiple times with package.json fields - just like with browser globals, when a tool pollutes a global namespace, it risk preventing its standardization forever, and I'm convinced that's now happened here.

we'd want to make sure that only the first line is looked at

It is my intention to make that a requirement, yes.

there's alsol been a request for comment support (like v1.2.3 # this is the version we depend on for reasons, for example). Thoughts?

I don't think that should be supported on the first line. Keep It Simple.

That's something we'd need to discuss.
ftr the reason your proposal from awhile ago didn't go anywhere was because it wasn't sufficient, not because it needed "trying out".

ftr the reason your proposal from awhile ago didn't go anywhere was because it wasn't sufficient

I had investigated and replied to each of the comments that followed my proposal. I'll clarify what my current position is.

https://github.com/nodejs/version-management/issues/13#issuecomment-560043897

You can add nvs to your list of version managers which support .node-version.

Done.

I also think that there's a valid use case for supporting aliases which resolve to a valid semver, such as "lts", "latest" or "dubnium".

There is a valid use case, but I had already excluded that and haven't changed my mind: I said: "lts et al: not universally supported, need to agree on format, need to agree on what it means"
My current position: no aliases in the first revision.

https://github.com/nodejs/version-management/issues/13#issuecomment-560061663

It seems like a waste of a UX opportunity to disallow the leading v, at the very least.

I investigated and found widespread support in the existing implementations, and noted that node displays its own version with a leading v.
My current position: allow optional leading v

https://github.com/nodejs/version-management/issues/13#issuecomment-560281323

Why not just start with the simplest most common form? E.g. 1.2.3.

That is what I'm proposing.

https://github.com/nodejs/version-management/issues/13#issuecomment-560367333

ideally I think the "single line" .node-version should be able to have no line ending, unix line ending, or Windows line ending?

https://github.com/nodejs/version-management/issues/13#issuecomment-560545532

and we should strongly encourage always including a trailing newline (all files should always have one).
I'd prefer to only support LF, not CRLF.

https://github.com/nodejs/version-management/issues/13#issuecomment-561005937
(Investigation)
My current position: encourage producers to always include a trailing LF. This is likely to have the widest compatibility with existing implementations, and is consistent with unix standards for a plain text file and hence other tools.
My current position: consumers shall allow no line ending, unix line ending, or Windows line ending. If users create a simple text file in a natural way on their platform, it should work.

I'll yank my n release and change the filename for now. (I think npm unpublish is valid for 48 hours...)

there's alsol been a request for comment support (like v1.2.3 # this is the version we depend on for reasons, for example). Thoughts?

I'll expand a little on my quick answer since I didn't give concrete reasons for my opinion: "I don't think that should be supported on the first line. Keep It Simple."

Comments is something that would fit naturally into a richer file format, whether in a future expanded version of .node-version with key values on subsequent lines, or in a differently named file. I feel adding comment support compromises the simple story that there is just a version on the first line.

I doubt comments are supported by many of the existing consumers of .node-version. My impression from code inspection when I was looking into leading v was that they mostly slurp either the whole file or the first line and treat it as a "version".

For example (and not singling out nvs, using it because I had recently looked at its code and could quickly reproduce):
% nvs add
Failed to parse version in file: /Users/john/Documents/Sandpits/.node-version
Invalid version string: 12.14.2 # comment

In the interested of clarity, while I do think future implementations should support Windows line endings, I have not investigated current implementations and would do that before deciding on how to word that aspect.

I am dropping my effort to get consensus on a minimal backwards compatible standard format. I suspect I joined this conversation years too late to gain interest from the original contributors, besides pushing a very conservative and unexciting format! Ah well.

I'll yank my n release and change the filename for now.

If I do add support in the future with the current site of affairs, it will be for quiet compatibility with existing and especially cross-platform implementations, and not noisy support of a standard of any sort.

@ljharb At some point an executive decision needs to be made here. If you think this is dead then please close this ticket so we can stop spending years on it.
I think if nvm pushes a standard the rest will fall in line. @shadowspawn's proposal strikes me as a pretty reasonable starting point, with easy expansion into a likely key=value system in the future on subsequent lines.
It's also unclear to me why every previous version of the file needs to work. Publish nvn v1.0.0, clearly and loudly tell people about the breaking change, and they can either conform, stick to an older version, or find another solution that works for them.

FWIW, nodenv will continue supporting .node-version as the primary means to specify a file. Regardless how heavy the use of n may be, the many users of it will not have started to use and rely on the file overnight. (Despite nodenv users having been using it for many years.)
I would be in favor of at least documenting the behavior of current tooling so that a minimal set of conformance could be decided. Implementors would then be free to implement as desired; but at least with the knowledge of where compatibility is possible.

we won't drastically change a file format that we've been using for years simply to match a late arrival

@jasonkarns very bluntly: the end users and downstream tooling will decide that. npm is about to start supporting yarn.lock files. Change is inevitable.

@MatthewHerbst i'm not aware of any plans for npm to support yarn.lock files, and i've been following the repos and in the RFC calls for many months.
I think that, if nodenv did not already use this file, then certainly it would be reasonable for the most popular projects - all of which are represented in this working group - to agree on something and thus defacto define it as the ecosystem standard. I don't think it would be reasonable, ethical, or kind for a majority to steamroll a single project, regardless of which project it is or that project's usage.
If there's a common format we can use that's compatible with nodenv, and its extensibility is specified and is also compatible with individual version managers, then that is a viable path forward.

It's also unclear to me why every previous version of the file needs to work. Publish nvn v1.0.0, clearly and loudly tell people about the breaking change, and they can either conform, stick to an older version, or find another solution that works for them.

Breaking users causes harm and costs a lot of time and money. Doing it out of necessity is one thing, but doing it capriciously - ie, when any nonbreaking option remains available - is a hostile act. nvm's v1.0 will be to indicate it's fully stable, not to justify radical breakage.

i'm not aware of any plans for npm to support yarn.lock files, and i've been following the repos and in the RFC calls for many months

@ljharb  Based on the most recent npm blog post, it seems yarn.lock support is coming in npm v7.

I don't think it would be reasonable, ethical, or kind for a majority to steamroll a single project, regardless of which project it is or that project's usage.

I agree, I don't want to "steamroll" anyone either for no reason. However, at some point a decision needs to be made, and based on every comment above, no one/no project is going to be perfectly happy with the outcome. There is no lack of community input on this thread.

Doing it out of necessity is one thing, but doing it capriciously - ie, when any nonbreaking option remains available

We've been at this for four years. Based on the requirements laid out in many, many comments above, and what you and others who have executive power here are and are not amenable to, it seems increasingly clear that there is not such an option.

nvm's v1.0 will be to indicate it's fully stable, not to justify radical breakage

I was just picking an easy/random sem-ver breaking number. I'm well aware that, as the package isn't at 1.0.0 yet any minor change is a breaking change.

Thanks, I missed the blog post.

at some point a decision needs to be made

You say that as if it's a given, but I don't think it is. Often, "no decision" is the best course of action rather than "the wrong decision".

Often, "no decision" is the best course of action rather than "the wrong decision".

I fully support "no decision" if that's what you think is best. If that's the case, let's close this and move on.

I'm honestly surprised that there hasn't been any progress on this issue for the past 4 years. Wouldn't it be a start to have an MVP kinda .node-env file, starting with only exact matches, and see how the community receives it.
If even that isn't acceptable, then I think it's better to just close this issue, and forget about a universal standard.
I'm happy with how nodenv works nonetheless.

@jasonkarns https://github.com/nodejs/version-management/issues/13#issuecomment-650172345

I would be in favor of at least documenting the behavior of current tooling so that a minimal set of conformance could be decided. Implementors would then be free to implement as desired; but at least with the knowledge of where compatibility is possible.

I had started investigating this early in the year. Dug out my notes and tidied up into a repo. I had tried fnm and nodenvand checked just a few things in nvs: https://github.com/shadowspawn/node-version-usage

@shadowspawn That research is fantastic, thank you for that!
Would there be interest in hosting a file in this repo proposing at least this format (https://github.com/shadowspawn/node-version-usage#suggested-compatible-format)? That could function as a reference for tooling to aim at or link to.

Per the compatibility matrix there's only one manager that doesn’t support a leading v, and there’s a PR open to fix that https://github.com/direnv/direnv/pull/1071 (I tested the logic there).
In that light, it might make sense to require the leading v as part of the common format.
Then, the common format becomes minimally:
v{major}[.{minor}[.{patch}]][optional CR/LF]

In perfect life docker pull node:$(cat .node-version) would just  always work as one expects, allowing SRE/DevOps/Sys.Admins to write knowledge about expected node version exactly once per code reposiory.

In perfect life docker pull node:$(cat .node-version) would just always work as one expects, allowing SRE/DevOps/Sys.Admins to write knowledge about expected node version exactly once per code reposiory.

Per the compatibility matrix there's only one manager that doesn’t support a leading v, and there’s a PR open to fix that direnv/direnv#1071 (I tested the logic there).
In that light, it might make sense to require the leading v as part of the common format.
Then, the common format becomes minimally:
v{major}[.{minor}[.{patch}]][optional CR/LF]

The PR was merged, so all support leading v.

To clarify, the Docker Hub node images are tagged without a leading v.
https://hub.docker.com/_/node/tags?page=&page_size=&ordering=&name=20

The PR was merged, so all support leading v.

Clarifying "all". All as of March 2023 when PR was opened. Not all in the current table.


docs(decision-records): use Lerna with Yarn workspaces

Record the decision to use Lerna and Yarn on https://github.com/blindnet-io/privacy-components-web and all similar monorepos.
Replace the initial draft made by @jboileau99 for https://github.com/blindnet-io/password-assistant (to be moved to https://github.com/blindnet-io/privacy-components-web) in #22.

This decision as already been implemented and discussed. The present PR is only here to publish them.


Update pagination

Don't show pagination if it isn't necessary
Diasable pagination buttons if first or last page is reached
Fix a small bug

Merged. Thank you!


UI - Platform: Form submission

Description of changes:
Start of form submission
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

Temporary Url for review: https://strr-platform-dev--pr-200-rwy33p3s.web.app


When initializing the app, there is no way to default to a dashboard as the initial view.

Expected Behavior:

Setting appBar.data.appBarId to the key of an app bar item should make that the initial view.

Actual Behavior

This requires clicking on the app bar item again which then sets local.settings.view to be stats
This cannot be set by the api side.

Other notes:

We may consider moving appBarId to another top level key - worth thinking about.

It would be great if we could find a way to avoid using the local.settings.view altogether.


Fetched relay data is not rendered server-side

In my app, I have a series of QueryRenderers (some nested inside each other) that are pulling data. When I disable javascript in my browser, I expect it to render the full page properly on the server, and give it to me, however, this does not happen.
Posted here, since I think this is a problem centric to the server-side render, and not specifically relay.

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Server side should render the full app, after all the QueryRenderer calls complete.
Current Behavior

It appears that after the fetch, the QueryRenderer#render prop is not called again on the server.
Steps to Reproduce (for bugs)

Add relay and a working query renderer to your app
Have the result just output the result as text
Disable javascript in your browser
Reload the page, you won't see the result text.

Context

Your Environment

Tech
Version

next
5.0.0

node
8.9.4

OS
osx sierra 10.12.6

browser
Chrome Version 66.0.3359.117 (Official Build) (64-bit)

I guess there is no way to know if queries have been fetched, and maybe I'm stuck doing all my queries ahead of time in getInitialProps?

[This example] demonstrates the intended pattern for next.js with Relay-Modern. Indeed you want to run your query in getInitialProps as you can see in there 👍


Enhancement: add file path to Background Dancers

add a file path to the Background Dancers. I'm making a mod and I'm making M.I.L.F have a different stage, and I'm changing the way the Background Dancers look, but I can't because there is no file path in the code
loadGraphic(Paths.image('limo/limoSunset','week4'));
var dancer:BackgroundDancer = new BackgroundDancer((370 * i) + 130, bgLimo.y - 400);
I can't pick a new file for the dancers

Closing because answered in https://github.com/KadeDev/Kade-Engine/discussions/272


Backport #87 on branch dev

The issue template i have made for branch master were not backported to the dev branch :)
So we have the default issue templates again on the repository

Thanks so i merge it !
could you please approve #159 too ? ( Related with this one, juste a remove of a file )
That's the opposite for me i'll probably not have time starting from september :disappointed:


Make OAuth2-Redirect Endpoint Configurable

My team is using this package in a slightly different way. We have our own endpoint for the UI trigger so we can add some additional built in endpoints to the swagger page.
If we use an OAuth2 flow on a function, we can sign in and redirect as expected with the package's built in UI trigger, and the /api/oauth2-redirect.html endpoint will work correctly.
If we us our own trigger to build the UI page, when we sign in, the redirect URL tries to hit /oauth2-redirect.html which fails as it lacks the api/ prefix. All other functionality works as expected.
This seems to be related to the issue and a request made within but I do not see an issue to track it .
#47

@alm0st907 If you want to use /oauth2-redirect.html, you should use the Azure Functions proxy feature, using proxies.json because you can't granular control of the /api prefix. Therefore the possible solution could be:

Use proxies.json for /oauth2-redirect.html, or
Use host.json to remove the /api prefix from all endpoints and manually add the /api prefix to each endpoint's Route property that you implement.


PSA: Too big/wide slider on initialization

When your swiper slider initializes too big (sometimes even far, far wider than the page),
this could happen from the slider wrapper element being inside a CSS flexbox/grid container.
The following styles fix the issue:
.swiper-container {
  width: 100%;
  max-width: 100%;
  max-height: 100vh;
  // CSS Grid/Flexbox bug size workaround
  // @see https://github.com/kenwheeler/slick/issues/982
  // @see https://github.com/nolimits4web/swiper/issues/3599
  min-height: 0;
  min-width: 0;
}

It also contains a fix for Firefox and it also works with the Slick slider (and probably other like Splide).
I had to search quite a bit to find a working solution, so I hope this is helpful for me in the future and other developers, enjoy!
 This solution actually works, and it should be in the doc.

Also, note that:
.swiper-slide requires these in some case:
  width: auto;
  flex-shrink: 0;
  display: block;
  height: 100%;
  max-height: 100%;

.swiper-wrapper needs:
  max-height: 100%;
  height: 100%;
  display: flex;

Если у вас проблема с swiper и grid layouts, когда у далекого от слайдера родителя установлены grid-template-columns в фракциях, то эти хаки уже не помогают просто так. Я имею ввиду ситуации когда например у body стоит grid-template-columns: 3fr 9fr; а уже у глубоко лежащего div внутри находится swiper, то ближайшему к swiper родителю надо установить display: grid; тогда эти хаки заработают.
Вот наглядный пример этого поведения: https://jsfiddle.net/codisy/2nc1dz4q/84/

@Codisy: Translated to English (Google Translate):

If you have a problem with swiper and grid layouts, when the parent far from the slider has grid-template-columns in fractions set, then these hacks no longer help just like that. I mean the situation when, for example, the body has grid-template-columns: 3fr 9fr; and already the deeply lying div has a swiper inside, then the parent closest to the swiper needs to set display: grid; then these hacks will work.
Here's a good example of this behavior: https://jsfiddle.net/codisy/2nc1dz4q/84/

This may be relevant too, it solved it for us: https://stackoverflow.com/a/53022198/7362396
It was added on a flex parent item many layers above the Swiper.

This may be relevant too, it solved it for us: https://stackoverflow.com/a/53022198/7362396
It was added on a flex parent item many layers above the Swiper.

Obligatory StackOverflow answer that answers should contain the code and not just a link to it. :)

Oh my god thank you this saved me. I was so confused for 30 minutes straight - my div size was 3 million pixels wide but this fixed it xD

if you use tailwind add overflow-hidden to swiper container
`

....

`

I LOVE YOU. I got rid of display: flex; and it solved the issue of my width going over 1.6 million pixels below 768px width. Crashed my computer once as well.

in my own case, swiper seems to be shrinking my webpage on mobile view but its  okay on desktop view

In my case I simply had to do the following:
.my-swiper-container {
  display: grid;
}

.my-swiper-container .swiper {
  max-width: 100%;
}

One workaround I found is to use minmax(0, 1fr) instead of fr or auto
https://lightrun.com/answers/nolimits4web-swiper-css-grid--swiper-wrapper---wrong-width-calculated

I solved the problem setting max values for height and width:
.carousel__container {         max-width: 100%;         max-height: 100%;     }

In my case I simply had to do the following:
.my-swiper-container {
  display: grid;
}

.my-swiper-container .swiper {
  max-width: 100%;
}

this has actually helped me. than you

.swiper-slide requires these in some case:
  width: auto;
  flex-shrink: 0;
  display: block;
  height: 100%;
  max-height: 100%;

This has fixed my bug, thanks 💪

In my case I simply had to do the following:就我而言，我只需执行以下操作：
.my-swiper-container {
  display: grid;
}

.my-swiper-container .swiper {
  max-width: 100%;
}

My God! You saved me! Thanks

Thanks. You saved my time.

DON'T USE css flex on swiper container. If you want make slide full height — just use height: 100% for parent and slides!

so many work around, so many people got this problem, why this is still not a fix you yet? I don't mean to be annoying, but I myself got this problem, and was very confused on why it is not working.
I can't or even know what to search in google lol. I was checking one by one if any of the issue (if any one) was same like me.. I hope this is fixed or at least moved to the docs as known bug / quickfix

Only this worked for me:

The Desktop version is perfectly fine, but once I go to mobile my slides get an inline width of width: 3.35544e+07px.

The Desktop version is perfectly fine, but once I go to mobile my slides get an inline width of width: 3.35544e+07px.

This was actually working fine dont know what might change, also i just return to the version that i have but still not working

Still the same problem. When initialized, the width of the sliders is very large. Overriding styles as above does not help.

Hi all! I had the same problem, the solutions described above did not help. I think that the creators slightly changed the classes inside the library. Now I don’t see the class "swiper-container", but there is just "swiper" . Here is my  only one thing , that I added into global styles file .swiper {
width: 100%;
}

I switched to splidejs, there are absolutely no problems with it.

This worked for me

Just ran into this and after trying a couple of the fixes mentioned w/o avail, it got me thinking and this finally resolved it in my case:
.swiper-slide {     flex-shrink: 1;   }
Note: My parent class to .swiper-slide is .swiper-wrapper, which is display: flex;

In my case I simply had to do the following:
.my-swiper-container {
  display: grid;
}

.my-swiper-container .swiper {
  max-width: 100%;
}

adding width full solved mine. thanks

Если у вас проблема с swiper и grid layouts, когда у далекого от слайдера родителя установлены grid-template-columns в фракциях, то эти хаки уже не помогают просто так. Я имею ввиду ситуации когда например у body стоит grid-template-columns: 3fr 9fr; а уже у глубоко лежащего div внутри находится swiper, то ближайшему к swiper родителю надо установить display: grid; тогда эти хаки заработают.
Вот наглядный пример этого поведения: https://jsfiddle.net/codisy/2nc1dz4q/84/

You saved my whole life brother! Thank you very much.


Review request for set-up-mobile-portfolio

Key consideration when building the project:

Used provided microverse figma portfolio template to visualize to UI.
Configured linters and workflows to meet requirements.
Added README.md as it is a requirement.
Linked the MIT licence to readme file

Changes requested have been implemented as follows:

logo wrapped with  tags for convertion, semantic and user experience.
Headline wrapped into section for generic stand alone.

 tags wrapped in

removed media query as requested.
background image positioned to absolute hence no overlapping.


Add sorting to json labels

This solves some test flakiness and is the right thing to do.

bors r+

bors r+


Issue with using Django for loops

When using a for loop in a component the .last and .first attributes do not work.
infinity_scroll.cotton.html

  {% for item in items %}
    <li class="{{ class }}"

        {% if forloop.last %} <-- does not work
                hx-get="{% url 'my-url' %}?page={{ page }}"
                hx-swap="afterend"
                hx-trigger="intersect once"

                data-has-more="{{ forloop.last }}"
      {% endif %}>
      {{ slot }}

  {% endfor %}

usage

<c-components.infinity-scroll :items="events"></c-components.infinity-scroll>

My assumption is that built-in template tags are being overridden.
Perhaps https://docs.djangoproject.com/en/5.0/ref/templates/builtins/#for should be protected while building the component?

@copyfactory Yes - have noticed this myself even this morning, a PR is going through now which should resolve it.

#27

This is fixes in v0.9.11

If you have a chance and is still possivle, maybe you can see if this resolves

#17

Sure thing, just checked and unfortunately did not resolve #17


Patch 1

Hello,
I think there are a bug in compile. If Bare Theme hat none javascript, the javascript from Plugin are loaded before "jquery.min.js" and then there are jquery errors.
Example:

I copy theme Responsive and make the rename changes in theme.php
Compile works , but in browser there are javascript error.
Debug from compile say that javascripts from Pluging are first included then jquery.min.js

array(53) {
  [0]=>
  string(113) "/html/engine/Shopware/Plugins/Default/Frontend/AdvancedMenu/Views/frontend/_public/src/js/jquery.advanced-menu.js"
  [1]=>
  string(135) "/html/engine/Shopware/Plugins/Community/Frontend/SwagLiveShopping/Views/responsive/frontend/_public/src/js/jquery.swag_live_shopping.js"
  [2]=>
  string(76) "/html/themes/Frontend/Minol/frontend/_public/vendors/js/jquery/jquery.min.js"
.....
.....
thanks.
David Lopez

Hi,
i can confirm this behavior / bug.
I also have a theme that inherits from Bare instead of Responsive and when enabling the "Advanced Menu" plugin, there will be jQuery errors.
The problem is indeed the order of includes. Bare has no JS files, then all plugins' JS files will be included and after that the JS files from the custom theme are included as you can see in engine/Shopware/Components/Theme/Compiler.php#L368 and following.
The reason this works for the Responsive theme is that someone has been so clever to define the "bare" property to either a theme that has no parent or an instance of ResponsiveTheme in engine/Shopware/Components/Theme/Inheritance.php#L109. So when you have enabled the Responsive Theme, the $files variable in engine/Shopware/Components/Theme/Compiler.php#L368 will already include the JavaScripts of the Responsive theme, then it will add the scripts of the plugins and after that merge again the file list of responsive theme.
Hope this helps evaluating this bug and fix it soon!
Kind Regards,
Stefan

I've created an issue in JIRA for this: http://jira.shopware.de/?ticket=SW-12272

@stefanullinger I closed the issue cause it's a duplicate with the following ticket: http://jira.shopware.de/?ticket=SW-12782

You can find the fix for this issue in the following commit: https://github.com/shopware/shopware/commit/a689775b5646062db4e3b8f4d392982215e81fe2

The fix still in version 5.1.4
in Theory was in version 5.1.2 was solved.


Properly decode unicode characters in token tickers/symbols

Currently tokens w/ unicode characters such as a ★ are not properly decoding and displaying in Badger.
This is where we decode the ticker.
Properly decode the characters or call REST/bitdb. Ex: https://rest.bitcoin.com/v2/slp/list/2505307c54c5bc8e8d4d71fb9d1ab18d06b26a18ddc29c2e437113b472eac8d2

Concurring on this: https://explorer.bitcoin.com/bch/tx/d2c8530ec0079be03151003549eecaf84f4cb1bbec9054de931e9f370ecc34aa displays as


bot.answerCallbackQuery has been deprecated, any other option?

After testing the answerCallbackQuery method with its associated buttons for long hours, I see in the console that it says the following:
node-telegram-bot-api deprecated The method signature answerCallbackQuery([options]) has been
deprecated since v0.29.0

There is some other method that handles or has the same functionality as answerCallbackQuery?
I also took a look at the documentation and I do not see anything about it
Thanks in advance

Very easy solution:
bot.answerCallbackQuery(message.id, {text: 'Your message'});

I'll try it and I'll tell you, thank you very much :stuck_out_tongue_winking_eye:


Added appsettings to gitignore

Closes #62

I guess you just added the appsettings.json to gitignore but it cannot add this file because it has already been tracked by git hub. So I used git rm to make this change

Why can't it be added?, those who said that teachers should add it


Weird issue with context length

First of all, thanks a lot for this great project!
I got a weird issue when generating with llama 2 on 4096 context using generator.generate_simple,
  File "/codebase/research/exllama/model.py", line 556, in forward
    cache.key_states[self.index].narrow(2, past_len, q_len).narrow(0, 0, bsz)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: start (3313) + length (808) exceeds

As I understand the code, it already limits the number of new tokens to under the context limit. Is there any settings that I might need to change?

What is the sequence length set to in the model config? Maybe something weird is happening if you haven't changed it from the default (2048), and it tries to generate a negative number of tokens.

Is there more of this error message?
  File "/codebase/research/exllama/model.py", line 556, in forward
    cache.key_states[self.index].narrow(2, past_len, q_len).narrow(0, 0, bsz)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: start (3313) + length (808) exceeds

It looks like it's been cut off.

I got a similar error. It seems to come from trying to put too many tokens into the model. I was putting 5k words into the model.
  File "C:\Users\ndurkee\.conda\envs\exllama\Lib\site-packages\flask\app.py", line 2190, in wsgi_app
    response = self.full_dispatch_request()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\ndurkee\.conda\envs\exllama\Lib\site-packages\flask\app.py", line 1486, in full_dispatch_request
    rv = self.handle_user_exception(e)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\ndurkee\.conda\envs\exllama\Lib\site-packages\flask\app.py", line 1484, in full_dispatch_request
    rv = self.dispatch_request()
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\ndurkee\.conda\envs\exllama\Lib\site-packages\flask\app.py", line 1469, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "F:\Flashblade_ML_Data_Test\meeting_notes\exllama\example_flask.py", line 48, in inferContextP
    outputs = generator.generate_simple(prompt, max_new_tokens=16000)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "F:\Flashblade_ML_Data_Test\meeting_notes\exllama\generator.py", line 316, in generate_simple
    self.gen_begin(ids, mask = mask)
  File "F:\Flashblade_ML_Data_Test\meeting_notes\exllama\generator.py", line 186, in gen_begin
    self.model.forward(self.sequence[:, :-1], self.cache, preprocess_only = True, lora = self.lora, input_mask = mask)
  File "F:\Flashblade_ML_Data_Test\meeting_notes\exllama\model.py", line 967, in forward
    r = self._forward(input_ids[:, chunk_begin : chunk_end],
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "F:\Flashblade_ML_Data_Test\meeting_notes\exllama\model.py", line 1053, in _forward
    hidden_states = decoder_layer.forward(hidden_states, cache, buffers[device], lora)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "F:\Flashblade_ML_Data_Test\meeting_notes\exllama\model.py", line 536, in forward
    hidden_states = self.self_attn.forward(hidden_states, cache, buffer, lora)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "F:\Flashblade_ML_Data_Test\meeting_notes\exllama\model.py", line 440, in forward
    new_keys = cache.key_states[self.index].narrow(2, past_len, q_len).narrow(0, 0, bsz)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: start (2048) + length (1265) exceeds dimension size (2048).

I'm using the_bloke/vicuna-13B-v1.5-16K-GPTQ which is supposed to be a 16k context model so it should be able to handle it. At any rate, this is the relevant portions of the config.json.
    "max_sequence_length": 16384,
    "max_position_embeddings": 4096,

What I found that worked was changing the parameters on lines 82-87 in model.py
        self.max_seq_len = 16384  # Reduce to save memory. Can also be increased, ideally while also using compress_pos_emn and a compatible model/LoRA
        self.max_input_len = 4096  # Maximum length of input IDs in a single forward pass. Sequences longer than this will be processed in multiple steps
        self.max_attention_size = 2048**2  # Sequences will be processed in chunks to keep the size of the attention weights matrix <= this
        self.compress_pos_emb = 4.0  # Increase to compress positional embeddings applied to sequence

Previously, these were 2048, 2048, 4096, and 1.0 respectively. This worked and seems to give reasonable results but I'm not sure if it's the correct way to go about it.

@w013nad  Where do you define those changes? In the source code or generator model settings?
config = ExLlamaConfig(model_config_path)               # create config from config.json
config.model_path = model_path                          # supply path to model weights file
model = ExLlama(config)                                 # create ExLlama instance and load the weights
tokenizer = ExLlamaTokenizer(tokenizer_path)            # create tokenizer from tokenizer model file
cache = ExLlamaCache(model)                             # create cache for inference
generator = ExLlamaGenerator(model, tokenizer, cache)   # create generator
Configure generator
generator.disallow_tokens([tokenizer.eos_token_id])
generator.settings.token_repetition_penalty_max = 1.2
generator.settings.temperature = 0.05
generator.settings.top_p = 0.65
generator.settings.top_k = 100
generator.settings.typical = 0.5
generator.settings.max_seq_len = 16000
Produce a simple generation
output = generator.generate_simple(prompt_template, max_new_tokens = 500)
I am using the same model but getting the following error
RuntimeError: start (2048) + length (1265) exceeds dimension size (2048).

@w013nad You wouldn't need to hard-code new values into the config class. You can just override the values after creating the config.
Also, it looks like that config file is incorrect. "max_sequence_length" and "max_position_embeddings" should mean the same thing, or at least I don't know how to interpret those values if they're different.
The max_input_len argument means specifically the longest sequence to allow during a forward pass. Longer sequences will be chunked into portions of this length to reduce VRAM usage during inference, and to make the VRAM requirement predictable which is sort of required when splitting the model across multiple devices. But max_attention_size imposes an additional restriction on the chunk length. In short, setting max_input_len > sqrt(max_attention_size) just wastes a bit of VRAM.
@Rajmehta123 The max_seq_len parameter is in the ExLlamaConfig object, not the generator settings.


Ability to set Camera to always default to Latency

If you want to snap a quick photo (short on time or busy place) you probably don't want to wait for all the stabilization etc. to happen that happens in Quality.
Naturally in those situations you also don't have time to dig in settings to switch to Latency.
I think it would be beneficial to have the ability to set Camera to default to Latency, and if the user does want to use Quality (which means they're not in a hurry), then that can be activated through Settings.
This would be similar to being able to set iOS's Camera to always default to Live Photos or the default filter.

We have no plans to change how this works beyond eventually changing the default from Quality to Latency.

The setting is persistent.

Yes, which means if it was previously set to Quality last time, it will still be on Quality when you reopen.

eventually changing the default from Quality to Latency.

This is more or less what I'm asking for, defaulting to Latency.


NameError: name 'body' is not defined

body variable is not defined when useHttpDelete is set to false and removeFromTarget is set to true.
Line https://github.com/hpe-storage/python-3parclient/blob/master/hpe3parclient/client.py#L3748 will give error.

@sneharai4 I'll be making changes to fix this.


get_query_results_as_dict() returns the column names instead of column contents

Describe the bug

Steps to reproduce

per the usage instructions, I run {% set my_dict = dbt_utils.get_query_result_as_dict("SELECT * FROM " ~ ref(my_table))
and it returns a list of all the columns in the table. Potentially of note here, my_table is a csv seed file in my instance.
Expected results

I expect to return a dictionary with the contents of the query. for example:
Table:
column_1, column_2
a,0
b,1
c,2
should return: {a:0, b:1, c:2}
Actual results

using the example above, I get:
[column_1, column_2]
Screenshots and log output

System information
The contents of your packages.yml file:
packages:

package: fishtown-analytics/dbt_utils
version: 0.6.4
package: fishtown-analytics/stitch_utils
version: 0.2.1

Which database are you using dbt with?

[ ] postgres
[ ] redshift
[ ] bigquery
[x] snowflake
[ ] other (specify: ____________)

The output of dbt --version:
packages:
  - package: fishtown-analytics/dbt_utils
    version: 0.6.4
  - package: fishtown-analytics/stitch_utils
    version: 0.2.1

Additional context

Are you interested in contributing the fix?

I was using this function incorrectly... closed


refactor: introduce todos selectors

What:

introduce todos selectors (and the async pipe)
Rewrite tests using @angular-extensions/testing-library

Issue number: N/A

Codecov Report

Merging #414 into master will increase coverage by 27.96%.
The diff coverage is 94.11%.

@@             Coverage Diff             @@
##           master     #414       +/-   ##
===========================================
+ Coverage   58.77%   86.73%   +27.96%
===========================================
  Files          66       66
  Lines        1043     1048        +5
  Branches       46       46
===========================================
+ Hits          613      909      +296
+ Misses        424      122      -302
- Partials        6       17       +11

Impacted Files
Coverage Δ

...ples/todos/components/todos-container.component.ts
96.36% <100%> (+59.26%)
:arrow_up:

...app/shared/big-input/big-input-action.component.ts
100% <100%> (+15.38%)
:arrow_up:

src/app/examples/todos/todos.selectors.ts
93.33% <91.66%> (+18.33%)
:arrow_up:

src/app/core/core.module.ts
88.88% <0%> (+3.7%)
:arrow_up:

src/app/examples/form/components/form.component.ts
80.48% <0%> (+7.31%)
:arrow_up:

src/app/examples/crud/books.selectors.ts
90.9% <0%> (+9.09%)
:arrow_up:

src/app/examples/form/form.actions.ts
100% <0%> (+10%)
:arrow_up:

...otifications/components/notifications.component.ts
72.22% <0%> (+11.11%)
:arrow_up:

src/app/core/animations/route.animations.ts
87.5% <0%> (+12.5%)
:arrow_up:

src/app/shared/big-input/big-input.component.ts
100% <0%> (+14.28%)
:arrow_up:

... and 38 more

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 b7b814a...3563041. Read the comment docs.


Short solution needed: "Iris dataset" (python-scikit-learn)

Please help us write most modern and shortest code solution for this issue:
Iris dataset (technology: python-scikit-learn)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments explain solution.
Link to this issue in comments of pull request.

How to load Iris dataset


How to get feed post of the current user ?

i want to get list of feed ,  what the funcion i have to use ?

Here is example
new FeedUserRequest(client.getSelfProfile().getPk()).execute(client)
.thenAccept(response -> {
    // act on response
});

Here is example
new FeedUserRequest(client.getSelfProfile().getPk()).execute(client)
.thenAccept(response -> {
    // act on response
});


[NestedTree] Parent change causes invalid tree

composer.json
"gedmo/doctrine-extensions": "2.4.13"

What I expect
Case: Replace one node with another.
I have a node, which has both root and parent, different from self.
When I click "Change node", I choose the replacement node, which is not a child or sub-child of the self.
Node
--Replacement Node
--Node
----Outdated Node
------Node1
------Node2
------Node3
------Node4
Node
--Replacement Node
----Node1
----Node2
----Node3
----Node4
--Node
Outdated Node
I expect all children of the self to become children of the replacement. Self is put into the tree root.
What I get
Tree is invalid
node [childID] left is less than parent`s [parentID] left value
node [childID] left is less than parent`s [parentID] left value
node [childID] left is less than parent`s [parentID] left value
...
x children count

Example
Consider this function:
public function replace(Node $currentNode, Node $replaceNode, $verify = false)
    {
        $em = $this->container->get('doctrine.orm.entity_manager');

        /** @var NodeRepository $repo */
        $repo = $em->getRepository('TreeBundle:Node');

        $em->beginTransaction();
        try {
            $currentNode->setParent(null);//without null, parent is left untouched
            $repo->persistAsLastChild($currentNode);

            $em->flush();

            //Start problems with tree
            $directChildren = $repo->children($currentNode, true);

            /** @var Node $node */
            foreach ($directChildren as $node) {
                $node->setParent($replaceNode);//used setParent, same as why in comment before
                $repo->persistAsLastChildOf($node, $replaceNode);
            }

            $em->flush();
            //End problems with tree

            if ($verify) {
                $this->verifyTree();
            }

            $em->commit();
            return true;
        } catch (\Exception $e) {
            $em->rollback();
            return false;
        }
    }

Notes
While in debug, $repo->persistAsLastChildOf($node, $replaceNode); caused RGT to be negative.

Fixed by using flush in loop. NOT GOOD BUT WORKS
/** @var Node $node */
foreach ($directChildren as $node) {
    $node->setParent($replaceNode);//used setParent, same as why in comment before
    $repo->persistAsLastChildOf($node, $replaceNode);
    $em->flush();
}


The UI becomes unresponsive when there are tons of logs return in logStream

To repro, create a queue trigger, and put lots of messages in the queue.   Noticing a lot of messages in logStream, then UI becomes frozen.   Pausing the logstream (clicking Pause button) is a challenge since the UI becomes unresponsive - it eventually pause though.

That could be a blocker for any high throughput scenario.

Is this really backlog or do we want to fix it for beta?


Return temperature sensor always showing as 0.0 degrees

Describe the bug
sensor.return_temperature is always showing at 0.0 degrees, even when the boiler has been running for many hours.
Other sensors, including sensor.actual_supply_temperature, sensor.actual_modulation, and sensor.hc1_supply_temperature_setpoint appear to function correctly.
Additionally, I can see that the sensor is being called. Logs show:
"DEBUG (MainThread) [custom_components.bosch.sensor.base] Update of sensor SensorsReturn temperature101477814 called."
To Reproduce
Steps to reproduce the behavior:

Go to Developer Tools
Find sensor.return_temperature
View the state of this sensor
See error

Expected behavior
I would expect that sensor.return_temperature shows a value above 0.0 degrees when the boiler is running.
Screenshots

Version

HA version: 2024.1.3
HA Bosch component version: v0.24.4

Please provide bosch scan

Please provide bosch scan

http://jsonblob.com/1196047054991646720
Thanks

you can look in scan that you don't have return temperature sensor connected to your installation.

you can look in scan that you don't have return temperature sensor connected to your installation.

Thanks. Can I just check - does this mean it's likely that the actual Bosch thermostat itself hasn't been connected to the boiler correctly, therefore it is unable to read the return temperature?


Kibana and Logstash not able to connect to ElasticSearch

every thing was working good. I accidentally clicked on "Connect To Host Network"  in elastic container in kitematic.

I reverted the changes and the bridge is dockerelk_elk, but still Kibana and logstash are not able to find elastic searh at http://elasticsearch:9200.

To recreate the stack with the correct network:
$ docker-compose down -v

$ docker-compose up

Closing since it's not directly related to this project.


Using a plain JS library in Vue - window is not defined

(quesion which might be an issue) We have a CDN of useful plain JS functionalities (opening/closing a modal, ..) that we would like to use in our Nuxt project. When including the CDN (//dij151upo6vad.cloudfront.net/2.latest/js/vlaanderen-ui.js) we instantly get window is not defined.
So my question: Is it possible to use a plain JS library in Nuxt/Vue in general?

Hi @warreb1
Sure you can, you need to use the head property in your nuxt.config.js, so it will be included in your generated HTML:
module.exports = {
  head: {
    script: [
      { type: 'text/javascript', src: '//dij151upo6vad.cloudfront.net/2.latest/js/vlaanderen-ui.js', defer: 'defer' }
    ]
  }
}


Cannot update to Cakephp 3.5.* due to 3.4.* requirement in composer.json

Please change the requirement
Thanks

Done and tagged. 1.2.1.
Thank you!