text:
Optimizing IDE Integration for Chain Interactions: Balancing DX with Performance and Bundle Size

Introduction
Enhancing Developer Experience with Improved Chain Interaction Selection in IDEs
When initiating this project, our goal was to offer a flexible interface for developers to select key chain interactions for their dApps, either through an interactive CLI or a web-based UI. However, developer feedback suggests a need for a different approach.
Feedback and Challenges
Shifting to Integrated Development Environment (IDE) Based Solutions
Developers have expressed a preference for having all possible chain interactions accessible directly within the IDE, rather than through separate tools. This shift presents two primary challenges:

Performance Concerns: Integrating all chain interactions could slow down TypeScript server performance, impacting IntelliSense responsiveness.
Bundle Size: A comprehensive integration leads to larger bundle sizes, potentially degrading user experience (UX).

Despite these concerns, the demand for IDE-based chain interaction selection is strong.
Current Solutions and Limitations
Progress with Code Generation and Bundle Size Optimization
Our recent efforts in code generation have significantly improved TypeScript server performance, even with extensive chain interactions. However, despite having decreased the bundle size significantly, it still remains a concern. For example, using Kusama metadata for descriptor generation can increase the bundle size for a typical dApp by approximately 80Kb, which is less than ideal.
Proposed Solutions
Exploring Options for Efficient Code Management
Option 1: Manual Descriptor Import

Approach: Developers manually import each descriptor, allowing unused code to be automatically trimmed. The code would look like this:

import { createClient } from "@polkadot-api/client"
import {
  StorageSessionValidators,
  StorageStakingValidators
} from "./codegen/ksm"
import { getProviderChain } from "./provider"

const client = createClient(getProviderChain.connect)

const sessionValidators = await client.query(StorageSessionValidators).getValue();
const validatorsData = await client.query(StorageStakingValidators).getValues(sessionValidators);

Drawback: This contradicts the desired developer experience, as it limits the discovery of available chain interactions within the client.

Option 2: Advanced Tree Shaking Solutions
The code looks like this:
import { createClient } from "@polkadot-api/client"
import ksm from "./codegen/ksm"
import { getProviderChain } from "./provider"

const client = createClient(getProviderChain.connect, ksm)

const sessionValidators = await client.query.Session.Validators.getValue();
const validatorsData = await client.query.Staking.Validators.getValues(sessionValidators);

Option 2a: Bundler Specific Plugins

Approach: Develop plugins for various bundlers (Vite, Rollup, Webpack, etc.) to analyze the AST and identify used interactions for custom tree-shaking.

Option 2b: Bundler Agnostic Solution

Approach: Create a tool that inputs a bundled JS file and its source map, performs analysis similar to Option 2a, and outputs a new, optimized JS file with an updated source map.
Challenge: This approach is complex and requires significant development effort.

Seeking Community Input
Collaboration on Plugin Development and Solution Refinement
I propose initially developing a plugin for Vite/Rollup as a starting point. I invite the community's thoughts on these solutions and encourage contributions towards developing plugins for other bundlers.
Conclusion and Next Steps
Balancing Developer Experience with Performance and UX
Our aim is to strike a balance between providing a seamless developer experience and maintaining optimal performance and UX. I look forward to the community's feedback and suggestions on these proposed solutions.

This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/polkadot-api-2023-q4-update/5318/1

Having written a "plugin", of sorts, for removing excess stuff from PolkadotJS, I found that many things you would expect to be removed by tree shaking were still included when bundling (e.g. the bytes.js file containing the giant WASM blob was never tree shaken even when specifying onlyJS throughout our code). AST couldn't work out that we didn't want to use the WASM version. I've found a reliable way to tree shake is to have deep package exports in the package.json.
I'm considering our options for bundling JS for interacting with ink! contracts and so far scale-ts looks like a good way to create the required encoding / decoding functions. The key thing when creating a small bundle for a single contract will be including the minimal amount of encoders. Currently, we're using Typechain to output contract bindings but this outputs a huge amount of code, requiring the ABI to be bundled with the JS.
In future, we are aiming to develop a Typechain style code-generation tool that creates the required encoders for a contract, but, critically, doesn't output the entire encoding library (scale-ts / polkadot-api). This means the ABI won't be required and neither will the 80% of other type definitions required by substrate pallets.
Do you think polkadot-api could help us achieve this goal?

I prefer option 1. Anything requires plugin to bundler is just going to be costly.

Drawback: This contradicts the desired developer experience, as it limits the discovery of available chain interactions within the client.

I don't really understand this. People should discover available interactions via docs, not auto completes.
Besides, we can do this
import { createClient } from "@polkadot-api/client"
import * as ksm from "./codegen/ksm"
import { getProviderChain } from "./provider"

const client = createClient(getProviderChain.connect)

const sessionValidators = await client.query(ksm.StorageSessionValidators).getValue();
const validatorsData = await client.query(ksm.StorageStakingValidators).getValues(sessionValidators);

so auto completes still works
(not 100% sure if this play nicely with tree shaking but to me it looks significantly easier for bundler to optimize compare to option 2)

Drawback: This contradicts the desired developer experience, as it limits the discovery of available chain interactions within the client.

We have actually made A LOT of iterations on this since the last time that we updated this document 😅.
In fact @voliva is just finishing this latest iteration. Once it's done, then we will have the best of both worlds: super-small bundle-sizes, plus kick-ass code-competition. Also, the user won't be importing the types from a custom folder, but from a subpath of the library...
The thing is that the only thing that adds size the the bundle is the registry of checksums. However, this registry of checksums will be automatically imported dynamically by the library. Which means that all modern bundlers (parcel, vitest, webpack, etc) will create a separate asset/chunk just with the registry of the checksums, which will be required in the background... That's totally fine, because we only need the checksums after we have compiled the latest runtime, which is also an async process. So, by having a separate asset that just contains the checksums and that is loaded dynamically, we are speeding the overall loading time quite significantly.

authors: Polkadot-Forum forgetso josepot xlc

repo: polkadot-api/polkadot-api


text:
Compare different approaches

Hi Vesa,
Long time ago I asked @mausch if we can add Lenses to F#+ and he told me he was more interested in Polymorphic Lenses.
Last year I was researching this area and came up with a similar solution which I added to F#+.
I need to analyse in detail what's the difference with your solution but I think you avoided to use a generic map by using a single Functor which combines both ID and Const whereas I used map and also the Profunctor abstraction from FsControl but later I found that from Profunctor the most used instance is the one for functions so I simplified it a bit.
I wonder if we can join forces and come up with a reasonable solution for this type of optics. What do you think?

I'm happy to discuss ideas!  I'm not yet happy with the results (in this repository) and my understanding of the topic.
I think you articulated one of the basic ideas exploited here correctly.  The other idea was to eliminate higher-rank polymorphism using mutation.  The idea has been to try and see whether types that are not well supported in F# could be eliminated using alternative approaches.  It should be possible to do a more or less "faithful" encoding of the Haskell approach (e.g. Higher), but it becomes quite complex and possibly expensive (object allocations and virtual functions).

I agree that it will be nice to eliminate or at least reduce the higher order types simulated through member constraints. If you take the approach of Higher you would move the overhead from compile-time to run-time, if you ask me I would prefer to keep it at compile time.
Regarding the compile-time performance I think the F# compiler still has room to improve it but also noted that if you use the |> operator it helps type inference a lot.
The other problem I faced was that the Lens Haskell library is huge and I wanted to keep it simple.
Another problem still not solved is how to abstract over folds while keeping it optimal, I mean not having to traverse the whole structure if it's not necessary, which in Haskell happens naturally.

source: gharchive/issue

authors: gmpl polytypic

repo: polytypic/FsOptics

license: mit

license_type: permissive

license_source: bigquery


text:
unresponsive header menu items

Hi @kimrutherford
I regret to inform you that one/some of the changes in #1584 has broken the header menu. When I click on any of the menu items below the search box, or below and to the right, nothing happens. Search and Submit are unaffected; Genome status works if I click the left-hand third but not the rest (roughly, clicking on 'Geno' works), and Downloads, Community, About, and Help don't respond at all. It seems like there's some invisible box overlying most, but not all, of the menu.
The problem affects every browser/platform combination I can test (Firefox & Chrome on Linux, and Firefox, Chrome, & Safari on Mac).
I know it's new because I happened to have a couple of unrefreshed tabs open in FF and the menus still work there.

Thanks for finding that.  I'm about to re-release with a fix.

repo: pombase/website

license: MIT

license_source: github-api


text:
Fix builder syntax

