text:
Error 400 - Invalid_Request

Each time i try to auth i get the following, the below is from the more details.
The out-of-band (OOB) flow has been blocked in order to keep users secure. Follow the Out-of-Band (OOB) flow Migration Guide linked in the developer docs below to migrate your app to an alternative method.
Request details: access_type=offline response_type=code redirect_uri=urn:ietf:wg:oauth:2.0:oob state=state client_id=367116221053-7n0vf5akeru7on6o2fjinrecpdoe99eg.apps.googleusercontent.com scope=https://www.googleapis.com/auth/drive

I am getting the same error and I dis at least 10 attempts.

Today it worked on the first attemp.

Its been hit and miss... its not really consistent other than it works less than it does.
When it does work... great application

The proper way to do this now seems to be to start up a local webserver and have the redirect_uri set to localhost to return the auth code directly to the app rather than requiring it to be copy-pasted, otherwise known as loopback.

Its been hit and miss... its not really consistent other than it works less than it does.

Same here. When I tried to run it on my Raspberry Pi 4 it complained, running the same thing on my Windows PC worked. Afterwards I just copied the token to the Raspberry 👍🏻
No problems with this so far

@frasercrossman Could you be a little more elaborate on how that should be done? A proper walk-through would be much appreciated

I can't sign in with gdrive about, not even a single success.
It's been there since when I started using this library a week ago.
I've tried several Windows PCs I have but no luck.

Same problem here

Same for me too.

same here:

Same here :(
The out-of-band (OOB) flow has been blocked in order to keep users secure. Follow the Out-of-Band (OOB) flow migration guide linked in the developer docs below to migrate your app to an alternative method.
Request details: redirect_uri=urn:ietf:wg:oauth:2.0:oob

Should be fixed by https://github.com/prasmussen/gdrive/pull/660 (at least until Jan 31 2023)

i find a way for fix this and get a build, this work for now: #665

@BugCode1 Everything works until I clicked on Trust button:
This site can’t be reached
The webpage at http://localhost:1/?state=state&code=4/0AWgavdfD4na4xHuPi7C-DRfURsZnLdk2MOUdUbyZFK-L4VlL1u8cXBbVO1ibNU9qvePbNw&scope=https://www.googleapis.com/auth/drive might be temporarily down or it may have moved permanently to a new web address.
ERR_UNSAFE_PORT

I am using gdrive on AWS EC2 Ubuntu 20.04 instance.

@BugCode1 Instructions doesn't work for me. I am getting "Unable to connect. Firefox can’t establish a connection to the server at localhost:1."

@BugCode1 The webpage at http://localhost:1/?state=state&code=4/0AWtgzh7vF22HJKAQjThFqo8_WO4kTnuW5h5aV_OtO5SZL0RQtAsQJFMDPSgcFbqAWrqi3g&scope=https://www.googleapis.com/auth/drive might be temporarily down or it may have moved permanently to a new web address.
ERR_UNSAFE_PORT

authors: BugCode1 G3zz MrAshRhodes Spit-fires Trysupe coderboy-exe frasercrossman grangep hradec mlauronen rtr-dnd slaff valoriblaise yuenherny

repo: prasmussen/gdrive


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

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

HTTP code: 0
Response time: 0 ms

Resolved: Natural Language <2> SQL Query is back up in 406646f after 3 hours, 19 minutes.

source: gharchive/issue

repo: prateekralhan/status

license: MIT

license_type: permissive

license_source: github-api


text:
Add fullname option to the reddit.redditor method

Fixes #1108
Feature Summary and Justification
As described in #1108, it would be useful to be able to fetch a Redditor by their fullname rather than username.
Using the /api/user_data_by_account_ids to resolve username.
Currently the call is made instantly as the entity is created rather than lazily. This could be changed if desired.
Returns a NotFound exception upon creation if invalid.
name param remains the first arg so is non breaking.
I have written a couple of tests but let me know if there's other edge cases you'd like tested.

Currently the call is made instantly as the entity is created rather than lazily. This could be changed if desired.

Given that PRAW uses lazy-loading in the rest of its codebase, I think this would be appropriate. However, I'm not sure exactly what the change would require. You may have to convert .name to a lazily-loaded property, so that Redditor objects created from fullnames can still get their name when needed.

And thanks for the PR!

Sorry for ignoring this PR for so long @jarhill0!
I've updated it now to be lazy by changing the place we get the name from the constructor to the _fetch calls.
It should be ready for a full review now. Let me know if you want any changes.

Merged. Thanks for the PR @jackodsteel!

source: gharchive/pull-request

repo: praw-dev/praw

license_source: bigquery


text:
Bump minimum Ruby version to 2.6.0

This commit bumps the minimum Ruby version to 2.6.0.  It also bumps the rubocop, rubocop-performance, and rubocop-spec gems to the latest, all of which are compatible with 2.6.0 - 3.1.0.
It also adds .ruby-version to .gitignore to make it easier to use/test with different Rubies

@pointlessone The easiest thing to do is to get this out in a new prawn-dev release and then I can sweep through the downstreams and get them passing.  I'll also update prawn-table to depend on it in the process.

@pointlessone What are the next steps to get this published as a new gem version?  Once that's done it will be straightforward to generate PRs for the downstream gems, but I'm blocked on that until it's published.

@petergoldstein v0.3.0 is now available with these changes.

authors: petergoldstein pointlessone

repo: prawnpdf/prawn-dev


text:
[feat] Custom time

Would it be better if you could customize the time?
If the custom time is through sliding the progress bar, is it more cool!!

what do you mean by customize time ? You can change timers in the small cog button (the 3rd one) when the timer is stopped :)

自定义时间是什么意思？当计时器停止时，您可以在小齿轮按钮（第 3 个）中更改计时器 :)
My error, I didn't see the setting button on the right:laughing:

repo: prazdevs/potato-timer


text:
Draft: Add docs for EUID module.

Added docs for the new EUID ID module, and made a tweak to the UID2 docs to match a new config option.
🏷 Type of documentation

[ ] new bid adapter
[ ] update bid adapter
[x] new feature
[ ] text edit only (wording, typos)
[ ] bugfix (code examples)
[x] new examples

📋 Checklist

[x] Related pull requests in prebid.js or server are linked -> Paste link in this list or reference it on the PR itself
[ ] For new adapters check submitting your adapter docs

Prebid.js PR: https://github.com/prebid/Prebid.js/pull/9968 (I've marked this as a draft until the Prebid.js PR is merged).

Preview link to the module: https://deploy-preview-4603--prebid-docs-preview.netlify.app/dev-docs/modules/userid-submodules/euid.html

@bretg fine by me now.


text:
fix 'npm run watch' docs

The command npm run watch no longer exists. It's now npm run server. This PR fixes the README.

you can just do npm start.

authors: jairovsky phra

repo: preboot/angular-webpack

license: mit


text:
Fatal error: Uncaught Predis\Response\ServerException: ERR syntax error

Describe the bug
Fatal error: Uncaught Predis\Response\ServerException: ERR syntax error
To Reproduce
I have read the issue related to #309, and do the same command like:
$client->set('k1', '1', 'EX', '10', 'PX', '10000', 'NX');,
then run and throw errors as title described.
Expected behavior
Expect to work properly
Versions (please complete the following information):

Predis: [v2.0.1]
PHP [7.2 | 7.4 | 8.1]
Redis Server [5.0.3]
OS [CentOS 7.9]

Code sample
<?php
require dirname(__FILE__, 2) . "/vendor/autoload.php";

$redis = new \Predis\Client();
$redis->connect();
$redis->set('k1', '1', 'EX', '10', 'PX', '10000', 'NX');

SET k1 1 EX 10 PX 10000 NX
ERR syntax error

SET k1 1 EX 10 PX 10000 NX
ERR syntax error

I feel puzzled why u closed this issue, so what's the problem for the code：
$redis->set('k1', '1', 'EX', '10', 'PX', '10000', 'NX');

and I couldn't understand the connection between the code you gave me and the code I described.  tks so much

to put it simply，I just wanna know what is the proper way to use set comand in predis with those extend options like EX、PX or NX and so on.

authors: phpmooc tillkruss

repo: predis/predis


text:
🛑 Secret Site is down

In c1db406, Secret Site ($SECRET_SITE) was down:

HTTP code: 404
Response time: 406 ms

Resolved: Secret Site is back up in a0f188a after 15 hours, 32 minutes.

repo: premii/upptime


text:
Fail to run custom builds on TeamCity 2018.1.2

We just upgraded to TC 2018.1.2 and found that Matrix tab is broken.
I found unreleased fix, compile and apply new version, after that matrix tab is fixed, BUT any custom build  (3 dots new run button) that contains Matrix throw an exception with huge stack trace.
Further more, if and matrix build was added in the queue, you can't open tab with queue
Log is here: TC-custom-build-exception.log

Is it possible to hot fix it? Rollback of a whole server is not what we want

@Chhed13 I'm sorry I don't have a time to work on this plugin. If you have time to prepare PR, I will be glad to review it and merge

@presidentio that's ok. I made small PR that helped us to find the root cause and fix changed params


text:
Current docker image broken

The current docker image uses a binary that is linked against glibc on an alpine base image which provides only musl libc:
/ # file prestd
prestd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, not stripped
/ # ldd prestd
        /lib64/ld-linux-x86-64.so.2 (0x7f27c3563000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f27c3563000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f27c3563000)

