text:
REFramework not working on MHRise under Game Porting Toolkit on Mac

Describe the bug
I installed Monster Hunter Rise using Game Porting Toolkit on Mac, and try to setup REFramework for Monster Hunter Rise but it seems to fail to start.
Upload logs and any crash dumps
re2_framework_log.txt
Identify the REFramework version
v1.5.1
To Reproduce
Steps to reproduce the behavior:

place the file in the Monster Hunter Rise Folder;
Open winecfg with WINEPREFIX=~/general-gaming $(brew --prefix game-porting-toolkit)/bin/wine64 winecfg and add dinput8.dll override;
Start by:
Via Steam (Started with arch -x86_64 gameportingtoolkit ~/general-gaming 'C:\Program Files (x86)\Steam\steam.exe' > /dev/null 2>&1 & ) directly
Via Fluffy Mod Manager;
Start directly.

Expected behavior
It should properly started.
Screenshots
Record a video for ref:
https://youtu.be/eK7HizBDSyk
Additional context

OS (e.g. Windows 11): MacOS Sonoma
Using Game Porting Toolkit (Wine 7.7)

Looks like there's some unexpected behavior from the DirectX implementation on this causing the command queue to fail to be found, as well as the first dummy swapchain creation to fail. This is inconsistent with Windows and Proton behavior. Not sure how to address this at the moment, don't have a Mac.

Any development to fix this?

Doesn't work too. The same issue.

authors: CatcherITGF LeaveNhA patrick330602 praydog


text:
jest unit test is broken after upgrade @preact/signals from 1.3.1 to 2.0.0.

[x] Check if updating to the latest version resolves the issue

Environment

[ ] I am using @preact/signals-core
[x] I am using @preact/signals
[ ] I am using @preact/signals-react

[ ] I understand usage changed in v2, and I've followed the React Integration instructions

Describe the bug
jest unit test is broken after upgrading @preact/signals from 1.3.1 to 2.0.0.
Follow the instructions for release updates: When you perform a signal update, you'll need to wrap it in act.
I did it, but it still failed. This test can pass after rolling back to 1.3.1
To Reproduce
https://stackblitz.com/~/github.com/rock-57blocks/NeverReact
Steps to reproduce the behavior:

Go to stackblitz
open terminal
run 'npm test'

Expected behavior
This test is passed on @preact/signals 1.3.1, but failed on 2.0.0.

I found that if a child component uses useEffect, and its dependencies have prop signal value from the parent component, it will make the parent component's useSignalEffect callback invalid.
e.g

Hmm yes, looks like the signal-effect does not rerun when the dependency changes

Hmm yes, looks like the signal-effect does not rerun when the dependency changes - does it work at runtime?

@JoviDeCroock Thanks for the quick replay.
I tested it and it works fine at runtime. This issue only occurs during unit testing.
BTW,  what confuses me is that if the child component's useEffect does not depend on the signal parameter in the signal props but only on something else, then this test will work.
See the follow code:
const MuteButton: FunctionalComponent<MuteButtonProps> = ({
  isMuted,
  isTestMuted,
}) => {
  useEffect(() => {
    console.log('isMuted', isTestMuted);
  }, [isTestMuted]);

  return null;
};

export const muteVideo = signal(false);
const TestPlayer: FunctionalComponent = () => {
  const videoRef = useRef<HTMLVideoElement>(null);
  useSignalEffect(() => {
    videoRef.current!.muted = muteVideo.value;
  });

  return (
    <Fragment>
      <div>
        <video
          data-testid='video-player'
          ref={videoRef}>
        </video>
        <MuteButton
          isMuted={muteVideo.value}
          isTestMuted={true}
          />
      </div>
    </Fragment>
  );

};

Yes, the act override all explains that. We queue twice because the timing of rerender --> effect queued up, signal update --> effect queued up are slightly different, see my last edits to the above which includes the fix

I see..
Will it be include in a new version 2.0.1 very soon or later？
Thanks a lot. @JoviDeCroock

As I said, I have no time now... it's Christmas today 😅 I gave you the solution so you can PR or patch it if it's urgent, this is from my phone

oh sorry. I'm not rushing you just to ask about a possible release date, don't worry it's not a very urgent need, please enjoy your holidays and Merry Christmas！

This will be fixed in 10.25.4, thanks to @rock-57blocks! You can track https://github.com/preactjs/preact/pull/4620 to see when the release goes out

Released in 10.25.4

source: gharchive/issue

repo: preactjs/signals

license: MIT

license_type: permissive

license_source: github-api


text:
Async client to backoff when model overloaded

Feature request
Have the (async) client automatically backoff sending requests when the deployment is overloaded.
Motivation
When the async client exceeds the deployment queue capacity / rate limits, it currently fails with
OverloadedError: Model is overloaded

Current thinking is to add more examples for doing batch inference to avoid this issue on the client. We can still look for ways to backoff automatically, though, in the future.

authors: jppgks tgaddair

repo: predibase/lorax


text:
Support for Pypi extra dependency

Problem description
Currently, Pixi does not support Pypi installing extra dependency. For example:
pixi add --pypi unstructured[pdf]
will result in:
no matches found: unstructured[pdf]
while the command outside of Pixi, which is:
'pip install unstructured[pdf]'
should works.
Let me know if I can help in anyway possible to speed up this enhancement.

Hi @QuynhTaVo, this works with the latest version of pixi. Could you try updating?

Hi @QuynhTaVo, this works with the latest version of pixi. Could you try updating?

Hi @ruben-arts , my pixi is up to date.
'pixi is already up-to-date (version 0.27.1)'
If what you said were true, is this a bug?

You might need to quote it so: 'unstructured[pdf]'

You might need to quote it so: 'unstructured[pdf]'

I did.
pixi add --pypi 'unstructured[pdf]'
The result is the same.
no matches found: unstructured[pdf]

This error makes no sense, is there possibly more you're getting. Otherwise could you run with -vv.
It seems like your shell is not doing anything with pixi.

This error makes no sense, is there possibly more you're getting? Otherwise could you run with -vv.
It seems like your shell is not doing anything with pixi.

No, that is all I am getting with pixi
(py310) (base) quynhvo@Quynhs-MacBook-Pro QuestionAnswering % pixi add --pypi -vv 'unstructured[pdf]'                           (eval):1: no matches found: unstructured[pdf] (py310) (base) quynhvo@Quynhs-MacBook-Pro QuestionAnswering %

This error doesn't seem to be coming from pixi itself. Does pixi add --pypi unstructured work?

Yes of course.
(py310) (base) quynhvo@Quynhs-MacBook-Pro QuestionAnswering % pixi add --pypi -vv 'unstructured'
INFO pixi::environment: verifying prefix location is unchanged, with prefix file: /Users/quynhvo/Downloads/Aitomatic/QuestionAnswering/.pixi/envs/default/conda-meta/pixi_env_prefix
INFO pixi::lock_file::outdated: the dependencies of environment 'default' for platform osx-64 are out of date because missing purls
INFO pixi::lock_file::resolve::uv_resolution_context: uv keyring provider is disabled
INFO resolve_conda{group=default platform=osx-64}:get_or_create_subdir{channel=Channel { platforms: None, base_url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("conda.anaconda.org")), port: None, path: "/conda-forge/", query: None, fragment: None }, name: Some("conda-forge") } platform=NoArch}:fetch_repo_data{cache_path=/Users/quynhvo/Library/Caches/rattler/cache/repodata}: rattler_repodata_gateway::fetch::jlap: fetching JLAP state from https://conda.anaconda.org/conda-forge/noarch/repodata.jlap (bytes=6447689-)
INFO resolve_conda{group=default platform=osx-64}:get_or_create_subdir{channel=Channel { platforms: None, base_url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("conda.anaconda.org")), port: None, path: "/conda-forge/", query: None, fragment: None }, name: Some("conda-forge") } platform=Osx64}:fetch_repo_data{cache_path=/Users/quynhvo/Library/Caches/rattler/cache/repodata}: rattler_repodata_gateway::fetch::jlap: fetching JLAP state from https://conda.anaconda.org/conda-forge/osx-64/repodata.jlap (bytes=9979183-)
INFO rattler_repodata_gateway::fetch::jlap: parsing cached repodata.json as JSON
INFO rattler_repodata_gateway::fetch::jlap: parsing cached repodata.json as JSON
INFO rattler_repodata_gateway::fetch::jlap: applying patches #1 through #65
INFO rattler_repodata_gateway::fetch::jlap: writing patched repodata to disk
INFO resolve_conda{group=default platform=osx-64}:get_or_create_subdir{channel=Channel { platforms: None, base_url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("conda.anaconda.org")), port: None, path: "/conda-forge/", query: None, fragment: None }, name: Some("conda-forge") } platform=NoArch}:fetch_repo_data{cache_path=/Users/quynhvo/Library/Caches/rattler/cache/repodata}: rattler_repodata_gateway::fetch: fetched JLAP patches successfully
INFO rattler_repodata_gateway::fetch::jlap: applying patches #1 through #60
INFO rattler_repodata_gateway::fetch::jlap: writing patched repodata to disk
INFO resolve_conda{group=default platform=osx-64}:get_or_create_subdir{channel=Channel { platforms: None, base_url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("conda.anaconda.org")), port: None, path: "/conda-forge/", query: None, fragment: None }, name: Some("conda-forge") } platform=Osx64}:fetch_repo_data{cache_path=/Users/quynhvo/Library/Caches/rattler/cache/repodata}: rattler_repodata_gateway::fetch: fetched JLAP patches successfully
INFO resolve_conda{group=default platform=osx-64}: pixi::lock_file::update: fetched 45907 records in 8.300640517s
INFO pixi::lock_file::update: resolved conda environment for environment 'default' 'osx-64' in 17s 771ms 775us 138ns
INFO pixi::environment: Creating prefix file at: /Users/quynhvo/Downloads/Aitomatic/QuestionAnswering/.pixi/envs/default/conda-meta/pixi_env_prefix
INFO pixi::environment: No update needed for the prefix file.
INFO pixi::environment: Checking if history file exists: /Users/quynhvo/Downloads/Aitomatic/QuestionAnswering/.pixi/envs/default/conda-meta/history
INFO pixi::lock_file::update: updated conda packages in the 'default' prefix in 21ms 281us 178ns
INFO resolve_pypi{group=default platform=osx-64}: pixi::lock_file::resolve::pypi: the following python packages are assumed to be installed by conda: langchain-text-splitters 0.2.2, typing-inspect 0.9.0, psutil 6.0.0, langchain-openai 0.1.21, h2 4.1.0, numpy 1.26.4, distro 1.9.0, greenlet 3.0.3, zipp 3.20.0, hpack 4.0.0, jinja2 3.1.4, charset-normalizer 3.3.2, yarl 1.9.4, attrs 24.2.0, importlib-metadata 8.2.0, multidict 6.0.5, unstructured 0.15.3, httpcore 1.0.5, pypdf 4.3.1, orjson 3.10.7, brotli 1.1.0, langchain 0.2.13, aiosignal 1.3.1, tqdm 4.66.5, requests-toolbelt 1.0.0, langchain-core 0.2.32, python-dateutil 2.8.2, chardet 5.2.0, jsonpatch 1.33, nltk 3.8.2, hyperframe 6.0.1, exceptiongroup 1.2.2, tenacity 8.5.0, regex 2023.12.25, jiter 0.5.0, mypy-extensions 1.0.0, annotated-types 0.7.0, ordered-set 4.1.0, sniffio 1.3.1, langdetect 1.0.9, python-magic 0.4.27, nest-asyncio 1.6.0, blinker 1.8.2, typing-extensions 4.12.2, sqlalchemy 2.0.32, dataclasses-json 0.6.7, emoji 2.12.1, werkzeug 3.0.3, idna 3.6, marshmallow 3.20.2, frozenlist 1.4.1, colorama 0.4.6, setuptools 72.1.0, aiohappyeyeballs 2.3.5, click 8.1.7, pysocks 1.7.1, aiohttp 3.10.3, itsdangerous 2.2.0, pydantic 2.8.2, backoff 2.2.1, soupsieve 2.5, anyio 4.4.0, async-timeout 4.0.3, unstructured-client 0.25.5, httpx 0.27.0, langsmith 0.1.99, pydantic-core 2.20.1, flask 3.0.3, rapidfuzz 3.9.6, wrapt 1.16.0, pyyaml 6.0.2, joblib 1.3.2, h11 0.14.0, jsonpointer 3.0.0, lxml 5.2.2, openai 1.40.6, packaging 23.2, six 1.16.0, filetype 1.2.0, jsonpath-python 1.0.6, python-iso639 2024.4.27, beautifulsoup4 4.12.3, deepdiff 7.0.1, tiktoken 0.7.0, certifi 2024.2.2, urllib3 1.26.18, markupsafe 2.1.5, tabulate 0.9.0, requests 2.32.3
INFO solve:solve_tracked: pubgrub::internal::partial_solution: add_decision: root @ 0a0.dev0
INFO solve:solve_tracked: pubgrub::internal::partial_solution: add_decision: unstructured @ 0.15.3
INFO pixi::lock_file::update: resolved pypi packages for environment 'default' 'osx-64' in 5s 358ms 634us 480ns
✔ Added unstructured
Added these as pypi-dependencies.
(py310) (base) quynhvo@Quynhs-MacBook-Pro QuestionAnswering %