botch to try get android to work properly (see glimesh/glimesh_app#22)
Fixing builder syntax

i think we'll have to change ref: glim-botch to ref: main in the glimesh_app repo. iirc there may be some changes required in the app too as part of upgrading to the latest version of flutter-webrtc

source: gharchive/pull-request


text:
backgroundColor, gravity not working: Only simple toast is displaying.

Snippets i used:
Fluttertoast.showToast(
    msg: "Don't be so fast! Retry after some time.",
    toastLength: Toast.LENGTH_LONG,
    gravity: ToastGravity.CENTER,
    timeInSecForIosWeb: 1,
    backgroundColor: Colors.red,
    textColor: Colors.white,
    fontSize: 16.0);

UPDATE: It is working as expected on the physical device (Android 10). But not working on emulator (Android 11)

Same for me, background color is not working on Android 11

Looks like, author has mentioned about it in the documentation:

Custom Toast will not work on android 11 and above, it will only use msg and toastLength remaining all properties are ignored

Is there any alternative ways to achieve this?

You can use https://github.com/ponnamkarthik/FlutterToast#toast-with-buildcontext-all-platforms to show custom toast

authors: anburocky3 eduardbraun ponnamkarthik

repo: ponnamkarthik/FlutterToast


text:
i added in one class

i added in one data

again you have to record

repo: poojithamende/alllstudentdetails


text:
Add Functionality to Filter PCA Background Population in Large Cohort Pipeline Ancestry Stage

This PR introduces an enhancement to the ancestry stage of the large cohort pipeline. The update allows for a more granular PCA by enabling the subsetting of the background population to individuals of a specific ancestry.
Changes include:
A new configuration option under [large_cohort.pca_background] named superpopulation_to_filter. This option allows users to specify the superpopulation to be used for the PCA. If not specified with population name, the new parameter defaults to False.
Additional lines of code in ancestry_pca.py that filter the background_mt matrix table based on the superpopulation specified in the configuration.
This enhancement provides users with the flexibility to perform PCA on a specific superpopulation, allowing for more detailed and targeted analysis.

Successful batch run here: https://batch.hail.populationgenomics.org.au/batches/455689/jobs/2
INFO:root:Superpopulations before filtering ['Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe', 'Europe',...]
INFO:root:Filtering background samples by ['Africa', 'South Asia']
INFO:root:Finished filtering background, kept samples that are ['Africa', 'South Asia']
INFO:root:Superpopulations after filtering ['Africa', 'Africa', 'Africa', 'Africa', 'Africa', 'Africa', 'Africa', 'Africa', 'Africa',...]

The cramqc was an oversight by me! Working on a different branch and that snuck its way in

repo: populationgenomics/production-pipelines


text:
Throw error in an esm environment

Description
I am trying to use
👉  index.js
import { toHTML } from "@portabletext/to-html";

in an esm project via setting
👉  package.json
// ...
"type": "module"
// ...

Expected Behavior
That the import works
Actual Behavior
An error is thrown
import { toHTML } from "@portabletext/to-html";
         ^^^^^^
SyntaxError: Named export 'toHTML' not found. The requested module '@portabletext/to-html' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:

import pkg from '@portabletext/to-html';
const { toHTML } = pkg;

Suggested solution
This package is not defined as an esm package (e.g. there is no entry in the package.json) therefore any file that is esm needs to end in *.mjs.
  "exports": {
    ".": {
-      "import": "./dist/to-html.esm.js",
+      "import": "./dist/to-html.mjs",
      "require": "./dist/to-html.cjs.js"
    }
  },

Renaming the file solves the issue for this package but then the same issue occurs within @portabletext/toolkit
import { nestLists, isPortableTextToolkitList, isPortableTextListItemBlock, isPortableTextToolkitSpan, spanToPlainText, isPortableTextBlock, isPortableTextToolkitTextNode, buildMarksTree } from "@portabletext/toolkit";
                                                                                ^^^^^^^^^^^^^^
SyntaxError: Named export 'buildMarksTree' not found. The requested module '@portabletext/toolkit' is a CommonJS module, which may not support all module.exports as named exports.
[...]

Help
What is the best way I can help to resolve this? Would you like me to start an issue/PR on @portabletext/toolkit or will you take it from here? 🤔
Environment
Tested on a Mac with node 16 & 17

Thanks for reporting! This should be fixed in v1.0.3

authors: daKmoR rexxars

repo: portabletext/to-html


text:
[Feature Request] - Pre-populate container ports that are to be added automatically/manually

Is your feature request related to a problem? Please describe.
When adding a new container, the only options for port mappings are to (A) Publish all exposed ports or (B) Map additional port but, in either of these options, portainer doesn't indicate what the base ports in the image are to be published and these have to either be added automatically (and then potentially changed manually after the container is created) or (B) added manually with no indication of what the ports might be that require mapping...
Describe the solution you'd like
It would be useful if portainer could list the container ports that would be added automatically, or better, when clicking (B) Map additional port, for the base container ports to be pre-listed listed as X:X, Y:Y etc and the user is given the option to change to A:X ad B:Y up front... This must be possible since I also use a Synology NAS and the Docker GUI in there pre-populates the image ports that the container would expose and gives the user the option to ammend these as they are creating (and before they start) the container

Duplicate of #1534

repo: portainer/portainer

license: Zlib


text:
portainer SSL support supports outdated, insecure cyphers

Bug description
portainer with --ssl supports outdated, insecure cyphers (TLS 1.0 and 1.1), but there is no way to configure it differently.
Expected behavior
I'd expect a way to specify which TLS versions and which cyphers are enabled.
Steps to reproduce the issue:

run a portainer instance with ssl enabled
use a ssl tester such as  http://sites.google.com/site/lupingreycorner/ssltest.pl on your portainer instance
Look at the result

Technical details:

Portainer version: 1.22.1
Platform (windows/linux): linux
Command used to start Portainer:
docker run -d --label owner=root -p 9000:9000 -p 8080:8000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v /etc/letsencrypt:/etc/letsencrypt -v portainer_data:/data portainer/portainer --ssl --sslcert /etc/letsencrypt/live/eregion.de/fullchain.pem --sslkey /etc/letsencrypt/live/eregion.de/privkey.pem -l owner=root
Browser: any

Additional context
in this day and age TLS < 1.2 should NOT be used, and insecure TLS 1.2 cyphers should not be used either - especially not in something as potentially critical as a container management frontend.

Duplicate of #2359


text:
Cannot push to quay.io registry as we are not including username in the quay registry URL

Bug description
Adding a Quay registry through the Quay registry option in our UI is broken. Pushing an image results in a 404. The URL we use is simply quay.io whereas the URL should be built to include username like so quay.io/<provided-username>
Expected behavior
When a quay registry is added, it should be built to include username like so quay.io/<provided-username>
Steps to reproduce the issue:

Go to add registry view
Add a quay registry with your username and password
Tag an image with this registry and try to push
Get error 404

Technical details:

Portainer version: 1.24.1, ee:develop
Docker version (managed by Portainer): 19.03.13
Platform (windows/linux): Linux
Command used to start Portainer (docker run -p 9000:9000 portainer/portainer): docker stack deploy
Browser: FireFox

Additional context
If I add a custom registry with the URL quay.io/itsconquest then the image will be successfully pushed

this bug remains in ce2.0.
We should prompt the user to confirm if the repo being added is "personal" or "organization" and if its personal, automatically append their quay.io username credential as the quay.io url, eg quay.io/username
If the user selects "organisation" we should prompt them for the organisation repo name and append that to the url, eg quay.io/portainer

Required changes
Registry creation view
Update the registry creation view to introduce a new "Use organisation registry" switch under the password field.

That switch should be disabled by default.
When that switch is enabled, introduce a new text input for the field "Organisation name". That input is required and should only be displayed when Use organisation registry switch is enabled.

authors: deviantony itsconquest ncresswell


text:
Standalone Hosts: Stack Migrate Fails, x509 error

when attempting to use the stack migrate feature on a standalone docker host: to migrate to an agent enabled remote standalone docker host OR a docker API exposed (2376) standalone Docker host, OR a agent enabled remote swarm cluster, the migration fails with an x509 error.

After investigation, here is what I found.
Specs
Portainer deployed locally (standalone docker host).
4 envs to connect with:

2 standalone direct connexions, 1 swarm agent, 1 standalone agent

Names in will refer to the following portainer endpoint types

local = unix socket endpoint
std1 / std2 = standalone hosts through port 2376
agent = standalone host, connected through agent (9001)
swarm = swarm cluster (1 master node) connected through agent (9001)

I purposefully excluded swarm cluster through 1 master node as it's not a setup users should use, and it will certainly behave similarly as a standalone through port 2376.
std2 is only used to test the scenario where we migrate from standalone with port 2376 exposed to another standalone with port 2376 exposed.
Action <> Behaviour table

Source
Destination
Result

local
std1
ok

local
agent
x509

local
swarm
x509

-
-
-

std1
local
ok

std1
std2
ok

std1
agent
x509

std1
swarm
x509

-
-
-

agent
local
unable to create stack (x509 error)

agent
std1
unable to create stack (x509 error)

agent
swarm
unable to create stack (x509 error)

-
-
-

swarm
local
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

swarm
std1
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

swarm
agent
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

Log files
These files show the generated objects during creation/migration. Migration objects should be similar to the objects created during stack creation on the destination environment.
Creation files are name with create_<env>.log pattern.
Migration files are named with <source>_<destination>.log pattern.
Creation log files
create_local.log
create_std.log
create_swarm.log
From local migration files
local_agent.log
local_std.log
local_swarm.log
From standalone migration files
std_agent.log
std_local.log
std_std.log
std_swarm.log
From swarm migration files
swarm_agent.log
swarm_local.log
swarm_std.log

After investigation, here is what I found.
Specs
Portainer deployed locally (standalone docker host).
4 envs to connect with:

2 standalone direct connexions, 1 swarm agent, 1 standalone agent

Names in will refer to the following portainer endpoint types

local = unix socket endpoint
std1 / std2 = standalone hosts through port 2376
agent = standalone host, connected through agent (9001)
swarm = swarm cluster (1 master node) connected through agent (9001)

I purposefully excluded swarm cluster through 1 master node as it's not a setup users should use, and it will certainly behave similarly as a standalone through port 2376.
std2 is only used to test the scenario where we migrate from standalone with port 2376 exposed to another standalone with port 2376 exposed.
Action <> Behaviour table

Source
Destination
Result

local
std1
ok

local
agent
x509

local
swarm
x509

-
-
-

std1
local
ok

std1
std2
ok

std1
agent
x509

std1
swarm
x509

-
-
-

agent
local
unable to create stack (x509 error)

agent
std1
unable to create stack (x509 error)

agent
swarm
unable to create stack (x509 error)

-
-
-

swarm
local
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

swarm
std1
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

swarm
agent
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

Log files
These files show the generated objects during creation/migration. Migration objects should be similar to the objects created during stack creation on the destination environment.
Creation files are name with create_<env>.log pattern.
Migration files are named with <source>_<destination>.log pattern.
Creation log files
create_local.log
create_std.log
create_swarm.log
From local migration files
local_agent.log
local_std.log
local_swarm.log
From standalone migration files
std_agent.log
std_local.log
std_std.log
std_swarm.log
From swarm migration files
swarm_agent.log
swarm_local.log
swarm_std.log

Great investigation @xAt0mZ !
I would recommend to park that one aside until we have a new stack implementation with #3750
Then we can re-investigate and see if that new implementation actually solves this problem.
Thoughts @ncresswell

Great investigation @xAt0mZ !
I would recommend to park that one aside until we have a new stack implementation with #3750
Then we can re-investigate and see if that new implementation actually solves this problem.
Thoughts @ncresswell

Yeah i agree.. we need to determine cause and effect, and if we can solve the root problem, then thats the ideal end case.
Rgds,
Neil Cresswell

Yeah i agree.. we need to determine cause and effect, and if we can solve the root problem, then thats the ideal end case.
Rgds,
Neil Cresswell

With the work on #3750 this issue is mostly fixed; these are my results:
Action <> Behaviour table

Source
Destination
Result

local
std1
ok

local
edge agent
ok

local
swarm
ok

-
-
-

std1
local
ok

std1
std2
ok

std1
edge agent
ok

std1
swarm
ok

-
-
-

agent
local
ok

agent
std1
ok

agent
swarm
ok

-
-
-

swarm
local
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

swarm
std1
ok

swarm
agent
ok

With the work on #3750 this issue is mostly fixed; these are my results:
Action <> Behaviour table

Source
Destination
Result

local
std1
ok

local
edge agent
ok

local
swarm
ok

-
-
-

std1
local
ok

std1
std2
ok

std1
edge agent
ok

std1
swarm
ok

-
-
-

agent
local
ok

agent
std1
ok

agent
swarm
ok

-
-
-

swarm
local
this node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again

swarm
std1
ok

swarm
agent
ok

should standalone -> swarm be converted to a swarm stack, or stay a compose stack (as it is now)

should standalone -> swarm be converted to a swarm stack, or stay a compose stack (as it is now)

converting will result in an error if compose version is 2. not converting might cause a confusion

converting will result in an error if compose version is 2. not converting might cause a confusion

Closing as it was fixed as part of the work on https://github.com/portainer/portainer/issues/3750

Closing as it was fixed as part of the work on https://github.com/portainer/portainer/issues/3750

authors: chiptus deviantony itsconquest ncresswell xAt0mZ


text:
⚠ ku-s has degraded performance

In afb45c2, ku-s ($KU_API_STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 13090 ms

Resolved: ku-s performance has improved in f8cb332.

repo: positive-infinity/api-status


text:
⚠ ku-s has degraded performance

In d4d4902, ku-s ($KU_API_STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 5602 ms

Resolved: ku-s performance has improved in 39799d3.


text:
Long github names break

Issue:
When using my full github name (khinshankhan), I get this error:

This doesn't seem to be an issue with the number of characters in the header (it was working if i put my github name as k, and since my linkedin is the same as github, I tried swapping them and still got the error).
Potential Fix:
I'm not wholly familiar with latex, but I think this line is the culprit https://github.com/posquit0/Awesome-CV/blob/5b05d935658377c73a3456269d23a276b19804f7/awesome-cv.cls#L495
Looking at the linkedin logic, I replaced the line with
\href{https://github.com/\@github}{\faGithubSquare\acvHeaderIconSep{\expandafter\ul\expandafter{\@github}}}%

and it works like a charm. Wonder if this should be merged in if it's 'proper'.

Thanks! Could you submit as a PR?

Hello, I updated to the latest awesome cv and this fix is no longer needed. Unless someone else comes along with the same issue, I think we can safely close this. Thanks for your hard work :+1:

authors: OJFord khinshankhan


text:
Remove map size hardcode

Map isn't going to be 40x15 or any other hardcoded constants, it will be encapsulated in separate file.

b1ec3faf5cc04074a981d5c7f96e16c5e0da6ad5

repo: postboy/kaliningrad


text:
VSCode Same colors

Color of search highlight and xml tags are the same, which do highlighted tags unreadable

Fixed.

repo: posterpole/vscode


text:
Add flags to externals to set truth values.

#external p(X) : q(X). [true]
#external p(X) : q(X). [false]   % default
#external p(X) : q(X). [free]
#external p(X) : q(X). [release] % because available via API

@tortinator, @BenKaufmann, @mgebser, @javier-romero: opinions are welcome!

I like your proposal. Do we use 'free' elsewhere as well?  -t

In the multi-shot solving with clingo paper we use unknown but I don't like that so much. Another option that could work might be choice.

I also like the idea. Another possible name for free would be open. I like these two names most, and they both look likewise good to me.

Then I will go for free because the same name is used in the API.

Implemented in 18e9981993051cfb3216e72797df87c4f8f9324d.

authors: mgebser rkaminsk tortinator

repo: potassco/clingo


text:
Filtered replication

Using a couchdb backend, socket pouch doesn't read filter set in replication options and therefore emit all changes to all connected clients.

Can you provide a test to reproduce? socket-pouch runs the entire PouchDB test suite and there is definitely a filter test in there.

To be exact, the changes do not replicate (perhaps they are filtered out at client side pouchdb). However I observe that data  are still sent over the wire when looking at websocket frames in chrome debugger. This is different from couchdb HTTP long poll, since it doesn't emit out any data that don't match filter condition set by client.
This is an undesired effect since unnecessary data are sent over to non-relevant clients.
In my test case, 2 or more clients are listening for changes using different channels. However as mentioned, messages meant for channel A are sent to channel B as well.
I'm still not familiar with pouchdb test suite, but my test code is as follows:
var socketpouch = new PouchDB({
	adapter: 'socket',
	name: 'test',
	url: 'ws://localhost:8000' (this socketpouch will proxy a couchdb at the backend)
})

//add a design doc to couchdb, to allow filter by channel
socketpouch.put{
  "_id": "_design/bychannel",
  "filters": {
	"channelfilter": "function(doc, req){if (doc.channel==req.query.channel){return true;} else {return false;}}"
  }
}

//client will listen to particular channel, in this case channel A
var pouchdb = new PouchDB('localpouch')
pouchdb.sync(socketpouch, {
	filter: "bychannel/channelfilter",
	query_params: {channel: 'A'},
	live: true
})

//add doc or update doc, this should replicate to other clients that filter for channel A
pouchdb.put({
	doc_content: 'xyz',
	channel: 'A'
})

@hongnk hey i think you are missing something. you need to add design document in the localdb as well.follow below link
http://pouchdb.com/2015/04/05/filtered-replication.html
and let me know if that works?
This is critical bug i think if that does not work.
please update as soon as possible

In my test case, 2 or more clients are listening for changes using different channels. However as mentioned, messages meant for channel A are sent to channel B as well.

This sounds like a separate bug. Can you confirm that the two clients have the same "messageId" and that's why they're getting the same messages? If two clients are getting the same messages, then that's a security issue and very different from a performance problem.

you need to add design document in the localdb as well.follow below link

Yep, that's true. If you use an ad-hoc filter function, then the filtering will be done client side. However it seems like @hongnk is not doing that.

I'm still not familiar with pouchdb test suite

Here's how you can debug this: read the README guide to testing, which will set up the tests in a browser. Navigate to the test in a browser, add ?grep=filter to the URL bar, which will search for any tests with the word "filter" in them. See what happens for tests that use design-doc-related filter functions.
It's possible that the docs are unnecessarily being sent over the wire, but from what I recall of how I implemented this, that is not possible.

Thanks nolanlawson for looking at this.
@faraazc yes the design doc is added in local pouch, I just didn't mention the previous message.
@nolanlawson I don't think messageId is the issue, because one client on Chrome and the other on Firefox.
I put all these codes in a working sample and attach here so you can test it out. It's a zip file but I rename as pptx to be able to upload here.
test.pptx
Reproduction steps:

Need pouchdb-server or couchdb, node and socketpouch (can use the sample socketpouchserver.js included in zip file)
On Chrome, go to: http://localhost/testfilterbug.html?channel=A
On Firefox, go to: http://localhost/testfilterbug.html?channel=A
Click "generate doc" button on Firefox, and watch Chrome websocket debug frames. the generated doc is synced to Chrome as expected because they filter for same channel A. Note: all generated doc IDs are prefixed with channel  A or B depending on querystring, so it is easier to watch.
On Firefox, switch to: http://localhost/testfilterbug.html?channel=B, and watch Chrome websocket log, the messages are still coming, while I expect that they should not be sent over to Chrome since it filters for channel A only.
You might try to switch to direct HTTP to couch server instead (I have a commented line in the html file to do that). And watch XHR message, it works as epxected, message are sent only if Firefox is on channel A, but not when switched to channel B.

@nolanlawson when shall we expect this to be fixed?.

@faraazc I am not currently putting socket-pouch high on my priority list, because it's a project I did for fun and am not currently using myself. So the answer is: never, unless somebody else takes it up.

@nolanlawson  filter parameter is not sent to websoket message that's why filtered replication is not working. Add socket adapter in if condition in pouchdb library to fix this bug.
[https://github.com/pouchdb/pouchdb/blob/master/packages/node_modules/pouchdb-core/src/changes.js#L180](See code)
Current:
if (this.db.type() !== 'http' && !opts.doc_ids) {
      return this.filterChanges(opts);
}

Should be:
if (this.db.type() !== 'http' && this.db.type() !== 'socket' && !opts.doc_ids) {
      return this.filterChanges(opts);
}

@pradiprv  thank you the issue is confirmed fixed after adding if condition. Currently I also follow @nolanlawson suggestion, after instantiate socketpouchdb, overriding it with socketpouchdb.type() = function() { return "http"; } as a work-around.

The implementation has changed in current version 8.0.1, so above provided solution didn't work for me.
Issue:
Facing 403 forbidden error on db replication with over web sockets with a proxy server using library "socket-pouchdb".
Solution:
I could solve the issue just by setting "pouchdbinstance._remote".
Explanation:
While using web socket adapter "pouchdbinstance._remote" is not set to true.
See code :

https://github.com/pouchdb/pouchdb/blob/7d71f444e61cc6b4d5da14998a959bb62a0bfb09/packages/node_modules/pouchdb-utils/src/isRemote.js#L15
https://github.com/pouchdb/pouchdb/blob/7d71f444e61cc6b4d5da14998a959bb62a0bfb09/packages/node_modules/pouchdb-core/src/changes.js#L175

For "pouchdbinstance._remote", it makes a get call for doc_id = "_design_id/filter_name", which fails with 403 forbidden error. By setting db._remote = true, it does not make this get call and avoids 403 forbidden error.
Implementation:
const remotedb = new PouchDB({
  adapter: "socket",
  name: "<db_name>",
  url: "ws://localhost:80", // your ws proxy server url
});
// Note: for http adapter, _remote is by default true
// For socket adapter, set  _remote true explicitly
remotedb._remote = true;

authors: faraazc hongnk nolanlawson pradiprv vshl92

repo: pouchdb-community/socket-pouch


text:
Bunch of tests reproducing #226 and #227

Sorry it's quite messy but at least it reproduces those 2 issues on my machine. There's a lot of cruft since I'm having other problems I can't quite wrap my head around, but maybe this will help track down those first two problems.

Related: #226 #227

Also yeah typically it is more useful to have separate PRs that contain only the changes necessary to repro the issue but just having a repro at all is helpful. :)

authors: jmatsushita nolanlawson

repo: pouchdb/pouchdb-server


text:
urllib.error.HTTPError: HTTP Error 401: Unauthorized

weather widget not working.

Maybe you need to get correct APPID first.

can you provide an example of a proper setting for
"weather": {
    "appid": 'what exactly goes here`
}

obviously you can omit your apikey, but formatting for reference on the top-level readme would be helpful

If you got the appid already, just put your addid only like this.
"appid" :  "xxxxxxxxxxxxxxxxxxxxxxxxxxx"
You can also check your appid by your web browser :
http://api.openweathermap.org/data/2.5/weather?q=seoul,KR&APPID=xxxxxxxxxxxxxxxxxxx
This is an example of response  :
{"coord":{"lon":127.14,"lat":37.44},"weather":[{"id":721,"main":"Haze","description":"haze","icon":"50d"}],"base":"stations","main":{"temp":297.19,"feels_like":297.11,"temp_min":296.15,"temp_max":298.15,"pressure":1013,"humidity":69},"visibility":9000,"wind":{"speed":4.1,"deg":230},"clouds":{"all":75},"dt":1591498475,"sys":{"type":1,"id":8096,"country":"KR","sunrise":1591474241,"sunset":1591527012},"timezone":32400,"id":1897000,"name":"Seongnam-si","cod":200}

authors: LukeGary462 almoce poucotm

repo: poucotm/Guna


text:
🛑 PowBot SDN is down

In 8cb0dfa, PowBot SDN (https://api.powbot.org/products) was down:

HTTP code: 502
Response time: 474 ms

Resolved: PowBot SDN is back up in 1bc2fea after 8 minutes.

repo: powbot/status


text:
vst@ --  saving/recalling parameters, plugin directories not working

specifically with envi loading/saving

This is fixed and has been tested by a couple other users.

authors: jpsteccato the-steech

repo: ppooll-dev/ppooll


text:
是否有人曾提过类似的问题
否（No）
升级到最新的版本是否存在这个问题
是（Yes）
是否已经查阅Wiki文档还未能解决的
是（Yes）
APP版本
v3.2.0
问题描述
不识别卡槽，转发的卡槽信息一律为SIM2
复现步骤
vivo x6d Android 5.1、Funtouch OS_2.5
是否必现
是（Yes）
出现问题的手机信息
vivo x6d
出现问题的安卓版本、系统版本
Android 5.1、Funtouch OS_2.5
提供截图或视频
No response
提供报错堆栈【请提供logcat抓取的日志，参考： https://blog.csdn.net/m0_64776928/article/details/126005119 】
No response
提供解决方案
No response

转发出去的信息 SubId 是多少？
先参考这个wiki设置一下对应关系
https://github.com/pppscn/SmsForwarder/wiki/1.通用设置

添加卡槽信息获取补偿机制,修复远程发短信指定卡不明确问题 #293
https://github.com/pppscn/SmsForwarder/pull/293
试试每周构建版

repo: pppscn/SmsForwarder


text:
adding multiple tap support

adding multiple tap support
documentation updated.

Sorry, I snuck in some changes before you wrote this. We now set a description for the tap device, showing iohyve ownership. See current implementation. (It's just iohyve-$name)
Also, it seems your txt2man run didn't work properly.
Please try:
cat iohyve.8.txt | txt2man -t iohyve -s 8 -v "FreeBSD System Manager's Manual" > iohyve.8

:octopus:

good idea the description.
i m deleting this PR and raising a new one


text:
Desempacotamento e conferência dos equipamentos do estúdio-Realeza

Essa tarefa tem como objetivo conferir os materiais que chegaram aos estúdios, bem como registrar seus referidos patrimônios para controle, é basicamente uma sequencia ao iniciado na #1185

[x] Conferir os equipamentos que estão no estúdio
[x] Registrar em planilha os seus referidos patrimônios
[x] Montagem inicial com o que há no estúdio
Aqui estão os materiais que devem conter nesse primeiro momento, registrar nessa issue se há falta de algum da lista abaixo e mais equipamentos necessários para necessidades básicas.

Quantidade
Material

01
Câmera Digital DSLR

01
Mesa digitalizadora

01
Kit de iluminação com tripé

01
Chromakey

01
Gravador de voz

01
Placa de conversão vídeo

02
Tripés

02
Fones de ouvido

02
Microfones de lapela

02
cabos HDMI 5m

02
cabos HDMI 10m

02
extensores HDMI

01
Televisor 50’’

01
Suporte para TV

01
HD externo (1GB)

02
Cartão de memória

02
Mesas

02
PCs

02
Cadeiras

A planilha deve seguir [esse modelo](https://docs.google.com/spreadsheets/d/1vPAayNl3i2JiUkdu0RrknKjl_0iOc6h5/edit#gid=1557128304)

Criei as pastas dessa issue no Google Drive:

 Pasta da issue
🔽 Entrada
🔼 Saída

Lembrar de adicioanar fotos dos estúdios na pasta dessa issue, bem como, comunicar o status sobre as autorizações para a entrada nas salas dos estúdios!

Ainda estamos sem autorização para poder utilizar os estúdios. Assim que liberado, nós iniciaremos essa tarefa.

Planilha preenchida;
Fotos enviadas;
Status da autorização: Ainda não temos autorização "plena".

Coloquei alguns comentários pertinentes na planilha

@amandasegattob te marcando para tu saber que teve atualizações nessa issue.

Essa issue estava aberta para colocarmos o que ainda faltava nos estúdios, porém como já sintetizei tudo e enviei para a Elis, acredito que podemos colocar novas atualizações na issue principal #1225.

authors: PracticeUFFSBot amandasegattob morgana-mo robisonjose

repo: practice-uffs/programa


text:
Method not found: int SQLitePCL.raw.sqlite3_bind_blob

The SQLite works just fine on Android phones. When I tried to upload a mobile application on an iOS phone I got the exception shown below. When the object was trying to be inserted or updated in the database this exception occurred. Based on my knowledge this exception appears when I updated Xamarin.iOS to version 15.0. I will appreciate it if someone helps me to solve the problem.
{System.MissingMethodException: Method not found: int SQLitePCL.raw.sqlite3_bind_blob(SQLitePCL.sqlite3_stmt,int,System.ReadOnlySpan1<byte>)   at SQLite.SQLiteCommand.BindParameter (SQLitePCL.sqlite3_stmt stmt, System.Int32 index, System.Object value, System.Boolean storeDateTimeAsTicks, System.String dateTimeStringFormat, System.Boolean storeTimeSpanAsTicks) <0x10ac37dc0 + 0x002e6> in <01c96d411fe34bd5940c99a56515582b>:0    at SQLite.PreparedSqlLiteInsertCommand.ExecuteNonQuery (System.Object[] source) <0x10c064d40 + 0x000fc> in <01c96d411fe34bd5940c99a56515582b>:0    at SQLite.SQLiteConnection.Insert (System.Object obj, System.String extra, System.Type objType) <0x10c060628 + 0x00178> in <01c96d411fe34bd5940c99a56515582b>:0    at SQLite.SQLiteConnection.Insert (System.Object obj) <0x10c05fbd0 + 0x00020> in <01c96d411fe34bd5940c99a56515582b>:0    at SQLite.SQLiteAsyncConnection+<>c__DisplayClass50_0.<InsertAsync>b__0 (SQLite.SQLiteConnectionWithLock conn) <0x10c05f9d8 + 0x0000e> in <01c96d411fe34bd5940c99a56515582b>:0    at (wrapper delegate-invoke) System.Func2[SQLite.SQLiteConnectionWithLock,System.Int32].invoke_TResult_T(SQLite.SQLiteConnectionWithLock)
at SQLite.SQLiteAsyncConnection+<>c__DisplayClass33_01[T].<WriteAsync>b__0 () <0x10c05f5d8 + 0x00032> in <01c96d411fe34bd5940c99a56515582b>:0    at (wrapper delegate-invoke) System.Func1[System.Int32].invoke_TResult()
at System.Threading.Tasks.Task`1[TResult].InnerInvoke () [0x0000f] in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/src/Xamarin.iOS/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:534
at System.Threading.Tasks.Task.Execute () [0x00000] in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/src/Xamarin.iOS/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2319
--- End of stack trace from previous location where exception was thrown ---

They claimed this was fixed in VS 2022 17.0.3, but it appears to still be happening in VS 2022 17.0.5.

They claimed this was fixed in VS 2022 17.0.3, but it appears to still be happening in VS 2022 17.0.5. Unfortunately there's no way to downgrade...

Also happening in VS 2022 17.1.0

Still happening on 17.1.2. Anyone have any solution or work-around for this?

Still happening on 17.1.2. Anyone have any solution or work-around for this?

You might be able to work around the issue if you force your project to use System.Memory, version 4.5.2. I've added it with NuGet to my project and the problem's gone.

I had the same error on my App, fiddling around with my models I found out it had something to do with the byte array (byte[]) data type, I modified my project to store the information on strings instead (not ideal, but it works), I prefered this insead of the System.Memory workaround

authors: BlueRaja Senso4sLab catapedamania hugomr89 kkppstudios nemekzg

repo: praeclarum/sqlite-net


text:
Fix typo in graph analysis example

I have not run the example to verify the fix.

Good catch @rfdonnelly, thanks for the PR and fix!

authors: jhejderup rfdonnelly

repo: praezi/rust


text:
Role based access control

Let us set-up login group for various category to manage permission better and grant access to different category with specific rights.
Ex-
Developer-R-W
Developer-RO
Admin
User

Hi Prafull,
I have created the below logins group and users. so we need to add the members in only AD group login, we don't need to create the new logins and users, also it will be standard and easy to manage the permission on group instead of particular users.
List of logins and users that created

ePanchayatAdmin => Granted full access (DDL, DML ,Read)
ePanchayatAppUser=> Granted read and write access ( DML ,Read)
ePanchayatDeveloper_R_W=> Granted read and write access ( DML ,Read)
ePanchayatDeveloper_Read_only=> Granted only read access (Read)

@RiteshKolhe - This will be good to start. Will you please submit your changes and raise pull request?

I have raised the PR with the db script changes, please check once.
https://github.com/prafullmaru/ePanchayat/pull/41

authors: RiteshKolhe prafullmaru

repo: prafullmaru/ePanchayat


text:
Addition of dependabot.yml file

We need to add dependabot.yml file as it helps us to keep our dependencies up to date. Every day, it checks your dependency files for outdated requirements and opens individual PRs for any it finds.
@pranjay-poddar  please assign me this issue under gssoc'23.

It is already present

authors: DivyanshiNarang pranjay-poddar

repo: pranjay-poddar/Dev-Geeks


text:
#2854 New Login signup page

Title and Issue number
#2854  login page
Close #2854
Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[] I have created a helpful and easy to understand README.md

@MohitGupta121  please review this PR under GSSoC'23

@MohitGupta121  I have created a new PR #2910  by making the changes. Please review that PR and please close this one


text:
Convert Manage Bootcamps Page from HTML to React

manage-bootcamp.html

Fixed by #81

authors: AkankshShigwan prasadhonrao

repo: prasadhonrao/devcamper


text:
🛑 Natural Language <2> SQL Query is down

In 87d9b33, Natural Language <2> SQL Query (https://natural-language-2-sql-queries.onrender.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Natural Language <2> SQL Query is back up in 91367e0 after 12 minutes.

repo: prateekralhan/status


text:
[Issue-481] Row-based router cannot be specified on non-null field

Signed-off-by: zhongle.wang zhongle_wang@dell.com
Change log description
In the new table sink, the non null fields cannot be specified as a routing key filed.
It is caused by the check
checkArgument(DataTypes.STRING().equals(fieldTypes[keyIndex]), "Key field must be of type 'STRING'");

Comparing on DataType level is not correct in this case, we need to check if the logical type root is CHAR or VARCHAR to determine if it is a string or not.
Purpose of the change
Fixes #481
What the code does
Check the type's root so both string and other string-like type like CHAR and VARCHAR could pass the check.
How to verify it
./gradlew clean build passes.

Remove the <p> in EventTimeOrderingFunction

repo: pravega/flink-connectors


text:
Registry aliases?

I'm working on a PR for js.spec and am short some unit testing coverage. Istanbul showed me a branch in registry.get() that is not tested:
export function get(id) {
  const s = REGISTRY[id]
  if (typeof s !== 'symbol') {
    return s
  }
  return get(s)  // <-- here is the untested branch
}

My interpretation of this code is that one could define an alias symbol for another Spec's symbol, and then use either symbol to fetch the defined spec. I have a test that looks like this:
    it("defines an alias to another defined spec and gets the aliased spec back", () => {
      const id = Symbol()
      const spec = {}
      define(id, spec)
      const alias = Symbol("alias")
      define(alias, id)
      const actual = get(alias)
      expect(actual).to.equal(spec)
    })

This test fails with:
TypeError: Cannot create property 'name' on symbol 'Symbol()'
    at define (lib/registry.js:19:3)
    at Context.<anonymous> (test/registry.test.js:20:7)

The problem is the second define(alias, id) call; define() assumes that spec is not a symbol and sets the name property.
Am I misinterpreting the purpose of Symbol values in Registry? How would I even define such a thing?

Damnit, I knew this spec.name would bite me. The line in registry.get is actually unrelated to the registry; the registry does/should not care about a spec's name, it only needs an ID to look up.
What you describe is correct, get should allow for aliases. The use of symbols itself is a recommendation to have guaranteed unique IDs and make accidentally overwriting a spec of another module very hard.
Two possible solutions:

check in define if we define an alias and don't set name then
allow to set name explicitly by user, fall back to default name like in current toString implementations

I'd rather have the second, what do you think?

I am not sure what the value of 'name' is; it doesn't exist in clojure.spec. Symbol is close enough to clojure keyword to be the main naming concept the users will need. The fantastic thing about Symbol is that it provides a clear way to find a named spec anywhere in the app in a manner similar to a clojure keyword: registry.get(Symbol.for("beach/blanket")).
It seems the main value of name is in explain output. In that case I would be interested in the registry symbol being explicitly called out; storing it in name is ambiguous. Did I set the name when I constructed the spec or did it get set when I defined it in the registry?

Another problem with define() is that it overwrites any existing name value on the spec.
Name value aside, my proposed fix to define() is this:
  if (!spec.name && typeof spec !== "symbol") {
    spec.name = getName(id)
  }

This preserves existing behaviour (autonaming spec from symbol) without throwing errors trying to set symbol.name. It doesn't make sense to name a symbol anyways. It also fixes the issue where the name is not overwritten.

I am not sure what the value of 'name' is; it doesn't exist in clojure.spec

Useful explain output, as you guessed, is pretty much the only reason why it's there. In Clojure I could just print the symbol (as in "variable name") itself, but not in JS.

In that case I would be interested in the registry symbol being explicitly called out; storing it in name is ambiguous.

Naming is hard :grin:

Did I set the name when I constructed the spec or did it get set when I defined it in the registry?

The latter. But I could imagine allowing to provide a name when the spec is constructed, then setting in define() when it's not there.

Another problem with define() is that it overwrites any existing name value on the spec.

I don't think it's too much a problem, since it's not part of a specs public API.

Closing due to #21

authors: mattbishop prayerslayer


text:
Concert bid adapter not featured on downloads list

Oddly it appears as though our Concert adapter (available in previous releases) has disappeared from the https://docs.prebid.org/download.html page, yet is still on https://dev.prebid.org/download.html
I see however that its still in both repos though, any idea on the inclusion / compile here?

This was fixed last week

authors: bretg bsheldon


text:
Default config (emoji.yaml) fails to converge

Hey, thanks so much for the code release. Really excited about the potential of this project.
I think the default config might have some incorrect hyper parameters? After 300-400 epochs I'm still not seeing the model able to reconstruct the emoji dataset.
Any guidance on what parameters to use would be appreciated. I tried what was suggested in  https://github.com/preddy5/Im2Vec/issues/5 but did not see an improvement.

Hey @evancasey
This tends to happen with high learning rates, could you try decreasing the learning rate https://github.com/preddy5/Im2Vec/blob/master/configs/emoji.yaml#L23 to 0.0001 and see if the changes anything.

I'm starting to see better results after reducing LR to 0.0001, however it takes much longer to train. Would you suggest tuning LR some more or are there any other parameters that come to mind?

)

After 2000 epochs it still does not converge

Hey @evancasey I think you might have to tune the LR a bit, could you try 0.0002 maybe, also increasing https://github.com/preddy5/Im2Vec/blob/master/configs/emoji.yaml#L8 the radius helps with the initial part of the optimization maybe try 20. Hopefully, this helps with the optimization.

Same here. Tried everything. Almost 3000 epochs and it still does not converge.
There are 3 logical possibilities:
1 - The code in this repository is not the one used in the paper (i.e. notebooks?)
2 - There is a secret way to tune those parameters with a separate tool/script
3 - The results in the paper are made up
Excluding the third, both the 1st and the 2nd explanations are easy to solve.
You just need to merge/add the source code of the notebook or of the tool with this repo.
Are you still under deadlines? I hope you will find a moment to fix this. This is an important work.
Thanks. 👍

Hey @Emasoft
There are many reasons why the network might not have converged when you train it.
The repo includes an example training run please use that for debugging your training. For each new training run, the code also creates a copy of the training code in the log directory, so the example training run also contains a backup of the code used for that specific training and trained weights, you can use them for debugging as well.
Hope that helps.

authors: Emasoft evancasey preddy5


text:
Duplicate entries in lock file (from examples)

Checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

Issue description
I just checked out the examples and noticed:
https://github.com/prefix-dev/pixi/blob/944094e682f4cef5dff7d54094fc937dd6d90dcc/examples/jupyterlab/pixi.lock#L11576-L11621
Expected behavior
No duplicated entries.

Oops, my bad. I see only now that they are for different platforms. Sorry for the noise.

repo: prefix-dev/pixi


text:
🛑 Secret Site is down

In 3aae9ce, Secret Site ($SECRET_SITE) was down:

HTTP code: 404
Response time: 294 ms

Resolved: Secret Site is back up in f35075a after 2 days, 12 hours, 14 minutes.

repo: premii/upptime


text:
Issues in documentation hindering options to work

The documentation in the readme is inaccurate
'presprog/auto-file-templates' should be 'presprog.auto-file-templates' (PluginOptions.php line 13 and elsewhere)
and the sub key 'auto-assign' does not work, since the plugin code looks for the string 'autoAssign' (as seen in PluginOptions.php line 16)
I was wondering why the hook didn't trigger and found these two errors that rendered the given options useless :)

Hi @milesleif
thank you very much for taking the time to open this issue! At least it was correct in the unit tests 😅
I updated the readme accordingly.
Best
Benedict

authors: bezin milesleif

repo: presprog/kirby-auto-file-templates


text:
Unable to decode JWK response from Azure JWK

Current jwt authenticator fails with following stack trace if set http-server.authentication.jwt.key-file to https://login.microsoftonline.com/TENANT_ID/discovery/v2.0/keys
Relevant Discussion on slack: https://prestosql.slack.com/archives/CGGL0EZ9N/p1607500620014400
Caused by: java.lang.RuntimeException: Unable to decode JWK response from https://login.microsoftonline.com/TENANT_ID/discovery/v2.0/keys
  at io.prestosql.server.security.jwt.JwkService.fetchKeys(JwkService.java:149)
  at io.prestosql.server.security.jwt.JwkService.<init>(JwkService.java:69)
  at io.prestosql.server.security.jwt.JwkService.<init>(JwkService.java:60)
  at io.prestosql.server.security.jwt.JwkService$$FastClassByGuice$$13916454.newInstance(<generated>)
  at com.google.inject.internal.DefaultConstructionProxyFactory$FastClassProxy.newInstance(DefaultConstructionProxyFactory.java:89)
  at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
  at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
  at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:98)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:112)
  at io.airlift.bootstrap.LifeCycleModule.provision(LifeCycleModule.java:54)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:120)
  at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:66)
  at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:93)
  at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
  at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
  at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
  at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
  at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
  at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
  at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
  at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
  at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:98)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:112)
  at io.airlift.bootstrap.LifeCycleModule.provision(LifeCycleModule.java:54)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:120)
  at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:66)
  at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:93)
  at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
  at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:62)
  at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
  at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
  at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
  at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
  at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
  at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
  at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
  at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:98)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:112)
  at io.airlift.bootstrap.LifeCycleModule.provision(LifeCycleModule.java:54)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:120)
  at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:66)
  at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:93)
  at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
  at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:62)
  at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
  at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
  at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
  at com.google.inject.internal.RealOptionalBinder$JavaOptionalProvider.doProvision(RealOptionalBinder.java:279)
  at com.google.inject.internal.RealOptionalBinder$JavaOptionalProvider.doProvision(RealOptionalBinder.java:240)
  at com.google.inject.internal.InternalProviderInstanceBindingImpl$Factory$1.call(InternalProviderInstanceBindingImpl.java:120)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:112)
  at io.airlift.bootstrap.LifeCycleModule.provision(LifeCycleModule.java:54)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:120)
  at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:66)
  at com.google.inject.internal.InternalProviderInstanceBindingImpl$Factory.get(InternalProviderInstanceBindingImpl.java:115)
  at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
  at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
  at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
  at com.google.inject.internal.ConstructorInjector.access$000(ConstructorInjector.java:32)
  at com.google.inject.internal.ConstructorInjector$1.call(ConstructorInjector.java:98)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:112)
  at io.airlift.bootstrap.LifeCycleModule.provision(LifeCycleModule.java:54)
  at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:120)
  at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:66)
  at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:93)
  at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
  at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
  at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
  at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
  at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:62)
  at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
  at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
  at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
  at com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(InternalInjectorCreator.java:213)
  at com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:184)
  at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:111)
  at com.google.inject.Guice.createInjector(Guice.java:87)
  at io.airlift.bootstrap.Bootstrap.initialize(Bootstrap.java:276)
  at io.prestosql.server.Server.doStart(Server.java:111)
  at io.prestosql.server.Server.lambda$start$0(Server.java:73)
  at io.prestosql.$gen.Presto_345____20201210_072203_1.run(Unknown Source)
  at io.prestosql.server.Server.start(Server.java:73)
  at io.prestosql.server.PrestoServer.main(PrestoServer.java:38)
Caused by: java.lang.IllegalArgumentException: Invalid JSON string for [simple type, class io.prestosql.server.security.jwt.JwkDecoder$Keys]
  at io.airlift.json.JsonCodec.fromJson(JsonCodec.java:137)
  at io.prestosql.server.security.jwt.JwkDecoder.decodeKeys(JwkDecoder.java:47)
  at io.prestosql.server.security.jwt.JwkService.fetchKeys(JwkService.java:146)
  ... 82 more
Caused by: com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.lang.String` out of START_ARRAY token
 at [Source: (String)"{"keys":[{"kty":"RSA","use":"sig","kid":"kg2LYs2T0CTjIfj4rt6JIynen38","x5t":"kg2LYs2T0CTjIfj4rt6JIynen38","n":"yTKa6m5GFOllz7oIHFCkvRJoBv7wLMuKIPLHbFGh5yOiO8o3akoqMhf1x6MxINGhZo6dkIrhVlVfWJhEJZPVaQdvyvVmlIZruhcbz3PGMqPAbjq2JqbB1mMnsyGHx-ovP0Cm5xj8sgI8wm67p3nosqzqFvg6mPKVO-w1QBr5seDU2AwU2DR88LF2v03Zjgn4mGvPdUOXihTQoNlf-nJFduXMDyRgZabnR2HlYHhagHwy1beWW1WtEaPz8iBN_0bGkGw705aDBUHJkdTty1mzsCZRur_n0imqXu9IzoSyiq5d0yKrRA5xkA-K3DMeRMquZ5QvPT9Eee4EZfFL97zBfQ","e":"AQAB","x5c":["MIIDBTCCAe2gAwIBAgIQQiR8gZ"[truncated 4262 chars]; line: 1, column: 473] (through reference chain: io.prestosql.server.security.jwt.JwkDecoder$Keys["keys"]->java.util.ArrayList[0]->java.util.LinkedHashMap["x5c"])
  at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:59)
  at com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1445)
  at com.fasterxml.jackson.databind.DeserializationContext.handleUnexpectedToken(DeserializationContext.java:1219)
  at com.fasterxml.jackson.databind.deser.std.StdDeserializer._deserializeFromArray(StdDeserializer.java:714)
  at com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:40)
  at com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:10)
  at com.fasterxml.jackson.databind.deser.std.MapDeserializer._readAndBindStringKeyMap(MapDeserializer.java:527)
  at com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:364)
  at com.fasterxml.jackson.databind.deser.std.MapDeserializer.deserialize(MapDeserializer.java:29)
  at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:286)
  at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:245)
  at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:27)
  at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:530)
  at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrapping(BeanDeserializer.java:528)
  at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:417)
  at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1292)
  at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:326)
  at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:159)
  at com.fasterxml.jackson.databind.ObjectReader._bindAndClose(ObjectReader.java:1719)
  at com.fasterxml.jackson.databind.ObjectReader.readValue(ObjectReader.java:1261)
  at io.airlift.json.JsonCodec.fromJson(JsonCodec.java:134)
  ... 84 more

