text:
How can I debug a 404?

Running a bundle exec rake praxis:routes on my local machine, I see the following routes:

Version
Path
Verb
Resource
Action
Implementation
Name
Primary
Options

2.0
/api/v2.0/business_units/:id
GET
V2::ApiResources::BusinessUnits
show
n/a

yes

2.0
/api/v2.0/business_units/:business_unit_id/somministration_hours
GET
V2::ApiResources::SomministrationHours
index
V2::SomministrationHours#index

yes

2.0
/api/v2.0/auth/client_credential
POST
V2::ApiResources::Auth::ClientCredentials
client_credential
V2::Controllers::Security#client_credential

yes

2.0
/api/v2.0/auth/password
POST
V2::ApiResources::Auth::Password
password
V2::Controllers::Security#password

yes

But when I try to perform a valid request such as:
curl -i http://localhost:8888/api/v2.0/auth/password -X POST -d '{}'

or
curl -i http://localhost:8888/api/v2.0/auth/password\?client_id\=2189k0Bca7K883D8k1Ljxwk02KV9cCmv51u0TXO2eIYr5F82wjB0D6yOF5JGO5K8\&client_secret\=t8yn30f39P9yxqq4r8nO01m92jpv4Yx5Y3vX3ETquS679D23844ub9y8A7k8A5ov\&username\=knightq\&password\=87654321 -X POST -d '{}'

on the server side log the request arrives, and I see:
::1 - - [05/May/2016:16:55:34 +0200] "POST /api/v2.0/auth/password HTTP/1.1" 404 - 0.0039

and on the client side i get a:
HTTP/1.1 404 Not Found
Content-Type: text/plain
X-Cascade: pass
Transfer-Encoding: chunked
Server: WEBrick/1.3.1 (Ruby/2.3.1/2016-04-26)
Date: Thu, 05 May 2016 14:55:34 GMT
Connection: Keep-Alive

NotFound%

(?, = and & are escaped in the second example just because I'm using zsh...)
What's going wrong?
BTW, where can I find some documentation on praxis console?
I suspect that this tool could be very useful to inspect my issue...
Thank you and kudos for your great API framework!

What does the routing you've defined in your resource definitions look like?
Have you configured your app to use the path-based routing, along the lines of the way it's setup in the praxis-example-app's design/api.rb ?

For the first question, the resource is under design/v2/resources/auth/password.rb and looks like this:
module V2
  module Resources
    module Auth
      class Password
        include Praxis::ResourceDefinition

        version '2.0'

        prefix '/auth'

        media_type V2::MediaTypes::Auth::OAuth2BearerToken

        action :password do
          routing do
            post '/password'
          end

          params do
            attribute :client_id, String,
                      description: "Identificativo del client che richiede
                      l'accesso alle API",
                      regexp: /(\w|\d){64}/,
                      required: true
            attribute :client_secret, String,
                      description: "Password del client che richiede l'accesso
                      alle API",
                      regexp: /(\w|\d){64}/,
                      required: true
            attribute :username, String,
                      description: "Username dell'operatore in ePersonam.",
                      required: true
            attribute :password, String,
                      description: "Password dell'operatore in ePersonam.",
                      required: true,
                      min: 8
          end
          response :ok
        end
      end
    end
  end
end

Here is also the controller (under app/v2/controllers/auth/security.rb):
module V2
  module Controllers
    module Auth
      class Security
        include Base
        include Praxis::Extensions::Rendering

        # implements ResourceDefinitions::Posts
        implements V2::Resources::Auth::Password
        implements V2::Resources::Auth::ClientCredentials

        # POST /auth/client_credential
        def client_credential(**_params)
          response.headers['Content-Type'] = 'application/com.e-personam.oauth2_bearer_token'
          JSON.dump(V2::MediaTypes::OAuth2BearerToken.example.render(:default))
        end

        # POST /auth/password
        def password(**_params)
          response.headers['Content-Type'] = 'application/com.e-personam.oauth2_bearer_token'
          JSON.dump(V2::MediaTypes::OAuth2BearerToken.example.render(:default))
        end
      end
    end
  end
end

Just for completeness, I've tried another RESTful endpoint I have (GET /api/v2.0/business_units/:business_unit_id/somministration_hours) and it works properly.
The only difference here - besides the nesting - is that the controller is bind to a resource in a non RESTful manner, but there is no evidence on your documentation that this is not allowed.
That is, the resource I serve from the endpoint POST /api/v2.0/auth/password is a V2::MediaTypes::Auth::OAuth2BearerToken, while the controller is named Security and has non canonical RESTful actions on it.
However, it should be allowed, isn't it?
Anyway, for your second question: of course.
I suspect that the routes task wouldn't give me the routes I posted above if there were formal errors on it...
Here is my design/api.rb:
Praxis::ApiDefinition.define do |api|
  # Applies to all API versions
  api.info do
    name 'ePersonam API'
    title 'API per l\'interfacciamento alla cartella cloud ePersonam.'
    description 'TODO'
    version_with :path
    base_path '/api/v:api_version'
    consumes 'json', 'x-www-form-urlencoded', 'form-data', 'xml'
    produces 'json', 'form-data', 'xml'
  end

  # Applies to 2.0 version
  # Also inherits everything else form the global one
  api.info('2.0') do
    description 'Versione 2.0 delle API ePersonam'
  end

  api.response_template :resource_not_found do
    description 'The requested API resource could not be found for the provided :id'
    status 404
  end

  # Trait that when included will require a Bearer authorization header to be
  # passed in.
  api.trait :authorized do
    description "..."

    headers do
      key 'Authorization', String, regexp: /Bearer (\w|\d){64}/i, required: true
    end
  end

  api.trait :paginated do
    description "..."

    params do
      attribute :page, Integer, min: 1, required: false, default: 1
      attribute :per_page, Integer, min: 1, required: false, default: 20
    end
  end
end

Gotcha!
The problem is that - as far as it seems - a single controller cannot implement multiple resources...
Have a look at the app/v2/controllers/auth/security.rb controller:
        ...
        # The second declaration overrides the first one.
        # If I switch these two lines, the password endpoint starts to work,
        # but the client_credentials one breaks.
        implements V2::Resources::Auth::Password
        implements V2::Resources::Auth::ClientCredentials

I can surely split the controller, mapping it 1-1 with resources, but

How can I have in a single controller both the actions?

My hope would be to have a single security controller that handles both the password and the client_credentials endpoints, since both endpoints will return the same media_type (an OAuth2BearerToken).

(Let's bring back to the original issue): How can I debug routing issues for future cases.

Thank you very much again for your support!

@knightq sorry for being late to the thread...I somehow didn't get the GH notifications for it.
I just want to know if you had your questions answered or you still need help in
1- having 1 controller implementing 2 resources
2- and debugging your routing issue
I can tell you that for (1) I actually never tried it...so I'd have to try and see if the framework supports it (or what it would take to support it).
for (2) I'd have to see if you have defined the versioning scheme in your 'api.rb' (or equivalent) where you have the api.info configuration...
for example, have you defined the api to have something like this?
  version_with :path
 base_path '/api/v:api_version'

otherwise Praxis would be expecting the version through a header or an api parameter (since that's the default versioning scheme)
let me know

ok, so I have to take my time and actually read your questions better before answering too quickly...sorry about that :(
First of all, I just saw that you have already provided the information about the api.rb contents, so that's correct.
Now, I've looked really quickly about the "implements" supporting multiple definitions...and it is not that easy to make it work, since there are other "assumptions" that come from that linking. For example, some that just were very apparent as soon as I looked at the code:
1- A given controller has a default media-type (which comes from its resource definition). If you allow a controller to implement several definitions we'd have make sure we resolve any differences that they might have (and/or complain if they're not matching...)
2- Registering routes is also based on the actions defined by a controller's definition (which is assumed to be one at the moment). So that will certainly not do what you expect (only the actions of the latest "implement" will be registered when the app starts). Although the "routes" listing does use the definitions directly (because it assumes there's only 1 per controller) so it will "mistakenly" list the routes you expect, but they won't be all connected (that's why you're getting a 404). :(
4- Also there are some "implicit" assumptions about how to generate routes from a controller, which rely on the the concept of canonical_path of a resource. That is is bound to a given action name of the resource, so if a controller were allowed to have multiple definitions one would have to make sure the right one is used when there are multiple ones in play (by default it is "show" but can be overridden in the resource definition so it could potentially clash when there are several for the same controller).
...long winded way to say: it is not trivial to change a controller implementing multiple resource definitions. Not impossible, but it would make certain some common operations more complex...so I'm not sure it is worth it.
So my question to you is, if you really have 2 different API resources exposed...what is the specific reason you'd like to have 1 common controller for them? It certainly doesn't matter if both have the same default media_type....it is often the case the several controllers have the same MT. Is it a sharing code concern? or cleanliness? or...
PS: Also, as far as debugging 404's, well your case is special since you've just uncovered a bug (that's because the praxis routes command assumes a 1:1 relationship so it does not show the real mounted routes when the app starts)...so we'll have to fix that to make sure it always reflects reality.
If that bug wasn't there you'd have gotten a better error message from the framework.

Hi @blanquer, I'm really surprised about the understanding effort behind your answer, so, thank you very much to begin with.
Let's start saying that I've overcome my issues at the base of my two questions: splitting the two different implementation into two different controllers solved.
Question 1
I agree with you: it isn't worth it to implement this kind of flexibility. However, let me explain my case, to see if it is so unusual or not...
In my case, I just want to expose an API endpoint to fetch a valid BEARER token, through a OAuth2 authentication. The two authorization flow that I want to be exposed are:

the Resource Owner Password Credentials Grant
the Client Credentials Grant

in both these kind of authentication, the exactly same resource (from a media-type perspective) is returned, that is a JSON object so made:
{
  "access_token": "537qQVs061638GeDM3wr7Ode8lB7a2Csqh86xN7B0rIWYk46Wn29XgM6m468RE6w",
  "token_type": "bearer",
  "expires_in": 7200,
  "refresh_token": "2G18gxD97x51e9PccG387MG8nL06Yh2LQX953o6449H5516A64M4mkFZtF593b14"
}

I modelled it as a V1::MediaType::Auth::OAuth2BearerToken media-type object.
but, while to request a token with a Resource Owner Password Credentials a client of the API must give four attributes (client_id, client_secret, username and a password), to request a token with a Client Credentials flow only a client_id and a client_secret must be given.
AFAIK (but tell me if I'm wrong), I cannot specify - in a Praxis::ResourceDefinition - that a certain attribute is required conditionally to other actual attributes. In my case, to be able to have a single endpoint to serve both kind of authentication flows, I would need to declare something like this (have a look at the username and password require options):
    # design/v1/resources/auth.rb
    class V1::Resources::Auth
        include Praxis::ResourceDefinition

        version '1.0'

        prefix '/auth'

        media_type V1::MediaTypes::Auth::OAuth2BearerToken

        action :password do
          routing do
            post '/password'
          end

          attribute :auth_type, String

          payload required: true do
            attribute :client_id, String,
                      description: "Identificativo del client che
                        richiede l'accesso alle API",
                      regexp: /(\w|\d){64}/,
                      required: true
            attribute :client_secret, String,
                      description: "Password del client che richiede
                        l'accesso alle API",
                      regexp: /(\w|\d){64}/,
                      required: true
            attribute :username, String,
                      description: "Username dell'operatore in ePersonam.",
                      required: -> { |x| x.auth_type == 'password' } # username required only for password flow
            attribute :password, String,
                      description: "Password dell'operatore in ePersonam.",
                      regexp: /.{8,}/,
                      example: 'secret1!',
                      required: -> { |x| x.auth_type == 'password' } # password required only for password flow            response :created
          end
        end
      end

but since the require option is a boolean field (and does not accept a lambda), I cannot bind the requireness of these two payload attributes to the actual value of another attribute (auth_type).
So I splitted the single Auth resource in two:

V1::Resources::Auth::ClientCredentials, with just two payload attributes (both required).
V1::Resources::Auth::Password, with all the four payload attributes present and required.

The reason why I tried to implement both of these two authentication resources (that outputs the same resource type, a V1::MediaType::Auth::OAuth2BearerToken) into a single controller, is that it simply makes sense, since there should be (IMHO) a single controller with the responsibility to serve all the authentication flows.
Anyway, it is just a matter of taste: it looks just a bit uglier to me to have two controllers (and worst, two distinct items on the documentation) to serve as endpoint to authentication.

Question 2
Leaving apart the error message clarity you mention, facing my original issue I've found no way to intercept and debug a request to the API.
I found by chance the insight about the fact that the double implementation could be the origin of the problem, but I've not been able to put a debugger of a binding.pry inside any router class or something like that to follow the request dispatching and to imagine where the problem could be...
So for the future, an hook to debug or even just a detailed trace of what the router is doing to serve the request (besides the useful praxis:routes rake task) might be helpful!
Thank you again, hope this thoughts may help you to make praxis even better (I love it)!

Response to Question1
Thank you for the explanation, Now I understand exactly what you wanted to accomplish...and the fact that you had to have 2 different resource definitions because you need the exact same verb and path for both "actions".
So...you'll be happy to know that it is "indeed" possible to have conditional behavior for requirements. You an use the required_if: option. And there are a few things you can do with it. For example, in your case you'd need to do something like:
attribute :username, String,
          description: "Username dell'operatore in ePersonam.",
          required_if: { 'auth_type' => 'username'}
attribute :password, String,
          description: "Password dell'operatore in ePersonam.",
          regexp: /.{8,}/,
          example: 'secret1!',
          required_if: { 'auth_type' => 'password'}

you can use it in a few different ways IIRC. Some (possibly useless) examples, but so you get the gist:

required_if: 'auth_type'   # would be required if the attribute named auth_type has any value (i.e. has been passed in)
required_if: { 'auth_type' => 'exact_value' } # The example above (what you want to use). note that this works for any type object based on the type of 'auth_type' attribute.
required_if: { 'auth_type' => /foobar/ } # required if the value of auth_type (which must be a string type) matches "foobar"
you can also do powerful things like: attribute :foobar, String, required_if: '$.params.test'  # a given payload (BODY) parameter is required if the test param (URL) exists (or matches a value)...

Now, that being said, there is a reason we haven't documented this well...and that is because it is not something we've worked/maintained for a bit and since it's an advanced (and powerful) case...so it was left it a little bit under the covers. So...use with caution. (or help us revise that code :) )
Another possible option for you to explore..
is to use one of the requires.at_most(1).ofsyntax.
In other words, you could achieve a similar requirement having the password and the username attributes and saying that only 1 of the two can be passed in. that would render the auth_type attribute unnecessary. The syntax for that would be something like:
  attribute :client_id, String, ...
  attribute :client_secret, String, ...
  attribute :username, String, ...
  attribute :password, String, ...
  requires.at_most(1).of :username, :password

I hope all this helps :)
NOTE: both required_if AND this type of requirements above (at_most,at_least...) are NOT shown in the Doc browser (yet?) maybe @gampleman knows and/or has a better idea if that's planned (they already exists in the generated JSON...it's just a matter of the JS app to use them and display them properly in the web page).

Response to Question 2
That's a good idea. I've opened a "loose" issue request to think about it: https://github.com/rightscale/praxis/issues/291
Thank you for the feedback!!

Hi @blanquer, is this project still maintained? (at least) the documentation on:

requires.at_most(<cardinaliy>).of <attribute_name>
requires.at_least(<cardinaliy>).of <attribute_name>

should be released.
Can I help you on this?

Hi @knightq ,
Yes it is still very much maintained and in use by companies. There are a lot of new improvements that are coming, but there hasn't been time to properly test and document them...stay tuned for some of that hitting master soon.
And sure, you can totally help in documenting this! Feel free to create a PR for the doc branch and I'll review and merge it.
BTW, just to be clear, this functionality comes from the Attributor gem (but it is perfectly fine to document it in Praxis as well). Also, there are more things that are supported in the structs, in particular:

requires.all :attr1, :attr2 ...
requires.at_least(<num>).of :attr1, :attr2 ...
requires.at_most(<num>).of :attr1, :attr2 ...
requires..exactly(<num>).of :attr1, :attr2 ...
requires..exclusive :attr1, :attr2 ...

authors: blanquer careo knightq

repo: praxis/praxis


text:
ERROR  Missing "./nuxt" export in "pinia-plugin-persistedstate" package

Describe the bug
Using Nuxt 3 and "pinia-plugin-persistedstate": "^3.0.2", I get the error:
 ERROR  Missing "./nuxt" export in "pinia-plugin-persistedstate" package
It works fine if I use "pinia-plugin-persistedstate": "^2.4.0",.
Did something change with the way this works with Nuxt 3?
See reproduction of the error: https://stackblitz.com/edit/github-mqufck?file=plugins%2Fpersistedstate.ts
Reproduction
https://stackblitz.com/edit/github-mqufck?file=plugins%2Fpersistedstate.ts
System Info
System:
    OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor
    Memory: 15.64 GB / 23.44 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.12.1/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  Browsers:
    Chrome: 108.0.5359.124

Used Package Manager
pnpm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] The provided reproduction is a minimal reproducible of the bug.

Hi :)
The plugin now has a full nuxt integration with a proper nuxt module!
https://prazdevs.github.io/pinia-plugin-persistedstate/frameworks/nuxt-3.html
You can find here how to use @pinia-plugin-persistedstate/nuxt package. :)