the binary will not start as the /lib64/ld-linux-x86-64.so.2 loader is non-existent:
exec container process (missing dynamic library?) `/prestd`: No such file or directory

@HorayNarea not sure if is related but I also having issues trying to use the docker image.
~
➜ docker images | grep prest
prest/prest                                                         latest              4fafc5babb65        7 minutes ago       18.8MB

~
➜ docker run -e PREST_HTTP_PORT=3000 \
        -e PREST_PG_HOST=127.0.0.1 \
        -e PREST_PG_USER=postgres \
        -e PREST_PG_PASS=pass \
        -e PREST_PG_DATABASE=prest \
        prest/prest
standard_init_linux.go:211: exec user process caused "no such file or directory"

/cc @avelino

https://github.com/prest/prest/commit/bd49ff905df5031721ba5c52d70a29dff649d7a9 and v1.0.3 which includes this commit does not fix this problem… it is still linked against glibc and not working in the alpine-based image

bd49ff9 and v1.0.3 which includes this commit does not fix this problem… it is still linked against glibc and not working in the alpine-based image

@HorayNarea I'm working on the correction

I bring great news, problem solved 🚀

sorry for the delay

❯ prest (master) ✔ docker pull prest/prest:latest
latest: Pulling from prest/prest
df20fa9351a1: Already exists
e8de339823c6: Pull complete
b901584b501a: Pull complete
Digest: sha256:4871ba7fb73b396fe25c5bffc340f2192b476f40bf9c78aa0f813654a20e4094
Status: Downloaded newer image for prest/prest:latest
docker.io/prest/prest:latest
❯ prest (master) ✔ docker run -it --rm prest/prest:latest
2020/08/16 20:09:53 [warning] adapter is not set. Using the default (postgres)
2020/08/16 20:09:53 [error] dial tcp 127.0.0.1:5432: connect: connection refused
❯ prest (master) ✔

authors: HorayNarea avelino fabriziomello

repo: prest/prest


text:
Native Parquet Writer

Current parquet writer internally use Hive RecordWriter which converts presto data to Hive structures. The new introduced native parquet writer write directly from presto memory structure to parquet data values, repetition values and definition values. It also has better memory control. Benchmarking of POC shows write throughputs could increase 43% ~ 165% depends on different test cases.
  write       LINEITEM                        NONE        PRESTO_PARQUET             1.12    53.7MB/s ±  1342.5kB/s ( 2.44%) (N = 150, α = 99.9%)
  write       BIGINT_SEQUENTIAL               NONE        PRESTO_PARQUET             1.12    74.5MB/s ±  1826.3kB/s ( 2.39%) (N = 150, α = 99.9%)
  write       BIGINT_RANDOM                   NONE        PRESTO_PARQUET             1.12    72.9MB/s ±  2557.1kB/s ( 3.43%) (N = 150, α = 99.9%)
  write       VARCHAR_SMALL                   NONE        PRESTO_PARQUET             1.05   109.2MB/s ±  4596.2kB/s ( 4.11%) (N = 150, α = 99.9%)
  write       VARCHAR_LARGE                   NONE        PRESTO_PARQUET             1.05   110.5MB/s ±  4263.7kB/s ( 3.77%) (N = 150, α = 99.9%)
  write       VARCHAR_DICTIONARY              NONE        PRESTO_PARQUET             1.08    74.8MB/s ±  1666.6kB/s ( 2.18%) (N = 150, α = 99.9%)
  write       MAP_VARCHAR_DOUBLE              NONE        PRESTO_PARQUET             1.72    52.9MB/s ±  1265.8kB/s ( 2.34%) (N = 150, α = 99.9%)
  write       LARGE_MAP_VARCHAR_DOUBLE        NONE        PRESTO_PARQUET             1.46    68.1MB/s ±  1695.4kB/s ( 2.43%) (N = 150, α = 99.9%)
  write       MAP_INT_DOUBLE                  NONE        PRESTO_PARQUET             1.96    50.4MB/s ±   982.6kB/s ( 1.90%) (N = 150, α = 99.9%)
  write       LARGE_MAP_INT_DOUBLE            NONE        PRESTO_PARQUET             1.83    56.3MB/s ±   786.1kB/s ( 1.36%) (N = 150, α = 99.9%)
  write       LARGE_ARRAY_VARCHAR             NONE        PRESTO_PARQUET             1.07    56.8MB/s ±  1590.1kB/s ( 2.74%) (N = 150, α = 99.9%)
  write       LINEITEM                        NONE        HIVE_PARQUET               1.12    37.5MB/s ±   604.7kB/s ( 1.58%) (N = 150, α = 99.9%)
  write       BIGINT_SEQUENTIAL               NONE        HIVE_PARQUET               1.12    60.5MB/s ±  1434.3kB/s ( 2.32%) (N = 150, α = 99.9%)
  write       BIGINT_RANDOM                   NONE        HIVE_PARQUET               1.12    65.8MB/s ±  2122.9kB/s ( 3.15%) (N = 150, α = 99.9%)
  write       VARCHAR_SMALL                   NONE        HIVE_PARQUET               1.05    41.8MB/s ±   998.6kB/s ( 2.34%) (N = 150, α = 99.9%)
  write       VARCHAR_LARGE                   NONE        HIVE_PARQUET               1.05    41.0MB/s ±   957.6kB/s ( 2.28%) (N = 150, α = 99.9%)
  write       VARCHAR_DICTIONARY              NONE        HIVE_PARQUET               1.08    27.2MB/s ±   381.6kB/s ( 1.37%) (N = 150, α = 99.9%)
  write       MAP_VARCHAR_DOUBLE              NONE        HIVE_PARQUET               1.72    38.2MB/s ±   647.1kB/s ( 1.65%) (N = 150, α = 99.9%)
  write       LARGE_MAP_VARCHAR_DOUBLE        NONE        HIVE_PARQUET               1.46    46.1MB/s ±   880.4kB/s ( 1.87%) (N = 150, α = 99.9%)
  write       MAP_INT_DOUBLE                  NONE        HIVE_PARQUET               1.96    66.3MB/s ±  1046.8kB/s ( 1.54%) (N = 150, α = 99.9%)
  write       LARGE_MAP_INT_DOUBLE            NONE        HIVE_PARQUET               1.84    57.9MB/s ±  1429.4kB/s ( 2.41%) (N = 150, α = 99.9%)
  write       LARGE_ARRAY_VARCHAR             NONE        HIVE_PARQUET               1.07    34.2MB/s ±   455.2kB/s ( 1.30%) (N = 150, α = 99.9%)

(PRESTO_PARQUET is the native parquet writer)