As far as I know, this is happening because of this line of code. https://github.com/prestosql/presto/blob/f72fadfc814906f1ceb182f984281878b6b5b861/presto-main/src/main/java/io/prestosql/server/security/jwt/JwkDecoder.java#L161
The map of the key is defined as <String, String> but the JWT has a key with an array of string for key x5c.
This can be confirmed from this response as well. https://login.microsoftonline.com/common/discovery/keys
I would like to work on this issue. With some help from @dain

repo: prestosql/presto


text:
Add support for inserts into partitioned bucket tables

removing check since the inserts into partitioned buckets are supported
adding specific test to capture this behaviour
removing repeated verification of failing inserts, as it's covered b a separate test right now
updating products tests to simulate new behaviour

Lgtm % Travis green tick and lgtm from findepi

@cla-bot check

Merged, thanks!

authors: findepi kokosing s2lomon


text:
🛑 PrevHelp Ticket System is down

In fddf72c, PrevHelp Ticket System (https://support.prevhelp.de/api/v1/monitoring/health_check?token=$ZAMMAD_TOKEN) was down:

HTTP code: 200
Response time: 241 ms

Resolved: PrevHelp Ticket System is back up in 2d3e28f.

repo: prevplan/prevhelp-status


text:
Core: Html5ContextFactory for removing type="text/javascript"

See original PF ticket: https://github.com/primefaces/primefaces/issues/4135
All JSF resources get loaded with script type="text/javascript"
Which if you run through W3C validator at https://validator.w3.org/ it generates this:

@OBreidenbach has provided an Html5ResponseWriter to strip these out I am going to add here so people can also use it if they like.
faces-config-xml:
<faces-config>
    <factory>
        <faces-context-factory>org.primefaces.extensions.application.Html5ContextFactory</faces-context-factory>
    </factory>
</faces-config>

Linking: https://github.com/jakartaee/faces/issues/1565


text:
add missing key emptySearchMessage using emptyFilterMessage

key emptyFilterMessage is depreacted (prime vue, 3.7)
Used the value for emptyFilterMessage but the key wasn't deleted.

I am hesitant to delete anything that may be used in PrimeReact or PrimeFaces etc.  I need to check on this.

repo: primefaces/primelocale


text:
Add fa locale.

Added Farsi locale for Persian language.

@b4rdia Is there any way I could get you to do a Farsi translation for PrimeFaces?  We have one but its old and basic.
In PrimeFaces we have two files to translate a client side and server side translation. Below are the two English full translations:
Client: Client English JS File
Server: Server English Properties File
I know its asking a lot but the PF community would really appreciate it!

Yeah, I'd be happy to.

Thank you!  You can either paste me the files and I can submit the PR or however you want to do it.

@melloware Just submitted the PR for translations.


text:
error when integrating collaborators

Please add as much information as possible to help us reproduce the issue.
when I enter collaborators, it sends an email that redirects to Create account after the passwords are entered and the Create account button is clicked, it throws an internal error 500

I can't reproduce this - when I invite an email address and they enter their email and click 'Create account' it goes through without issue. Could you try inviting a different email address (maybe a gmail account or a temporary email from https://temp-mail.org/en)? Also - can you see the error logs in Vercel or wherever you're hosting your primo server?

we just made a test, this is the error we're having
TypeError: Cannot read properties of null (reading 'id')
at default (file:///var/task/.svelte-kit/output/server/entries/pages/auth/set-password/_page.server.js:9:75)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async handle_action_request (file:///var/task/.svelte-kit/output/server/index.js:443:18)
at async render_page (file:///var/task/.svelte-kit/output/server/index.js:1880:23)
at async resolve (file:///var/task/.svelte-kit/output/server/index.js:2645:24)
at async Object.handle (file:///var/task/.svelte-kit/output/server/chunks/hooks.server.js:17:20)
at async respond (file:///var/task/.svelte-kit/output/server/index.js:2531:22)
at async Server.default (file:///var/task/.svelte-kit/vercel-tmp/index.js:47:3)
at async Server. (/var/task/___vc/__launcher/bridge-server-DRMDGSVU.js:1:9199)

Hey there, I've been testing Primo and I've been encountering the exact same issue when attempting to invite either site or primo collaborators. I encounter this both when attempting to add a collaborator through the "Invite Server Member" menu on the top right or adding a site collaborator through the collaborators button and subsequent "Invite Site Collaborator" menu.
Tested with multiple different email addresses, They are able to access the sign-up page and set a password but Vercel reports an Internal Server Error before the password is actually set in Supabase.
Here are screenshots showing the issue from a collaborator and what it looks like on my end with Vercel logs:

I hid some of the info like host names and account names for personal reasons but those probably won't interfere with the bug report itself.
I hope this information proves to be beneficial with troubleshooting and I'm glad that I'm not the only one who has encountered that. My guess is that it may possibly be to do with Vercel as a hosting provider rather than Primo or Supabase on their own but I'm still pretty new with this stuff in general and I still need to set up SMTP for Supabase email as I'm excited to have team members onboard with using these tools and resources.

@GreenerLeaf thanks for the info. There's a big update coming which should help address some of the collaborator issues, but I don't have a timeline yet.

I have exactly same issue in a clean install in latest version.
@mateomorris is there any workaround for this? it seems Primo is unusable if this bug exists

authors: GreenerLeaf estefany00170 jalberto mateomorris

repo: primocms/primo


text:
Does it only support Python?

Describe the issue
When I try to run it I get
Error: Install command failed to execute successfully: Obtaining file:///Xylon2__todefer ERROR: file:///Xylon2__todefer does not appear to be a Python project: neither 'setup.py' nor 'pyproject.toml' found.
My project is not Python it's Clojure.
Optional: Relevant documentation page
No response

If it only supports Python perhaps you could mention that in the README?

I'm honestly surprised that it tried to run pip install or something. What command did you run?  As discussed in #53, it should probably be still possible to run on a different language, even though some helpful tools (like the linting) will not be enabled.

If you believe there is a bug, please open a bug report and I can investigate (I have tried but could not reproduce your error, unless you directly specified --environment_setup with a python setup script).

OK I tried again and it worked. Not sure what happened before.

Great to hear that & thanks for checking :)  @Xylon2

repo: princeton-nlp/SWE-agent


text:
Support parallel testing with pytest-xdist

Currently some tests will break because of the multithreading.
Reproduce:
pip install pytest-xdist
pytest -n auto

Mira que me siento solo y el tiempo aquí se detiene

Thanks for your interest @aksh16. This has now been fixed with swe-agent 1.0.


text:
[BUG]white cubes in the scene

Describe the bug
Why is there some cubes in the generated scene ? The following image was rendered with Blender 3.6:

Steps to Reproduce

What version of the code were you using? Tell us the output of git log -n 1
'''
commit 2c51a18971b07fa4b78d7b70af8a64709545ffa7 (HEAD -> main, origin/main, origin/HEAD)
'''

What command did you run?
546  $BLENDER -noaudio --background --python generate.py -- --seed 0 --task coarse -g forest simple --output_folder outputs/forest/coarse
547  $BLENDER -noaudio --background --python generate.py -- --seed 0 --task populate fine_terrain -g forest simple --input_folder outputs/forest/coarse --output_folder outputs/forest/fine\n
548  $BLENDER -noaudio --background --python generate.py -- --seed 0 --task render -g forest simple --input_folder outputs/forest/fine --output_folder outputs/forest/frames\n
549  $BLENDER -noaudio --background --python generate.py -- --seed 0 --task render -g forest simple --input_folder outputs/forest/fine --output_folder outputs/forest/frames -p render.render_image_func=@flat/render_image

What are your output logs?

Add your logs here, preferably from a job run with --debug

** (If this is your first time running Infinigen) What are the full output logs of install.sh ?**
Add your install.sh logs here

Platform

OS & OS Version: MacOS 13.4.1
GPU (?) : M1
GPU Driver Version (?) : ?
RAM (GB): 16

Additional context

Hello, these cubes are supposed to be placeholders for objects that are not visible and did not get populated, but there seems to be some kind of rare bug that causes this. I will patch a temporary fix soon

I added a bandaid fix in a28da5a to at least hide the cubes, doesnt yet fix the underlying cause for why they arent being populated, will revisit hopefully for v1.0.2

authors: araistrick jgranie

repo: princeton-vl/infinigen


text:
Multiplication by percent sign is counterintuitive (affects the resulting unit)

On fend version 1.0.4
> # user probably expects this to report 0.4 kg
> 8 kg * 5%
40 kg %
> 8 kg * (5%)
40 kg %
> (8 kg) * (5%)
40 kg %
> (8 kg) * 5%
40 kg %
> # this is the correct way to do this
> 8 kg * 5% to kg

It appears treating percentages as units is intentional (based on commit 5fd98000529ab38c785ab35dfab4263e7ee509c5).
However, the fact the "%" affects the resulting unit was very surprising to me (it makes sense for radians).
Is there an easier/shorter way to write "8 kg * 5% to kg" (or could you ad one)?
Even better, could we change the default behavior of multiplying by percentages to automatically return back to the original unit?

Thanks for the issue! You’re right, percentage units are definitely pretty weird. I’ll take a look at how to try and fix this.

Fixed in #165

The percentage calculation here is quite strange.
$ qalc 90+10%
90 * (110 * percent) = 99

$ kalker 90+10%
99

$ fend 90+10%
90.1

authors: Techcable printfn sergeevabc

repo: printfn/fend


text:
fix: correct grammar

Describe this PR
Correct the grammar in the documentation.

Thanks for catching this @Dhoni77 🙏

repo: prisma/docs


text:
Error in VS Code extension: "Connection to server got closed. Server will restart."

The VS Code extension doesn't work for me in my .prisma files any more.
The OUTPUT tab in VS Code shows the following errors:
[Info  - 2:44:34 PM] Default version of Prisma binary 'prisma-fmt': 3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:34 PM] Extension name @prisma/language-server with version 2.17.0
[Info  - 2:44:34 PM] Prisma CLI version: 2.17.0
[Info  - 2:44:34 PM] Local prisma-fmt path: /Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/@prisma/language-server/dist/src/prisma-fmt.3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:34 PM] Downloading prisma-fmt from https://binaries.prisma.sh/all_commits/3c463ebd78b1d21d8fdacdd27899e280cf686223/darwin/prisma-fmt.gz
[Info  - 2:44:39 PM] Connection to server got closed. Server will restart.
[Error - 2:44:39 PM] Request textDocument/formatting failed.
Error: Connection got disposed.
	at Object.dispose (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/main.js:904:25)
	at Object.dispose (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-languageclient/lib/client.js:74:35)
	at LanguageClient.handleConnectionClosed (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-languageclient/lib/client.js:2309:42)
	at LanguageClient.handleConnectionClosed (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-languageclient/lib/main.js:155:15)
	at closeHandler (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-languageclient/lib/client.js:2296:18)
	at CallbackList.invoke (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/events.js:62:39)
	at Emitter.fire (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/events.js:121:36)
	at closeHandler (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/main.js:240:26)
	at CallbackList.invoke (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/events.js:62:39)
	at Emitter.fire (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/events.js:121:36)
	at IPCMessageReader.fireClose (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/messageReader.js:111:27)
	at ChildProcess.<anonymous> (/Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/vscode-jsonrpc/lib/messageReader.js:213:45)
	at ChildProcess.emit (events.js:327:22)
	at maybeClose (internal/child_process.js:1021:16)
	at Socket.<anonymous> (internal/child_process.js:443:11)
	at Socket.emit (events.js:315:20)
	at Pipe.<anonymous> (net.js:674:12)
[Info  - 2:44:39 PM] Default version of Prisma binary 'prisma-fmt': 3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:39 PM] Extension name @prisma/language-server with version 2.17.0
[Info  - 2:44:39 PM] Prisma CLI version: 2.17.0
[Info  - 2:44:39 PM] Local prisma-fmt path: /Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/@prisma/language-server/dist/src/prisma-fmt.3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:39 PM] Connection to server got closed. Server will restart.
[Info  - 2:44:39 PM] Default version of Prisma binary 'prisma-fmt': 3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:39 PM] Extension name @prisma/language-server with version 2.17.0
[Info  - 2:44:39 PM] Prisma CLI version: 2.17.0
[Info  - 2:44:39 PM] Local prisma-fmt path: /Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/@prisma/language-server/dist/src/prisma-fmt.3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:39 PM] Connection to server got closed. Server will restart.
[Info  - 2:44:39 PM] Default version of Prisma binary 'prisma-fmt': 3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:39 PM] Extension name @prisma/language-server with version 2.17.0
[Info  - 2:44:39 PM] Prisma CLI version: 2.17.0
[Info  - 2:44:39 PM] Local prisma-fmt path: /Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/@prisma/language-server/dist/src/prisma-fmt.3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:39 PM] Connection to server got closed. Server will restart.
[Info  - 2:44:40 PM] Default version of Prisma binary 'prisma-fmt': 3c463ebd78b1d21d8fdacdd27899e280cf686223
[Info  - 2:44:40 PM] Extension name @prisma/language-server with version 2.17.0
[Info  - 2:44:40 PM] Prisma CLI version: 2.17.0
[Info  - 2:44:40 PM] Local prisma-fmt path: /Users/nikolasburk/.vscode/extensions/prisma.prisma-2.17.0/node_modules/@prisma/language-server/dist/src/prisma-fmt.3c463ebd78b1d21d8fdacdd27899e280cf686223
[Error - 2:44:40 PM] Connection to server got closed. Server will not be restarted.