Thanks! I tried removing my plugin and using the new module, but then my whole app refuses to load. It puts it into a state of constantly restarting the server. Not sure why, as I can't reproduce the error in StackBlitz. Will have to do some major debugging to figure out what module it's conflicting with, or some other plugin, or code.

Thanks! I tried removing my plugin and using the new module, but then my whole app refuses to load. It puts it into a state of constantly restarting the server. Not sure why, as I can't reproduce the error in StackBlitz. Will have to do some major debugging to figure out what module it's conflicting with, or some other plugin, or code.

Make you you only install the nuxt module, as it will install the plugin itself, maybe a clean node_modules install can help

Make sure you only install the nuxt module, as it will install the plugin itself, maybe a clean node_modules install can help

Well, it took a reboot of my machine, and re-cloning my repo, and then running pnpm install again and have it create a fresh lockfile - and now it works! Whew! Thanks for the suggestion.

source: gharchive/issue

authors: nathanchase prazdevs

repo: prazdevs/pinia-plugin-persistedstate

license: MIT

license_type: permissive

license_source: github-api


text:
RAD-1229 add docs for Custom CPM Bucket Sizing

(From 0.14 release)

@mkendall07 here's the PR for the custom CPM bucket sizing - is there any additional context/detail needed to use this other than what I've added?  (Which is basically what's in the 0.14 release notes)

OK, gonna merge since I'm pretty confident this is a good starting point - updates can happen in another issue.

source: gharchive/pull-request


text:
Sovrn: updated docs

tcf 2.0 support noted
gvlid added
supported user ID's updated

Just a note that the Prebid PR related to these docs changes was released in 4.13.0.


text:
Add a remove command

Add a command to remove a dependency from the project file. Basically the opposite of the add command.

can this be assigned to me

Note: It can be incredibly useful to be able to remove a package without removing any of it's dependencies. conda implements this with the --force flag which will then only remove the specified package from the environment.
Discussion in:

https://github.com/mamba-org/mamba/issues/412
https://github.com/mamba-org/mamba/issues/1523

@dhirschfeld I wonder what that would look like in our pixi.toml. When you use pixi remove python it would simply remove python from the [dependencies] (and co) table and then resolve and reinstall the environment.
The pixi.toml defines the source of truth, not the cli. You can always recreate the exact same environment from it (especially with a lockfile). So if you want to only install the dependencies of a certain package that should be specified in the pixi.toml. (Thats currently not supported).
If I read the usecase specified in the issues correctly I think you want to override a dependency of a project to be able to use a development version. We will most likely support this by overriding the source of a dependency:
my_dependency = { git = "some git repo URL" }
# or
my_dependency = { path = "../path_to_other_project" }
# or
my_dependency = { package = "my_dependency.conda" }

Doing this should be available through the pixi CLI but it will just update the pixi.toml file so that that file always contains the "truth".

[!Note]
This is all still future talk!

Being able to tell the resolver to completely ignore a required dependency (i.e. assume a compatible version is already installed) would be more in line with what I was thinking - e.g. something like:
my_dependency = "ignore"

This can also be invaluable when the dependencies are mis-specified but you need to install it regardless. With conda you can do that by installing the .tar.bz2 directly which can be a useful escape-hatch.

Mamba and conda also have a --no-deps and --only-deps flag. We could add that in pixi.toml

self hide as offtopic

[!Note]
This is all still future talk!

so, github gave green flag to this feature, wow....

authors: Wackyator baszalmstra dhirschfeld goyalyashpal wolfv

repo: prefix-dev/pixi


text:
Price cross in orderbook

In my test application, the orderbook is maintained by subscribing to the L2Update channel. When receiving a snapshot message, it creates a orderbook struct and it handles each l2update message after that. Sometimes I see the price crosses, i.e. best bid is higher than the best ask.
It might be a bug in my code, but I also want to check with users of this library and see if you are having the same issue.

you're meant to use also the sequence no to determine if you need to reconnect or not.
it's hard to see what the problem is without looking at the code in it's entirety.

@zhengyangfeng00 any update?

authors: mbana preichenberger zhengyangfeng00

repo: preichenberger/go-gdax


text:
"Write after end" error

Hi,
i'm using prerender (version 1.3.0) on my NodeJS+Express app, and i have this crash after some requests:
events.js:85       throw er; // Unhandled 'error' event             ^ Error: write after end     at ServerResponse.OutgoingMessage.write (_http_outgoing.js:413:15)     at ServerResponse.res.write (/home/scx-page/app/node_modules/compression/index.js:95:17)     at ServerResponse.res.end (/home/scx-page/app/node_modules/compression/index.js:112:14)     at ServerResponse.send (/home/scx-page/app/node_modules/express/lib/response.js:191:8)     at fn (/home/scx-page/app/node_modules/express/lib/response.js:896:10)     at Function.exports.swig.render (/home/scx-page/app/node_modules/consolidate/lib/consolidate.js:247:5)     at /home/scx-page/app/node_modules/consolidate/lib/consolidate.js:146:25     at /home/scx-page/app/node_modules/consolidate/lib/consolidate.js:99:5     at fs.js:334:14     at FSReqWrap.oncomplete (fs.js:95:15)
To reproduce this bug:

Open www.mydomain.com/test?escaped_fragment=
The node app crash.

Without prerender it works correctly.
Thank you.

Can you try upgrading to the latest version of Prerender? That's a really old version.

@thoop it's true, the latest version fixes the bug. Thank you.

hi @thoop, i have deeply tested the latest version "2.2.0" and i found that it's affected by the same bug reported.
Thank you.

I fixed the bug updating Express framework.

The latest version of Prerender as of writing this is 4.0.5. Glad you fixed it by upgrading Express!

authors: nottix thoop

repo: prerender/prerender

license: mit

license_source: bigquery


text:
Indentation spaces

Hello, thanks for maintaining a plugin I use every day.
Would you consider adding a configuration variable like NERDTreeIndentSpaces=1 ?
Sometimes I work on deeply nested projects and it would mean I could keep NERDTree a bit smaller (so my buffers can be bigger), while still seeing all the relevant information.
I appreciate this is a bit of a petty request. I had a quick go at adding this myself but when I changed the code that renders the menu, I could no longer open menu items and I couldn't figure out why.
Thanks

@tuzz , as you discovered, changing NERDTree code is an adventure. I have looked at this very thing myself, and decided at the time to abandon any further changes. Instead I wrote a syntax file to accomplish the same thing. Here it is. Make sure you save it to the right location: ~/.vim/after/syntax/nerdtree.vim.
" This file adds some customization to the syntax highlighting in NERDTree.
" Requirements:
"  * Vim must be compiled with the +conceal feature turned on.
"  * The file must be saved here: ~/.vim/after/syntax/nerdtree.vim

if !has("conceal")
    finish
endif

let s:dirArrows = escape(g:NERDTreeDirArrowCollapsible, '~]\-').escape(g:NERDTreeDirArrowExpandable, '~]\-')

syntax clear NERDTreeOpenable
syntax clear NERDTreeClosable

" ----------------------------------------------------------------------------
" This statement changes the indentation of NERDTree to appear as 1 space per
" level instead of the normal 2 spaces.
exec 'syntax match CompressSpaces #['.s:dirArrows.' ]\zs \ze.*' . g:NERDTreeNodeDelimiter . '# containedin=ALL conceal'

Thanks @PhilRunninger, that's working perfectly!

authors: PhilRunninger tuzz

repo: preservim/nerdtree

license: WTFPL


text:
avoid panic on tx.commit calls

ref: https://github.com/prest/adapters/pull/55 by @arxdsilva
While using this mock pkg I came across a commit panic when the mock tx was used to commit. I made a branch that shows how this panic occurs (here).
This PR does:

makes Mock struct implement the driver.Driver interface
registers a new driver "mock" on New
returns a fake db tx on mock.GetTransaction
implements mockConn that allows Mock{} to return a mocked connection

We are in the process of centralizing the repository to simplify the contribution and maintainability of pREST.
I have taken care to maintain the credit of the contribution (commit history)

@arxdsilva can you understand the mistake that happened? help-me pls

:(

basically is set the packages on go.mod
module github.com/prest/prest/adapters

go 1.13

require (
	github.com/jmoiron/sqlx v1.2.0
	github.com/lib/pq v1.8.0
	github.com/mitchellh/go-homedir v1.1.0 // indirect
	github.com/nuveo/log v0.0.0-20190430190217-44d02db6bdf8
	github.com/prest/prest/config v0.0.0-20200729162849-86fce87522f2
	github.com/prest/prest/template v0.0.0-20200729180256-565f3bc1ae70
	github.com/spf13/viper v1.7.0 // indirect
	github.com/stretchr/testify v1.3.0
)

@arxdsilva you are 4 commits behind the master branch.
Try to do a git rebase master. This will probably fix the problem with CI.

@tiaguinho can you resolve this PR conflict and solve the bug so we can merge?

@avelino on it.

I had to remove the assert package because isn't working in go 1.10, 1.11, and 1.12.

Thanks @arxdsilva (cc @levpay)

authors: arxdsilva avelino tiaguinho

repo: prest/prest


text:
Implement periodic cpu usage tracking in resource groups

This PR contains the following changes at a high level:

Periodically update and cache cpu usage for resource groups.
Add memory and cpu usage update at query completion.
Update eligibility through a post-order traversal in updateEligibilityAll after resource usage update to avoid calling updateEligibility recursively in the internalRefreshStats.
Rename processQueuedQueries to reflect what the method is doing
move memory limit check in canRunMore for better readability.

Resolves #1059 . @dain @wagnermarkd

@dain @raghavsethi I've updated the PR addressing your comments.
Numbers for TestResourceGroups benchmark:

Benchmark
(children)
(queries)
Time taken (us/op) (Before)
Time taken (us/op) (With updateEligibilityInSubTreemethod)
Time taken (us/op)(After removing updateEligibilityInSubTree method as in c16e711 )

BenchmarkResourceGroup.benchmark
1000
100
1.364
216.476
2.499

BenchmarkResourceGroup.benchmark
1000
1000
13.428
236.021
33.543

BenchmarkResourceGroup.benchmark
1000
10000
495.993
1148.303
1211.227

BenchmarkResourceGroup.benchmark
10000
100
1.094
2353.871
2.405

BenchmarkResourceGroup.benchmark
10000
1000
12.18
2489.451
26.708

BenchmarkResourceGroup.benchmark
10000
10000
445.518
4522.486
717.43

BenchmarkResourceGroup.benchmark
100000
100
1.217
33370.087
2.151

BenchmarkResourceGroup.benchmark
100000
1000
14.851
31872.003
26.752

BenchmarkResourceGroup.benchmark
100000
10000
455.631
32303.722
534.325

After seeing that the benchmark takes a lot longer to execute with updateEligibilityInSubTree method, I replaced its usage with updateEligibilityOnPathToRoot calls in internalCpuQuotaGeneration and updateResourceUsageAndGetDelta.  This change (a bit more than) doubles the time taken for the update (from before this PR), which seems reasonable to me given that we're updating two values per node now.
Removing updateEligibilityInSubTree requires us to invoke updateEligibilityOnPathToRoot method inside and internalGenerateCpuQuota. This works well for shallow trees, even with a high fanout. But I've a concern that it might not work well for deep trees. Do you think we should optimize this further?

@raghavsethi I think updateEligibilityInSubtree method created some confusion. I've removed it (here looking at the benchmark result. That might simplify things, and work well for shallow trees at least.  Happy to schedule a call if required for discussing this further.

If that's the case, it seems like we one have one updateEligibility method, can we rename it back?

@raghavsethi Addressed your comments.

Minor changes requested, looks generally good.

@raghavsethi Thanks for the review, I've updated the PR addressing your latest comments.

It's definitely not great behavior and could lead to a lot of user confusion, did your change make this worse? If not, then you can address it in a follow up PR.

This has been the behavior before the change as well. But it starves a queued query only if new queries submitted between the invocation of cpu quota generation and updateGroupsAndProcessQueuedQueries exceed limits instantaneously.

Can you go ahead and squash your commits into a single commit?

@phd3 could you provide a draft of the release notes for this change?

Merged, thanks for your contribution!

when we upgrade to version 318 or later we found that there is a very big bug

Could you provide your resource groups config file?

authors: ImTangYun phd3 raghavsethi

repo: prestosql/presto


text:
Collect plan statistics for explain only by default

Plan stats collection creates considerable load on
Hive metastore (even when CBO is disabled). Therefore
is better not to collect stats for plan for
non-explain queries

@findepi AC


text:
Development docs

aferritto created the following on Apr 27:
Closes #113

Adds development documentation
Adds markdown parser for sphinx so we can write docs guides in markdown

Marking this as draft pending decisions from https://ibm.ent.box.com/notes/947626860262
Original issue: https://github.ibm.com/ai-foundation/PrimeQA/pull/162

On Apr 28, aferritto commented:
Converting to ready for review and opened #165 for follow up.

On Apr 29, aferritto commented:
Thanks for your review.  In that case I will leave this PR open until the team has agreed on the sections in the box note.

On Apr 29, aferritto commented:
This PR is blocked upon deciding on https://ibm.ent.box.com/notes/947626860262 as a team and we will be including the work for now-closed #165 as part of this PR.

This is complete, the v1 of dev docs is merged into main

repo: primeqa/primeqa


text:
Normalizing HTML entity codes for XML?

I'm using XML rules for normalization in discovery import profiles to allow actions not possible with DC -- but some of the fields that import fine with DC rules aren't importing properly with XML. When the source fields include HTML links, using < and > for the < and > characters, with DC the fields import and display/function fine in Primo VE. But with XML, the entity values break the fields and don't display nor work in Primo VE.
I see in Ex Libris documentation that there is:
replace string by string – This action replaces all occurrences of a regular expression with a specified value. Valid format:
replace string by string (TEMP"{i}","<Java_regex>","")
So I thought maybe I could use this -- but I can't figure out to write a rule that works within the XML discovery normalization rule. Can anyone help with this, or do you have a suggestion for a better way to fix this problem?

Hi nbabb1,
I think you are on the right path, but are you able to provide an example of a URL that contains the characters you would like normalised?
Regards,
Craig.

Hi, Craig,
Thanks so much! Here's are a couple of examples:
dc:relationhttp://www.hallwalls.org/perflit/709.html</a></dc:relation>
dc:rightsContact the Poetry Collection: http://library.buffalo.edu/pl/</a></dc:rights>
My XML rules are very simple; just:
rule "Copy relation"
when
exist "//[local-name()='relation']"
then
copy "//[local-name()='relation']/text()" to "dc"."relation"
end
Best,
--Nancy

Hi Nancy,
Try using:
rule "Copy relation"
when
exist "//[local-name()='relation']"
then
copy "//[name()='dc:relation']" to  "dc"."relation"
end
The "/text()" element selects the individual text elements in the field so you end up with multiple "dc":"relation" elements containing one letter/word. Just a straight copy/mapping command worked for me.
Let me know how you get on.
Cheers,
Craig.

Aha! And of course -- that makes sense! Thank you!

You are welcome. I'm going to close this issue now.
Regards,
Craig.

repo: primousers/primo-ve-norm


text:
issue when running train_vo.py

the error shows 'No module named eval_tartan'
Traceback (most recent call last):   File "/home/kefei/workspaces/MultiSlam_DiffPose/train_vo.py", line 19, in <module>     from eval_tartan import validate ModuleNotFoundError: No module named 'eval_tartan'
And I can't find the file eval_tartan.py.
Did I miss some steps?

No you didn't miss anything, I honestly just forgot to commit this file lol. This is just to validate the SLAM training, you can comment out the validation code in train_vo.py if you want.
I've added the file in this branch: add_missing_file. I'll merge to main shortly.

authors: LoFaiTh lahavlipson


text:
chore: scaffold website

will close #224

deps
stub pages
build script
should be ready for gh hosting into /docs ... can only confirm after merge?

Error on build, don't know why:

https://github.com/prisma-labs/graphql-santa/issues/224#issuecomment-571344615

repo: prisma-labs/graphql-santa


text:
Passing in InputObjectType to an arg causes Nexus Error: this should never happen

#69 is similar to this, however error message that returns if the user does the wrong path is confusing.
Reproduction
INCORRECT CODE

const SongInput = inputObjectType({
  name: "SongInput",
  definition(t) {
    t.string('title', {nullable: true})
    t.string('artist', {nullable: true})
  }
});

const createSong = mutationField('createSong', {
  type: Model,
  args: {
    record: SongInput
  },
  resolve:(_, {record}, {dataSources: {rtdb}}) => {
    return rtdb.firebaseCreate(`song`,record);
  }
});

causes error:
Error: Nexus Error: This should never happen, please check your code or open a GitHub ticket if you believe this is an issue with Nexus
    at invariantGuard (/projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:709:15)
    at SchemaBuilder.getOrBuildType (/projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:526:9)
    at SchemaBuilder.getInputType (/projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:500:25)
    at /projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:417:48
    at Array.forEach (<anonymous>)
    at SchemaBuilder.buildArgs (/projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:414:27)
    at SchemaBuilder.buildObjectField (/projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:396:24)
    at /projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:377:44
    at Array.forEach (<anonymous>)
    at SchemaBuilder.buildObjectFields (/projects/graphql-nexus/firebase-example/node_modules/nexus/dist/builder.js:376:16)

https://github.com/prisma/nexus/blob/develop/src/builder.ts#L1481
CORRECT CODE

const SongInput = inputObjectType({
  name: "SongInput",
  definition(t) {
    t.string('title', {nullable: true})
    t.string('artist', {nullable: true})
  }
});

const createSong = mutationField('createSong', {
  type: Model,
  args: {
    record: arg({type: SongInput}) // the diff is here
  },
  resolve:(_, {record}, {dataSources: {rtdb}}) => {
    return rtdb.firebaseCreate(`song`,record);
  }
});

Expected
Would expect an error like, Did you forget to pass in arg(...) for an argument?, because that was the case here.

Rather than making this a better error, I think we should also consider allowing an input object type placed here to automatically be an arg the arg wrapping is mostly for type consistency, and we actually have an .asArg method on input objects to do the wrapping. It'd be simple to detect valid inputs and automatically wrap.
This is also exactly why we have this catch-all guard, to find code-paths that never happen and figure out how to improve the experience, though we should probably change to:
Error: Nexus Error: This codepath should never happen, please open a GitHub
issue to help us understand how you got here :)

This syntax should be supported in 0.12.0-rc.4. Please let me know if you're still having issues.

authors: hrgui tgriesser

repo: prisma-labs/nexus


text:
Fix backward slash typos

Fix a couple of typos with back-slashes instead of forward-slashes in file paths.
Fix broken link:

Thank you! 💚 That was me being a Windows user. 😅 I've fixed the image in #409.

authors: mhwelander robin-macpherson

repo: prisma/docs


text:
Seeding fails in prisma migrate dev with timeout but works with prisma db seed

Bug description
prisma migrate dev invokes the prisma db seed command when executed for the first time but it always seems to fail. Here's the output I'm getting:
$ npx prisma migrate dev --name init

Prisma schema loaded from prisma/schema.prisma
Datasource "db": SQLite database "dev.db" at "file:./dev.db"

SQLite database dev.db created at file:./dev.db

Running seed command `ts-node prisma/seed.ts` ...
Start seeding ...
PrismaClientUnknownRequestError:
Invalid `prisma.user.create()` invocation in
/Users/nikolasburk/Desktop/graphql/prisma/seed.ts:56:36

   53 async function main() {
   54   console.log(`Start seeding ...`)
   55   for (const u of userData) {
→  56     const user = await prisma.user.create(
  Error occurred during query execution:
ConnectorError(ConnectorError { user_facing_error: None, kind: ConnectionError(Timed out during query execution.) })
    at cb (/Users/nikolasburk/Desktop/graphql/node_modules/@prisma/client/runtime/index.js:38506:17) {
  clientVersion: '3.4.2'
}

An error occured while running the seed command:
Error: Command failed with exit code 1: ts-node prisma/seed.ts

Applying migration `20211110102834_init`

The following migration(s) have been created and applied from new schema changes:

migrations/
  └─ 20211110102834_init/
    └─ migration.sql

Your database is now in sync with your schema.

✔ Generated Prisma Client (3.4.2) to ./node_modules/@prisma/client in 115ms

When I subsequently run prisma db seed, the seeding works correctly:
$ npx prisma db seed

Running seed command `ts-node prisma/seed.ts` ...
Start seeding ...
Created user with id: 1
Created user with id: 2
Created user with id: 3
Seeding finished.

🌱  The seed command has been executed.

How to reproduce
You can reproduce by following the setup steps in this example project: https://github.com/prisma/prisma-examples/tree/latest/typescript/graphql
To summarize the steps here, you can just run the following commands to reproduce the problem:
curl https://codeload.github.com/prisma/prisma-examples/tar.gz/latest | tar -xz --strip=2 prisma-examples-latest/typescript/graphql
cd graphql
npm install
npx prisma migrate dev --name init # seeding will fail
npx prisma db seed # seeding will work

Expected behavior
The seeding should work when running prisma migrate dev
Prisma information
Prisma schema
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = "file:./dev.db"
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  posts Post[]
}

model Post {
  id        Int      @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  title     String
  content   String?
  published Boolean  @default(false)
  viewCount Int      @default(0)
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?
}

Seed script
import { PrismaClient, Prisma } from '@prisma/client'

const prisma = new PrismaClient()

const userData: Prisma.UserCreateInput[] = [
  {
    name: 'Alice',
    email: 'alice@prisma.io',
    posts: {
      create: [
        {
          title: 'Join the Prisma Slack',
          content: 'https://slack.prisma.io',
          published: true,
        },
      ],
    },
  },
  {
    name: 'Nilu',
    email: 'nilu@prisma.io',
    posts: {
      create: [
        {
          title: 'Follow Prisma on Twitter',
          content: 'https://www.twitter.com/prisma',
          published: true,
          viewCount: 42,
        },
      ],
    },
  },
  {
    name: 'Mahmoud',
    email: 'mahmoud@prisma.io',
    posts: {
      create: [
        {
          title: 'Ask a question about Prisma on GitHub',
          content: 'https://www.github.com/prisma/prisma/discussions',
          published: true,
          viewCount: 128,
        },
        {
          title: 'Prisma on YouTube',
          content: 'https://pris.ly/youtube',
        },
      ],
    },
  },
]

async function main() {
  console.log(`Start seeding ...`)
  for (const u of userData) {
    const user = await prisma.user.create({
      data: u,
    })
    console.log(`Created user with id: ${user.id}`)
  }
  console.log(`Seeding finished.`)
}

main()
  .catch((e) => {
    console.error(e)
    process.exit(1)
  })
  .finally(async () => {
    await prisma.$disconnect()
  })

Environment & setup

OS: Mac OS 12.0.1
Database: SQLite
Node.js version: v14.12.0

Prisma Version
prisma                  : 3.4.2
@prisma/client          : 3.4.2
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 57771c0558568c7d08bd34c7248af5244ae16bd9
Studio                  : 0.438.0

I can confirm the observations and error message.

Is this related to other SQLite timeout errors being reported?  Wondering if it has nothing to do with seeding.

authors: janpio nikolasburk pkellner

repo: prisma/prisma


text:
Consider renaming the @prisma/sdk package to reduce confusion

The name @prisma/sdk is a bit confusing since it's not really an SDK, so we might consider renaming it. Based on this internal Slack convo:

Yeah it should be renamed to be like "common" or "helpers" cause a lot of people think that it's an API for external usage from its name, but it's a really good point that this is a breaking change cause there are a lot of repositories depending on @prisma/sdk.

Thanks @YassinEldeeb for your feedback!
Note: We are considering adding a deprecation message soon and rename it for Prisma 4 (date undefined yet)

[Internal]
Me, Pierre and Alexey created a draft of a plan the renaming
https://www.notion.so/prismaio/Renaming-prisma-sdk-and-cleaning-up-internal-packages-f217f9ba96aa40fd91f47995b9266dc3
Work in progress, nothing planned yet, but this would be the general direction we want to go for.

Can we move this issue to "done"?

The internal package @prisma/sdk will be available under the new, more explicit name @prisma/internals from Prisma version 4.0.0.
@prisma/sdk will be published for Prisma 4.0.0 and marked as deprecated on npm, it will be the last version published in its current shape.
The upgrade path would be to rename the usage @prisma/sdk to @prisma/internals.
⚠ Note that functionality of this internal package can be changed or even removed any time and our SemVer guarantees (no breaking changes without major version increase) are not valid here.
Making the intended use of that package explicit (internal only) is important as it helps to manage expectations with users.
This is technically not a breaking change as usage of the sdk package was not documented nor supported.
If you are using this package, it would be helpful if you could help us gain an understanding of where, how and why you are using it. Your feedback will be valuable to us to define a better API. Please share this information at https://github.com/prisma/prisma/discussions/13877 - Thanks!
npm packages
https://www.npmjs.com/package/@prisma/sdk
https://www.npmjs.com/package/@prisma/internals

authors: Jolg42 YassinEldeeb jkomyno nikolasburk


text:
PANIC: called Option::unwrap() on a None value in query-engine/core/src/query_document/parser.rs:250:87

Hi Prisma Team! My Prisma Client just crashed. This is the report:
Versions

Name
Version

Node
v16.13.1

OS
debian-openssl-1.1.x

Prisma Client
3.5.0

Query Engine
0.1.0

Database
mysql

Logs
  prisma:tryLoadEnv Environment variables loaded from /mnt/c/Users/Avell A52/Desktop/Programação/tiny-transportadoras/.env
  prisma:tryLoadEnv Environment variables loaded from /mnt/c/Users/Avell A52/Desktop/Programação/tiny-transportadoras/.env
  prisma:client clientVersion: 3.5.0
  prisma:client:libraryEngine internalSetup
  prisma:client:libraryEngine Search for Query Engine Library in /mnt/c/Users/Avell A52/Desktop/Programação/tiny-transportadoras/node_modules/.prisma/client
  prisma:client:libraryEngine loadEngine using /mnt/c/Users/Avell A52/Desktop/Programação/tiny-transportadoras/node_modules/.prisma/client/libquery_engine-debian-openssl-1.1.x.so.node
  prisma:client:libraryEngine sending request, this.libraryStarted: false  +33s
  prisma:client:libraryEngine library starting
  prisma:client:libraryEngine library started  +2s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +7s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +7s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +1s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +3s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +4s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +3s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +3s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +11s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +4s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +2s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +9s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +7s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +13s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +5s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +2s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +3s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +3s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +19s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +3s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +4s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +17s
  prisma:client:libraryEngine sending request, this.libraryStarted: true  +8s

Client Snippet
 const verifyLastStatus = await prisma.tracking.findMany({
        where: {
          shipping: order.shipping,
          nf: order.tracker,
          ocurrencyStatus: order.ocurrency.statusLast,
        },
      })

Schema
// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "mysql"
  url      = env("DB_URL")
}

model Tracking {
  id          Int     @id @default(autoincrement())
  createdAt   DateTime? @default(now())
  shipping    String
  nf          Int
  lastStatus  String
  ocurrencyStatus Int @default(0)
}

model Emails {
  id          Int      @id @default(autoincrement())
  createdAt   DateTime @default(now())
  trackingId  Int   @unique
  success     Int
}

Prisma Engine Query
{"X":{}}

Hey @eduardondev, what data did you send in:
 const verifyLastStatus = await prisma.tracking.findMany({
        where: {
          shipping: order.shipping,
          nf: order.tracker,
          ocurrencyStatus: order.ocurrency.statusLast,
        },
      })

What's order.shipping, order.tracker, order.ocurrency.statusLast?

Duplicate of https://github.com/prisma/prisma/issues/10586

authors: dpetrick eduardondev matthewmueller


text:
On Raspbian 64 bit (aarch64) tries to install linux-arm-openssl-1.1.x which cannot be found

Bug description
On Raspbian 64 bit (aarch64) tries to install linux-arm-openssl-1.1.x which cannot be found.
In your release notes you've stated binaryTargets = ["linux-arm-openssl-1.1.x"]. However new I look for those binaries in your documentation I can only find linux-arm64-openssl-1.1.x.
Is there a solution which forces it to point to the correct binary?
How to reproduce

Raspberry Pi with Raspbian 64 bit (aarch64)
Run any Prisma related command
See error > Downloading Prisma engines for Node-API for linux-arm-openssl-1.1.x [                    ] 0%Error: Not Found https://binaries.prisma.sh/all_commits/d6e67a83f971b175a593ccc12e15c4a757f93ffe/linux-arm-openssl-1.1.x/prisma-fmt.gz

Expected behavior
It works
Prisma information
> Downloading Prisma engines for Node-API for linux-arm-openssl-1.1.x [                    ] 0%Error: Not Found https://binaries.prisma.sh/all_commits/d6e67a83f971b175a593ccc12e15c4a757f93ffe/linux-arm-openssl-1.1.x/prisma-fmt.gz

Environment & setup

OS: Raspbian 64 bit
Database: SQLite
Node.js version: v18.12.0

generator client {
  provider = "prisma-client-js"
  binaryTargets = ["linux-arm64-openssl-1.1.x"]
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model Video {
  id             String @id
  publishedAt    String
  title          String
  thumbnails     String
  viewCount      String
}

Prisma Version
4.8.1

Hi @pimmesz, what happens if you remove the binaryTargets from your schema entirely?

This is a 404
https://binaries.prisma.sh/all_commits/d6e67a83f971b175a593ccc12e15c4a757f93ffe/linux-arm-openssl-1.1.x/prisma-fmt.gz
This exists
https://binaries.prisma.sh/all_commits/d6e67a83f971b175a593ccc12e15c4a757f93ffe/linux-arm64-openssl-1.1.x/prisma-fmt.gz
Not that the binaryTargets = ["linux-arm64-openssl-1.1.x"] property in the Prisma schema only affects the Query Engine download. So this property is unrelated to the prisma-fmt error here.
A workaround would be to set this env var before running npm install
PRISMA_CLI_BINARY_TARGETS=linux-arm64-openssl-1.1.x

Though it should normally not be needed and we want to investigate this, code is here https://github.com/prisma/prisma/blob/1a17fdf5520c287d926c4e92049a163adbe19877/packages/get-platform/src/getPlatform.ts#L289-L297

@pimmesz Could you confirm that the workaround I mentioned works?

@Jolg42 still getting the same.
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model Video {
  id             String @id
  publishedAt    String
  title          String
  thumbnails     String
  viewCount      String
}

On Linux 5.15.84-v8+ aarch64

echo $PRISMA_CLI_BINARY_TARGETSreturns linux-arm64-openssl-1.1.x.
Removed node_modules
Run npm install
Run npx prisma generate
Receive error Error: Not Found https://binaries.prisma.sh/all_commits/d6e67a83f971b175a593ccc12e15c4a757f93ffe/linux-arm-openssl-1.1.x/prisma-fmt.gz

node -e 'console.log(process.arch)' returns armfor me. Perhaps issue with node not correctly recognizing which arch is used?

But that still means that linux-arm-openssl-1.1.x images on binaries.prisma.sh should be available I think.

@pimmesz Thanks for the additional info!
I think we got enough info to investigate with that 🙌🏼
Could you try this workaround for now:

download the engines manually from https://binaries.prisma.sh/all_commits/d6e67a83f971b175a593ccc12e15c4a757f93ffe/linux-arm64-openssl-1.1.x/prisma-fmt.gz (change the name of the engine file at the end to get other engines)
set the following env vars with the correct path to the related engines:

PRISMA_FMT_BINARY=folder/my-format-engine
# I think these below will also be needed (please confirm)
PRISMA_QUERY_ENGINE_LIBRARY=folder/libquery_engine-<target>.so.node
PRISMA_INTROSPECTION_ENGINE_BINARY=folder/my-introspection-engine
PRISMA_MIGRATION_ENGINE_BINARY=folder/my-migration-engine

Seems to get a bit further. Currently breaking on
Error: Unable to establish a connection to query-engine-node-api library. It seems that the current architecture arm is not supported, or that libc is missing from the system.
Details: Unable to require(`/home/pi/prisma-binaries/libquery_engine.so.node`)
 /home/pi/prisma-binaries/libquery_engine.so.node: wrong ELF class: ELFCLASS64
[Context: getDmmf]

Note: adding support for Linux ARM 32bit is tracked in https://github.com/prisma/prisma/issues/5379
(Though since Raspbian has a 64 bit version, it's the one currently recommended.)

@Jolg42 thank you! After fully reinstalling 64 bit OS it finally detects well and it works! I think the issue for incorrect detection still stands but 64 bit works perfectly! Thank you.

Closing this as OP solved their problem with the provided suggestion.

authors: Jolg42 jkomyno pimmesz


text:
DATABASE_URL required when setting datasources.db.url

Bug description
I originally identified this as a regression of https://github.com/prisma/prisma/issues/2609.
DATABASE_URL is required, even when explicitly setting datasources.db.url in the PrismaClient constructor.
How to reproduce
Given the following,
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  // ...etc
}

import { PrismaClient } from '@prisma/client'

const url = `postgresql://user:pass@localhost/mydb`

const prisma = new PrismaClient({
  datasources: { db: { url } },
})

console.log('user count', await prisma.user.count())

Without setting DATABASE_URL, I get this error.
(node:35938) UnhandledPromiseRejectionWarning: Error:
Invalid `prisma.user.count()` invocation in
/Users/defrex/Code/treasure/api/src/prisma-repro.ts:19:47

  15 const prisma = new PrismaClient({
  16   datasources: { db: { url } },
  17 })
  18
→ 19 console.log('user count', await prisma.user.count()

  error: Environment variable not found: DATABASE_URL.
  -->  schema.prisma:7
   |
 6 |   provider = "postgresql"
 7 |   url      = env("DATABASE_URL")
   |

Validation Error Count: 1
    at PrismaClientFetcher.message [as _request] (/Users/defrex/Code/treasure/api/node_modules/@prisma/client/src/runtime/getPrismaClient.ts:999:51)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:35938) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:35938) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Expected behavior
I expect it to connect without needing to set the DATABASE_URL environment variable.
This error can be solved by setting DATABASE_URL to a "dummy" value that appears valid. Eg. DATABASE_URL=postgres://notarealhostname.
Environment & setup

OS: Mac OS
Database: Postgres
Prisma version: 2.2.0
Node.js version: 12.18.1

Do you get this output just when executing the count()?

Any DB query from that prisma object will do.

Do you have a .env file in your project root as well? We currently have a bug that this file is loaded by the CLI instead of just the prisma/.env as documented. This will be fixed on Monday if that is the reason.

I do have a .env in my project root, but it doesn't contain DATABASE_URL.

And to clarify, I do not have a prisma/.env file.

Exactly, the CLI currently does read the .env in the root although it should not. Can you try if putting the value in there fixes your issue?

Putting an incorrect but well-formed value for DATABASE_URL in .env does indeed remove the error, implying that the root .env is being read.
I'm not sure what this has to do with the issue though. The problem is that DATABASE_URL shouldn't be required at all, rather than where it should be specified.

That is just not supported, as we require a valid schema. You can replace the env("DATABASE_URL") with a nonsense value in the schema.prisma if you want, then no error message should appear and the explicitly defined wvalue will overwrite the nonsense value.

I still need it for introspection, and eventually migrations, locally. I guess I'll just live with setting a nonsense value in production. 🤷♀

authors: defrex janpio


text:
Cannot deploy on heroku from local server

Prisma version :prisma/1.26.6 (linux-x64) node-v8.15.0
OS : linux mint 19 (ubuntu 18.04)
NOTE : database is printed to be as "Schema"  in logs. database name is d6idulpflfr3k9
Issue while deploying to heroku from local prisma server
Deployment worker initialization complete.
Warning: Management API authentication is disabled. To protect your management server you should provide one (not both) of the environment variables 'CLUSTER_PUBLIC_KEY' (asymmetric, deprecated soon) or 'PRISMA_MANAGEMENT_API_JWT_SECRET' (symmetric JWT).
Warning: Management API authentication is disabled. To protect your management server you should provide one (not both) of the environment variables 'CLUSTER_PUBLIC_KEY' (asymmetric, deprecated soon) or 'PRISMA_MANAGEMENT_API_JWT_SECRET' (symmetric JWT).
[Debug] Initializing deployment worker for default$default
[Debug] Scheduling deployment for project default$default
Warning: Management API authentication is disabled. To protect your management server you should provide one (not both) of the environment variables 'CLUSTER_PUBLIC_KEY' (asymmetric, deprecated soon) or 'PRISMA_MANAGEMENT_API_JWT_SECRET' (symmetric JWT).
Warning: Management API authentication is disabled. To protect your management server you should provide one (not both) of the environment variables 'CLUSTER_PUBLIC_KEY' (asymmetric, deprecated soon) or 'PRISMA_MANAGEMENT_API_JWT_SECRET' (symmetric JWT).
Encountered exception while applying migration. Rolling back. org.postgresql.util.PSQLException: ERROR: schema "d6idulpflfr3k9" does not exist
Position: 24
org.postgresql.util.PSQLException: ERROR: schema "d6idulpflfr3k9" does not exist
Position: 24
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2433)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2178)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155)
at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:144)
at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
at slick.jdbc.StatementInvoker.results(StatementInvoker.scala:38)
at slick.jdbc.StatementInvoker.iteratorTo(StatementInvoker.scala:21)
at slick.jdbc.Invoker.first(Invoker.scala:30)
at slick.jdbc.Invoker.first$(Invoker.scala:29)
at slick.jdbc.StatementInvoker.first(StatementInvoker.scala:15)
at slick.jdbc.StreamingInvokerAction$HeadAction.run(StreamingInvokerAction.scala:52)
at slick.jdbc.StreamingInvokerAction$HeadAction.run(StreamingInvokerAction.scala:51)
at slick.dbio.DBIOAction$$anon$4.$anonfun$run$3(DBIOAction.scala:239)
at scala.collection.Iterator.foreach(Iterator.scala:929)
at scala.collection.Iterator.foreach$(Iterator.scala:929)
at scala.collection.AbstractIterator.foreach(Iterator.scala:1417)
at scala.collection.IterableLike.foreach(IterableLike.scala:71)
at scala.collection.IterableLike.foreach$(IterableLike.scala:70)
at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
at slick.dbio.DBIOAction$$anon$4.run(DBIOAction.scala:239)
at slick.dbio.DBIOAction$$anon$4.run(DBIOAction.scala:237)
at slick.basic.BasicBackend$DatabaseDef$$anon$2.liftedTree1$1(BasicBackend.scala:275)
at slick.basic.BasicBackend$DatabaseDef$$anon$2.run(BasicBackend.scala:275)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Warning: Management API authentication is disabled. To protect your management server you should provide one (not both) of the environment variables 'CLUSTER_PUBLIC_KEY' (asymmetric, deprecated soon) or 'PRISMA_MANAGEMENT_API_JWT_SECRET' (symmetric JWT).
Warning: Management API authentication is disabled. To protect your management server you should provide one (not both) of the environment variables 'CLUSTER_PUBLIC_KEY' (asymmetric, deprecated soon) or 'PRISMA_MANAGEMENT_API_JWT_SECRET' (symmetric JWT).
[Debug] Applied migration for project default$default