All results as references:
  read        LINEITEM                        NONE        PRESTO_ORC                 2.00   333.1MB/s ±  6003.9kB/s ( 1.76%) (N = 150, α = 99.9%)
  read        LINEITEM                        NONE        PRESTO_PARQUET             1.12   115.0MB/s ±  1533.2kB/s ( 1.30%) (N = 150, α = 99.9%)
  read        LINEITEM                        NONE        HIVE_ORC                   2.04    68.5MB/s ±  1103.2kB/s ( 1.57%) (N = 150, α = 99.9%)
  read        LINEITEM                        NONE        HIVE_PARQUET               1.12   101.0MB/s ±  1505.6kB/s ( 1.46%) (N = 150, α = 99.9%)
  read        BIGINT_SEQUENTIAL               NONE        PRESTO_ORC                 8.88  1095.4MB/s ±    28.7MB/s ( 2.62%) (N = 150, α = 99.9%)
  read        BIGINT_SEQUENTIAL               NONE        PRESTO_PARQUET             1.12   145.9MB/s ±  3048.5kB/s ( 2.04%) (N = 150, α = 99.9%)
  read        BIGINT_SEQUENTIAL               NONE        HIVE_ORC                   8.87   127.8MB/s ±  2484.1kB/s ( 1.90%) (N = 150, α = 99.9%)
  read        BIGINT_SEQUENTIAL               NONE        HIVE_PARQUET               1.12   137.2MB/s ±  1744.7kB/s ( 1.24%) (N = 150, α = 99.9%)
  read        BIGINT_RANDOM                   NONE        PRESTO_ORC                 2.99   820.1MB/s ±    16.5MB/s ( 2.01%) (N = 150, α = 99.9%)
  read        BIGINT_RANDOM                   NONE        PRESTO_PARQUET             1.12   143.8MB/s ±  1803.6kB/s ( 1.22%) (N = 150, α = 99.9%)
  read        BIGINT_RANDOM                   NONE        HIVE_ORC                   2.99   118.6MB/s ±  1921.4kB/s ( 1.58%) (N = 150, α = 99.9%)
  read        BIGINT_RANDOM                   NONE        HIVE_PARQUET               1.12   135.3MB/s ±  1636.1kB/s ( 1.18%) (N = 150, α = 99.9%)
  read        VARCHAR_SMALL                   NONE        PRESTO_ORC                 9.67   661.3MB/s ±  8093.2kB/s ( 1.20%) (N = 150, α = 99.9%)
  read        VARCHAR_SMALL                   NONE        PRESTO_PARQUET             1.05   148.6MB/s ±  2381.6kB/s ( 1.56%) (N = 150, α = 99.9%)
  read        VARCHAR_SMALL                   NONE        HIVE_ORC                   9.66    99.3MB/s ±  1246.8kB/s ( 1.23%) (N = 150, α = 99.9%)
  read        VARCHAR_SMALL                   NONE        HIVE_PARQUET               1.05   141.7MB/s ±  2195.2kB/s ( 1.51%) (N = 150, α = 99.9%)
  read        VARCHAR_LARGE                   NONE        PRESTO_ORC                 9.67   652.3MB/s ±  8406.9kB/s ( 1.26%) (N = 150, α = 99.9%)
  read        VARCHAR_LARGE                   NONE        PRESTO_PARQUET             1.05   147.0MB/s ±  3201.5kB/s ( 2.13%) (N = 150, α = 99.9%)
  read        VARCHAR_LARGE                   NONE        HIVE_ORC                   9.66    96.5MB/s ±  1822.4kB/s ( 1.84%) (N = 150, α = 99.9%)
  read        VARCHAR_LARGE                   NONE        HIVE_PARQUET               1.05   140.8MB/s ±  1885.7kB/s ( 1.31%) (N = 150, α = 99.9%)
  read        VARCHAR_DICTIONARY              NONE        PRESTO_ORC                 23.04  1334.3MB/s ±    13.2MB/s ( 0.99%) (N = 150, α = 99.9%)
  read        VARCHAR_DICTIONARY              NONE        PRESTO_PARQUET             1.08   100.2MB/s ±  1555.6kB/s ( 1.52%) (N = 150, α = 99.9%)
  read        VARCHAR_DICTIONARY              NONE        HIVE_ORC                   22.99    67.9MB/s ±   987.1kB/s ( 1.42%) (N = 150, α = 99.9%)
  read        VARCHAR_DICTIONARY              NONE        HIVE_PARQUET               1.08    93.3MB/s ±  1982.9kB/s ( 2.07%) (N = 150, α = 99.9%)
  read        MAP_VARCHAR_DOUBLE              NONE        PRESTO_ORC                 3.20   497.6MB/s ±  6970.6kB/s ( 1.37%) (N = 150, α = 99.9%)
  read        MAP_VARCHAR_DOUBLE              NONE        PRESTO_PARQUET             1.72   118.3MB/s ±  1537.4kB/s ( 1.27%) (N = 150, α = 99.9%)
  read        MAP_VARCHAR_DOUBLE              NONE        HIVE_ORC                   3.20    35.2MB/s ±   463.1kB/s ( 1.28%) (N = 150, α = 99.9%)
  read        MAP_VARCHAR_DOUBLE              NONE        HIVE_PARQUET               1.72   107.1MB/s ±  1794.6kB/s ( 1.64%) (N = 150, α = 99.9%)
  read        LARGE_MAP_VARCHAR_DOUBLE        NONE        PRESTO_ORC                 1.74   292.7MB/s ±  4445.9kB/s ( 1.48%) (N = 150, α = 99.9%)
  read        LARGE_MAP_VARCHAR_DOUBLE        NONE        PRESTO_PARQUET             1.46   129.8MB/s ±  2923.2kB/s ( 2.20%) (N = 150, α = 99.9%)
  read        LARGE_MAP_VARCHAR_DOUBLE        NONE        HIVE_ORC                   1.74    53.4MB/s ±   704.8kB/s ( 1.29%) (N = 150, α = 99.9%)
  read        LARGE_MAP_VARCHAR_DOUBLE        NONE        HIVE_PARQUET               1.46   119.3MB/s ±  1754.8kB/s ( 1.44%) (N = 150, α = 99.9%)
  read        MAP_INT_DOUBLE                  NONE        PRESTO_ORC                 2.74   472.2MB/s ±  5251.9kB/s ( 1.09%) (N = 150, α = 99.9%)
  read        MAP_INT_DOUBLE                  NONE        PRESTO_PARQUET             1.96   155.0MB/s ±  2827.7kB/s ( 1.78%) (N = 150, α = 99.9%)
  read        MAP_INT_DOUBLE                  NONE        HIVE_ORC                   2.74    53.6MB/s ±  1006.0kB/s ( 1.83%) (N = 150, α = 99.9%)
  read        MAP_INT_DOUBLE                  NONE        HIVE_PARQUET               1.96   150.5MB/s ±  2310.7kB/s ( 1.50%) (N = 150, α = 99.9%)
  read        LARGE_MAP_INT_DOUBLE            NONE        PRESTO_ORC                 1.83   381.3MB/s ±  4885.8kB/s ( 1.25%) (N = 150, α = 99.9%)
  read        LARGE_MAP_INT_DOUBLE            NONE        PRESTO_PARQUET             1.83   152.6MB/s ±  2873.0kB/s ( 1.84%) (N = 150, α = 99.9%)
  read        LARGE_MAP_INT_DOUBLE            NONE        HIVE_ORC                   1.84    97.9MB/s ±  5705.6kB/s ( 5.69%) (N = 150, α = 99.9%)
  read        LARGE_MAP_INT_DOUBLE            NONE        HIVE_PARQUET               1.84   147.2MB/s ±  2206.6kB/s ( 1.46%) (N = 150, α = 99.9%)
  read        LARGE_ARRAY_VARCHAR             NONE        PRESTO_ORC                 1.44   241.6MB/s ±  5157.7kB/s ( 2.08%) (N = 150, α = 99.9%)
  read        LARGE_ARRAY_VARCHAR             NONE        PRESTO_PARQUET             1.07    91.1MB/s ±  1925.7kB/s ( 2.06%) (N = 150, α = 99.9%)
  read        LARGE_ARRAY_VARCHAR             NONE        HIVE_ORC                   1.44    37.4MB/s ±   573.8kB/s ( 1.50%) (N = 150, α = 99.9%)
  read        LARGE_ARRAY_VARCHAR             NONE        HIVE_PARQUET               1.07    83.4MB/s ±  1717.9kB/s ( 2.01%) (N = 150, α = 99.9%)
  write       LINEITEM                        NONE        PRESTO_ORC                 2.00    58.8MB/s ±  1032.0kB/s ( 1.72%) (N = 150, α = 99.9%)
  write       LINEITEM                        NONE        PRESTO_PARQUET             1.12    53.7MB/s ±  1342.5kB/s ( 2.44%) (N = 150, α = 99.9%)
  write       LINEITEM                        NONE        HIVE_ORC                   2.04    57.5MB/s ±   774.4kB/s ( 1.32%) (N = 150, α = 99.9%)
  write       LINEITEM                        NONE        HIVE_PARQUET               1.12    37.5MB/s ±   604.7kB/s ( 1.58%) (N = 150, α = 99.9%)
  write       BIGINT_SEQUENTIAL               NONE        PRESTO_ORC                 8.88   246.1MB/s ±  4550.7kB/s ( 1.81%) (N = 150, α = 99.9%)
  write       BIGINT_SEQUENTIAL               NONE        PRESTO_PARQUET             1.12    74.5MB/s ±  1826.3kB/s ( 2.39%) (N = 150, α = 99.9%)
  write       BIGINT_SEQUENTIAL               NONE        HIVE_ORC                   8.87    99.7MB/s ±  1511.6kB/s ( 1.48%) (N = 150, α = 99.9%)
  write       BIGINT_SEQUENTIAL               NONE        HIVE_PARQUET               1.12    60.5MB/s ±  1434.3kB/s ( 2.32%) (N = 150, α = 99.9%)
  write       BIGINT_RANDOM                   NONE        PRESTO_ORC                 2.99   123.1MB/s ±  3335.1kB/s ( 2.65%) (N = 150, α = 99.9%)
  write       BIGINT_RANDOM                   NONE        PRESTO_PARQUET             1.12    72.9MB/s ±  2557.1kB/s ( 3.43%) (N = 150, α = 99.9%)
  write       BIGINT_RANDOM                   NONE        HIVE_ORC                   2.99    74.7MB/s ±  1178.3kB/s ( 1.54%) (N = 150, α = 99.9%)
  write       BIGINT_RANDOM                   NONE        HIVE_PARQUET               1.12    65.8MB/s ±  2122.9kB/s ( 3.15%) (N = 150, α = 99.9%)
  write       VARCHAR_SMALL                   NONE        PRESTO_ORC                 9.67    94.0MB/s ±  1831.2kB/s ( 1.90%) (N = 150, α = 99.9%)
  write       VARCHAR_SMALL                   NONE        PRESTO_PARQUET             1.05   109.2MB/s ±  4596.2kB/s ( 4.11%) (N = 150, α = 99.9%)
  write       VARCHAR_SMALL                   NONE        HIVE_ORC                   9.66    14.9MB/s ±   199.7kB/s ( 1.31%) (N = 150, α = 99.9%)
  write       VARCHAR_SMALL                   NONE        HIVE_PARQUET               1.05    41.8MB/s ±   998.6kB/s ( 2.34%) (N = 150, α = 99.9%)
  write       VARCHAR_LARGE                   NONE        PRESTO_ORC                 9.67    93.4MB/s ±  1576.2kB/s ( 1.65%) (N = 150, α = 99.9%)
  write       VARCHAR_LARGE                   NONE        PRESTO_PARQUET             1.05   110.5MB/s ±  4263.7kB/s ( 3.77%) (N = 150, α = 99.9%)
  write       VARCHAR_LARGE                   NONE        HIVE_ORC                   9.66    14.9MB/s ±   187.3kB/s ( 1.23%) (N = 150, α = 99.9%)
  write       VARCHAR_LARGE                   NONE        HIVE_PARQUET               1.05    41.0MB/s ±   957.6kB/s ( 2.28%) (N = 150, α = 99.9%)
  write       VARCHAR_DICTIONARY              NONE        PRESTO_ORC                 23.04   101.4MB/s ±  1831.4kB/s ( 1.76%) (N = 150, α = 99.9%)
  write       VARCHAR_DICTIONARY              NONE        PRESTO_PARQUET             1.08    74.8MB/s ±  1666.6kB/s ( 2.18%) (N = 150, α = 99.9%)
  write       VARCHAR_DICTIONARY              NONE        HIVE_ORC                   22.99    44.2MB/s ±   773.0kB/s ( 1.71%) (N = 150, α = 99.9%)
  write       VARCHAR_DICTIONARY              NONE        HIVE_PARQUET               1.08    27.2MB/s ±   381.6kB/s ( 1.37%) (N = 150, α = 99.9%)
  write       MAP_VARCHAR_DOUBLE              NONE        PRESTO_ORC                 3.20   153.4MB/s ±  3598.5kB/s ( 2.29%) (N = 150, α = 99.9%)
  write       MAP_VARCHAR_DOUBLE              NONE        PRESTO_PARQUET             1.72    52.9MB/s ±  1265.8kB/s ( 2.34%) (N = 150, α = 99.9%)
  write       MAP_VARCHAR_DOUBLE              NONE        HIVE_ORC                   3.20    57.7MB/s ±   815.6kB/s ( 1.38%) (N = 150, α = 99.9%)
  write       MAP_VARCHAR_DOUBLE              NONE        HIVE_PARQUET               1.72    38.2MB/s ±   647.1kB/s ( 1.65%) (N = 150, α = 99.9%)
  write       LARGE_MAP_VARCHAR_DOUBLE        NONE        PRESTO_ORC                 1.74    22.5MB/s ±   618.1kB/s ( 2.68%) (N = 150, α = 99.9%)
  write       LARGE_MAP_VARCHAR_DOUBLE        NONE        PRESTO_PARQUET             1.46    68.1MB/s ±  1695.4kB/s ( 2.43%) (N = 150, α = 99.9%)
  write       LARGE_MAP_VARCHAR_DOUBLE        NONE        HIVE_ORC                   1.74  10170.2kB/s ±   148.0kB/s ( 1.45%) (N = 150, α = 99.9%)
  write       LARGE_MAP_VARCHAR_DOUBLE        NONE        HIVE_PARQUET               1.46    46.1MB/s ±   880.4kB/s ( 1.87%) (N = 150, α = 99.9%)
  write       MAP_INT_DOUBLE                  NONE        PRESTO_ORC                 2.74   245.3MB/s ±  7993.0kB/s ( 3.18%) (N = 150, α = 99.9%)
  write       MAP_INT_DOUBLE                  NONE        PRESTO_PARQUET             1.96    50.4MB/s ±   982.6kB/s ( 1.90%) (N = 150, α = 99.9%)
  write       MAP_INT_DOUBLE                  NONE        HIVE_ORC                   2.74   101.6MB/s ±  1680.9kB/s ( 1.62%) (N = 150, α = 99.9%)
  write       MAP_INT_DOUBLE                  NONE        HIVE_PARQUET               1.96    66.3MB/s ±  1046.8kB/s ( 1.54%) (N = 150, α = 99.9%)
  write       LARGE_MAP_INT_DOUBLE            NONE        PRESTO_ORC                 1.83   204.4MB/s ±  9800.7kB/s ( 4.68%) (N = 150, α = 99.9%)
  write       LARGE_MAP_INT_DOUBLE            NONE        PRESTO_PARQUET             1.83    56.3MB/s ±   786.1kB/s ( 1.36%) (N = 150, α = 99.9%)
  write       LARGE_MAP_INT_DOUBLE            NONE        HIVE_ORC                   1.84    67.2MB/s ±  2107.8kB/s ( 3.06%) (N = 150, α = 99.9%)
  write       LARGE_MAP_INT_DOUBLE            NONE        HIVE_PARQUET               1.84    57.9MB/s ±  1429.4kB/s ( 2.41%) (N = 150, α = 99.9%)
  write       LARGE_ARRAY_VARCHAR             NONE        PRESTO_ORC                 1.44    17.6MB/s ±   577.5kB/s ( 3.20%) (N = 150, α = 99.9%)
  write       LARGE_ARRAY_VARCHAR             NONE        PRESTO_PARQUET             1.07    56.8MB/s ±  1590.1kB/s ( 2.74%) (N = 150, α = 99.9%)
  write       LARGE_ARRAY_VARCHAR             NONE        HIVE_ORC                   1.44  4149.8kB/s ±    69.0kB/s ( 1.66%) (N = 150, α = 99.9%)
  write       LARGE_ARRAY_VARCHAR             NONE        HIVE_PARQUET               1.07    34.2MB/s ±   455.2kB/s ( 1.30%) (N = 150, α = 99.9%)