I also see these notifications pop up in the bottom right of VS Code:

Note that running prisma format on the Prisma schema does work.

Looks like a duplicate of https://github.com/prisma/language-tools/issues/675

repo: prisma/language-tools


text:
Confusing transaction semantics in Postgres migrations

Bug description
Hi there,
I wanna clarify the exact behavior of Postgres DDL migrations and their transactionality. I am opening this as a bug because I think it is, possibly docs related, but I think it terms of functionality also.
First, it's been reported, and continues to be the case in Prisma public documentation, that Prisma does not wrap Postgres migrations in a transaction (either implicitly, or via outputting a BEGIN and END to the generated script). This is a known case. However, I don't think it's true? Consider this example:
CREATE INDEX CONCURRENTLY "User_organizationId_idx" ON "User"("organizationId");
CREATE INDEX CONCURRENTLY "User_createdAt_idx" ON "User"("createdAt");

In this example, the migration will fail, with the Postgres error: cannot run inside a transaction block. This error is ONLY raised if the DDL migration was indeed running in a transaction. So, my first question is: which is it? Does Prisma run DDL migrations in a transaction or not?. I am running 5.6.0.
My own interpretation is that Prisma is checking the arity of the statements: if its just one statement, no transaction, but if there are more than one, then it's wrapped in a transaction. And indeed, if I change the migration above to ONLY have one concurrent index created, it passes. This is problematic on two fronts:

It's at odds with the documentation and various answers from Prisma employees.
It breaks for all non-transactional DDL statements, like creating indexes concurrently.

For instance, doing:
-- Basically any statement you want here (SET lock_timeout, SET statement_timeout; even VACUUM)
CREATE INDEX CONCURRENTLY "User_createdAt_idx" ON "User"("createdAt");

will fail, because Prisma decides this is two statements and wraps it in a transaction. Again, wrong on two fronts: not what the doc says, but more importantly, does not allow creating indexes concurrently with some safe SET choices plugged in. An example additional statement can be setting a lock_timeout, such as SET lock_timeout = '30s'. This is common for traffic heavy application that want to run migrations but not to the point where it hogs locks. Other applications might choose to do SET statement_timeout, or any other thing they want to run before the creating of indexes concurrently, which does not apply to the transaction because there are not any, but because they want to attach certain behavior to the connection (such as "please don't run for longer than 30 seconds").
Starting from the basics, can you confirm that it is indeed the code's behavior that whether a migration is transactional or not depends on the statement count of the migration? If so, it seems to me like that might be fundamentally wrong because it rules out any statement combinations that include non-transactional statements, which is a very big deal to us.
Thanks :)
How to reproduce
See description above.
Expected behavior
No response
Prisma information
None. Pretty self-explanatory.
Environment & setup