@georgemickael-b
Did you use our heroku integration?
If yes please paste the PRISMA_CONFIG variable from the config vars here?
Also, share your workspace slug as well(it is under prisma cloud settings)

@georgemickael-b
Did you use our heroku integration?
If yes please paste the PRISMA_CONFIG variable from the config vars here?
Also, share your workspace slug as well(it is under prisma cloud settings)

I did not use prisma cloud. I was developing locally and tried to use heroku.
docker-compose.yml
version: '3' services:   prisma:     image: prismagraphql/prisma:1.26     restart: always     ports:     - "4466:4466"     environment:       PRISMA_CONFIG: |         port: 4466         # uncomment the next line and provide the env var PRISMA_MANAGEMENT_API_SECRET=my-secret to activate cluster security         # managementApiSecret: my-secret         databases:           default:             connector: postgres             host: ec2-23-21-128-35.compute-1.amazonaws.com             database: d6idulpflfr3k9             user: *******             password: *******             port: '5432'             migrations: true             ssl: true
prisma.yml
`endpoint: http://localhost:4466
datamodel: datamodel.prisma
generate:

generator: javascript-client
output: ./generated/prisma-client/`

datamodel.prisma
type User {   id: ID! @unique   name: String! }

@georgemickael-b
Here are some instructions for deploying prisma to heroku. Please try to deploy using them: https://github.com/dpetrick/prisma-heroku