This is great! Do you have a timeline for putting up the first PR? Having a native Parquet writer will also be beneficial for Iceberg.

Hi, I am in the middle of sth else. Please expect the first PR in two weeks. thanks!

authors: electrum qqibrow

repo: prestosql/presto


text:
A way to drop statistics

When using wide Hive tables, stats on all columns are usually redundant.
Currently we pull all stats from Metastore, which is expensive for wide tables.
Beside allowing users to analyze subset of columns (https://github.com/prestosql/presto/issues/1884),
we should provide a way to drop existing stats

Closed via #2538

authors: ebyhr findepi


text:
Absence of height and vertical speed

After analyzing the GPY files in the latest version of GPS results there were 2 fields empty: (Alt[m] and [knts]) .
When I checked with Manfred Fuchs he indicated that these fields (height and vertical speed) are not stored in GPY. Although for speed windsurfing I don't believe this is a relevant field, but for other sports (skiing, sky-diving, ...) it might be very valuable. As this is an open-source format, it is a valuable field. I don't think the file-size would increase a lot having this field available.
I also don't know if the field need to be used once available and if it is not used by the GPS logger, if the file size would even grow at all.
Manfred did point out that it does require an update of the software once enabled.

There are lots of fields in NAV-PVT sentences that could be useful in other sports. None of those are needed for speedsurfing, and they all would increase the size of the file format, so they will not be added to the minimal format. Adding the two fields you mentioned would increase the file size by 20%, with zero gain for the current purpose. For sports like skydiving, the increase in actual file size would likely be significantly larger since compression overflows would be much more frequent.
The original plan was to make the gpy format extendable. Implementing this would allow the storage of arbitrary other data, but it would also make the parsers more complicated. The actual gain would be somewhat limited, at least with respect to the EPS logger, since anyone interested in other applications can simply log in ubx format.

authors: Freezer-SD prichterich

repo: prichterich/compactgnss


text:
[routing] Map named capture groups to request.path.<name>

Currently, it is possible to access the parts of a pathname via the request.path array:
router.get(`/namespace/action/([a-z0-9]*)`, request => {
   const [,, _id] = request.path;
});

It would be more convenient to populate request.path with the results of matching named capture groups, such as that the name of the capture group is available as a property on request.path.
router.get(`/namespace/action/(?<_id>[a-z0-9]*)`, request => {
   // still works
   const [,, _id] = request.path;
   // but also available as
   const {"_id": also_id} = request.path;
});

done as of 916b134

repo: primatejs/primate


text:
Spike: Button with css

Going to test this with dotcom
Bundled css as into one file, needs to be imported explicitly
import {Button} from '@primer/react/lib-esm/drafts/Button2'
import '@primer/react/lib-esm/components.css'

This PR is busted 😢, going to nuke it and start over from main
@langermank, saw your comment, will copy it on the new PR!

repo: primer/react


text:
Primer box-shadow update

Closes https://github.com/github/primer/issues/3362

This needs to be updated to also support tokens that use box-shadow to mimic a border (https://primer.style/foundations/primitives/color#shadow)

repo: primer/stylelint-config


text:
removeListener function removes all subscriptions for a given listener and eventName

As per Nodejs EventEmitter documentation for removeListener function:

removeListener will remove, at most, one instance of a listener from the listener array. If any single listener has been added multiple times to the listener array for the specified eventName, then removeListener must be called multiple times to remove each instance.

eventEmitter3 removeListener implementation however seems to be removing all the subscriptions for a given eventName and listener function. Following is a sample code to reproduce the issue.
var emitter = new window.EventEmitter();
var fn = function(){ alert("called");}

//add fn listener twice for event1
emitter.on("event1", fn);
emitter.on("event1", fn);

//try removing one listener
emitter.removeListener("event1",fn);

//expected: fn should get called once
//actual: fn doesn't get called
emitter.emit("event1");

Yes, this is expected, that's how it is implemented in eventemitter3.

I see. Interesting. This is a deviation from the behavior documented on nodejs site here and implemented by eventemitter2 library.

Yes, you can even remove all listeners of a given event if you don't pass a function.
ee.removeListner('event');

is the equivalent to
ee.removeAllListeners('event');

Good to know that. Thanks.
I think the point I am trying to make here is that, although it's a rare edge case,technically it's not a 100% 'drop in replacement for existing EventEmitters' as it does modify an existing behavior :)

You are correct, but It has been like this as long as I can remember.
Maybe it makes sense to document this deviation.

I agree.

Want to send a pr?

Sorry for the delay. Thanks for the closure.

No problem.

authors: chintan-solanki lpinca


text:
Question about the length-normalization

Hi, thank you for the interesting work.
I have a question regarding the length-normalization in the “scripts/simpo_trainer.py” file. It appears that the key difference in the concatenated_forward function between simpo_trainer and dpo_trainer is that simpo_trainer uses average_log_prob. I assume that setting average_log_prob=True averages over loss_mask.sum(-1), contributing to the length-normalization in simpo. Does this interpretation make sense?
Thanks!

Yes, that's where the length-normalization was implemented.
Thanks,
Yu

repo: princeton-nlp/SimPO


text:
Reproducing on NeRF synthetic dataset

Hi,
Thanks for sharing the code!
Is it possible for you to share the configs for the NeRF synthetic dataset or the pre-trained models? That would be very helpful!
Thanks!

Thanks for update, closing this issue

repo: princeton-vl/SNP


text:
White blocks in Scene

Describe the bug
A clear and concise description of what the bug is.
I am getting white blocks in my desert scene. tried the "hide viewport" property but assets are not shown fully.

Steps to Reproduce
What version of the code were you using?
'''
What is the output of git log -n 1?
v1.0.4
'''
What command did you run?
python -m tools.manage_datagen_jobs --output_folder outputs/hello_world --num_scenes 1 --specific_seed 0
--configs desert.gin simple.gin --pipeline_configs local_16GB.gin monocular.gin blender_gt.gin --pipeline_overrides LocalScheduleHandler.use_gpu=False

What are your FULL output logs?

If this is your first time running Infinigen, what are the full output logs of install.sh ?**
Platform

OS & OS Version: macOS Ventura 13.4 (22F66) (Macbook Air M2)
GPU (?) : Apple M2 GPU
GPU Driver Version (?) :
RAM (GB): 16GB

Additional context
Add any other context about the problem here.

Getting the exact same issue

authors: XeuniceX munsonbh

repo: princeton-vl/infinigen


text:
Test autocrop QA with new Master script

Now that the master script is up and running the first task will be to get the autocrop test script back up and running. After that, the subprocesses like clearing old results and collating metadata can be implemented – in addition to any new metrics for the metadata.

This is currently working with the autocrop script but because of some difficulty with sbatch accepting arguments when it is called from Python, the log files for the qa scripts are put into the logs folder where qa.py and qa_autocrop.py are currently run.

repo: printprobability/qa-workflow


text:
AFK

Auto-set AFK status when the player is inactive. And kick after the time allowed has expired.
Make kicking OPs configurable.

#11 Added AFK command and cancelled damage if the user is AFK. Need to add logic to kick player after x time.

repo: prism/Bedrock


text:
Plugin does not recognize custom typings

Issue
There are some packages that don't have types, so I created an index.d.ts file then I declared them there. It works fine when the source is compiled locally but when I'm trying to run any serverless command, it stucks with the following error:
Could not find a declaration file for module ... implicitly has an 'any' type. Try npm install ... if it exists or add a new declaration (.d.ts) file containing declare module ...;
TS Config
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "lib": [
      "es2016",
      "dom"
    ],
    "outDir": ".build",
    "rootDir": "./",
    "removeComments": true,
    "preserveConstEnums": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": false,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "pretty": true,
    "inlineSourceMap": true,
    "inlineSources": true
  },
  "exclude": [
    "node_modules",
    "src/types"
  ],
  "typeRoots": [
    "node_modules/@types",
    "src/types"
  ]
}