OS: Mac OS.
Database: Postgres 15.
Node.js version: 20.

Prisma Version
5.6.0

CREATE INDEX CONCURRENTLY is currently not supported: https://github.com/prisma/prisma/issues/14456

@janpio thanks for the response. That's not what this issue is about. I am are of the issue you linked, and alluded to that in my original post.
The main issue is that Prisma says it does not wrap Postgres migrations in transactions, but it sometimes does, based on how many statements are in the SQL migrations. This directly breaks a lot of innocent looking code like doing;
SET lock_timeout = '30s';
CREATE INDEX CONCURRENTLY....

This would not work, and again, for bad reasons. If it was true that Prisma does not wrap migrations in a transaction, this should have worked. And in fact, it DOES work, if you drop the SET lock_timeout = '30s';, and do only:
CREATE INDEX CONCURRENTLY....

which directly contradicts the comment you link to where you state that Prisma does not support CREATE INDEX CONCURRENTLY.. That is not true! Prisma supports CREATE INDEX CONCURRENTLY. as long as the statement arity is 1. If more than one statement, it fails. Which, to me, sounds like a bad bug. Prisma is wrapping the migration in a transaction somewhere when it says more than one statement where the docs explicitly say it doesn't.

I've collected further evidence of this problem. Here are some migrations that will clarify things, with notes:
One-statement migration, transactional statement only.
insert into foo values(1);