@georgemickael-b
Here are some instructions for deploying prisma to heroku. Please try to deploy using them: https://github.com/dpetrick/prisma-heroku

I did not use heroku for  prisma server. I used local dev server.
I used only postgres db from heroku (external database)

@georgemickael-b Are you still having this issue? I just ran into today, while yesterday was working just fine and I did not touch nor update anything.


text:
Preview feature feedback: groupBy

Please share your feedback about the preview feature groupBy  that was released in v2.14.0 in this issue.

If you encounter a bug, please open a bug report in this repo.
If the feature is working well for you, please share this in a comment below or leave a 👍 on this issue.

If you have any questions, don't hesitate to ask them in the #prisma2 channel in the Prisma Slack.

So a few things:

The ModelGroupByOutputType puts all keys as nullable even if they are not nullable in the database.
The groupBy method parameter is pretty ugly, can you create an alias like AggregateTicketArgs and others like it.

So a few things:

The ModelGroupByOutputType puts all keys as nullable even if they are not nullable in the database.
The groupBy method parameter is pretty ugly, can you create an alias like AggregateTicketArgs and others like it.

Thanks for the feedback!

The ModelGroupByOutputType puts all keys as nullable even if they are not nullable in the database.

Asking about this one. I'll get back to you early next week.

The groupBy method parameter is pretty ugly, can you create an alias like AggregateTicketArgs and others like it.