This makes it even weirder. I'm not sure which shell this is but it seems like the error is coming from it. It feels like the brackets are not parsed correctly as it's not reaching pixi. Does echo bla[test] work?

This makes it even weirder. I'm not sure which shell this is but it seems like the error is coming from it. It feels like the brackets are not parsed correctly as it's not reaching pixi.

It is zsh from Mac Terminal

Does echo bla[test] work?
I dont think so?
zsh: no matches found: bla[test]

I'm not sure what your shell is doing but this is not a pixi issue. Closing it for now.

Ah, my bad, I did not know what the square bracket does in shell. Anyways, it works normally.
(py310) (base) quynhvo@Quynhs-MacBook-Pro QuestionAnswering % ls -d bla*
blat
(py310) (base) quynhvo@Quynhs-MacBook-Pro QuestionAnswering % echo bla[test]
blat

You know, just for sanity check, can someone with another Mac confirm this problem?

authors: QuynhTaVo ruben-arts tdejager

repo: prefix-dev/pixi


text:
Question about prerenderReady

I'm working in an angular environment and am having trouble getting prerender to wait long enough to get the correct version of my page.
During the page setup, after the base asset loads, there are multiple Ajax calls and then some addition image retrieval. The idea is to wait until these images are loaded (I actually need the image width/height for OG tags) and then ask prerender to come and get the page.
In the body of the page I have the following code at the bottom.
<script> window.prerenderReady = false; </script>
In my JS, after a bunch of ajax calls, I have the following
var img = new Image(); img.onload = function() {     window.prerenderReady = true; } img.src = "Some Image URL";
The problem is that prerender captures the page before the image is loaded.
Any thoughts on how I can fix this?
Thanks

Sorry for the delay! By default, we set our PhantomJS up so that we don't load images. If you are waiting for images to download, then that might be the issue there. Any way you can do that without downloading the images? If you are running your own Prerender server you can turn on the rendering of images by default.

@thoop @graemehoffman I'm suffering from the exact same issue here.  And at this point we are still using the prerender.io service (not our own prerender server).
Facebook requires og:image:width and og:image:height metatags and in order to get these dimensions I need to wait for only one of my images to download.  Here's my code:
    //If property has images then set it's metatags for Facebook and Twitter.
    if($scope.property.images.length) {

      ngMeta.setTag('twitter:image', $scope.property.images[0].location);
      ngMeta.setTag('og:image', $scope.property.images[0].location);

      //Facebook needs image dimensions so we wait for image to load then populate.. this sucks.
      var metaImage = new Image();
      metaImage.onload = function () {
        ngMeta.setTag('og:image:width', this.width);
        ngMeta.setTag('og:image:height', this.height);
        $window.prerenderReady = true;
      };
      metaImage.src = $scope.property.images[0].location;

    }

Notice I'm setting window.prerenderReady = true after I have set the og:image:width and og:image:height metatags.  Fore some reason the page is still prerendered while window.prerenderReady is false.
Thanks for help!

window.prerenderReady is just used as a signal to tell us to wait longer when rendering the page. If it doesn't get set to true then we timeout after 20 seconds and save the page as-is. If we aren't loading images then waiting longer won't change that.
Is there anything else that can be done there? Are you able to cache those values so that you don't have to download the entire image?

Feel free to reopen if you have any more info here so that we can help. If you want to enable image loading then you'll need to run Prerender on your own servers.

Enabling images by setting parameter in lib/server.js does not seem to be working. Any other config we should look at?

Can you send a URL that you are testing to support@prerender.io? That way we can try some things and see what's going on.

@thoop why not use a signal to tell that the page is ready and can response 200 ? when the page load, we set the signal false to wait for response, until it is be set to true agin ...before your explain, i think window.prerenderReady is do that thing...

authors: ccqgithub graemehoffman that1guy thoop vireneponym

repo: prerender/prerender

license: mit

license_source: bigquery


text:
🛑 Beta is down