This migration is trivial. It will run like normal (I am using an insert just to show the idea, these are usually DDLs of course). Since it's only one statement, there is no point talking about transactions. Postgres will do an autocommit here which is to run the statement implicitly in a transaction.
Multi-statement migration, transactional statements only.
insert into foo values(1);
insert into foo values(2);

these, amazingly, are run in one transaction. Which means, Prisma IS wrapping the whole migration in a transaction. You can trivially confirm this was indeed one transaction by checking the hidden column xmin, which will show the same transaction ID, therefore, same transaction. So, while there is material online about Prisma not running things in a transaction in Postgres migration, this is false and should be corrected.
One statement migration, non-transactional statement only.
Such as:
create index concurrently on foo(a);

or even:
VACCUM;

both cannot run in a transaction, but these migrations are run successfully by Prisma, which means, these statements, unlike the above two insert example, are NOT wrapped in a transaction.
Two statement migration, non-transactional statements only.
create index concurrently on foo(a);
create index concurrently on foo(b);

This will fail. Again, why does it fail when a similar migration with only one index passed? Well, clearly, there is logic in Prisma (or a dependent library) that wraps statements inside a transaction if it sees more than one, making it statement arity dependent. This is the main reason why folks have complained to Prisma that "concurrent indexes" are not supported! It's because they add multiple indexes at once, which, again, has nothing to do with the fact that Prisma does not support concurrent indexes, rather, they added a multi-statement migration which was wrapped in a transaction, which will never work for concurrent indexes. Similarly:
VACUUM;
SELECT (1);