Which method parameter? The name of the type declaration? Can you share some code?

Thanks for the feedback!

The ModelGroupByOutputType puts all keys as nullable even if they are not nullable in the database.

Asking about this one. I'll get back to you early next week.

The groupBy method parameter is pretty ugly, can you create an alias like AggregateTicketArgs and others like it.

Which method parameter? The name of the type declaration? Can you share some code?

@matthewmueller  you can see the difference

@matthewmueller  you can see the difference

Thanks for the response! I hopefully can see the difference, do you mean you'd like for the 2nd and 3rd generic type parameters to have aliases?
Something like:
export type HasSelectOrTake = HasSelectOrTake extends Or<
  Extends<'skip', Keys<T>>,
  Extends<'take', Keys<T>>
>

export type OrderByArg = OrderByArg extends True extends HasSelectOrTake
  ? { orderBy: GroupByAgentArgs['orderBy'] }
  : { orderBy?: GroupByAgentArgs['orderBy'] },
  OrderFields extends Keys < MaybeTupleToUnion < T['orderBy'] >>,
    ByFields extends TupleToUnion < T['by'] >,
      ByValid extends Has < ByFields, OrderFields >,
        HavingFields extends GetHavingFields < T['having'] >,
          HavingValid extends Has < ByFields, HavingFields >,
            ByEmpty extends T['by'] extends never[] ? True : False,
              InputErrors extends ByEmpty extends True
                ? `Error: "by" must not be empty.`
                : HavingValid extends False
                  ? {
                    [P in HavingFields]: P extends ByFields
                      ? never
                      : P extends string
                        ? `Error: Field "${P}" used in "having" needs to be provided in "by".`
                        : [
                          Error,
                          'Field ',
                          P,
                          ` in "having" needs to be provided in "by"`,
                        ]
                  }[HavingFields]
                  : 'take' extends Keys<T>
                    ?'orderBy' extends Keys<T>
                    ?ByValid extends True
                    ? {}
                    : {
                      [P in OrderFields]: P extends ByFields
                        ? never
                        : `Error: Field "${P}" in "orderBy" needs to be provided in "by"`
                    }[OrderFields]
                    : 'Error: If you provide "take", you also need to provide "orderBy"'
                    : 'skip' extends Keys<T>
                    ?'orderBy' extends Keys<T>
                    ?ByValid extends True
                    ? {}
                    : {
                      [P in OrderFields]: P extends ByFields
                        ? never
                        : `Error: Field "${P}" in "orderBy" needs to be provided in "by"`
                    }[OrderFields]
                    : 'Error: If you provide "skip", you also need to provide "orderBy"'
                    : ByValid extends True
                    ? {}
                    : {
                      [P in OrderFields]: P extends ByFields
                        ? never
                        : `Error: Field "${P}" in "orderBy" needs to be provided in "by"`
                    }[OrderFields]