In 44b3e17, Beta (https://beta.presquelabs.com) was down:

HTTP code: 400
Response time: 667 ms

Resolved: Beta is back up in 5a414b3.

repo: presquelabs/upptime


text:
Eliminate pushed down filters above JDBC TableScan

Fixes https://github.com/prestosql/presto/issues/4111

CI failed -- https://github.com/prestosql/presto/issues/4568

cc @martint @kokosing

How this will work with statistics?

The changes to QueryAssert look good. I haven't looked at the rest

The changes to QueryAssert look good. I haven't looked at the rest

rebased. @martint i can separate some commits into a separate PR. Which ones would you see there?

CI failed -- https://github.com/prestosql/presto/issues/4568

source: gharchive/pull-request

authors: findepi martint sopel39

repo: prestosql/presto


text:
Add test for masking not refrenced columns

Add test for masking not refrenced columns

Fixes https://github.com/prestosql/presto/issues/4496

Which commit, resolved this issue ?

Which commit, resolved this issue ?

I have no idea. I would need to do the bisection.

The test was wrong. Assertions changed after: cfadfe534d4f35859e4690eebfa5a411177b69a0

@martint @Praveen2112 @skrzypo987 Please take a look once again.

@martint Comments addressed, please take a look.


text:
On the processing sequence of parameters

Does mrq has any built-in mechanism to enforce a processing sequence of the parameter list?
For instance, given a parameter list ["a","b", "aa", "ab"], I would like parameters "a" and "b" to be processed first before parameters "aa" and "ab" are  processed.

Hi @ecebuzz ! Can you give an example? I am not sure which parameter list you are referring to.
Do you mean a queue in redis? (if so, a Lock would seem to be the solution here. Maybe setting max_concurrency=1 in your Task ? See https://github.com/pricingassistant/mrq/blob/master/mrq/task.py#L7)

Any news on this @ecebuzz ?

Closing until further explanation

authors: ecebuzz sylvinus

repo: pricingassistant/mrq


text:
Add functional functional color support to LabelComponent

The color mapping is pulled from https://github.com/primer/css/blob/mkt/color-modes-docs/docs/content/support/v16-migration.mdx#labels
supports https://github.com/primer/view_components/issues/231
This change updates the internal CSS we use to use the existing classes
while full functional color support is implemented in Primer CSS.

@joelhawksley @colinkeany this PR partially undoes https://github.com/primer/view_components/pull/135. Will this change break anything you're working on?

Closing because of https://github.com/primer/view_components/pull/278


text:
add version identification to pete package

Trello Labels: doc,feature,tools
Trello Card Description:

pete.version

repo: principal-engineering/pete


text:
0.1.13 has not been published to Npm

latest is 0.1.12: https://www.npmjs.com/package/@pimeys/connection-string

0.1.14 is now in both.

authors: janpio pimeys

repo: prisma/connection-string


text:
Update docs explaining why the User and Post models are chosen

Going over the reasons the User and Post models are used across the docs.

Love it! 👍

authors: m-abdelwahab mhwelander

repo: prisma/docs


text:
Cannot create a list of a custom scalar type

I'm using the PositiveInt scalar from the @okgrow/graphql-scalars package:
const PositiveIntScalar = asNexusMethod(PositiveInt, 'positiveInt');

When trying to create a list of PositiveInt scalars using:
t.list.positiveInt('editionNumbers');

It throws the following error:
TypeError: t.list.positiveInt is not a function
    at Object.definition (/Users/user/project/src/module/schema.ts:61:16)
    at SchemaBuilder.buildObjectType (/Users/user/project/node_modules/nexus/dist/builder.js:185:16)
    at SchemaBuilder.getOrBuildType (/Users/user/project/node_modules/nexus/dist/builder.js:540:29)
    at /Users/user/project/node_modules/nexus/dist/builder.js:127:45
    at Array.forEach (<anonymous>)
    at SchemaBuilder.getFinalTypeMap (/Users/user/project/node_modules/nexus/dist/builder.js:118:42)
    at buildTypes (/Users/user/project/node_modules/nexus/dist/builder.js:632:20)
    at makeSchemaInternal (/Users/user/project/node_modules/nexus/dist/builder.js:661:19)
    at Object.makeSchema (/Users/user/project/node_modules/nexus/dist/builder.js:689:18)
    at Object.<anonymous> (/Users/user/project/src/schema.ts:31:24)

I'm currently using Nexus 0.11.6

Anyone looking for a workaround, you can always resort to the basic form:
t.list.field('editionNumbers', { type: 'PositiveInt' });

Ah good catch, will make sure this gets fixed.

You can use t.list.positiveInt if you pass to makeSchema the config object with 'types' prop containing an array with PositiveIntScalar that stands before type used PositiveIntScalar.

Same issue for me using a custom scalarType. I put the scalarType at first position in types array config in makeSchema but it works only for single and not for lists.

@createvo, I had "t.list.customScalar is not a function" error and resolve it similar example below:
// schema/scalars/custom-1.js
import { scalarType } from 'nexus';

const CustomScalar1 = scalarType({
  name: "CustomScalar1",
  asNexusMethod: 'customScalar1',
  // scalar definition
})

export default CustomScalar1;

// schema/scalars/custom-2.js
import { scalarType } from 'nexus';

const CustomScalar2 = scalarType({
  name: "CustomScalar2",
  asNexusMethod: 'customScalar2',
  // scalar definition
})

export default CustomScalar1;

// schema/scalars/index

export { default as CustomScalar1 } from './custom-1';
export { default as CustomScalar2 } from './custom-2';

// schema/type/custom-1.js
import { objectType } from 'nexus';

const CustomType1 = objectType({
  name: "CustomType1",
  definition(t) {
    t.int("id", { description: "Id of the Custom Type 1" });
    t.customScalar1("custom1");
  },
});

export default CustomType1;

// schema/type/custom-2.js
import { objectType } from 'nexus';

const CustomType2 = objectType({
  name: "CustomType2",
  definition(t) {
    t.int("id", { description: "Id of the Custom Type 2" });
    t.customScalar2("custom2");
  },
});

export default CustomType1;

// schema/scalars/index.js
import { makeSchema } from 'nexus';

export { default as CustomType1 } from './custom-1';
export { default as CustomType2 } from './custom-2';

// schema/index.js
import * as scalars from './scalars';
import * as types from './types';

export default makeSchema({ types: [scalars, types] });

Do you use it like this?

Hello, I also have the same issue using nexus v0.11.7
When adding a custom scalar and assigning "asNexusMethod", I can use it like:
t.myCustomScalar
But I can't use it as:
t.list.myCustomScalar
The error is the same as above.

@zeehjr Can you try with the latest beta? The beta will become the official release quite soon.

authors: createvo schuma7 tgriesser unmyke zeehjr

repo: prisma/nexus


text:
When calling the upsert() method, return a Boolean value indicating if the record is newly created or not.

Problem
Currently with Upsert, it is not possible to know if the record is newly created or is an existing record.
Suggested solution
Something from Django's ORM that can possibly be implemented.
obj, created = Person.objects.update_or_create(
    first_name='John', last_name='Lennon',
    defaults={'first_name': 'Bob'},
)

Not familiar with sequalise but I found this in their docs.
const [instance, created] = await MyModel.upsert({});

Alternatives
As suggested by Ryan in the slack forum, the alternative would be to compare the createdAt and updatedAt fields.

I'm not sure if the alternative is still possible. I'm noticing in prisma 3.4.2, my updatedAt is 0.001 seconds off from my createdAt.

Should we close this issue?

repo: prisma/prisma


text:
Unable to update with MongoDB in AWS DocumentDB

Bug description
Hi everyone,
I have a typescript + node + prisma + mongo app
Locally works fine even working with mongo atlas. but when I deploy my solution on aws upsert and update fails and give me an unfriendly message
Error occurred during query execution:
ConnectorError(ConnectorError { user_facing_error: None, kind: RawDatabaseError { code: "unknown", message: "Command failed (): Feature not supported)" } })
    at Object.request (/var/www/somedir/node_modules/@prisma/client/runtime/index.js:45633:15) {
  clientVersion: '3.13.0'
}

export DEBUG="*"
don't provide more explanation
also add those
new PrismaClient({
          log: [
            {
              emit: 'stdout',
              level: 'query',
            },
            {
              emit: 'stdout',
              level: 'error',
            },
            {
              emit: 'stdout',
              level: 'info',
            },
            {
              emit: 'stdout',
              level: 'warn',
            },
          ],
        });

nothing seems improve error
How to reproduce
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient({
          log: [
            {
              emit: 'stdout',
              level: 'query',
            },
            {
              emit: 'stdout',
              level: 'error',
            },
            {
              emit: 'stdout',
              level: 'info',
            },
            {
              emit: 'stdout',
              level: 'warn',
            },
          ],
        });

prisma.$connect();
let result = prisma.tabledata.upsert({
  where: {
    code_city: {
      code: 'bTKznB3ppPVQu8tOmW0DtA1DlfRloGFtCUW5C0',
      city: 'placeA'
    }
  },
  update: {
    phone: 'update phone'
  },
  create: {
    code: 'bTKznB3ppPVQu8tOmW0DtA1DlfRloGFtCUW5C0',
    city: 'placeA',
    address: 'another data',
  }
});

i tried also replace upsert with a select and a create and update but update fails but in both cases create work fine, from console I can do an update and upsert but not via prisma.
Expected behavior
update data
Prisma information
// 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"
  previewFeatures = ["mongoDb", "extendedIndexes"]
}

datasource db {
  provider = "mongodb"
  url      = env("DSN")
}

model tabledata {
  id String @id @default(auto()) @map("_id") @db.ObjectId
  code String
  city String
  phone String?
  address String?
  @@unique([code,city])
}

Environment & setup

OS: Ubuntu 18.04.4 LTS
Database: aws mongodb ~ documentdb
Node.js version: v12.18.2  all version fails

Prisma Version
prisma                  : 3.13.0
@prisma/client          : 3.13.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine    : introspection-core efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary           : prisma-fmt efdf9b1183dddfd4258cd181a72125755215ab7b (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash    : efdf9b1183dddfd4258cd181a72125755215ab7b
Studio                  : 0.459.0
Preview Features        : mongoDb, extendedIndexes

if some one ask my dsn is something like this
DSN="mongodb://user:pass@myserver.cluster.us-west-2.docdb.amazonaws.com:27017/mydatabase?authSource=mydatabase&retryWrites=false&tls=true&tlsCAFile=mypem.pem"
EDIT: I update prisma to the latest and that only improve the error a little
EDIT 2: After upgrade prisma version can not create but it was possible before with version 3.10.0

prisma                  : 3.10.0
@prisma/client          : 3.10.0

The first step here would be to update to the newest Prisma to make sure this is not a bug that we already fixed. Can you please do that and report back? Thanks.

I already do it, that improve the message but not much

the problem is that in 3.10.0 version of prisma allow insert but at 3.13.0 not
update can not be done in both, I think that this is something wrong with prisma not documentdb

This feature request has more information on why this is not working right now, and that we unfortunately do not plan to fix this any time soon: https://github.com/prisma/prisma/issues/13205

authors: emimarz janpio


text:
chore: stop publishing @prisma/migrate package

It's bundled in prisma CLI and not needed as an independent package.

We should probably deprecate the package on Npm as well to make clear for the old releases and versions that they are not to be used.

@janpio yes though it was "never" used/mentioned I think.

That will not hinder people to try :D


text:
Split the client for automated rollback of transactions

A trial of using the same technique as tokio-postgres for transactions.
The user can spawn this in any runtime that supports spawning, so it still keeps us runtime agnostic as well.
@pimeys this is still a bit raw in terms of documentation, tests and efficiency (and lack of shared code between the client implementations), so its more of a proof of concept at this stage, but if you are happy with this approach in general I'll push some more commits to clean it up

I'll take a look later. What is your own feeling about the code base after these changes?

I had a quick look. It's definitely not ready code-wise, I'd like to split things into smaller pieces, especially the larger methods. BUT. There is a need for proper transaction API. And I think you @esheppa for sure need one because spending time on design here, which is really nice! I know we in Prisma will probably not going to use this because we abstract transactions elsewhere. But for many of our users this is much better API compared to what we have now.
I'd continue making this nice and focusing on having as simple as possible public API even though the internals get a bit more complex. And focus on good documentation.
I'm always hoping to keep Tiberius code base suuuper simple, As simple as possible. But, this is a feature we might need to swallow, because async drop is not happening in the near future. Thank you for putting effort, I'd like to see this PR shiny and nice, so we can merge.

please rebase with master to get the new github actions visible here!

Hi @pimeys  - just had another look at this after a while. I agree that the code where the user has to spawn the split client isn't a particularly great API. I've included three possibilities below - do you think any of them look reasonable? The last one would use the split client internally so has the worst performance, but has potentially the cleanest API.
  client.transaction(|conn| Box::pin(async move {

        conn
            .execute(
                "delete from vegetables where name = @P1",
                &[&"asparagus"],
            )
            .await?;
        conn
            .execute(
                "insert into vegetables (name) values (@P1)",
                &[&"cabbage"],
            )
            .await?;

        Ok(())
    })).await?;

    transaction!(|client| async move {

        client
            .execute(
                "delete from vegetables where name = @P1",
                &[&"asparagus"],
            )
            .await?;
        client
            .execute(
                "insert into vegetables (name) values (@P1)",
                params!["cabbage"],
            )
            .await?;

        Ok(())
    });

    client.transaction_split(|mut conn| async move {
        conn
            .execute(
                "delete from vegetables where name = @P1",
                &[&"asparagus"],
            )
            .await?;
        conn
            .execute(
                "insert into vegetables (name) values (@P1)",
                &[&"cabbage"],
            )
            .await?;

        Ok(())
    }).await?;

The more I think of this problem, I start coming to a conclusion we might want to have a separate crate offering a higher level API:

tiberius should work as-is. Very minimal API and super compatible with different executors.
tiberius-batteries-included settles on Tokio, provides all possible high level interfaces such as transactions.

There are other API things we could have much easier if we can settle on a specific executor etc.

sounds good to me, especially as the first two transaction APIs don't use any private code and so can easily be implemented in another crate (and that is probably a good justification for not choosing the last option :smile:). The code for implementing the first transaction API could easily just be an example which users can copy if they want it, and the second one is just the first plus a small macro. I'll close this for now and perhaps create a PR with the minimal transaction implementation and an example

authors: esheppa pimeys

repo: prisma/tiberius


text:
show TokioAsyncWriteCompatExt in Client docs

fixes #182

thank you.

authors: pimeys rkuhn


text:
Auth experiments

Still in progress
ping @Weakky

Closing as this is now possible in master.

Outdated

@wtrocki, just wanted to highlight that you just popped up in my GitHub notifications in 2 very different contexts (Prisma/Yoga and Cordova) 🚀

I do a lots of os contributions and usually clean PR's by the end of the year.

authors: janpio wtrocki


text:
Protocol context is a trait

This change makes ProtocolContext a trait and implements it for two newly created structs that represent semi-honest and malicious contexts.
Each protocol can decide whether it supports semi-honest/malicious security model or both by injecting SemiHonestProtocolContext, MaliciousProtocolContext or  generic type parameter C: ProtocolContext<F> accordingly.
There are a couple of important changes to the context API:

narrow no longer enforces "don't narrow to the same step twice" rule.  There were two reasons for having this rule.

Don't use the same shared randomness more than once. #208 protects against it
Make sure every communication is uniquely addressable by record_id + step. If someone narrows to the same step more than once and uses the same record id to communicate, Infra is in trouble. It won't be able to resolve these two communications and likely apply last-write-wins which is obviously not correct here.  It is also mitigated because of acceptable record ranges introduced in #183. Now if protocol attempts to send a record outside of valid range, it will be caught. If it attempts to send the same record twice within the acceptable range, fsv will panic.

bind is gone. No need to explicitly bind context to a record because of the above

I think tests from #241 now can be enabled - I would expect Infra to panic if someone tries to send the same message twice. I can also add a test for that (Friday PT).
I also didn't update the panic message inside fsv to make it clear what went wrong for protocol authors.

Progress!

authors: akoshelev martinthomson

repo: private-attribution/ipa


text:
Data: project addition by Parmesh Bhatt

Add a new project to the list
Add the project in cloud computing and web development.
Record

[X] I agree to follow this project's Code of Conduct
[ ] I'm a GSSoC'23 contributor
[X] I want to work on this issue

Completed. Thanks for your contributions 🎉 ❤

repo: priyankarpal/ProjectsHut


text:
Update README.md

Related Issue
fixes #505
for GSSOC'23
Suggestion
@priyankarpal I think we should add the Ph. logo here can you provide that in this comment section?

Done @priyankarpal


text:
Support *args **kwargs to built in converters (e.g. pydantic by_alias)

Is your feature request related to a problem? Please describe.
Pydantic is supported out of the box but I can't use it to serialize when using field aliases.
Pydantic has support for this but I don't see a way to pass this information in Uplink.
Say I have a pydantic model like the following. The API uses camelcase but Python api should use snake case.
from pydantic import BaseModel

def to_camel(string: str) -> str:
    return "".join(word.capitalize() for word in string.split("_"))

class Case(BaseModel):
  instance_name: str
  instance_state: str

    class Config:
        alias_generator = to_camel
        allow_population_by_field_name = True

In Uplink I have
from .models import Case
from uplink import Consumer, get, post, json, returns, Body

class CaseAPI(Consumer):
    @get("scenario/{case_id}")
    def get(self, case_id: int) -> Case:
        """Get case by case_id"""

    @json
    @returns.json
    @post("scenario")
    def create(self, payload: Body(type=Case)):
        """Create a new case"""

The GET works based on the alias_generator in model but the POST does not work (does not convert snake to camel case) because one needs to pass by_alias argument to the .json() method on Pydantic model class [doc]
Describe the solution you'd like
I'd like to be able to pass *args and **kwargs to the converters that are built in. API something like
...
    @json
    @returns.json
    @post("scenario")
    def create(self, payload: Body(type=Case, by_alias=True)):
....

For now my work-around is just to use custom serialization function.
Cheers - Josh

I'm looking into different approaches for how we can address this. The approach I'm favoring presently is to define a new decorator (e.g., converters.pydantic.dict_args(...)):
@json
@returns.json
@converters.pydantic.dict_args(by_alias=True)
@post("scenario")
def create(self, payload: Body(type=Case)):
	pass

Passing args through Body sounds fine to me, too. However, It may require more effort for similar functionality. One upside of this approach is that we could clearly specify different model.dict args per Body argument. However, I don't think such a feature would be necessary, since there should only be one @Body-annotated argument per @json-decorated method.

As long as the by_alias works by really providing aliases requested here. I remember some surprising name effect collisions fro browsing through the pydantic project issue discussions after banging my head trying to hand-over snake case aliases as function arguments onto camel case model elements when in reality this was only working for pushing dicts/json through the parameter gate. But maybe that is exactly the use case here. I do not remember the name Samuel Colvin in  retrospect would have preferred for the concept - I will try to find it again and update my words here, sorry for the noise.

@jkornblum
How were you able to override the built-in Pydantic converter? I've created a custom converter, but it doesn't seem to take precedence.

authors: jkornblum mure prkumar sthagen

repo: prkumar/uplink


text:
Module build failed: Error: Couldn't find preset "es2015" relative to directory "/node_modules/markdown-to-jsx"

Here is the error:
Uncaught Error: Module build failed: Error: Couldn't find preset "es2015" relative to directory "/var/www/kcrypt/frontend/node_modules/markdown-to-jsx"
    at :3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:293
    at Array.map (<anonymous>)
    at OptionManager.resolvePresets (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:275)
    at OptionManager.mergePresets (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:264)
    at OptionManager.mergeOptions (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:249)
    at OptionManager.init (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368)
    at File.initOptions (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/index.js:212)
    at new File (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/index.js:135)
    at Pipeline.transform (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/pipeline.js:46)
    at transpile (:3000/var/www/kcrypt/frontend/node_modules/babel-loader/lib/index.js:50)
    at Object.module.exports (:3000/var/www/kcrypt/frontend/node_modules/babel-loader/lib/index.js:175)
    at :3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:293
    at Array.map (<anonymous>)
    at OptionManager.resolvePresets (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:275)
    at OptionManager.mergePresets (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:264)
    at OptionManager.mergeOptions (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:249)
    at OptionManager.init (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368)
    at File.initOptions (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/index.js:212)
    at new File (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/file/index.js:135)
    at Pipeline.transform (:3000/var/www/kcrypt/frontend/node_modules/babel-core/lib/transformation/pipeline.js:46)
    at transpile (:3000/var/www/kcrypt/frontend/node_modules/babel-loader/lib/index.js:50)
    at Object.module.exports (:3000/var/www/kcrypt/frontend/node_modules/babel-loader/lib/index.js:175)
    at Object.<anonymous> (ViewPostComponent.js:65)
    at __webpack_require__ (bootstrap c145be9b1a2adf02a477:19)
    at Object.<anonymous> (ViewPostComponent.js:1)
    at __webpack_require__ (bootstrap c145be9b1a2adf02a477:19)
    at Object.defineProperty.value (PostsRoutes.js:16)
    at __webpack_require__ (bootstrap c145be9b1a2adf02a477:19)
    at Object._typeof (index.js:28)
    at __webpack_require__ (bootstrap c145be9b1a2adf02a477:19)
    at Object.<anonymous> (main.bundle.js:27759)
    at __webpack_require__ (bootstrap c145be9b1a2adf02a477:19)
(anonymous) @ ViewPostComponent.js:65
__webpack_require__ @ bootstrap c145be9b1a2adf02a477:19
(anonymous) @ ViewPostComponent.js:1
__webpack_require__ @ bootstrap c145be9b1a2adf02a477:19
Object.defineProperty.value @ PostsRoutes.js:16
__webpack_require__ @ bootstrap c145be9b1a2adf02a477:19
_typeof @ index.js:28
__webpack_require__ @ bootstrap c145be9b1a2adf02a477:19
(anonymous) @ main.bundle.js:27759
__webpack_require__ @ bootstrap c145be9b1a2adf02a477:19
Object.defineProperty.value @ bootstrap c145be9b1a2adf02a477:62
(anonymous) @ bootstrap c145be9b1a2adf02a477:62

I'm using babel-env and don't want to install preset es2015. Can I still use markdown-to-jsx? What about babel 7?

@HristoKolev updated to preset env in 6.6.4.
Not going to handle babel 7 until it's out of beta, thanks!

It's also worth mentioning that this package ships a transpiled version already, shouldn't need to run babel over it.

It still doesn't work after the update. I think that you missed babel field in your project.json file.

@HristoKolev I don't even remember adding that heh. Removed in 6.6.5.

authors: HristoKolev probablyup

repo: probablyup/markdown-to-jsx


text:
Report target voltage in CLI when available

ST-Link probes support reporting the target voltage detected on their VAPP pin, which is a useful problem-solving tool when solving connection issues. openocd prints this information by default for every operation:
Info : Target voltage: 1.529843

I propose that probe-rs-cli and related tools would benefit from reporting this information to the user whenever available.
Additionally, there are several QoL improvements which could easily be built on top of this functionality. Firstly, warning in the case of a voltage which is clearly too low, again in the style of openocd:
Error: target voltage may be too low for reliable debugging

I can also imagine it being easy to detect a disconnected VAPP pin by taking several consecutive measurements and comparing them. When left disconnected, the measured target voltage seems to flicker between several values, in my case:
0.003141
1.556545
0.001571

whereas a correctly connected VAPP fluctuates by around 0.02v. When handling errors like SwdDpFault, SwdApError, JtagGetIdcodeError and SwdDpParityError (for which little-to-no useful debugging information is currently available), automatically detecting a disconnected VAPP from the fluctuating target voltage would be a useful diagnostic.

I’d be happy to try working on any of these enhancements, but I’m new to rust and would need some guidance. I already browsed through the code and found a few places which seem relevant, but it isn’t obvious to me exactly where the features I propose would best fit into the codebase.

I’d be happy to try working on any of these enhancements, but I’m new to rust and would need some guidance. I already browsed through the code and found a few places which seem relevant, but it isn’t obvious to me exactly where the features I propose would best fit into the codebase.

Oh, I forgot to mention: the same error case caused by leaving VAPP disconnected can sometimes cause probe-rs-cli info to print an empty Available Access Ports: rather than an error. Whatever codepath leads to that outcome would therefore also be a candidate for low target voltage or disconnected-VAPP diagnostics, but it’s also possible that printing an empty Available Access Ports: rather than an error should be considered a separate bug.

Oh, I forgot to mention: the same error case caused by leaving VAPP disconnected can sometimes cause probe-rs-cli info to print an empty Available Access Ports: rather than an error. Whatever codepath leads to that outcome would therefore also be a candidate for low target voltage or disconnected-VAPP diagnostics, but it’s also possible that printing an empty Available Access Ports: rather than an error should be considered a separate bug.

I think it's a great idea to add this.
I would suggest to add a new function to the DebugProbe trait, which can be used to read the target voltage.
The function can then be implemented by the different probes.
On the Probe struct you can then add a similar function, which forwards to the actual probe. Similar to how the Probe::speed_khz() function works.
For reporting the voltage, it would probably be easiest in the beginnnig to add some log output to the Probe::attach method, which prints the detected voltage.

I think it's a great idea to add this.
I would suggest to add a new function to the DebugProbe trait, which can be used to read the target voltage.
The function can then be implemented by the different probes.
On the Probe struct you can then add a similar function, which forwards to the actual probe. Similar to how the Probe::speed_khz() function works.
For reporting the voltage, it would probably be easiest in the beginnnig to add some log output to the Probe::attach method, which prints the detected voltage.

authors: Tiwalun barnabywalters

repo: probe-rs/probe-rs


text:
Root

Bug Report
Current Behavior
A clear and concise description of the behavior.
// Your code here
module.exports = (app) => {
  app.log.info("There is a bug");
};

Expected behavior/code
A clear and concise description of what you expected to happen (or code).
Environment

Probot version(s): [e.g. v6.0.0]
Node/npm version: [e.g. Node 8/npm 5]
OS: [e.g. OSX 10.13.4, Windows 10]

Possible Solution

Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.

i
ü

ayvazjet@gmail.com

authors: ayvazjet golfviva

repo: probot/probot

license: ISC


text:
Return something helpful on GET / when opened in the browser

Right now, the root path returns a 404 and the text Cannot GET /.
It would be nice if we could return something more helpful. That would also allow us to use the root path for monitoring of our probot apps :)

just found out about GET /ping so that is good enough for monitoring 👍
I’ll still have a look into this

This has long been fixed since #279. Thanks for the reminder @stale[bot]! 💖


text:
daysUntilStale not being strictly enforced, plus surge of notifications within periods of calm

Hi. Thanks for this bot. It really helps.
I've got a question. If I have daysUntilStale=7, why do I often get situations like this, where the stale bot intervenes in an issue a few days after the 7 days mark has passed?
See how in the example below, the bot commented 13 days after the last activity.

OTOH we've noticed surges of stale-bot notifications. That is, we have days without any activity, and then days when there's a significant surge. I'd rather have a few notifications coming in daily than having days with all the notifications from the past few days all at once.

We've noticed the same thing, and ended up switching to a scheduled GitHub action (https://github.com/actions/stale). This is just my personal theory, but I'm suspecting that GitHub changed an API and stale-bot now has to run in intervals instead of continuously like it did before.

authors: embeddedt gnapse

repo: probot/stale

license: isc


text:
Duplicate comments

I'm observing some double commenting over at atom/atom. Take a look at atom/atom#8267, atom/atom#8252 and atom/atom#8249
Is this an issue with stale bot, or something that is configured wrong by atom team?

It's not the configuration.

@hultberg @lee-dohm have you see any more duplicate comments? I haven't been able to track down what happened here, and haven't seen it anywhere else.
I'm going to close this, but let me know if you've seen it again and I'll reopen it.

authors: bkeepers hultberg lee-dohm


text:
[FEAT] Home - always display paragraph titles + add back to top

WIP
May be available live at https://cdn.statically.io/gh/process-analytics/bpmn-visualization-examples/feat/always_display_title_in_home_add_back_to_top/examples/index.html

Work in progress bb63c822

New improvements: cfa23f9
improvements:

h2 sticky position: the background color of the h2 elements must still be reworked to better match the theme
back to top: no more text-decoration, better positioning when reaching the bottom of the page (it still moves a little)

Attempt to let collapse some sections: 613dcba

Improvements 6e71fc3

Titles have been removed from preview images in #98, so last try for cards.

image on top 3203fe3 (as before)
title on top 59f5b24

I prefer the title on top 🙂
Nice job 😉

I also prefer "Title on top" and agree we need to rework the CSS to highlight them, maybe a light background color.

After working on the topic with @aibcmars (thanks again), this is now ready for review

Card title on top of the card (as everybody agree on this) and made more visible
no more glitch after clicking on the card or usage the tabulation to access the card
'back to top' button: always stay at bottom and more visible on hover/focus

On MacOS + safari:

authors: NathalieC csouchet tbouffard


text:
New versions released on npm do not contain the latest changes

@kurtaking  Are you sure that the new versions released on npm contain the changes?
I'm currently trying to enable authentication in our instance again and the search module fails to authorize (as before). If I try it via local linking of the current mainline it works fine. Looking into the minified version of the dependencies, they don't seem to contain the expected code (@procore-oss/backstage-plugin-search-backend-module-announcements 0.2.0 for example).
Originally posted by @Roshick in https://github.com/procore-oss/backstage-plugin-announcements/issues/249#issuecomment-2072054879

@kurtaking the latest release now includes my changes and the auth is working! :) It's probably still a good idea to try to understand how this happened.