@slnz00 were you been able to fix this? I'm running into the same issue.

Oh nevermind! I just fixed my issue following this comment: https://github.com/prisma/serverless-plugin-typescript/issues/92#issuecomment-400984161

@andreyvital Does this issue need more attention or can I close this in favour of #92?

same to you

I resolved this with typeRoots. The typeRoots  all paths are relative to the tsconfig.json. My tsconfig.json is below
{
  "compilerOptions": {
    "typeRoots": ["./src/typings/", "./node_modules/@types/"],
    "module": "commonjs",
    .....
  }
}

project directory struct
project
  -- src/typings/global/index.d.ts
  ....


text:
Type information is lost for scalar types

I'm using various scalars from the @okgrow/graphql-scalars package, such as:
const NonNegativeIntScalar = asNexusMethod(NonNegativeInt, 'nonNegativeInt');
Applying such a scalar to a field using:
t.nonNegativeInt('totalCount');
will produce an "any" type in the resulting typescript file, instead of the more specific "number":
totalCount: any; // NonNegativeInt!
I wanted to ask if there might be a way to provide a type hint when creating the scalar, for example like this: asNexusMethod(NonNegativeInt, 'nonNegativeInt', { targetType: 'number' });
It'd be great if this type information doesn't get lost when working with scalars. Since it's quite an overhead to manually specify all these types and merging them with typegenAutoConfig.

It'd be great if this type information doesn't get lost when working with scalars. Since it's quite an overhead to manually specify all these types and merging them with typegenAutoConfig.