?

Thanks for the response! I hopefully can see the difference, do you mean you'd like for the 2nd and 3rd generic type parameters to have aliases?
Something like:
export type HasSelectOrTake = HasSelectOrTake extends Or<
  Extends<'skip', Keys<T>>,
  Extends<'take', Keys<T>>
>

export type OrderByArg = OrderByArg extends True extends HasSelectOrTake
  ? { orderBy: GroupByAgentArgs['orderBy'] }
  : { orderBy?: GroupByAgentArgs['orderBy'] },
  OrderFields extends Keys < MaybeTupleToUnion < T['orderBy'] >>,
    ByFields extends TupleToUnion < T['by'] >,
      ByValid extends Has < ByFields, OrderFields >,
        HavingFields extends GetHavingFields < T['having'] >,
          HavingValid extends Has < ByFields, HavingFields >,
            ByEmpty extends T['by'] extends never[] ? True : False,
              InputErrors extends ByEmpty extends True
                ? `Error: "by" must not be empty.`
                : HavingValid extends False
                  ? {
                    [P in HavingFields]: P extends ByFields
                      ? never
                      : P extends string
                        ? `Error: Field "${P}" used in "having" needs to be provided in "by".`
                        : [
                          Error,
                          'Field ',
                          P,
                          ` in "having" needs to be provided in "by"`,
                        ]
                  }[HavingFields]
                  : 'take' extends Keys<T>
                    ?'orderBy' extends Keys<T>
                    ?ByValid extends True
                    ? {}
                    : {
                      [P in OrderFields]: P extends ByFields
                        ? never
                        : `Error: Field "${P}" in "orderBy" needs to be provided in "by"`
                    }[OrderFields]
                    : 'Error: If you provide "take", you also need to provide "orderBy"'
                    : 'skip' extends Keys<T>
                    ?'orderBy' extends Keys<T>
                    ?ByValid extends True
                    ? {}
                    : {
                      [P in OrderFields]: P extends ByFields
                        ? never
                        : `Error: Field "${P}" in "orderBy" needs to be provided in "by"`
                    }[OrderFields]
                    : 'Error: If you provide "skip", you also need to provide "orderBy"'
                    : ByValid extends True
                    ? {}
                    : {
                      [P in OrderFields]: P extends ByFields
                        ? never
                        : `Error: Field "${P}" in "orderBy" needs to be provided in "by"`
                    }[OrderFields]