This is pretty strange.  Noticed the same trying to run these in my environment:
        <AnnouncementsPage
          ...
          buttonOptions={{ name: "Pizza" }}
          ...
          />

But am met with Property 'buttonOptions' does not exist on type 'IntrinsicAttributes & { themeId?: string | undefined; title?: string | undefined; subtitle?: string | undefined; category?: string | undefined; cardOptions?: { ...; } | undefined; }'
Running in:
"@procore-oss/backstage-plugin-announcements@^0.6.2":
  version "0.6.2"

But the release says it's there...?
https://github.com/procore-oss/backstage-plugin-announcements/blob/main/plugins/announcements/CHANGELOG.md#patch-changes

Weird. I don't know what is happening right now, and I am tapped out for resources. 😞

I tried reverting back to publishing with yarn changset publish, but that released two versions with the workspace:^ in the package.json instead of the actual version. I'm still stumped on this.

authors: Roshick billabongrob kurtaking


text:
Add a state diagram to the documentation

Something similar to https://github.com/timgit/pg-boss/blob/master/docs/readme.md#job-states

Note: we can do it with Mermaid, Myst supports it (so does Github Flavored Markdown)

I gave it a shot and it's a bit annoying:

If we don't compile the mermaid graph when building the doc (a.k.a raw):