Have you seen the backingTypeMap option of typegenAutoConfig. Makes it a little simpler to specify them manually, and I believe it should do what you're looking for.
I do like the idea of adding the targetType or similar though to provide this as runtime info. Would like some better options for runtime type specification in general (see #17).

I have indeed missed the backingTypeMap option and managed to get it to work using the following options:
const schema = makeSchema({
  types: [Query, collectionSchema, commonSchema, companySchema],
  outputs: {
    schema: path.join(__dirname, '..', 'schema.graphql'),
    typegen: path.join(__dirname, 'generated', 'nexus-typegen.ts'),
  },
  typegenAutoConfig: {
    contextType: 'common.Context',
    sources: [
      {
        alias: 'common',
        source: path.join(__dirname, 'common', 'commonTypes.ts'),
      },
    ],
    backingTypeMap: {
      NonNegativeInt: 'number',
    },
  },
});

This is not directly related to the initial issue, however, when running the compiled version in the dist directory, Nexus prints the following message:
"GraphQL Nexus: Unable to find file or module /Users/user/project/dist/common/commonTypes.ts, skipping
Missing required typegen import: common"
I've used the approach from the ghost example, have I missed something here?

Yep, the issue is that your makeSchema file is in /src which gets compiled to dist starts up from there, and you're looking for commonTypes.ts which doesn't exist. You either want the .d.ts (assuming you're outputting those):
path.join(__dirname, 'common', 'commonTypes.d.ts'),

or the .ts that is up a directory in src
path.join(__dirname, '../src/common', 'commonTypes.ts'),

One should clearly restrain from late night coding ;-). Thanks for your help!
Btw, I'm really enjoying the DX so far, great work!

repo: prisma/nexus


text:
Allow data proxy with local environments

Problem
I want to use the prisma data proxy but the fact the prisma environments are tied to github branches for their schema definition makes this hugely impractical. I have a dedicated local database with no static github branch associated to it for it to pull the schema.
I don't know whether this is on the roadmap or even possible to resolve.
Suggested solution
One option could be to use introspection against the database instance for the prisma data platform environment's schema definition, rather than the files hosted in github. Don't know if that's actually possible but i've seen some introspection stuff in your docs and I know it would be viable with graphql so 🤷
Alternatives
Another option would be manage whether data proxy is on or off via an environment variable rather than in the prisma generate command itself as this is the reason why i can't easily run my local environment with a direct connection and my deployed environments with the data proxy.

Hi @janpio, apologies, ill try again. I think i confused the issue by referring to the database as "local", i just mean it's the database I use for my development cycles. It's a fully fledged cloud hosted available database.
I have 3 databases, 1 for local development cycles (that i was calling my local database, ill call this development from here on out), 1 for a stable development environment (i'll call this staging from here on out to avoid confusion) and another for production.
The staging and production databases have stable schema files accessible in github by prisma data platform, but the development database doesnt as the schema file is in flux on my machine. For that reason, i can't connect a prisma data proxy to it. I would love to be able to as my database is in east US and i'm in New Zealand, so local development is painfully slow. Having the data proxy in east US speeds things up by miles in my testing.
I was enquiring after 2 things.

Is it possible to have the data proxy access the schema in more ways than a github branch, like introspection for instance, which would work with a database that gets used for local development cycles.
Failing that, manage whether the data proxy is on or off via an environment variable rather than a flag on the prisma generate command so I can have the same generate command across my environments and avoid the data proxy locally. i.e. prisma generate checks whether a PRISMA_ALLOW_DATA_PROXY env variable is set to decide whether it generates the stripped back or full blown query engine.

I know i could set option 2 up myself with a bash script or something but just suggesting it here as needing to figure it out yourself might be holding people back from using the data proxy?
In my case, its not worth doing as my local environment is where I want the data proxy most 😆 However if it was just an env var or something I probably would adopt it for the benefits my staging and production environments would get.

I think i confused the issue by referring to the database as "local", i just mean it's the database I use for my development cycles. It's a fully fledged cloud hosted available database.
I have 3 databases, 1 for local development cycles (that i was calling my local database, ill call this development from here on out), 1 for a stable development environment (i'll call this staging from here on out to avoid confusion) and another for production.

Thanks, that indeed makes much more sense now 👍

The staging and production databases have stable schema files accessible in github by prisma data platform, but the development database doesnt as the schema file is in flux on my machine. For that reason, i can't connect a prisma data proxy to it. I would love to be able to as my database is in east US and i'm in New Zealand, so local development is painfully slow. Having the data proxy in east US speeds things up by miles in my testing.

Actually, the Data Proxy will not even use the Prisma Schema from your PDP account. It will upload the local version of the schema file when you start using it. I know, that is not super obvious, but the PDP Schema is actually only used for the functionality in there and not the Data Proxy.
Does that maybe already resolve your situation?

Is it possible to have the data proxy access the schema in more ways than a github branch, like introspection for instance, which would work with a database that gets used for local development cycles.

Yes, when you create a project you can finish the whole flow without actually connecting to a GitHub repository. That will use Introspection of the database instead of reading the file. Problem is that as soon as one environment is connected, all of them are.
So maybe you could create another project in PDP and to the Introspection only onboarding there and use your development database via that. Not optiomal, as you will have 2 projects, but maybe that is acceptable to you.

Failing that, manage whether the data proxy is on or off via an environment variable rather than a flag on the prisma generate command so I can have the same generate command across my environments and avoid the data proxy locally. i.e. prisma generate checks whether a PRISMA_ALLOW_DATA_PROXY env variable is set to decide whether it generates the stripped back or full blown query engine.

Unfortunately not easily right now, as we run and generate different code based on the --data-proxy flag during generate. We will hopefully get there one day.

Nice. I'll close the issue for now, but please follow up if this works or not.

Hey there @janpio , thanks for the help. Yep it's worked nicely, i now have a hosted data browser and query tool for each of my environments, it's great :)

@reubenjh or @janpio, could you say a little bit more about the solution here? I'm having the same problem, but am not quite following the conversation on how to fix.
At, least I think I'm having the same problem, describing here to confirm...
In production, I have to use the data proxy because I want to use Vercel's edge runtime. But for local development, I have a database running on localhost that is not accessible to the internet and thus cannot be used with the data proxy.
Is there a way to say "use the data proxy in production, but not for local development?"

Hi @jveldridge , basically, I was wanting to use a dataproxy locally, but have it introspect my database's schema rather than read it from a schema file, since i change it during development of new features without committing. It turns out you can create a project /environment without connecting to a github account and it wont ask for the file or branch where the schema file exists, it will introspect instead.
So I ended up being able to use the data proxy locally. However, it turns out to be a terrible idea as the data proxy is on the other side of the world from me so local dev was too slow. I've since actually reverted off the data proxy entirely, I should probably be on it but I just ran out of time to think about it and it is so fast as is anyway that it didnt seem important anymore.
Good luck! No idea about edge stuff sorry

@jveldridge As Reuben already explained, your question is a different one.
In your case, we don't have a great answer yet - to run a local DataProxy.
I would suggest to differentiate testing and deployment for both the Client import (normal vs. edge), the connection string, and how you generate the Client (generate vs. generate --data-proxy). I know that is not great, and we are working on improving this right now. Can't promise it will make the next release though, but hopefully the one after.
Can you maybe open a new issue @jveldridge? Then we can make sure we properly fix your use case. Thanks!

Thanks to you both for clarifying.
I'm going to hold off on opening a new issue since I'm going to be moving away from Prisma and don't want anything overindexed on my use case.

authors: janpio jveldridge reubenjh

repo: prisma/prisma


text:
Warnings when bundling Prisma Client with esbuild

Bug description
When bundling a project using a Prisma Client with esbuild, esbuild complaints about “‘dead’ conditional branches that can never be reached” in the package.json of the client.
How to reproduce

In a project using a Prisma Client, run prisma generate to generate the client, resulting in the package.json file shown below
Run esbuild --bundle --platform=node --packages=bundle --format=esm on the project’s entrypoint
Observe the following output, originating here:

▲ [WARNING] The condition "default" here will never be used as it comes after both "import" and "require" [package.json]

    prisma/client/package.json:25:6:
      25 │       "default": "./index.js"
         ╵       ~~~~~~~~~

  The "import" condition comes earlier and will be used for all "import" statements:

    prisma/client/package.json:17:6:
      17 │       "import": {
         ╵       ~~~~~~~~

  The "require" condition comes earlier and will be used for all "require" calls:

    prisma/client/package.json:9:6:
      9 │       "require": {
        ╵       ~~~~~~~~~

[… and similar warnings for every export]

Is the package.json created by prisma generate syntactically correct?
Expected behavior
No warnings and no “dead” conditional branches that can never be reached in the client’s package.json
Prisma information

generator client {
  provider        = "prisma-client-js"
  output          = "./client"
  […]
}

[…]

  […]
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "require": {
        "node": "./index.js",
        "edge-light": "./wasm.js",
        "workerd": "./wasm.js",
        "worker": "./wasm.js",
        "browser": "./index-browser.js",
        "default": "./index.js"
      },
      "import": {
        "node": "./index.js",
        "edge-light": "./wasm.js",
        "workerd": "./wasm.js",
        "worker": "./wasm.js",
        "browser": "./index-browser.js",
        "default": "./index.js"
      },
      "default": "./index.js"
    },
    "./edge": {
      "types": "./edge.d.ts",
      "require": "./edge.js",
      "import": "./edge.js",
      "default": "./edge.js"
    },
    "./react-native": {
      "types": "./react-native.d.ts",
      "require": "./react-native.js",
      "import": "./react-native.js",
      "default": "./react-native.js"
    },
    "./extension": {
      "types": "./extension.d.ts",
      "require": "./extension.js",
      "import": "./extension.js",
      "default": "./extension.js"
    },
    "./index-browser": {
      "types": "./index.d.ts",
      "require": "./index-browser.js",
      "import": "./index-browser.js",
      "default": "./index-browser.js"
    },
    "./index": {
      "types": "./index.d.ts",
      "require": "./index.js",
      "import": "./index.js",
      "default": "./index.js"
    },
    "./wasm": {
      "types": "./wasm.d.ts",
      "require": "./wasm.js",
      "import": "./wasm.js",
      "default": "./wasm.js"
    },
    "./runtime/library": {
      "types": "./runtime/library.d.ts",
      "require": "./runtime/library.js",
      "import": "./runtime/library.js",
      "default": "./runtime/library.js"
    },
    "./runtime/binary": {
      "types": "./runtime/binary.d.ts",
      "require": "./runtime/binary.js",
      "import": "./runtime/binary.js",
      "default": "./runtime/binary.js"
    },
    "./generator-build": {
      "require": "./generator-build/index.js",
      "import": "./generator-build/index.js",
      "default": "./generator-build/index.js"
    },
    "./*": "./*"
  },
  […]

Environment & setup

OS: Alpine Linux v3.20.2
Database: PostgreSQL
Node.js version: 22.6.0

Prisma Version
prisma                  : 5.18.0
@prisma/client          : 5.18.0
Computed binaryTarget   : linux-musl-arm64-openssl-3.0.x
Operating System        : linux
Architecture            : arm64
Node.js                 : v22.6.0
Query Engine (Node-API) : libquery-engine  (at ../../tools/node_modules/@prisma/engines/libquery_engine-linux-musl-arm64-openssl-3.0.x.so.node)
Schema Engine           : schema-engine-cli  (at ../../tools/node_modules/@prisma/engines/schema-engine-linux-musl-arm64-openssl-3.0.x)
Schema Wasm             : @prisma/prisma-schema-wasm 5.18.0-25.4c784e32044a8a016d99474bd02a3b6123742169
Default Engines Hash    : 4c784e32044a8a016d99474bd02a3b6123742169
Studio                  : 0.502.0
Preview Features        : postgresqlExtensions

Appears to be fixed in esbuild 0.24.0 by https://github.com/evanw/esbuild/commit/045a87f164b31838aad7e2bcba112cf7717898d0. See also: evanw/esbuild#3887


text:
sslaccept=accept_invalid_certs seems to not be the default #3564

Bug description
When trying to connect to a MySQL database, with a user that has the REQUIRE SSL option set the following error appears:
[1657368933547] FATAL: Startup failed
    err: {
      "type": "PrismaClientInitializationError",
      "message": "Authentication failed against database server at `[omitted]`, the provided database credentials for `[omitted]` are not valid.\n\nPlease make sure to provide valid database credentials for the database server at `[omitted]`.",
      "stack":
          Error: Authentication failed against database server at `[omitted]`, the provided database credentials for `[omitted]` are not valid.

          Please make sure to provide valid database credentials for the database server at `[omitted]`.
              at [omitted]/node_modules/@prisma/client/runtime/index.js:45403:20
      "clientVersion": "4.0.0",
      "errorCode": "P1000"
    }

The MySQL server uses a self-signed certificate.
How to reproduce
You need a MySQL server which allows SSL connections and uses a self-signed certificate. This is the default behaviour in MySQL.
Enable the REQUIRE SSL option for your MySQL user: ALTER USER 'myuser'@'myhost' REQUIRE SSL
Start your prisma application
Expected behavior
The connection should be successfully established using default options.
According to the docs, sslaccept=accept_invalid_certs is the default. However, this does not seem to be the case, because the connection does not work.
When I manually add ?sslaccept=accept_invalid_certs to the database URL, the connection gets established successfully.
Prisma information
Not working database url: mysql://myuser:mypassword@dbhost:3306/database
Working database url: mysql://myuser:mypassword@dbhost:3306/database?sslaccept=accept_invalid_certs
Environment & setup

OS: MacOS 12.3
Database: MySQL 8.0.29
Node.js version: 16.13.0

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

Context: https://prisma-company.slack.com/archives/C058VM009HT/p1733386348703599

authors: ankur-arch aqrln


text:
Prisma Client 1.17 create mutation generates 2 records

Describe the bug
Prisma Client 1.17 create mutation generates 2 records
To Reproduce
Steps to reproduce the behavior:

Clone https://github.com/prisma/prisma-examples
Go to node-graphql
Follow the instructions to setup
Run createDraft mutation
You will have 2 records returned by the drafts query

Versions:

OS: OS X High Sierra
prisma CLI: prisma/1.17.0-beta.11 (darwin-x64) node-v8.11.3
Prisma Server: 1.17-beta-1

I can reproduce this.
For anyone trying to reproduce this locally, you will need to follow slightly different instructions and create a user.

Interestingly enough, I cannot reproduce this anymore after some while, without changing anything.
If I then deploy a new service, I cannot reproduce it at all in the new service.
This seems like a very subtle bug or even a problem with the environment setup. To start looking into this, we require a consistent and reliable reproduction, so let us know if you found one.

I got this same issue and seems so hopefully its consistently reproducible with my repo.
To Reproduce

Clone https://github.com/addstar34/labeouf
cd into packages/apollo-server-api
run yarn install
run docker-compose up -d
run prisma deploy
run prisma generate
yarn start
using graphql playground create a mutation for createTodo
using graphql playground query todos and you'll see 2 todos

Versions:

OS: OS X Mojave
prisma cli: prisma@1.17.1
node: v8.12.0

Thanks @addstar34, I can once again confirm your reproduction. Looking into this.

@marktani I think I found out what the problem is here, the resolvers need to use async/await with the call to prisma. Eg:
async function createTodo(_parent, args, context, _info) {
  return await context.prisma.createTodo({
    title: args.title,
    description: args.description,
  })
}

I think the issue stems from the docs as I just copy pasted the resolvers from here as my starting point which don't use async/await: https://www.prisma.io/docs/1.17/get-started/03-build-graphql-servers-with-prisma-e001/#implement-resolver-functions

Closing this in favor of #3210, which seems to be a bug in Prisma core.

authors: addstar34 bogdansoare marktani


text:
test(client): add integration runner

Includes and closes: https://github.com/prisma/prisma/pull/13169

Why

https://github.com/prisma/prisma/issues/13092
I was finding that the integration tests were running all at once and it was hard to tell jest to treat the integration differently without losing potential on the simple tests.

What
This PR excludes all of the tests in ./packages/client/tests/integration from the main test suite and introduces:
integration-runner.test.ts
This new file will readDir both the happy/ and errors/ tests and then perform sequential batching of n amount of tests.
Between each batch, a backoff is added so that we don't completely overwhelm other components such as the database.
How can I run them?
You should not need to change anything in your workflow, however, if you especially want to run the integration test's on their own you can run:
cd ./packages/client && pnpm run test integration

Findings
This shows my recorded stats of the time taken to run the client test suite before, with maxWorkers, and then after this addition.
Before
cd ./packages/client && pnpm run test
Could not run - Timed out!
Test Suites: 3 failed, 5 skipped, 181 passed, 184 of 189 total
Tests:       35 failed, 18 skipped, 717 passed, 770 total
Snapshots:   562 passed, 562 total
Time:        560.228 s
Ran all test suites.
 ELIFECYCLE  Test failed. See above for more details.

cd ./packages/client && pnpm run test integration
Could not run - Timed out!
Test Suites: 3 failed, 4 skipped, 142 passed, 145 of 149 total
Tests:       17 failed, 12 skipped, 554 passed, 583 total
Snapshots:   383 passed, 383 total
Time:        297.905 s
Ran all test suites matching /integration/i.
 ELIFECYCLE  Test failed. See above for more details.

Using maxWorkers

https://github.com/prisma/prisma/pull/13149#pullrequestreview-962094944

These run! However, the issue here is now that the entire test suite is running at 50% capacity when in reality we only want to limit the heavy load stuff(the integration tests).
cd ./packages/client && npx jest --maxWorkers="50%"
Pass - Slower as expected!
5 skipped, 184 passed, 184 of 189 total
Tests:       18 skipped, 752 passed, 770 total
Snapshots:   580 passed, 580 total
Time:        523.493 s, estimated 538 s

cd ./packages/client && npx jest integration --maxWorkers="50%"
Pass
Test Suites: 4 skipped, 145 passed, 145 of 149 total
Tests:       12 skipped, 571 passed, 583 total
Snapshots:   399 passed, 399 total
Time:        330.482 s
Ran all test suites matching /integration/i

After
cd ./packages/client && pnpm run test
Pass - 222.898 seconds faster
Test Suites: 1 skipped, 40 passed, 40 of 41 total
Tests:       6 skipped, 183 passed, 189 total
Snapshots:   181 passed, 181 total
Time:        300.595 s
Ran all test suites.

cd ./packages/client && pnpm run test integration
Pass - 83.634 seconds faster
integration/integration-runner
    √ happy (243661 ms)
    √ errors

Test Suites: 1 passed, 1 total
Tests:       2 passed, 2 total
Snapshots:   0 total
Time:        246.848 s
Ran all test suites matching /integration/i.

Regressions
Some things we miss out on in this implementation, this is because we are now spawning Jest using exec. This means that the main Jest process doesn't have a full collective view of how many tests are run for example or the coverage of those files tested on inside the spawned process.

Jest Stats - You can still see all in the console but it won't be in one nice neat place like normal.
Code Coverage? - IDK yet standby

Included and closes: https://github.com/prisma/prisma/pull/13169

Findings

Yes, and this does help. I have added a section in the PR description Findings that shares my stats using maxWorkers.

Have you tried limiting maxWorkers in jest.config.js? This is not the same thing as what you're doing in this PR (which is also an interesting idea), but it might've solved the issue.

Yes, and this does help. I have added a section in the PR description Findings that shares my stats using maxWorkers.


text:
Support non TS handlers

This plugin should handle having handles with both the .js and .ts extension, and simply not transpile the .js files.
I wanted to convert my current serverless project to TS, and only rename TS files once I've updated them.
Currently we get an error that looks like
Serverless: Using local tsconfig.json
{ file: undefined,
  start: undefined,
  length: undefined,
  messageText: 'File \'myfunction.ts\' not found.',
  category: 1,
  code: 6053 }

  Type Error ---------------------------------------------

  Cannot read property 'getLineAndCharacterOfPosition' of undefined

     For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

👍 This would be useful for us as well.

I'd like to see this supported, too. Usecase: we use custom authorizers that we ship as a npm module; the code is written in TypeScript and transpiled to JavaScript, but then it cannot be used because it won't be picked up.
The workaround currently is to ship it as npm module, but include the source and reference the source file in the handler: line, thus having the main project's build re-build the authorizer again.

:tada: This issue has been resolved in version 1.1.8 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: MikeBlair divyenduz kiesel ro-savage

repo: prisma/serverless-plugin-typescript


text:
@db is changed to @[object Object]

During the last step of the prisma upgrade CLI the @db is changed to @[object Object]
In example the following:
@db.VarChar(30)

is changed to:
@[object Object].VarChar(30)

I can confirm this happened as well in our project.

Also happening for me

Hey, sorry about that. I'll be looking into this soon.

Hey, this is fixed in 0.0.43

authors: chemicalkosek matthewmueller omar-dulaimi smschick

repo: prisma/upgrade


text:
Pull through symbols for postprocess functions

Bug fix for #97.  Some post process functions were passing through without connecting to the source columns.  Fixed bug and added two new exceptions to catch any case where a function forgets to implement the symbol() call.  Added unit test.

Ran the DP powerset test on POWER(SUM(Usage), 2) and it passes now.

authors: ankit-oss joshua-oss

repo: privacytoolsproject/burdock


text:
Skrub table report does not appear correctly in skore UI

Describe the bug
Skrub table report appears as a base 64 string.

Steps/Code to Reproduce
from skore import create
from skrub import TableReport
from skrub.datasets import fetch_employee_salaries

p = create("toto", overwrite=True)
df = fetch_employee_salaries().X
report = TableReport(df)
p.put("large table report", report)

skore launch toto

Expected Behavior
Table report should appear and be interactive.
Actual Behavior
TabelReport appears a sa base64 string.
Environment
System:
    python: 3.12.7 (main, Oct  1 2024, 02:05:46) [Clang 15.0.0 (clang-1500.3.9.4)]
executable: /Users/rouk1/dev/skore/venv/bin/python
   machine: macOS-14.6.1-arm64-arm-64bit

Python dependencies:
        skore: 0.0.0+unknown
          pip: 24.2
   setuptools: None
    diskcache: 5.6.3
      fastapi: 0.115.5
 plotly<6,>=5: None
      pyarrow: 18.1.0
         rich: 13.9.4
        skops: 0.10.0
      uvicorn: 0.32.1

Note: this happens for all media items with text/html media type.

repo: probabl-ai/skore


text:
blocked gibbs sampling for LGSSM as alternative to EM

Implement blocked gibbs sampling for LGSSM. Then make a GS version of this EM demo:
https://github.com/probml/ssm-jax/blob/main/ssm_jax/lgssm/demos/lgssm_learning.py
Some details can be found in this paper
A. Wills, T. B. Schön, F. Lindsten, and B. Ninness, “Estimation of Linear Systems using a Gibbs Sampler,” IFAC proc. vol., vol. 45, no. 16, pp. 203–208, Jul. 2012, doi: 10.3182/20120711-3-be-2027.00297. [Online]. Available: https://linkinghub.elsevier.com/retrieve/pii/S1474667015379520

Note that https://github.com/probml/ssm-jax/issues/57 might be a useful intermediate step for debugging the NIW machinery.

repo: probml/ssm-jax


text:
Manual release creation and Badge addition in README

Manual release creation and Badge addition in README

Thanks for making this PR!
Sorry I'm not on teams/email today, I'm having login issues and still waiting on the internal support team to figure out what's broken 😅
Looks like something slipped in the go code prior to this PR, causing the ci.yml to fail. We'll need to deal with that in a follow-up PR, and can ignore it for now.
As we've tested these pipelines on a standalone repo, I'm going to approve them for merge. Our next step will then be to validate that they behave as expected in this repo.

authors: eddie-knight shuchitach

repo: probr/probr-core


text:
Daily download limit for nightly builds too low

Description of the feature, modification, idea or suggestion
ProcessHacker informs me about an available update. When I click on download, it fails.
When I go to https://processhacker.sourceforge.io/nightly.php and try to download the newest version directly, I get:
{"message":"Artifacts download limit (1024 MB/day) exceeded."}
I have been using ProcessHacker nightly builds for years without problems downloading, this seems to be a recent change.
1024 MB/day for a ~10MB file would mean only 100 downloads are possible every day.
According to https://sourceforge.net/projects/processhacker even the old ProcessHacker2 version has more than 1000 downloads/day, so I assume ProcessHacker3 downloads are above 100/day.
Proposed implementation details (optional)
No response

this seems to be a recent change

this seems to be a recent change

Appveyor seems to have started using stricter quota limits... I've migrated the nightly downloads to the github mirror 👍

repo: processhacker/processhacker


text:
Icreased CPU Usage

On system start up your program using around 12-15%. The only way to fix it is to open Process Hacker window. After that I can clearly see the difference on the graph and on the usage it's self. It goes back to normal 0.06%
Couple of things you should know: Program version - 3.0.2975
Windows Version - Win 10x64 1909
I'm using portable version and using task manager to run your program with administrative privilege on system launch.

using task manager to run your program with administrative privilege on system launch.

Task Scheduler or Task Manager?

On system start up your program using around 12-15%

Have you tried unchecking/disabling these two settings from the options window?

Check images for digital signatures
Check services for digital signatures

Some machines have performance issues with checking digital signatures (especially for services) and disabling these two options might help. Please let me know if it does :P

Task Scheduler. Sorry for the wrong name
Both this options are turned off.

Are you using Avast antivirus or some other security product?

Nothing of this sort. I even removed windows defender competly because I value my computer resources.

Are you using any uxtheme patching for custom windows themes or non-default plugins for Process Hacker from plugins-extra or the forums?

This is a whole plugin list and no. Never heard about uxtheme program.

Maybe this graph would illustrate my issue better.

Maybe this graph would illustrate my issue better.

I can't reproduce it. Can you enable multiple instances and check the thread stacks for the first instance?
e.g. after rebooting the first instance will be consuming CPU... start a second instance of Process Hacker and view the threads for the first instance. You should see the thread with the highest utilization and double click to open the thread stack.
Screenshot the stack for that thread(s) and upload them. You might need to click the Refresh button a few times and check for any changes / longer stacks and screenshot those too.

This is the result. And this is the stack thread with the highest CPU usage.
I waited for a while (my refresh rate was 15s). Only cpu result was jumping from 19 to 22 and cyclces delta were increasing in numbers. Same window after 30+ min

@LIMUNADE
I can't reproduce the issue. The only other report was from 2014 and we never found the cause:
https://wj32.org/processhacker/forums/viewtopic.php?t=1482
Your screenshot should be showing GetMesageW for the main thread but its showing DispatchMessageW... GetMesage blocks the thread when there are no messages but when there are messages we immediately call DispatchMessageW which indicates the message loop is processing window messages (which isn't something that happens when the window is invisible).
Can you try disabling the dark theme support in the options window since the dark theme sublasses the main window and could cause this issue?
The only other explanation would be some third party software spamming our window with unsolicited messages and causing the CPU usage. You could try doing the same as last time and execute a second instance of Process Hacker while the first one is consuming CPU usage and terminate any non-Microsoft process one by one and if the cpu usage suddenly stops it would be the offending process?

Well, default theme made no difference in consumption of CPU. Stack thread screenshot. Maybe I should note that I don't use kernel-mode drivers.

After recent updates it's appears that the problem has been fixed. Thank you for you great software and constant updates.

authors: LIMUNADE dmex


text:
P5 editor  top portion  Height

The editor top portion height is too much please reduce it ,, and its not adjustable also... below image explains more..

I think we'd like to keep this for now.

authors: kusha-b-k lmccart


text:
added check for  [bins] argument in fft method of P5,  along with unit Test( in es6 style)

issue :

the bins arguments is very vulnerable , as there is no check to what user provides as  the input to bins argument  , suppose the user enters a negative value of bins by mistake , then it's a crash !
so there must be a check to what user gives input as  "bins" arguments"
solution :

added a filter (safeBins) to what user enters as argument .

checks are esablished as shown

added a unit test for the function

@therewasaguy
please  review this Pr!

Also, just a note:
In the Web Audio API, the AnalyserNode.frequencyBinCount is Read only (I'm looking at the MDN documentation for reference https://developer.mozilla.org/en-US/docs/Web/API/AnalyserNode). It is always half of the fftSize. So we're kind of doing things backwards in p5.Sound by allowing users to set the binSize directly. We're doing that because it seemed like it would be more intuitive to set a value that represents the array size you get from the analysis, rather than a value that is twice that amount... but I'm having second thoughts about that now.

yeah ! you are right ! but it is very intuitive and generous to provide user the flexibilty  to choose length of array in which analysed data will be served to them !, and we are no where assigning the value to "AnalyserNode.frequencyBinCount" that means it is good to use ,
infact we are creating a level of abstraction that provides ease to user !, so we don't need to remove that ,however we can rename it , name other than bins because it seem to  represent "AnalyserNode.frequencyBinCount"
how about name "length" which represents the length of array !

I suggest testing the public methods, and making this a private method.
i was actually thinking the same , means i need to create a wrapper for this method ? or you have any other  suggestions?

Do you think the functionality of safeBins could be incorporated into safeBufferSize, rather than making it a separate method?

we can create a safeCheck function which can be placed inside of both of these methods and
rather writing the same check twice , also safeBufferSize have other checks than  safeBIns has

Also ,
https://github.com/processing/p5.js-sound/pull/419#issuecomment-603586872
i agree to the w3 specs and not giving our user the ability to change the bufferSIZe() and hence we don't need to add tests for it like in safeBins !!

i would like to draft this one until the module system work is done !


text:
Adding support for macOS  to GitHub Actions tests

Increasing Access
Extending GitHub Action tests makes your project more reliable, compatible, and inviting to contributors and users. It ensures smoother functionality across different systems, fosters a welcoming community, and maintains high quality through continuous testing, ultimately increasing access to and adoption of your project.
Most appropriate sub-area of p5.js?
Other (specify if possible)
Feature request details
To extend the workflow to cover Windows as well

@limzykenneth please assign this issue to me .
I would like to work on this issue

There is not likely to be differences in terms of which OS the CI runs on as the runtime we rely on is Node.js and not the underlying OS. I don't think it is necessary to set it up to run on additional OSes for CI.

authors: AdityyaX limzykenneth


text:
Cron every hour or minute?

/1 * * * * does not work.

Hi, it looks like your cron expression you are trying to use is wrong. Can you please try to schedule again by using the following expression?
*/1 * * * *

This is not an issue so it will be closed.

authors: burakkoken guyeatspants

repo: procyon-projects/chrono


text:
CLI: Name the generated Dockerfile "plz.Dockerfile".

It's perfectly reasonable for the user to have a Dockerfile for some
other purpose. Expecting them to rename it is a bit rude.
We can't randomly generate a filename because that would affect the
final image hash, causing Docker image cache misses.

Oh, crap, thought you'd reviewed this, @sergiogiro. I should not do two things at once. If you have any issues with the implementation just shout.

repo: prodo-ai/plz


text:
fixed spelling in README.md

Изменения

Исправил орфографическую ошибку в README
Детали реализации

Не правильное использование прописных и строчных букв в предложении является орфографической ошибкой
В данном случае в начале предложения
Check-List

[ ] Вы проверили свой код перед отправкой запроса?
[ ] Вы написали тесты к реализованным функциям?
[ ] Вы не забыли применить форматирование black и isort для Back-End или Prettier для Front-End?

@DaymasS когда делаешь ПР тегай пару мейнтейнеров в ревью пж

authors: DaymasS grigoriev-semyon

repo: profcomff/userdata-api


text:
🛑 Multi Hardware is down

In d69c983, Multi Hardware (https://www.multi-hardware.com/retrogami) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Multi Hardware is back up in 499961c after 4 minutes.

repo: proger-su/upptime


text:
Update to latest github action that supports commits signoff

Switch to v1.2 with commit signoff support. This should pass DCO requirements.
closes #412

& ironically, I forgot to signoff the commit myself..

repo: project-akri/akri


text:
Add sample data with random data creation logic

Add junit as a test dependency in pom.xml
Add sampleData model and implement random seed
generation and signature logic
Implement related unit tests

Fix #10
Signed-off-by: Karim Elghamry karimelghamry@gmail.com

rebased in 6a8f290313f961739b587817b089a5ebdc259ca1

repo: project-alvarium/example-java