?

Nothing specifically yet but when you cmd+click on the name ita pretty ugly where the other methods are clean. So mostly for consistency. I also usually do that to navigate to the arguments parameters when I forget what I can input.

Nothing specifically yet but when you cmd+click on the name ita pretty ugly where the other methods are clean. So mostly for consistency. I also usually do that to navigate to the arguments parameters when I forget what I can input.

The ModelGroupByOutputType puts all keys as nullable even if they are not nullable in the database.

FYI, we'll be working on this one in #4987. Thanks for spotting this @Sytten!

The ModelGroupByOutputType puts all keys as nullable even if they are not nullable in the database.

FYI, we'll be working on this one in #4987. Thanks for spotting this @Sytten!

I don't see any way to order by the highest count, this seems to be the only missing feature?
 let casesByCode = await appDb.caseCode.groupBy({
    by: ['code', 'id'],
    count: {
      code: true,
    },
    take: 6,

  //no way to do this:
  orderBy: {
   count: true
  }
  })

So if I want to group a table by a column, and i want only the most used 'code's in this case, i cant control ordering by the amount that were grouped?
In raw sql i would select count(*) and then order by count

I don't see any way to order by the highest count, this seems to be the only missing feature?
 let casesByCode = await appDb.caseCode.groupBy({
    by: ['code', 'id'],
    count: {
      code: true,
    },
    take: 6,

  //no way to do this:
  orderBy: {
   count: true
  }
  })

So if I want to group a table by a column, and i want only the most used 'code's in this case, i cant control ordering by the amount that were grouped?
In raw sql i would select count(*) and then order by count

small feature request if it doesn't exist. one thing i need to do is to be able to group by year extracted from a string in the timestamp column. i'm using postgres as my db and the raw sql for what i'm describing is this:
GROUP BY
	“report”.source,
	EXTRACT(YEAR FROM “report”.timestamp)

i don't see a way to be able to generate the EXTRACT using the groupBy arg, by: [].

small feature request if it doesn't exist. one thing i need to do is to be able to group by year extracted from a string in the timestamp column. i'm using postgres as my db and the raw sql for what i'm describing is this:
GROUP BY
	“report”.source,
	EXTRACT(YEAR FROM “report”.timestamp)

i don't see a way to be able to generate the EXTRACT using the groupBy arg, by: [].

Agreed with @zackify above! Would love to be able to orderBy count while performing a groupBy.
For example, I have the follow raw query I'd be interested in moving to Prisma syntax instead:
const topArtists = await ctx.db.$queryRaw<{ artistId: number }[]>`SELECT "artistId"
        FROM "UserArtist"
        GROUP BY "artistId"
        ORDER BY COUNT(*) DESC
        LIMIT 10`

However I cannot fully translate this query due to the fact that I cannot orderBy count!

Hey @zackify and @uncvrd, thanks for sharing your use cases. That's indeed a limitation right now. I've opened an issue for this feature: https://github.com/prisma/prisma/issues/5464. The workaround for now is to sort in your application.
@pseuyi we don't yet support arbitrary expressions like this. It's on our radar, but solving it requires quite a bit of internal refactoring. We'd also like to solve it in a much broader way. In the meantime, raw is the way to go. Sorry about that!

This one will be stabilized in 2.20.0. Thanks for the comments everyone! We'll continue in separate issues.

authors: Sytten matthewmueller pseuyi uncvrd zackify


text:
MDBE: Deprecation warning or code-mod to transition users from type to alias

Using type within PSL is undocumented, but discussed in Github comments.
We should allow some grace period to switch over. If not easily doable, maybe we do this for Prisma 3.0.

Seems like we won't end up doing this.


text:
Error: [libs\sql-schema-describer\src\lib.rs:171:32] Column id not found in Table videos

Command: prisma db pull
Version: 3.2.1
Binary Version: b71d8cb16c4ddc7e3e9821f42fd09b0f82d7934c
Report: https://prisma-errors.netlify.app/report/13544
OS: x64 win32 10.0.19043
JS Stacktrace:
Error: [libs\sql-schema-describer\src\lib.rs:171:32] Column id not found in Table videos
    at ChildProcess.<anonymous> (C:\<Jan'sComputer>\9717\node_modules\prisma\build\index.js:43135:28)
    at ChildProcess.emit (events.js:400:28)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)

Rust Stacktrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: <unknown>
  15: <unknown>
  16: <unknown>
  17: <unknown>
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: BaseThreadInitThunk
  28: RtlUserThreadStart

Let's create a feature request issue for that. Scope has expanded considerably.

New error report: https://prisma-errors.netlify.app/report/13559

Yet another: https://prisma-errors.netlify.app/report/13561

Are we 100% sure these are all connected to permission problems on the database user?
Could we catch these and just output a helpful error as a smaller scoped feature to implement (vs. the grant checks mentioned before)?

authors: janpio tomhoule


text:
feat(client): add support for Driver Adapters

This PR:

integrates https://github.com/prisma/prisma-engines/pull/4174 into @prisma/client.
adapts the new DX to the js-connectors reproduction folder, which is now named driver-adapters.

This PR subsumes https://github.com/prisma/prisma/pull/20507, and includes https://github.com/prisma/prisma/pull/20969.
/integration

Note: we can't merge before we figured out how to fix this e2e fail test accelerate-types failed with exit code 1
https://github.com/prisma/prisma/actions/runs/6183004875/job/16783862042?pr=20965#step:5:337


text:
Question about imageImgixParams (&q=50)

Apologies if this is not a plugin issue but a general Prismic issue...
I noticed a strange issue with one of our image-heavy clients.
By default images are returned from imgix with the following params
?ixlib=gatsbyFP&q=50&auto=compress%2Cformat&w={imgwidth}&h={imgheight}

I've been looking at reducing the file size of the images and decided to play around with the q (quality) parameter which by default is set to 50 (as above)
If in my config I set q to be blank...
imageImgixParams: {
  q: ''
}

This actually results in a smaller file size, which is found odd.
Upon further reading - https://docs.imgix.com/apis/rendering/format/q it states...
When auto=compress is applied to an image, the default value becomes 45 unless overridden.
So either this plugin or Prismic is overwriting imgix's default image quality compression and naturally making the file size bigger.
Should the q parameter be removed by default?
Versions

gatsby-source-prismic: 5.0.3
gatsby-plugin-prismic-previews: 5.0.3
node: 14.17.3

Reproduction
coming soon
Steps to reproduce
run any site using the standard out the box Imgix setup. Check the file size (kb) of an image, then add a blank q parameter to config and check the file size, it should result in a smaller image.
What is expected?
I think the q parameter should be removed by default and instead reply on Imgix compression. If you want to override that q value you should have to add it to the config.
What is actually happening?
The image file sizes are purposely made larger by default.

Hey @jodiedoubleday, you're absolutely right. q=50 will be removed in the version which should be published soon. Until then, the parameter can be disabled using { q: undefined } or { q: '' } like you pointed out.
Thanks for finding this!

authors: angeloashmore jodiedoubleday

repo: prismicio/prismic-gatsby


text:
🛑 Smnz (🇩🇪) is down