will also not work, again, nothing to do concurrent indexes, everything to do with confusing logic around statement arity.
So what to do?
Prisma must wrap Postgres migrations in a BEGIN ; END explicitly, like it does for SQL Server, and drop any logic that is doing the conditional transactionality based on arity. This will solve all the problems. If folks wanted to create 10 indexes concurrently, they can drop the BEGIN and END, and that's about it, it should work normally.

@janpio is this something your team can either confirm or give an update on? I think if you address this it will close a whole lot of issues (including the one you linked) and clear a lot of confusion among new Prisma users.

We unfortuantely do not give public ETAs. Thanks for opening the issue and providing this information, we will get to it as soon possible. Your investigation should help a lot with that.

no worries. :) Thanks for getting back to me.

Prisma supports CREATE INDEX CONCURRENTLY. as long as the statement arity is 1

I thought that was true for too long until I wrote a migration script with a single statement split into multiple lines. It failed to run because Prisma attempted to run it inside a transaction. It seems that it's correct to say "as long as the line arity is 1" instead.

Should be fixed. One-line migrations are not a solution but seems to work... So queries are being wrapped somewhere see @why-el 's post.

authors: janpio leppaott mateuspiresl why-el

repo: prisma/prisma


text:
Case sensitivity issue on Mysql during Introspection

If you have very similar names for tables / columns in your db all MySQL versions except MySQL 8 can produce wrong introspection results. Sample schema:
model ADDRESS {
   ADDRESSID Int @id
}

model Address {
  AddressID Int @id @default(autoincrement())
}

model address {
  addressid Int @id
}

This also causes the order of the models in the generated schema file to be random and changing with each time you run Introspection.


text:
fix(telemetry): fix Span instanciation

This PR aims at fixing a compatibility problem with dd-trace (and possibly other opentelemetry providers), the library provided by Datadog to instrument nodejs apps.
dd-trace is now compatible with opentelemetry by default and makes collecting opentelemetry data in Datadog a breeze. However, it uses it's own Provider / Span... implementation which doesn't work with the current prisma:engine:* Span implementation.
As stated in this issue, engines spans don't show up in the instrumentation. prisma:client:* spans do appear though.
It seems to be linked to the fact that the current implementation instantiate an @opentelemetry/sdk-trace-base Span, which is not picked up by Datadog.
Instead, I suggest to let the tracer create the Span as it's the only one that knows which type of Span it expects.
With this change, prisma:egine:* spans do pop in Datadog.
Sidenotes:

I have absolutely 0 experience with opentelemetry. Make sure to review thoroughly, even if it's a small change :)
with versions >5.0 of @prisma/instrumentation, the code completely breaks the dd-trace integration, as instanciating an opentelemetry sdk-trace-base Span calls code that doesn't work with a dd-trace tracer. Dd-trace tracer doesn't implement the getSpanLimits  method as they don't use it. So their Span constructor doesn't have this parentTracer.getSpanLimits() call. See the error below

TypeError: parentTracer.getSpanLimits is not a function
at new Span (/app/node_modules/@opentelemetry/sdk-trace-base/build/src/Span.js:59:41)
at Ki.createEngineSpan (/app/node_modules/@prisma/client/runtime/library.js:123:1600)
at pr.logger (/app/node_modules/@prisma/client/runtime/library.js:114:1093)
at /app/node_modules/@prisma/instrumentation/dist/ActiveTracingHelper.js:59:20
at ActiveTracingHelper.createEngineSpan (/app/node_modules/@prisma/instrumentation/dist/ActiveTracingHelper.js:44:27)
at Array.forEach (<anonymous>)
at /app/node_modules/@prisma/client/runtime/library.js:114:850

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

I think the current implementation in this PR doesn't propagate correctly the engineSpan.parent_span_id as it takes the parentSpanId from the active context in tracer.startSpan().
I will look into that.

So the parent_span_id is fixed. But there is one last (big) difference with the previous code: previously the spanId was forced with spanId = engineSpan.spanId. Which is not doable with startSpan().
It's probably the reason the tests fail => The child - parent relationship must be broken at some point

Closing as this PR is getting old and the proposed solution is not optimal.
I reckon a better way to solve this problem would be to send Rust spans not only when they end, but when they start as well. So that the spans could be properly created in TS land, keeping the parent / child relationship.

authors: CLAassistant Riron