We won't know if there's a syntax error at build time
Actually, even as I'm trying to do that, Mermaid won't say what the syntax error is Oo
(and it will be probably trickier for some doc users though probably a very small proportion who don't consume the doc in the browser)

if we compile it (a.k.a svg)

Then we need node in the build (that's actually ok but probably a bit annoying)
And also, the doc build is slower
(and for some reason, I don't encounter the same issues in raw vs svg, no idea why)

(also light/dark mode)
I'll post my branch as a starting point but I probably won't be spending more time on it until we know where we're going. That said, anyone willing to continue it, feel free :)

As cool as something like Mermaid is, our state chart isn't that difficult (and hopefully consistent as soon as we get the "aborting" state caused by me out again 😞). How about just creating it by hand with a SVG editor? In the SVG, we can also use CSS to support the light and dark modes. I can look into it for the v3 branch (then I don't have to include "aborting").

You're probably right. Let's say the question is whether we just intend to have a single graph or if we can think of other parts of the doc that could benefit from some of the graphs Mermaid supports. I don't see one right now but I'll keep a brain cell on that, and I'll try to filter actually useful ideas, not just useless but cool ones :D

I also gave it a shot using Mermaid but in raw mode, and I think it's quite pretty 🙂. I used the "neutral" theme, which looks ok in light and dark mode. I also put a legend below that describes the edges, making it more clear and not so bloated. The syntax error in your example came from [](), which I also did not manage to escape inside the graph (but it doesn't matter, IMHO). I built the graph in their playground, where error reporting is better. I prefer the raw mode because it is easier to build. Even the unrendered source of the graph is simple to understand.

Closed by #1208

authors: ewjoachim medihack

repo: procrastinate-org/procrastinate


text:
Bind to IPv4 ( 0.0.0.0 ); fix listening port print to console

Change-type: patch
Signed-off-by: Ramiro Gonzalez ramiro.gonzalez@balena.io

This PR makes the server listen on 0.0.0.0 to force it to use an IPv4 address.
According to (https://nodejs.org/docs/latest-v16.x/api/net.html#serverlisten)[https://nodejs.org/docs/latest-v16.x/api/net.html#serverlisten]

If host is omitted, the server will accept connections on the unspecified IPv6 address (::) when IPv6 is available, or the unspecified IPv4 address (0.0.0.0) otherwise.

This seems to explain what happens on https://github.com/product-os/jellyfish/pull/8385, meaning that if the host has both IPv6 and IPv4 available, it will bind to the IPv6 "localhost"

repo: product-os/jellyfish-metrics


text:
Improve heuristics in trigger validation

This PR covers a few more cases where we can safely reject the trigger without having to make a query to the database.

@balena-ci I self-certify!

repo: product-os/jellyfish-worker


text:
Loosen up cheerio dependency

Loosen up the cheerio dependency, since enzyme 1.5.0 now requires cheerio ^0.20.0 . /cc @lelandrichardson  [Fixes #28] [Closes #25]
Initially I tried removing the dependency, but we're requiring it in our codebase. (😓)

:+1:

@ljharb thoughts?

:+1:

LGTM, other than, that all three deps should use ^ or .x syntax because it's weird to mix them :-)

@ayrton would you rebase this on latest master?

Will do tomorrow and merge in

authors: andreasklinger ayrton ljharb vesln

repo: producthunt/chai-enzyme


text:
MASTER : Master skill

master add skill, delete skill, and window to see what skills master has

issue is completed

authors: Elbekovich temurkodirov

repo: profexuz/profex-desktop


text:
Compilation problems on async example

I tried to use moon-core straight out of the box to convert a function of mine to async, so that it could show a loading indicator while loading.  I got some compiler errors.
So I tried to just compile the sugared async example, and got the same errors.  Maybe my haxe 3.2.1 for win7x64 is the wrong environment?  Or am I missing something else?
Here's trying to compile the example from the command line:
C:\HaxeToolkit\haxe\lib\moon-core\1,0,0\test>haxe -lib moon-core -main AsyncSuga
redExamples AsyncSugaredExamples.hx
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:20
: characters 22-42 : Class<haxe.macro.Context> has no field getLocalType
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:58
: characters 22-40 : Class<haxe.macro.Context> has no field currentPos
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:60
: characters 25-47 : Class<haxe.macro.Context> has no field getBuildFields
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:12
5: characters 12-30 : Class<haxe.macro.Context> has no field defineType
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:20
: characters 22-42 : Class<haxe.macro.Context> has no field getLocalType
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncMacroTools.hx
:121: characters 27-41 : Class<haxe.macro.Context> has no field typeof
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:70: characters 29-52 : Class<haxe.macro.Context> has no field getExpectedType
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:79: characters 30-43 : Class<haxe.macro.Context> has no field error
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:90: characters 25-39 : Class<haxe.macro.Context> has no field typeof
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:121: characters 26-39 : Class<haxe.macro.Context> has no field error
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:200: characters 15-37 : Class<haxe.macro.Context> has no field getLocalModule
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:648: characters 34-47 : Class<haxe.macro.Context> has no field error
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:654: characters 30-43 : Class<haxe.macro.Context> has no field error
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:1173: characters 32-34 : Class<haxe.macro.Context> has no field makeExpr
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:1273: characters 48-50 : Class<haxe.macro.Context> has no field makeExpr
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:1307: characters 38-40 : Class<haxe.macro.Context> has no field makeExpr
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:1313: characters 36-38 : Class<haxe.macro.Context> has no field makeExpr
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:1339: characters 43-45 : Class<haxe.macro.Context> has no field makeExpr
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:1353: characters 51-53 : Class<haxe.macro.Context> has no field makeExpr

And here's from my project:
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:20: characters 22-42 : Class<haxe.macro.Context> has no field getLocalType
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:58: characters 22-40 : Class<haxe.macro.Context> has no field currentPos
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:60: characters 25-47 : Class<haxe.macro.Context> has no field getBuildFields
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:125: characters 12-30 : Class<haxe.macro.Context> has no field defineType
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/signal/SignalMacro.hx:20: characters 22-42 : Class<haxe.macro.Context> has no field getLocalType
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncMacroTools.hx:121: characters 27-41 : Class<haxe.macro.Context> has no field typeof
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:70: characters 29-52 : Class<haxe.macro.Context> has no field getExpectedType
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:79: characters 30-43 : Class<haxe.macro.Context> has no field error
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:90: characters 25-39 : Class<haxe.macro.Context> has no field typeof
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:121: characters 26-39 : Class<haxe.macro.Context> has no field error
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:200: characters 15-37 : Class<haxe.macro.Context> has no field getLocalModule
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:648: characters 34-47 : Class<haxe.macro.Context> has no field error
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:654: characters 30-43 : Class<haxe.macro.Context> has no field error
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:1173: characters 32-34 : Class<haxe.macro.Context> has no field makeExpr
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:1273: characters 48-50 : Class<haxe.macro.Context> has no field makeExpr
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:1307: characters 38-40 : Class<haxe.macro.Context> has no field makeExpr
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:1313: characters 36-38 : Class<haxe.macro.Context> has no field makeExpr
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:1339: characters 43-45 : Class<haxe.macro.Context> has no field makeExpr
C:/HaxeToolkit/haxe/lib/moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.hx:1353: characters 51-53 : Class<haxe.macro.Context> has no field makeExpr

(...plus a few others specific to my project)

In my naive attempt at problem-solving here, I started wrapping anything that was complaining in #if macro blocks.  That started working until AsyncTransformer:
C:\HaxeToolkit\haxe\lib\moon-core\1,0,0\test>haxe -lib moon-core AsyncSugaredExa
mples.hx
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Int
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Int
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Bool
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Bool
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Int
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Int
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Bool
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Int
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Bool
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Float
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Float
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Float
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Int
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Int
C:\HaxeToolkit\haxe\lib\moon-core/1,0,0/src/moon/macros/async/AsyncTransformer.h
x:283: characters 38-42 : On static platforms, null can't be used as basic type
Bool

If I change the offending line to            codes.push(macro var $v:Dynamic = null); it compiles...

But then compiling it for cpp fails:
cl.exe -Iinclude -nologo -O2 /WX- /fp:precise -DHX_WINDOWS -D_USING_V140_SDK71_
-GR -FS -Oy- -c -EHs -GS- -arch:SSE -IC:/HaxeToolkit/haxe/lib/hxcpp/3,2,205/incl
ude -DHXCPP_VISIT_ALLOCS -DHXCPP_API_LEVEL=321 -D_CRT_SECURE_NO_DEPRECATE -D_ALL
OW_MSC_VER_MISMATCH -D_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH -wd4996 -MT ./src/__r
esources__.cpp -FoC:/HaxeToolkit/haxe/lib/moon-core/1,0,0/test/export/obj/msvc19
xp/501f6158___resources__.obj
AsyncSugaredExamples.cpp
./src/AsyncSugaredExamples.cpp(233): error C2365: 'AsyncSugaredExamples_obj::cus
tomIterator::_Function_2_1::__run': redefinition; previous definition was 'data
member'
./src/AsyncSugaredExamples.cpp(200): note: see declaration of 'AsyncSugaredExamp
les_obj::customIterator::_Function_2_1::__run'
./src/AsyncSugaredExamples.cpp(414): error C2365: 'AsyncSugaredExamples_obj::sim
pleExample::_Function_1_1::run::_Function_3_1::__run': redefinition; previous de
finition was 'data member'
./src/AsyncSugaredExamples.cpp(381): note: see declaration of 'AsyncSugaredExamp
les_obj::simpleExample::_Function_1_1::run::_Function_3_1::__run'
./src/AsyncSugaredExamples.cpp(792): error C2365: 'AsyncSugaredExamples_obj::per
mutationsExample::_Function_2_1::run::_Function_4_1::__run': redefinition; previ
ous definition was 'data member'
./src/AsyncSugaredExamples.cpp(763): note: see declaration of 'AsyncSugaredExamp
les_obj::permutationsExample::_Function_2_1::run::_Function_4_1::__run'
./src/AsyncSugaredExamples.cpp(1027): error C2365: 'AsyncSugaredExamples_obj::ne
stedExample::_Function_1_1::run::_Function_3_1::__run': redefinition; previous d
efinition was 'data member'
./src/AsyncSugaredExamples.cpp(994): note: see declaration of 'AsyncSugaredExamp
les_obj::nestedExample::_Function_1_1::run::_Function_3_1::__run'
./src/AsyncSugaredExamples.cpp(1295): error C2365: 'AsyncSugaredExamples_obj::fi
bonacciExample::_Function_1_1::run::_Function_3_1::__run': redefinition; previou
s definition was 'data member'
./src/AsyncSugaredExamples.cpp(1262): note: see declaration of 'AsyncSugaredExam
ples_obj::fibonacciExample::_Function_1_1::run::_Function_3_1::__run'
./src/AsyncSugaredExamples.cpp(1628): error C2365: 'AsyncSugaredExamples_obj::se
ndExample::_Function_1_1::run::_Function_3_1::__run': redefinition; previous def
inition was 'data member'
./src/AsyncSugaredExamples.cpp(1595): note: see declaration of 'AsyncSugaredExam
ples_obj::sendExample::_Function_1_1::run::_Function_3_1::__run'
./src/AsyncSugaredExamples.cpp(1927): error C2365: 'AsyncSugaredExamples_obj::an
otherSendExample::_Function_1_1::run::_Function_3_1::__run': redefinition; previ
ous definition was 'data member'
./src/AsyncSugaredExamples.cpp(1894): note: see declaration of 'AsyncSugaredExam
ples_obj::anotherSendExample::_Function_1_1::run::_Function_3_1::__run'
./src/AsyncSugaredExamples.cpp(2212): error C2365: 'AsyncSugaredExamples_obj::fi
berExample::_Function_1_1::run::_Function_3_1::__run': redefinition; previous de
finition was 'data member'
./src/AsyncSugaredExamples.cpp(2179): note: see declaration of 'AsyncSugaredExam
ples_obj::fiberExample::_Function_1_1::run::_Function_3_1::__run'
./src/AsyncSugaredExamples.cpp(2500): error C2365: 'AsyncSugaredExamples_obj::fi
berFutureExample::_Function_1_1::run::_Function_3_1::__run': redefinition; previ
ous definition was 'data member'
./src/AsyncSugaredExamples.cpp(2467): note: see declaration of 'AsyncSugaredExam
ples_obj::fiberFutureExample::_Function_1_1::run::_Function_3_1::__run'
./src/AsyncSugaredExamples.cpp(2761): error C2365: 'AsyncSugaredExamples_obj::fi
berDurationExample::_Function_1_1::run::_Function_3_1::__run': redefinition; pre
vious definition was 'data member'
./src/AsyncSugaredExamples.cpp(2728): note: see declaration of 'AsyncSugaredExam
ples_obj::fiberDurationExample::_Function_1_1::run::_Function_3_1::__run'

__files__.cpp
__boot__.cpp
__resources__.cpp
Error: Build failed

Yikes. So far I've mostly tested it on neko and javascript. I haven't really tried it on static platforms. I'll try to get this working on static targets for the next release.


text:
rename userLabel attribute to NodeLabel in both Basic Information Cluster and Bridge Basic Information Cluster

rename userLabel attribute to NodeLabel (Mandatory attribute) in both Basic Information Cluster and Bridge Basic Information Cluster. SDK needs to have implementation for the added UniqueID attribute
Spec Ref

closing this one, as this is done

authors: cjandhyala franck-apple

repo: project-chip/connectedhomeip


text:
cecille): We should add a PII bytespan concept.

false

https://github.com/project-chip/connectedhomeip/blob/f0f5de0d79ae1c51d7fddbf70900ebac0acd899a/src/controller/CommissioningDelegate.h#L57-L62

This issue was generated by todo-issue based on a TODO comment in f0f5de0d79ae1c51d7fddbf70900ebac0acd899a.

Please remove this TODO

authors: tcarmelveilleux woody-apple


text:
[Android] Use MEI char array attributes

Reproduction steps
We are trying to gather Manufacturer cluster information based on samples-app-for-matter-android and attempt to edit the sample-mei-cluster.xml to read XML attributes but we are having a hard time to understand what the attribute line should look like, here's our attempt:
<attribute side="server" code="0x0000" define="MAC_ADDR" type="chararray" writable="false" default="">MacAddress</attribute>

And we are tried to build the lib with scripts/tools/zap_regen_all.py but failed. Is there any guide on how to do to read MEI attributes which are char array?
Platform
android
Platform Version(s)
No response
Type
Manually tested with SDK
(Optional) If manually tested please explain why this is only manually tested
No response
Anything else?
https://developers.home.google.com/matter/extensions/sample-cluster

I don't know what you mean by "chararray".  The types in the XML are spec-defined types.  For something like a MAC address, you probably want octstr (which represents a byte sequence).

@bzbarsky-apple We do not know where to find the lib and import into Android Studio, can you give us a guide on where to do so?

authors: bzbarsky-apple law-ko


text:
[BouffaloLab] Update BouffaloLab platform requirements

bflb-iot-tool need to specify some module version, like pyserial module.

Thanks, updated.

bflb-iot-tool need to specify some module version, like pyserial module.

bflb-iot-tool need to specify some module version, like pyserial module.

bflb-iot-tool need to specify some module version, like pyserial module.

This description seems incomplete - you seem to be adding module not just specifying versions. Given that boufallolab examples already compile could you explain the change?
As a reviewer I would like to understand where this is heading because for now we share pip modules across all platforms (our fault: we use the free version of buildjet so we cache only one build environment) so any modules interacts with all other platforms: fixing versions has higher chances of conflicts and more dependencies will cause images to become slightly larger (probably not much, but would still like to understand and ensure the images are minimal).

I unpacked https://pypi.org/project/bflb-iot-tool/1.8.6/#files and I see:
    install_requires=[
        'ecdsa>=0.15',
        'pycryptodome==3.9.8',
        'bflb-crypto-plus==1.0',
        'pycklink>=0.1.1',
        'pyserial==3.5',
        'pylink-square==0.5.0',
        'portalocker==2.0.0'
    ],

in setup.py
So you do not need these requirements here.

You are right， but use  "source ./scripts/activate.sh -p bouffalolab" to install bflb-iot-tool will appear dependency conflicts. I have contact bflb-iot -tool developer try reslove this issue.


text:
Test RAM savings if we re-order some structure members based on pahole feedback

Just randomly picked some structures, to see if going this path is even remotely worthwile.
Expectation is that RAM usage should decrease in some platforms.

This seems to give some savings across the board. Moving it out of draft.


text:
Move StoreCurrentUpdateInfo() call from ApplyUpdate to DownloadUpdate

Update to DefaultOTARequestor.cpp where the API call to StoreCurrentUpdateInfo() is moved from ApplyUpdate() to DownloadUpdate().

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

authors: CLAassistant NicholasFay-IFX


text:
Update demos for v0.6.1

Issue link
#281
What changes have been made

Updated notebooks to reflect changes in v0.6.1
Also polished various bits to be more informative/up-to-date

Checks

[x] I've made sure the tests are passing.
Testing Strategy

[ ] Unit tests
[ ] Manual tests
[x] Testing is not required for this change

@tedhtchang @jbusche the only reason that the batch demos were removed is because they were redundant (so not actually being removed). Take a look in the PR at guided-demos/2_basic_jobs.ipynb and guided-demos/notebooks-ex-outputs/2_basic_jobs.ipynb and let me know if you feel anything in there does not encompass what was in the batch demos.

@MichaelClifford needs to approve this PR.

authors: Maxusmusti anishasthana

repo: project-codeflare/codeflare-sdk


text:
feat(costmodels): Migrate to PF4 DataToolbar in Assign Sources

address #1306

Codecov Report

Merging #1347 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1347   +/-   ##
=======================================
  Coverage   76.99%   76.99%
=======================================
  Files         222      222
  Lines        4347     4347
  Branches      840      840
=======================================
  Hits         3347     3347
  Misses        874      874
  Partials      126      126

Continue to review full report at Codecov.

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

repo: project-koku/koku-ui


text:
Export AWS orgs

Enabled CSV export for AWS org units.
https://issues.redhat.com/browse/COST-488

Codecov Report

Merging #1653 into master will increase coverage by 0.04%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1653      +/-   ##
==========================================
+ Coverage   77.05%   77.10%   +0.04%
==========================================
  Files         242      243       +1
  Lines        4114     4118       +4
  Branches      742      742
==========================================
+ Hits         3170     3175       +5
  Misses        845      845
+ Partials       99       98       -1

Impacted Files
Coverage Δ

src/utils/computedReport/getComputedReportItems.ts
71.64% <100.00%> (+1.49%)
:arrow_up:

.../sources/InactiveSources/inactiveSources.styles.ts
100.00% <0.00%> (ø)

...onents/sources/InactiveSources/InactiveSources.tsx
16.66% <0.00%> (+0.82%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: codecov-commenter dlabrecq


text:
lang: Error if account init payer account is not marked mutable

This coincidentally works if the account is not marked mutable since the client will use the provider to pay for the transaction (and thus it is mutable). However, we should require the developer to explicitly mark these paying accounts mutable.

I'm up for giving this a spin. First time I dive into this part of Anchor though, so do you have a specific place where adding this logic would be best, maybe?
I see there seems to be constraint checks done here, but they seem limited to per-account checks (e.g. payer attribute unique per account), and I have not found an instance of cross-account check yet.
Would it make sense to add these checks here?

@losman0s are you still interesting in doing this?
If so, you can add the checks in this new function https://github.com/project-serum/anchor/blob/01ff03b09b30b974f2854dd0b0b9a958dd509622/lang/syn/src/parser/accounts/mod.rs#L40

@paul-schaaf yes, been a bit tied up the last few days but I'll get to it soon. Thanks for the update.

Hi guys im experiencing this error, can any one help
thread 'main' panicked at 'Code not parseable: Error("the payer specified for an init constraint must be mutable.")', lang/syn/src/idl/file.rs:360:58
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Hi guys im experiencing this error, can any one help
thread 'main' panicked at 'Code not parseable: Error("the payer specified for an init constraint must be mutable.")', lang/syn/src/idl/file.rs:360:58 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

It should pretty much be what the error describes. You are likely init-ing an account through the init macro, but forgot to mark the payer account you specified as mut.
If this does not fix your issue, please post your question on Discord instead.

Oh thanks, that solved the issue. but im finally trying to deploy to dev net but i get this error again
error: Custom: Invalid blockhash
There was a problem deploying: Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "" }.

Even if this does not fix your issue, please post your question on Discord instead.

Whats the link to the discord channel seems the one i'm on wont allow me post anything
Thanks

authors: adimnaka armaniferrante losman0s paul-schaaf

repo: project-serum/anchor


text:
SB-22577 - remove unused variables.

SB-22577  Refactoring implementation for reliability and scalability - 1

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Type of change
Please choose appropriate options.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes in the below checkboxes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Ran Test A
[ ] Ran Test B

Test Configuration:

Software versions: Java 11, scala-2.11, play-2.7.2
Hardware versions:

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

We have StorageService implicit variables defined in MimeTypeManagerFactory also.

authors: PradyumnaNagendra maheshkumargangula

repo: project-sunbird/knowledge-platform


text:
Sodium dump 2022a

sodium's dump 🆗

well done

license: Unlicense


text:
H1 and H2 size look very similar

need to change H2 text size to be smaller in CSS.
Sub-topics are very hard to differentiate with H1 and H2 sizes being very similar.
See this doc for example: https://tigera.github.io/calico/master/reference/architecture/

H1's should not be used more than once (or in documentation at all for that matter), as per https://github.com/projectcalico/calico/issues/39#issuecomment-251835326

repo: projectcalico/calico


text:
Fix swapped VM endpoint label values

Description
Fixes the OpenStack VM endpoint label values (they're in the wrong place.)

Related issues/PRs

Todos

[ ] Tests
[ ] Documentation
[ ] Release note

Release Note

None required

Deploy preview for calico ready!
Built with commit 80c791cd22f4f090bb31a754bbf728bce8352a58
https://deploy-preview-2743--calico.netlify.com

authors: caseydavenport lmm


text:
Docs update - add operator steps to the metric page

Description
This PR adds required changes for the metrics page to support an Operator installation.
Update: Services are now headless. (Thanks to @fasaxc for explanation)
Add: Tabs added to the document to split manifest and Operator resources.
Update: Promethues config updated to get rid of typha-client discovery. (reported by Daniel Carroll in slack)
Add: API-server friendly commands to the document.
Related issues/PRs
https://calicousers.slack.com/archives/CPTH1KS00/p1639154366343900
Todos

[ ] Documentation

Release Note
None required

I have been told: "third time's a charm". :grin:
@caseydavenport


text:
Moved IP validation into libcalico

so that other calico orchestrator plugins can reuse it

Accidently opened this, closing in favor of #91

repo: projectcalico/libcalico


text:
Add support for customizing the interface prefix

Currently it's hardcoded to "cali"

Fixed by #88

repo: projectcalico/libnetwork-plugin


text:
Updated License Changes

updated license changes for OPENSSF Compilance

Expected syntax:
Commit message one-line summary
  Extra paragraphs can be added here.

  Longer description that explains the problem / solution
  or whatever that needs to be said

  It can contain
    multiple lines
    multiple paragraphs
    blank lines
    references

  But each paragraph must be followed by a blank line

  However, you need to keep the 'Tracked-On', 'Change-Id',
  'Signed-off-by', ..., fields in the **lastest** paragraph of
  the commit message.

  Change-Id: I9e58f79c7faf7f0edb9792e8b5322ab161331141
  Tracked-On: https://jira.server.ext/browse/PROJECTA-123
  Signed-off-by: Developer Name <developer.name@intel.com>

Android CI has completed MERGE Build for this pr, build is SUCCESS. Please check the linked Tracked-On issue/Android CI Web  for more details. For Binaries: /cactus-absp-or-local/celadon-merge/762

authors: sysopenci xshahbazintel

repo: projectceladon/external-mesa


text:
Fix katana consuming all cpu

consider a scenario of url is some icon or css url
it does not have any more urls to traverse, at that time
it was looping and checking if queue is nil or not for 10s.
if we are passing multiple urls, then it consume all the CPU
coz, infinite loop and using time.Now() in for loop.
now, it will check after 1s.

Using dev branch

using this PR

repo: projectdiscovery/katana


text:
Features can be flipped off but not back on

Descriptive summary
Flipflop 2.3.0 released 23 days ago switched the param value used to commit from "on" to "1" which breaks flipping features back on.  Hyrax should either pin to flipflop 2.2.1, create an issue with flipflop, or update the view to use the new value for commit.
Flipflop code in question:
https://github.com/voormedia/flipflop/blob/master/app/controllers/flipflop/strategies_controller.rb#L17-L19
Hyrax submit button with "on" value:
https://github.com/projecthydra-labs/hyrax/blob/master/app/views/hyrax/admin/features/index.html.erb#L44
Commit in question:
https://github.com/voormedia/flipflop/commit/51cc858f3307003d16c15dd78ad8541941bd3274#diff-50f28c8e6f2ebbc297d52daa88bac730

https://github.com/voormedia/flipflop/issues/20

Fixed by Flipflop 2.3.1

authors: cjcolvar jcoyne

repo: projecthydra-labs/hyrax


text:
jsclient not responding

I just decided to do the https://tryappservice.azure.com/en-us tutorial. I dowloaded the native iOS and played around using the iPhone simulator. I wanted to see if the data that I entered into the app would be available if accessed from another device. I tried to go to https://f264c34c-0ee0-4-231-b9ee.azurewebsites.net/jsclient/ where the guid obviously is my "try-it-out" id. The jslient page loaded but it is not getting any data. This is what the page looks like:

Regards,
Johan Sundström

The JS client had an issue and we've currently removed it from Try App Service. We'll add it back soon.

repo: projectkudu/SimpleWAWS


text:
Error running kudu locally

I followed the video at https://www.youtube.com/watch?v=FmufYOz0KXI  and ran kudu locally on Win 10 with VS 2015 installed.
Doing so I get the following error in the log file:
2016-03-21T23:48:53.7374231Z,Command: "C:\Projects\Kudu\apps\mysite\site\deployments\tools\deploy.cmd",,0     2016-03-21T23:48:53.9515164Z,Handling .NET Web Application deployment.,,0     2016-03-21T23:48:55.1898520Z,  Test -> C:\Projects\Kudu\apps\mysite\site\repository\bin\Test.dll,,0     2016-03-21T23:48:55.4373125Z,  Transformed Web.config using C:\Projects\Kudu\apps\mysite\site\repository\Web.Release.config into obj\Release\TransformWebConfig\transformed\Web.config.,,0     2016-03-21T23:48:55.4478190Z,  Copying all files to temporary location below for package/publish:,,0     2016-03-21T23:48:55.4578256Z,  C:\Users\mysite\AppData\Local\Temp\8d351e35c1dd7ff.,,0     2016-03-21T23:48:55.6695261Z,Error: Value cannot be null.,,1     2016-03-21T23:48:55.6770302Z,Parameter name: name,,1     2016-03-21T23:48:55.6825338Z,Failed exitCode=1, command="kudusync" -v 50 -f "C:\Users\mysite\AppData\Local\Temp\8d351e35c1dd7ff" -t "C:\Projects\Kudu\apps\mysite\site\wwwroot" -n "C:\Projects\Kudu\apps\mysite\site\deployments\fa7d7cd8decc22fdaac4d81c9b61896eb3b7aec8\manifest" -p "c:\Projects\Kudu\Kudu.Services.Web\bin\scripts\firstDeploymentManifest" -i ".git;.hg;.deployment;deploy.cmd",,0     2016-03-21T23:48:55.6920406Z,An error has occurred during web site deployment.,,0     2016-03-21T23:48:55.7100530Z,Error: Value cannot be null.\r\nParameter name: name\r\nc:\Projects\Kudu\Kudu.Services.Web\bin\scripts\starter.cmd "C:\Projects\Kudu\apps\mysite\site\deployments\tools\deploy.cmd",,2     2016-03-21T23:48:55.7160425Z,   at Kudu.Core.Infrastructure.Executable.ExecuteInternal(ITracer tracer, Func2 onWriteOutput, Func2 onWriteError, Encoding encoding, String arguments, Object[] args) in C:\Projects\Kudu\Kudu.Core\Infrastructure\Executable.cs:line 235\r\n   at Kudu.Core.Infrastructure.Executable.ExecuteWithProgressWriter(ILogger logger, ITracer tracer, String arguments, Object[] args) in C:\Projects\Kudu\Kudu.Core\Infrastructure\Executable.cs:line 115,,2
What am I doing wrong? Why is the application trying to write to C:\Users\mysite\AppData\Local\Temp\ folder when mysite is the name of the site I am creating?

Hi
Kudu will continue to run in Azure App Service. However, this repo will no longer be maintained.
If the problem persists and is related to running on Azure App Service, please open a support incident in Azure:
https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request
This way we can better track and assist you on this case
Thanks,
Joaquin Vano
Azure App Service

authors: ajayrahatekar jvano

repo: projectkudu/kudu


text:
Detected WebJob file/s were updated, refreshing WebJob

Hi,
I'm completely confused now!
I started a "Hello World" web job on Friday, uploaded it as a zip, it ran etc.
Did this through a few iterations.
Then we spent some time working on the VSTS build/deployment steps to get this webjob build and deployed, and eventually got it to deploy with its parent web app.
However after deployment it was appearing as Stopped in the azure portal, and the following was in the logs.
Detected WebJob file/s were updated, refreshing WebJob
Status changed to Stopped

Back to zipping again and reverted the code to the bare minimum but was still getting the above error.
I tried deploying to a different Azure App Service and it worked there!!!
WebJob is built using .Net Core 2.
Parent Web App is Asp.Net Core 2.
The contents of the zip file I upload is the contents of the dotnet publish target folder.
Any ideas how to figure out the above error.
Apologies if this is not the correct place to ask!
Using VS 2017 15.5.5
Targetting .NET Core 2
<PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions" Version="3.0.0-beta4" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="2.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging.Console" Version="2.0.0" />

Dummy site - adummysitetotracewebjobproblem
Real site - starts with b, ends with e
It runs in a different web app in same plan - starts with w ends with n
Thanks
Donal

@dmcweeney , Are you using Azure App Service Manage task (Stop/Start continuous webjobs actions) to manage your WebJobs or Azure PowerShell task?
Azure App Service Manage task uses WebJobs API to start and stop all continuous Jobs.
Earlier, we provided a workaround to use the WEBJOBS_STOPPED variable using Azure PowerShell.

Hi @vincentdass we are using the Azure App Service Manage task to stop before deployment and start after deployment.
We have not been able to reproduce this since but keeping a close eye on it.

authors: dmcweeney vincentdass


text:
Highlight several dates with color.

Good afternoon! Can I highlight a few dates as in the picture? How can I do that?

you can use a decorator to do this! You might wanna have a different drawable for the first element, the last element, and the elements in the middle.


text:
Add an OnPageChangeListener that can be publicly accessed from MaterialCalendarView

In order to react with user's swipe action.

It's called OnMonthChangeListener 👍

Hi sorry for not being clear. I was referring to WeekMode.
So I guess I was looking for onWeekChangeListener ?  Thanks.


text:
collect-smartctl-json: shell fixes for script (#188)

Remove ", ( and ) from file names (see #188)
Added regex ignore for some devices, fixes:

Collecting data for '/dev/sda'...       Saving to sat-Intel_S4510_S4610_S4500_S4600_Series_SSDs-INTEL_SSDSC2KB240G8-sda.json
Collecting data for '/dev/sdb'...       Saving to sat-Intel_S4510_S4610_S4500_S4600_Series_SSDs-INTEL_SSDSC2KB240G8-sdb.json
Collecting data for '/dev/bus/0'...jq: error (at <stdin>:34): null (null) cannot be matched, as it is not a string
        Saving to null-null--0.json
Collecting data for '/dev/bus/0'...jq: error (at <stdin>:34): null (null) cannot be matched, as it is not a string
        Saving to null-null--0.json
Collecting data for '/dev/nvme0'...     Saving to nvme-null-HUSMR7632BHP301-nvme0.json
Collecting data for '/dev/nvme1'...     Saving to nvme-null-HUSMR7632BHP301-nvme1.json
Collecting data for '/dev/nvme2'...     Saving to nvme-null-HUSMR7632BHP301-nvme2.json
Collecting data for '/dev/nvme3'...     Saving to nvme-null-HUSMR7632BHP301-nvme3.json
Collecting data for '/dev/nvme4'...     Saving to nvme-null-HUSMR7632BHP301-nvme4.json

The /dev/bus/* is some pseudo-device comes with Broadcom driver, after fix:
Collecting data for '/dev/sda'...       Saving to sat-Intel_S4510_S4610_S4500_S4600_Series_SSDs-INTEL_SSDSC2KB240G8-sda.json
Collecting data for '/dev/sdb'...       Saving to sat-Intel_S4510_S4610_S4500_S4600_Series_SSDs-INTEL_SSDSC2KB240G8-sdb.json
Collecting data for '/dev/nvme0'...     Saving to nvme-null-HUSMR7632BHP301-nvme0.json
Collecting data for '/dev/nvme1'...     Saving to nvme-null-HUSMR7632BHP301-nvme1.json
Collecting data for '/dev/nvme2'...     Saving to nvme-null-HUSMR7632BHP301-nvme2.json
Collecting data for '/dev/nvme3'...     Saving to nvme-null-HUSMR7632BHP301-nvme3.json
Collecting data for '/dev/nvme4'...     Saving to nvme-null-HUSMR7632BHP301-nvme4.json

1.+1 on dropping /dev/bus; other than weird raid controllers, I can't think of anything we need in there, that's captured in Linux source tree anyway.

Should we allow-list the acceptable name characters rather than replace specific ones? [A-Za-z0-9._+*,-] would be my first-pass on allowed chars.


text:
test

Description
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Type of change
What type of changes does your code introduce to the kube-prometheus? Put an x in the box that apply.

[ ] CHANGE (fix or feature that would cause existing functionality to not work as expected)
[ ] FEATURE (non-breaking change which adds functionality)
[ ] BUGFIX (non-breaking change which fixes an issue)
[ ] ENHANCEMENT (non-breaking change which improves existing functionality)
[ ] NONE (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

Changelog entry
Please put a one-line changelog entry below. Later this will be copied to the changelog file.

https://github.com/prometheus-operator/kube-prometheus/pull/2172 fails so this is required

repo: prometheus-operator/kube-prometheus


text:
stat fails on process names with spaces

Reference: https://www.openwall.com/lists/oss-security/2022/12/21/6
Failing test: in fixtures.tarr, change line 628 from
26231 (vim) R 5392 7446 5392 34835 7446 4218880 32533 309516 26 82 1677 44 158 99 20 0 1 0 82375 56274944 1981 18446744073709551615 4194304 6294284 140736914091744 140736914087944 139965136429984 0 0 12288 1870679807 0 0 0 17 0 0 0 31 0 0 8391624 8481048 16420864 140736914093252 140736914093279 140736914093279 140736914096107 0
to:
26231 (RDD Process) R 5392 7446 5392 34835 7446 4218880 32533 309516 26 82 1677 44 158 99 20 0 1 0 82375 56274944 1981 18446744073709551615 4194304 6294284 140736914091744 140736914087944 139965136429984 0 0 12288 1870679807 0 0 0 17 0 0 0 31 0 0 8391624 8481048 16420864 140736914093252 140736914093279 140736914093279 140736914096107 0
Before change:
$ make test
>> extracting fixtures testdata/fixtures
./ttar -C testdata/ -x -f testdata/fixtures.ttar
touch testdata/fixtures/.unpacked
>> running all tests
go test -race  ./...
ok  	github.com/prometheus/procfs	0.220s
ok  	github.com/prometheus/procfs/bcache	0.031s
ok  	github.com/prometheus/procfs/blockdevice	0.028s
ok  	github.com/prometheus/procfs/btrfs	0.027s
ok  	github.com/prometheus/procfs/internal/fs	(cached)
ok  	github.com/prometheus/procfs/internal/util	(cached)
ok  	github.com/prometheus/procfs/iscsi	0.023s
ok  	github.com/prometheus/procfs/nfs	(cached)
ok  	github.com/prometheus/procfs/sysfs	0.081s
ok  	github.com/prometheus/procfs/xfs	0.029s

After above change:
$ make test
>> extracting fixtures testdata/fixtures
./ttar -C testdata/ -x -f testdata/fixtures.ttar
touch testdata/fixtures/.unpacked
>> running all tests
go test -race  ./...
--- FAIL: TestProcStatComm (0.00s)
    proc_stat_test.go:113: want comm vim, have RDD Process
FAIL
FAIL	github.com/prometheus/procfs	0.209s
ok  	github.com/prometheus/procfs/bcache	0.025s
ok  	github.com/prometheus/procfs/blockdevice	0.031s
ok  	github.com/prometheus/procfs/btrfs	0.029s
ok  	github.com/prometheus/procfs/internal/fs	(cached)
ok  	github.com/prometheus/procfs/internal/util	(cached)
ok  	github.com/prometheus/procfs/iscsi	0.023s
ok  	github.com/prometheus/procfs/nfs	(cached)
ok  	github.com/prometheus/procfs/sysfs	0.081s
ok  	github.com/prometheus/procfs/xfs	0.028s
FAIL
make: *** [Makefile.common:151: common-test] Error 1

Commit and env:
$ git rev-parse HEAD
bb7727a9ca9b3cd1559b42ffa74e13ef7efb6283
$ uname -a
Linux optiplex7010 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ go version
go version go1.18 linux/amd64

Apologies, the above changes to fixtures.ttar do not show the issue, just me not properly understanding these tests.

Just wrote a short Go program that indicates parsing spaces is ok.

repo: prometheus/procfs