In 9591ab4, Smnz (🇩🇪) (https://pipedapi.smnz.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Smnz (🇩🇪) is back up in a7d23da.


text:
Remove iterators and boxing from recursively_compute_final_check

As we discussed in #1166, the way iterators are boxed to achieve the desired result of recursively exhaust them and build the final result made code look more complex that otherwise it should be.
This is a proposal to simplify this implementation by:

re-using the u and v allocations for compression algorithm
using a more straightforward chunks method that is available on vectors
removing custom arraychunks implementation
Simplifying trait bounds for functions in this module

For the first iteration, we probably do not want to collect the u or v in a vector before compressing them since that would take around 670 Megabytes in memory for 50 million bit multiplications. The current changes would make it necessary to collect the initial iterator over u,v values in a vector.

This change does not require collecting iterators into vectors, it simply re-uses the existing allocation for u and v values

I synced with @danielmasny and he pointed me to the new PR that actually changes how things are passed into this function. It won't be a vec anymore, but an iterator that yields field values for all bits stored in a batch. So it is definitely suboptimal to collect all 50M field values into a vec.
I don't think this PR makes sense

repo: private-attribution/ipa


text:
Please review your logic.

Hi.
This is Bikas Lin, a developer of hopres.io
I am using your python code for generating rarity rank for nfts on hopers.io and it was greatly helpful and saved lots of time.
But unfortunately, I have found some mismatching between generated rarity rank and original metadata.
So I would like you to review your code.
The metadata URL is the following.
https://hopegalaxy.mypinata.cloud/ipfs/QmX1i7DKeHyDHrnhFT8ab4E5mtfgtGH4XQ29ETi3WsGS5a/_metadata.json
https://hopegalaxy.mypinata.cloud/ipfs/QmSiJT5Jz9w55G3S2QUq5ZHz8VxsUFDN7VFYmUGF5U9LYR/_metadata.json
I would be very appreciative if you would test your code with these metadata and check the correctness.

As you can see from the image, the attributes for BAIC3D #472 in calculated data are not the same as the origin metadata(https://hopegalaxy.mypinata.cloud/ipfs/QmSiJT5Jz9w55G3S2QUq5ZHz8VxsUFDN7VFYmUGF5U9LYR/_metadata.json).

And there is no rarity info in calculated data for HexGorilla.457. (https://hopegalaxy.mypinata.cloud/ipfs/QmX1i7DKeHyDHrnhFT8ab4E5mtfgtGH4XQ29ETi3WsGS5a/_metadata.json)

Take a look at this and let me know if it works.
https://github.com/prmali/NFT-Rarity-Scanner/blob/master/src/client/aggregate/cw721.py

Take a look at this and let me know if it works. https://github.com/prmali/NFT-Rarity-Scanner/blob/master/src/client/aggregate/cw721.py

Thanks, it works well.

authors: prmali sheriff-rango

repo: prmali/NFT-Rarity-Scanner


text:
encoder binary classification tasks

Hi @jeff-regier, here is a proposed task list for the new PR related to fixing the new combined encoder so that it can detect galaxies,

[ ] Issues in #46

[x] Fix any remaining bugs in sourcenet.py and sleep.py (currently predicts stars with 100% probability)

[ ] Add a 1/3 galaxies sleep phase test and pass it.

[ ] Add a one star & one galaxy test and pass it.

[ ] Figure out how to train the encoder only once but still pass all the above tests and the existing star one too.

Here is also a list of questions and roadblocks that I can see along the way:

[x] I remember that we used different padding configurations for stars and galaxies (galaxies are bigger than stars). If we want to classify and find both, do we need to find a "sweetspot" ?

[x] Is training the encoder only once (see above) too ambitious?

Please let me know if you have additional suggestions/tasks. Thanks!

This issue is not useful, I prefer the smaller issues like #123 , so I will close it and reopen a more specific one if appropriate later.

repo: prob-ml/bliss


text:
validate BLISS with HST catalogs

compute metrics of agreement of BLISS and SDSS with an HstFullCatalog object serving as the ground truth (avoid counting moving stars)

Using the HST catalog may not be necessary after all. The DECaLS catalog seems to be accurate enough to serve as a proxy for ground truth in our tests with the SDSS data.


text:
revised color model

While working on a case study, I noticed that we're generating some crazy fluxes. I saw cases where the z-band flux was 10,000,000 times as large as the r-band flux. In real data, I don't think you'll find many (any?) objects where fluxes for consecutive bands vary by more than 1 or 2 orders of magnitude, so our color prior seems off here.
This PR partially fixes the problem. I retrained the color model, and revised it to be more canonical: I fit the GMM to log flux ratios for adjacent bands (rather than comparing everything to the r band). Then, in the prior, I clip flux ratios to avoid the most extreme cases. I'm not entirely satisfied with this solution but it seems like an improvement.
@sawanp813 Please check out my changes to load_ratios.ipynb notebook.

@sawanp813 Near the end of load_ratios.ipynb I may have caught/corrected a bug. It appears that the star color GMM was being saved to gal_gmm_nmgy.pkl while the galaxy color GMM was being saved to star_gmm_nmgy.pkl.

Changes look good - I actually was aware of that issue (seeing crazy ratios being sampled in the other bands) but didn't get around to correcting/clipping when we populate each source's flux in simulator. Thanks for catching that!
Is there a particular reason why we take the ratios relative to adjacent bands? It definitely is a reasonable method - is it just to avoid outliers solely with respect to when we take the ratios against the r-band?

@sawanp813 Near the end of load_ratios.ipynb I may have caught/corrected a bug. It appears that the star color GMM was being saved to gal_gmm_nmgy.pkl while the galaxy color GMM was being saved to star_gmm_nmgy.pkl.

I'm guessing I had the order of the models switched when saving via pickle - thanks for noticing that.

I'm not sure whether taking flux ratios with respect to the r band was the problem. I did it this way instead because it's more common/idiomatic to model log ratios of fluxes in adjacent bands: these are what are called "colors". The new GMM seems to be working better though. With the old one, once I started clipping unreasonable samples, a lot were being clipped. With the new GMM, it's much less frequent.

Right - it makes sense to consider adjacent bands since that's how we are defining colors. And if the new GMM doesn't have as many crazy samples, that's also a positive!


text:
Crash in ESTIMATE * FROM VARIABLES OF population WHERE  with ignored variables

Consider
ESTIMATE *
FROM VARIABLES OF gapminder
WHERE DEPENDENCE PROBABILITY WITH "life expectancy at birth" > 0.5

The compiled BQL is
SELECT c.name AS name
FROM bayesdb_population AS p,
bayesdb_variable AS v, bayesdb_column AS c
WHERE
p.id = 1 AND v.population_id = p.id
AND c.tabname = p.tabname
AND c.colno = v.colno
AND v.generator_id IS NULL
AND (bql_column_dependence_probability(1, NULL, 136, c.colno) > 0.5)

Because sqlite does not guarantee the order of evaluation of the expressions in the WHERE clause, it is possible that
bql_column_dependence_probability(1, NULL, 136, c.colno) > 0.5 is evaluated first, which causes a crash if c.colno is IGNORED in the population.
I believe a simple fix is to simply compile as:
SELECT v.name AS name
FROM bayesdb_variable AS v
WHERE population_id = 1
AND v.generator_id IS NULL
AND (bql_column_dependence_probability(1, NULL, 136, v.colno) > 0.5)

It is also the case that the current implementation, which is selecting names from bayesdb_column, skips latent variables.

repo: probcomp/bayeslite


text:
Minor typo in section 19.2 (Distribution shift), latex pg. 727, and Index, version 2023-08-15.

Typo at the third line of section 19.2 (Distribution shift): "Datatset shift". Should be "Dataset shift". This typo is also reflected in the Index.

fixed

authors: cleitonmoya murphyk


text:
missing types in yui docs

here's some errors in the docs:
p5.sound.js:4261, return has invalid type: Tone.Signal
p5.sound.js:4330, return has invalid type: p5.SignalAdd
p5.sound.js:4349, return has invalid type: Tone.Multiply
p5.sound.js:4368, return has invalid type: p5.SignalScale
p5.sound.js:7677, param "input" has invalid type: WebAudioNode
p5.sound.js:7677, param "output" has invalid type: WebAudioNode
p5.sound.js:7677, param "wet" has invalid type: WebAudioNode

because of the age of this issue, i am closing it for now ~

authors: Spongman montoyamoraga


text:
[Feat] :Adding a move to top icon

[Feat] : Adding a move to top icon
#597 - Added the feature.
Feature details-
This feature reduces the time and effort needed to manually scroll up, making navigation smoother.
How to see the change

Scroll Button Location: The "Move to Top" button is positioned at the bottom-right corner of the homepage.
Visibility Condition: The button becomes visible only when the user has scrolled down from the top of the page, enhancing usability by not cluttering the view initially.
Functionality: Clicking on the button will instantly scroll the user back to the top of the page.

This contributes to making the site more intuitive for users, allowing them to quickly navigate long pages, especially helpful on the homepage with multiple sections.
Here is the screenshot
https://github.com/user-attachments/assets/708d5c3e-a335-4aa4-8232-ed384cf866a0

Hi @limzykenneth,
I’ve added the "scroll to top" feature. When you have a moment, could you please review it and let me know if any changes or improvements are needed? If everything looks okay, it would be great if you could merge it.
Thank you so much!

Hi @limzykenneth,
I hope you're doing well! I just wanted to check in regarding the "scroll to top" feature I submitted recently. When you have a moment, could you kindly review it and let me know if any adjustments are needed? If everything looks good, it would be great if you could merge it.
Thank you so much for your time and consideration!

I'm not sure if this is the right way to implement this with inline style and scripts. There really should be some discussions in the issue to determine the implementation first.


text:
Toggle auto-merge with a reduced scope ephemeral token

GitHub support suggested this should prevent auto-merging without required checks.
Change-type: patch

I self-certify!

repo: product-os/flowzone


text:
What can't it do?

Under things it can't do according README.md:

Multi-node. Not a huge leap, but this isn't the project for it. Maybe as Super Dokku.
Multitenancy. It's ready for it, but again, probably for Super Dokku.

Does this mean I can't deploy more than 1 node app (or ruby) app at time time, or something else?
@frillip also.

This still needs to be clarified.

Not sure what you mean. Please be more specific in what needs to be
clarified. This has since been resolved in the docs:
http://progrium.viewdocs.io/dokku/index
On Sun, Feb 1, 2015 at 11:52 AM, Andrew Badr notifications@github.com
wrote:

This still needs to be clarified.
—
Reply to this email directly or view it on GitHub
https://github.com/progrium/dokku/issues/12#issuecomment-72380758.

--
Jeff Lindsay
http://progrium.com

The content I see on that page is almost exactly the same as in naggie's original bug report. Does multitenancy mean multiple apps or multiple users with distinct security privileges?

There is no real concept of users, but multiple apps, sure. I'll update that part.

Thanks! Would have made me more confident before digging in.

authors: naggie progrium reverie

repo: progrium/dokku