Question: Usage with Angular 10+

Library

[ ]<EMAIL_ADDRESS>or<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>[x]<EMAIL_ADDRESS>[x]<EMAIL_ADDRESS>[ ]<EMAIL_ADDRESS>
Description
Will I able to use the library with Angular 11. Your documentation says that only version 2 can be used but it's in alpha. So, I was wondering how I should go about it?
Source

[ ] Internal (Microsoft)
[ ] Customer request

@akshaybabloo We would encourage you to try out our msal-angular v2 library and send us any feedback you have. We are working on it, and msal-angular v2 should be in public preview soon.
Alternatively, you can try implementing your own version of msal inside your Angular 11 application to wrap msal-browser. While it does not have the up-to-date features that are in msal-angular v2, you can try referencing our angular10-browser-sample, which implements msal in the application and uses msal-browser.

@akshaybabloo We would encourage you to try out our msal-angular v2 library and send us any feedback you have. We are working on it, and msal-angular v2 should be in public preview soon.
Alternatively, you can try implementing your own version of msal inside your Angular 11 application to wrap msal-browser. While it does not have the up-to-date features that are in msal-angular v2, you can try referencing our angular10-browser-sample, which implements msal in the application and uses msal-browser.

OK got it. Thanks.

OK got it. Thanks.


create migration and relation

I want to Create migration like: php artisan make:migration for creating migration with your package, can i do this one? how work your package for migration? and how can use or select model data like eloquent in your package? you don't have any example!

I'm afraid none of us really use this package anymore so I don't know either how to do that you're asking. You might wanna find an alternative package that is more supported.


Add GetFullName

Fixes #22. Not a lot else to say. This should be an exact replica of GetFullName, including the behavior where game is excluded from the full name.

Coverage increased (+0.05%) to 96.586% when pulling 20ac5c33769ebe3cd312896cdccebbe241d3fc92 on AmaranthineCodices:getfullname into 4c29218057ff24d6a8964d798469ebc991a16f4c on LPGhatguy:master.

PR has already been merged but can you also add it to FEATURES.md?

This was already done in 1279dc60c676448e021ac12cfb4d95866917b74a.


Add ImageSetID to image creation event for notification link.

Description
Add ImageSetID to image creation event for notification link.
Currently we only send the image id and we need both image id and imageset id for the link to the image.
Fixes # (issue)
Type of change
What is it?

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] 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
[ ] I run make pre-commit to check fmt/vet/lint/test-no-fdo

Codecov Report
Base: 49.50% // Head: 49.53% // Increases project coverage by +0.03% :tada:

Coverage data is based on head (590c899) compared to base (2f574e3).
Patch coverage: 0.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1825      +/-   ##
==========================================
+ Coverage   49.50%   49.53%   +0.03%
==========================================
  Files          70       70
  Lines        9834     9834
==========================================
+ Hits         4868     4871       +3
+ Misses       4503     4501       -2
+ Partials      463      462       -1

Impacted Files
Coverage Δ

pkg/services/images.go
32.70% <0.00%> (ø)

pkg/services/devices.go
50.43% <0.00%> (+0.32%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Implement missing basic functions

Basi functions which are missing:

[x] fmod
[x] remainder
[x] fdim
[x] clip

Implemented in #46


Don't convert key to bytes on Python 3. Fixes #565.

Disables the first clause on Python 3. I did test and setting a 'unicode' attribute of an object on Python 2 is also acceptable, but per the guidance on not changing Python 2 behavior, I'm leaving that undesirable code in place and only disabling it when not on Python 2, thus having zero impact on the officially-supported Python versions.

I meant for this to be against working.

For whatever it's worth, I have no intention of supporting Python 3 as it would just give this project further legs in a time where we're working to move away from it. Of course this change by itself is fine, but there will be no wholesale porting effort.

Coverage remained the same at 96.674% when pulling c72aff60924689d65384270f1c8309a7a65ef2ef on jaraco:issue-565 into b4691a3b1d4aa46892cf051c841995670f27aea6 on rackspace:master.


Update PowerShell version

To the latest worker build.
cc @pragnagopa @SteveL-MSFT @daxian-dbw @asavaritayal @soninaren @ahmelsayed

Can you also update https://github.com/Azure/azure-functions-docker/blob/master/host/2.0/stretch/amd64/mesh.Dockerfile#L12

@ahmelsayed good catch. Will keep that in mind for next time. All fixed now!

@ahmelsayed are there any blockers to merge this in?

Thanks @ahmelsayed! What's the release process like for this container to MCR? Just want to check when I can start playing with this :smile:

@tylerl0706  It should be there under mcr.microsoft.com/azure-functions/powershell:dev by now (the CI machine builds it on merge), though I'm also building mcr.microsoft.com/azure-functions/powershell:2.0.12165 and once that's done I'll update the 2.0 tag

Awesome. Thanks @ahmelsayed. I'll give it a try tomorrow


trealla: only put valgrind in checkInputs if not darwin

Description of changes
Fixes breakage caused by #215567
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 219568 run on aarch64-darwin 1

1 package built:

trealla

The diff LGTM. I suggest rebasing this branch to combine both commits in this PR into one commit that has the message
trealla: only put valgrind in checkInputs if not aarch64-darwin

because valgrind does not work on Apple Silicon

In line with https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#writing-good-commit-messages

Ok, will rebase into one commit.


Messages in client for events

For example "Username joined your server", "Username disconnected from your server", ...

If you're bored, you can even add a sound effect like Teamspeak.


build(ci): Github actions dispatch

OpenRegistry runs differently now: We need to mount the config directory inside the container at runtime. This PR takes care of that.
We're also adding a dispatch.yml file to orchestrate running of workflows on Pull requests as such:

External Apps (like GitGuardian runs independently)
Linter runs first
If Linter succeeds, We run all the OCI Tests

OCI Push
OCI Pull
OCI Content Discovery
OCI Content Management

If Linter fails, everything stops

@guacamole this PR waits on #194


non-persistant entities

although the test project is build with a non-persistant entity as a testcase: a widget created with the boilerplate which actually passes an entity to the widget is never allowed to use a non-persistant entity.
Even when adding allowNonPersistableEntities="true" to the entity in the XML.
This is either a bug or the test project needs to be updated to only use a persistant object. At the moment it's not possible to use the test project to test a widget which uses a entity as input.

We will look into this for #31


chore(deps): upgrade dev dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-dev-dependencies-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2258

Questions ?
Please refer to the Backport tool documentation


Long test names are truncated

As this example shows, long test titles are truncated. However, there is currently no way to see the full test title.

Possible solutions

Show full test title when test is expanded
Add title attribute to the <h4> so hovering will show the full test title

Fixed in 2.3.2


Publish new version to crates.io

The git2 version in the repo is 0.15.0, however crates.io only has the version 14.4.
Could you please publish the latest version to crates.io? This fixes a segfault issue hit by some of my projects.

Yea, I can publish the new versions soon.

The new versions should be published now.

Thank you very much.


gitsubmodules download

I want to do this myself but i don't know how. i need it do download gitsubmodules

@klowdo - do you mean on build process via Dockerfile or just in your fork?

in the docker file. i'm using atlasboard that use submodules as plugins to the dashboard. i tried adding git-core to docker file. but the "git repository" don't exsist in src

@klowdo I don't understand this statement:

but the "git repository" don't exsist in src

can you please clarify?

@curcuz i want to download the git submodules in the docker build. Because i need it in my output directory
I'm using atlasboard and submodule https://bitbucket.org/atlassian/atlasboard-atlassian-package

@klowdo
A git submodule, as per git official documentation is a way "to keep another Git repository in a subdirectory of your repository." - so you should either add the desired repos as submodules to your own repo or clone them on the Dockerfile.
So, again, I don't understand this statement:

but the "git repository" don't exsist in src

what src?
Also,

i want to download the git submodules in the docker build

you can't download submodules since they are just links to repositories. You can clone them in the docker build
Maybe you meant that the resin builder ignores submodules you have set in your repository? in that case, can you please provide a description of how you added the submodules before pushing to resin builder, what is expected and what is the given output from the builder?

Okey i understand! i wll clone in advance an push them in as my own code! thanks!


RFC: Set CARGO_CHECK environment variable when type checking

Add a new environment variable CARGO_CHECK that is set to true when running cargo check so build scripts can skip expensive compilation steps that are unnecessary for Rust type checking, such as compiling external C++ code in cxx based projects.
Rendered

Is there a reason why you propose an environment variable instead of just, a cfg option? Sure, the environment variable can be accessed in the main function in the build.rs script, but it can't be used for conditional compilation even though that would be incredibly handy as well. This would not only remove the runtime penalty of doing all these things, but the compile time penalty of using them in the build script as well.
You would just have to ensure that this cfg option is only available in the build script itself, and not in the actual crate or its dependencies, since you could do some really naughty things otherwise…

Is there a reason why you propose an environment variable instead of just, a cfg option? Sure, the environment variable can be accessed in the main function in the build.rs script, but it can't be used for conditional compilation even though that would be incredibly handy as well. This would not only remove the runtime penalty of doing all these things, but the compile time penalty of using them in the build script as well.

Wouldn't this be about the same since Cargo needs to build all build-dependencies regardless of whether it is checking or compiling? I would expect that excluding these dependencies would be more significant than time savings from partially configuring out build.rs (since the build script itself usually doesn't contain a lot of slow-to-compile logic), but that would require being able to specify something like codegen-only build dependencies or features.
One advantage of using an environment variable is that you can compile the build script once and use it for both checking and codegen.

Wouldn't this be about the same since Cargo needs to build all build-dependencies regardless of whether it is checking or compiling? I would expect that excluding these dependencies would be more significant than time savings from partially configuring out build.rs (since the build script itself usually doesn't contain a lot of slow-to-compile logic), but that would require being able to specify something like codegen-only build dependencies or features.

That's fair, although I guess that my thought process was that dependencies don't change often and thus can have their builds cached, whereas build scripts would essentially need to be built and run no matter what.
Since the RFC mentions rust-analyzer specifically, I'd imagine that the primary case is speeding up type checking between changes of the code when dependencies would already be built, but I guess that also changing the build script would be a potential use case.
I guess it is one of those weird cases where compiling two copies only is a big deal if you need to compile both copies often, whereas here you'd likely only be building one or the other.

A cfg option would undermine the purpose of cargo check: Code with cfg(not(check)) would not be checked, so you couldn't be sure that your code compiles until you actually build it.
Right now, it is possible for cargo build to fail even though cargo check succeeded, but this should be extremely rare.

A couple people have said it's best not to have this as a cfg since that would mean it's possible for cargo check to miss code that's only configured in when not(check); but, that's still possible with it as an environment variable - you could just set a cfg in the build script. That may be obvious, but I do feel like any way for conditional compilation to tell the difference between check and build is probably inoptimal - my current intuition is that check is just build-but-cheaper, and this could change it to something more like 2 different build profiles.

Code with cfg(not(check)) would not be checked, so you couldn't be sure that your code compiles until you actually build it.

That's still possible with it as an environment variable - you could just set a cfg in the build script. That may be obvious, but I do feel like any way for conditional compilation to tell the difference between check and build is probably inoptimal - my current intuition is that check is just build-but-cheaper, and this could change it to something more like 2 different build profiles.


Cannot select input and output directories in GUI desktop application

When attempting to select audio directory under "Batch analysis", "Segments", or "Review", there is no error or reaction from the GUI. Doesn't open a file path for me to select a directory.
To Reproduce
Steps to reproduce the behavior:
For the GUI:

Go to 'Single analysis' to upload a file
Click on 'Segments' in order to extract the analyzed 3 second segments
Scroll down to 'Select audio directory (recursive)'
No reaction
For the CLI provide us with the arguments used.

Expected behavior
Expect that it opens a file path for me to select my audio directory which allows me to manually verify 3 s segments of analyzed recordings. The auto-ID results are given along with a confidence interval but I cannot vet them.
Using Windows

I am having a similar problem with my Desktop BirdNET:
When attempting to select audio input directory under "Batch analysis", "Segments", or "Review", a large ERROR message is displayed and it doesn't open a file path for me to select a directory.

Hi,
i am assuming your are using the windows installer version.
This may be related to selecting the "install for all users" option when installing the GUI, at least thats where i encounter similar problems.
Reinstalling with the "install for me only" option might already fix this issue. Alternatively starting the gui as administrator might also be a workaround.
More general this may be caused by installing into a directory where you don't have write access, as the GUI uses some files to store settings. So if you changed the default path during installation this might also be related.
I will also see if i can make it more robust to this problem.

Thanks for these potential fixes, I'll give them a try.
One challenge is the desktop (and BirdNET on it) is used by multiple students to analyze their recordings, so the "install for all users" is really useful for me here. I suppose I can try the reinstall and giving everyone administrator access, but that isn't ideal either.
In the end, would be helpful to know if/when you can make it more robust to this problem.
Thanks for the quick feedback.


Property $ does not exist on Ref property when using em.populate(Entity, ...)

Describe the bug
I am unsure if this is a bug, or if the docs simply need to be updated, but when calling WrappedEntity.populate(...) or em.populate(Entity, ...) without assigning to a new variable we lose any sort of type hints to the fact we have indeed populated the reference.
To Reproduce
Steps to reproduce the behavior:
// Foo entity
@Entity()
export class Foo extends BaseEntity<Foo, "id"> {
  @PrimaryKey()
  id: number;

  @ManyToOne(() => Bar, { onUpdateIntegrity: "cascade", onDelete: "cascade" })
  bar: Ref<Bar>;
}

// Bar
@Entity()
export class Bar extends BaseEntity<Bar, "id"> {
  @PrimaryKey()
  id: number;

  @Property()
  name: string;
}

@Injectable()
export class FooService {
  constructor(private readonly orm: MikroORM) {}

  async populateFooOnFind(fooId: number): Promise<Foo> {
    const foo = await this.orm.em.findOneOrFail(Foo, fooId, {
      populate: ["bar"],
    });
    console.log(foo.bar.$.name); // Fine
    return foo;
  }

  async populateFooAfterFind(fooId: number): Promise<Foo> {
    const foo = await this.orm.em.findOneOrFail(Foo, fooId);
    await this.orm.em.populate(foo, ["bar"]);
    console.log(foo.bar.$.name); // TS2339: Property  $  does not exist on type  { id: number; } & Reference<Baz>
    return foo;
  }

  async populatePassedFoo(foo: Foo): Promise<Foo> {
    await this.orm.em.populate(foo, ["baz"]);
    console.log(foo.baz.$.name); // TS2339: Property  $  does not exist on type  { id: number; } & Reference<Baz>
    return foo;
  }

  async populatePassedFooNewVar(foo: Foo): Promise<Foo> {
    const populatedFoo = await foo.populate(["baz"]);
    console.log(populatedFoo.baz.$.name); // Fine
    return foo;
  }

  async populatePassedFooAssignOldVar(foo: Foo): Promise<Foo> {
    foo = await foo.populate(["baz"]);
    console.log(foo.baz.$.name); // TS2339: Property  $  does not exist on type  { id: number; } & Reference<Baz>
    return foo;
  }
}

Expected behavior
Given that the populate method mutates the original entity it would be expected that it also changes the typing of the variable. That being said, this may be a limitation of Typescript or simply intended behavior.
Versions

Dependency
Version

node
16.16.0

typescript
5.2.2

mikro-orm
5.8.3

your-driver
MySQL

This is a wontfix, it is not possible to alter a type of an existing property, only way to do this is via asserts keyword, which does not work with async methods (and it would require us to return boolean - it cannot do both, either it mutates, or it returns something).
I am planning to have a section about working with the Loaded type in the getting started guide, so will try to mention this there.

I figured it was something like that. Is there any way to restrict usage of the get() or the $ keywords unless you use a find* method? That would probably be more explicit, but also likely a large chore to attempt.

Another question (and this is stretching my knowledge of Typescript): if we passed a Loaded<Foo> instead of just Foo to the methods, is there any way to expand the type that way in changing the never signature to the type hints? I'm thinking of things like how type assertions work on optional fields.


Create sites using sharepoint v2 api

Can we have a detailed documentation of how to create sharepoint sites using the v2.0 sharepoint API

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: accadff1-1b70-6a67-4465-d66245aa3a09
Version Independent ID: 8e108e60-9c50-0856-712c-f85e64c9813a
Content: Operations using SharePoint REST v2 (Microsoft Graph) endpoints
Content Source: docs/apis/sharepoint-rest-graph.md
Product: sharepoint online
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

The Graph API does not support creating sites. You should be using the  v1 SharePoint APIs for this.


refactor: uniformized the way to show the nutrition page

Impacted files:

add_new_product_page.dart: now using the new method showNutritionPage
add_nutrition_button.dart: now using the new method showNutritionPage
edit_product_page.dart: now using the new method showNutritionPage
nutrition_page_loaded.dart: new method showNutritionPage

What

While having a look at #3354 I noticed that some not-easy code was repeating 3 times.
I've created a method instead.

Part of

#3354

Codecov Report

Merging #3362 (f377a92) into develop (b72a8b0) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           develop    #3362      +/-   ##
===========================================
- Coverage    10.48%   10.47%   -0.02%
===========================================
  Files          255      255
  Lines        12405    12421      +16
===========================================
  Hits          1301     1301
- Misses       11104    11120      +16

Impacted Files
Coverage Δ

...th_app/lib/pages/product/add_new_product_page.dart
0.00% <0.00%> (ø)

...th_app/lib/pages/product/add_nutrition_button.dart
0.00% <0.00%> (ø)

...mooth_app/lib/pages/product/edit_product_page.dart
0.54% <ø> (-0.04%)
:arrow_down:

...h_app/lib/pages/product/nutrition_page_loaded.dart
0.00% <0.00%> (ø)

...pp/lib/pages/product/common/product_refresher.dart
2.00% <0.00%> (-0.05%)
:arrow_down:

...smooth_app/lib/pages/product/new_product_page.dart
0.00% <0.00%> (ø)

...ib/cards/product_cards/product_image_carousel.dart
0.00% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Improve description how to enable hyperlinks in tables when using Direct Query

Please update the description to set a column to Web URL on this page https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-hyperlinks-in-tables.
The current description "2. In Data view, select the column." does not work for Direct Query, because there is no Data view when you use direct query.

What works for both In Memory and Direct Query, is to select the column in the Data panel in the Report view.

Then the same Column tool ribbon is shown, where you can set the Data Category to Web URL.
Please update the description and the screenshot. Thank you very much for considering this update. :-)

Thanks for your comment, @hski-bayer. This issue has been assigned to the doc author for review.

Hi @hski-bayer,
Thank you for your suggestion, we'll consider this update in one of our future doc revamps.
Kesem

Hello Kesem,
How frequently are you doing those doc updates? I am asking because I consider a lot of people struggling with this problematic description which does not work, if you work with direct query.
Also I would not consider this issue as "closed", as the issue is still there, just postponed to be resolved, right?
BR, Holger


Added new dotnetcore Active learning sample

Active learning sample on latest architecture and with latest SDK data.
Support for nodejs added
Remove it from experimental.
Update the documentation.

Parity with JS required.

NodeJS is also added


Delete uique indexes first to avoid "Duplicate entry" error

"Duplicate entry" could occur if we drop a column and
a unique index which include the column.

Coverage increased (+0.006%) to 96.846% when pulling 83141362b8f4129f4e9e908f59ad67523f990f10 on abicky:hotfix/drop-unique-index into 2e115c504a6c5e65111759fdcfc746904e8197b8 on winebarrel:0.7.

Thanks!


Fix condition to use default value in case parameter is not set

Reason for Change:
PR introduced a change where if the MellanoxMonitorIntervalSecs is not passed in we should use the default value, however the condition was faulty and in case of implicit default 0 value (when config value is not set), we are not defaulting to 30 secs explicit default value.
Issue Fixed:

Requirements:

[x] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] relevant PR labels added

Notes:

@smittal22 this PR shows no changes now, which doesn't seem right

@smittal22 this PR shows no changes now, which doesn't seem right

@rbtr Yeah, I reverted it. Will work on it later. Might even close this out.

@smittal22 No need to push a revert commit on something that hasn't been merged. You can just leave it.


added socket_offload_dns_deregister (ST-1522)

Changes

added simple API, socket_offload_dns_deregister, to allow deregistering offloaded API and consequently adding another one.

Testing

verified within application code that re-registration works and functions for appropriate device are called

__ASSERT_NO_MSG(dns_offload)

There are __ASSERT_NO_MSG(dns_offload); in a couple of functions. Any concern that deregistering will result in a crash if we don't properly synchronize calls to DNS?

Yes. The assertions are within actual API calls. That's why application ensures DNS API is registered before use of those APIs. Deregistration puts DNS offload into initial state.

There are __ASSERT_NO_MSG(dns_offload); in a couple of functions. Any concern that deregistering will result in a crash if we don't properly synchronize calls to DNS?

Yes. The assertions are within actual API calls. That's why application ensures DNS API is registered before use of those APIs. Deregistration puts DNS offload into initial state.

I understand that. But normally we set up the DNS and then don't worry about it. Now we'll be constantly deregistering/registering. This isn't so much a comment for this PR. Just that we need to be aware of this and make sure we don't do DNS calls if not registered, because that will cause an assert/reboot.

I also recommend we submit this upstream. May be it'll make into into main repo.

I also recommend we submit this upstream. May be it'll make into into main repo.

I'll do that. Just waiting on feedback from Mariano if there is a suggested alternative way for this.

There are __ASSERT_NO_MSG(dns_offload); in a couple of functions. Any concern that deregistering will result in a crash if we don't properly synchronize calls to DNS?

Yes. The assertions are within actual API calls. That's why application ensures DNS API is registered before use of those APIs. Deregistration puts DNS offload into initial state.

I understand that. But normally we set up the DNS and then don't worry about it. Now we'll be constantly deregistering/registering. This isn't so much a comment for this PR. Just that we need to be aware of this and make sure we don't do DNS calls if not registered, because that will cause an assert/reboot.

Fair enough. We ensure this by actually registering when setsocketoption is called, which selects correct socket interface. This should ensure we always have correct API registered. You'll see that in app PR.


Add exif to php container to support sylius

See the sylius documentation. PR incoming

Added PR for Variant A (new php-fpm image type with exif support) and Variant B (exif support in base php-fpm image)


Empty result on get requests v4.0.2

When I try to get my apps or devices etc..
I get the right count but an empty result...
curl -X 'GET' \
  'http://<IP>:8090/api/devices?applicationId=<APPID>' \
  -H 'accept: application/json' \
  -H 'Grpc-Metadata-Authorization: Bearer <API-TOKEN>'

{
  "totalCount": 2,
  "result": []
}

As far as I know you have to specify the limit parameter as well.
You can set it to 10 for example:
curl -X 'GET' \
  'http://<IP>:8090/api/devices?limit=10&applicationId=<APPID>'  \
  -H 'accept: application/json' \
  -H 'Grpc-Metadata-Authorization: Bearer <API-TOKEN>'

{
  "totalCount": 2,
  "result": [
    {
      "devEui": "<devEui>",
      "createdAt": "2022-02-01T10:18:21.093435Z",
      "updatedAt": "2022-02-01T10:18:21.093435Z",
      "lastSeenAt": "2022-10-28T17:23:44.801669Z",
      "name": "<name>",
      "description": "...",
      "deviceProfileId": "...",
      "deviceProfileName": "...",
      "deviceStatus": {
        "margin": 27,
        "externalPowerSource": true,
        "batteryLevel": -1
      }
    },
    .....
    .....
    }
  ]
}

@Korny666 did this solve your issue?

@t-huyeng Thanks for the hint. it did.


Expect ttl suffix by default for model loads.

https://github.com/geneontology/minerva/issues/80

Looks right enough.


install.sh: Use cut, grep and sed instead of awk

If install.sh relies on awk, install.sh malfunctions when run on a
device with a limited environment where awk is not available. This patch
replaces the use of awk with cut, grep and sed commands.
Change-Id: I071d9f565ff7ef38445a6dd0ea9692b903721601
Signed-off-by: Joakim Roubert<EMAIL_ADDRESS>

I'm not doubting the need for this, but I'm curious what environment doesn't have awk?  Is busybox awk not enough?  Just an honest question.
Can you please put a comment somewhere in the file that we have purposely avoided the use of awk.  Seems like something down the line we will get another PR say, "cleaned up script by using awk".

I'm not doubting the need for this, but I'm curious what environment doesn't have awk? Is busybox awk not enough? Just an honest question.

Thank you for your swift and nice response! An honest question deserves an honest answer: this is not something I made up theoretically, but stumbled upon when trying to fire up k3s on a device with a small armv7 openembedded/yocto-based system. I really like k3s and the aim for small devices with limited resources, and am trying to show the "hey, look at this, just this single line 'curl -sfL https://get.k3s.io | sh -' is all that is needed to get going!" experience. With "oh, well, then I need to install awk too, no, not for k3s per se but just the installer" that experience is just not the same cool pull-the-trigger-and-go one.
So, grep and sed was already used in the script, so I add a dependency to cut while removing the one to awk. From what I have seen, cut is more ubiquitous than awk on systems that do not have both, although I am open to facts that state the opposite.
Anyways, I have this patch for my own use and thought I'd might share it since others might run k3s on restricted systems just like me.

Can you please put a comment somewhere in the file that we have purposely avoided the use of awk. Seems like some point down the line we will get another PR saying, "cleaned up script by using awk".

Yes, that is indeed a good idea and I will do that immediately.
For the record, I do like awk and use it almost every day, but when it comes to "cleaned up" in the context here, to me that is more like a case of "if all you have is a hammer, everything looks like a nail". Comparing
awk '{print $1}'
with the 3 character shorter and simpler
cut -d' ' -f1
that also uses a smaller program that is also (IMO?) expected to be found on more platforms, I cannot really see such an eventual change back as a cleanup.
It could of course be suggested to solve some of this with internal shell script functionality, but I reckon that would decrease maintainability since developers generally are more at ease with constructions like this.

One reason for using awk over cut or sed is that awk will handle different types of whitespace in a more robust manner. If there are slight variations in the utilities that output multiple spaces or tabs the parsing may break. It would be good to test & verify this change on multiple types of machines before merging.

One reason for using awk over cut or sed is that awk will handle different types of whitespace in a more robust manner. If there are slight variations in the utilities that output multiple spaces or tabs the parsing may break. It would be good to test & verify this change on multiple types of machines before merging.

Yes, awk is a nice tool indeed, when available.
I was thinking perhaps some of the handling awk/cut/sed here should/could be done with built-in shell functionality instead, where things like whitespace handling is very robust, the use of built-in functionality means maximum portability and a bonus is increased performance (although most people are not concerned with that these days). I have seen though that there often is a resistance towards using such built-ins since developers seem more comfortable with using external tools than built-in functionality. What are your thoughts on this?

Creating a shell function to parse out positional arguments sounds like a good idea, although may make for some complicated code with multi-line inputs (but at least reduce sed/cut to a single function). Unfortunately since this needs to be POSIX shell compatible we are missing the power of bash, but I do like the idea of creating a utility function for this.

Creating a shell function to parse out positional arguments sounds like a good idea, although may make for some complicated code with multi-line inputs (but at least reduce sed/cut to a single function). Unfortunately since this needs to be POSIX shell compatible we are missing the power of bash, but I do like the idea of creating a utility function for this.

I am a fan of POSIX and portability (the latter is, I guess, stating the obvious) so I'll see if I can come up with some suggestion. (Maybe I can't.)

I think it could be pretty simple, something like the following might work:
get_col() {
  pos=$1
  sed -e '...collapse whitespace...' | cut -d' ' -f $pos
}

The sha256sum trimming is easily solved with the construction
HASH_BIN=`sha256sum ${TMP_BIN}`
HASH_BIN=${HASH_BIN%%[[:blank:]]*}

which is more robust than cut since it handles all kinds of whitespace, more robust than awk since it is built-in functionality, more portable since it is built-in and then also faster. :-)
Well, those are the easy ones, I will look into the others tomorrow.

Yah thank you very much!
As a side note we would also like to support wget so that curl is not a requirement, if you have any interest in helping with that, I have been meaning to make a PR but dealing with other priorities.

As a side note we would also like to support wget so that curl is not a requirement, if you have any interest in helping with that, I have been meaning to make a PR but dealing with other priorities.

Out of curiosity: Why do you want wget instead of curl? I like wget and use it every day, but then again curl is everywhere on all systems while wget is not. Furthermore, curl has a MIT license whereas wget has GPLv3, meaning companies tend to prefer using curl. (And Daniel Stenberg, who seems to be a nice guy, won the Polhem prize for curl too). Even if I use wget as a user daily, I cannot see any reason to want wget in scripts. (I have actually made patches, for other projects, that replace wget with curl instead.)

Out of curiosity: Why do you want wget instead of curl? I like wget and use it every day, but then again curl is everywhere on all systems while wget is not.

Some operating systems / images may have wget installed by default rather than curl.

Some operating systems / images may have wget installed by default rather than curl.

I have several examples of the opposite! :-)
Perhaps the best thing would be if the script had support for both then? As long as either is in the system, the script would then select one of them and succeed.

Ah yes it should support both, sorry did not mean switch to wget instead of curl. Just need to add support for wget in case curl is not available, but keep the current curl code.

Yah thank you very much!

Now there is an updated patch where all awk ocurrences are replaced with built-in shell script functionality instead. Handling of whitespace(s) should be equally or more robust than awk with this setup.

Thanks for updating @joakimr-axis! Am planning to merge this on Monday, would like to do a little more testing first. Eventually I think we would like to see the killall functionality built into the k3s binary & probably re-written to use Go.


deps: Bump toolshed actions -> 0.0.2

This fixes an issue with sync

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

I have started adding tests for these actions (locally) so hopefully they should stabilize a bit


Standardize ACK Github labels

Currently, we manually create and manage labels in the community repository. Ideally, we could have a script/prow job that periodically syncs the Github labels.
Here is a list of requirements/nice-to-have things I'm thinking of:

We need to prefix all label names with their type: kind, area, priority, service, etc...
We need a label for each service controller named service/$SERVICE
We need labels for various areas/domains like area/architecture, area/infra, area/testing, area/documentation etc...
We need to automatically create a new label whenever a new service controller repository - probably this something we can combine with @JamesJHPark work.
Bring unique labels like release for release PRs, and needs-triage for unlabeled issues ...
Create a script that syncs the Github labels across all service controller repositories

/lifecycle frozen

Spent sometime brainstorming (mostly getting inspired from open source k/k style of labeling) what labels can be helpful fo r us to support.
Service labels (issues and PRs)

service/$AWS_SERVICE (when an issue or PR is related to one service and/or one service controller)
service/none (when an issue or PR a not related to any service specifically)
service/all (when an issue is related to all the services)

Area labels (issues and PRs):
(issues or PRs can have one or more of those)

area/testing (Categorizes issue or PR as related to unit tests or e2e tests)
area/runtime (Categorizes issue or PR as related to controller runtime, common reconciliation logic, etc...)
area/code-generation (Categorizes issue or PR as related to controllers or docs code generation)
area/infra (Categorizes issue or PR as related to our testing infrastructure, prow/flux configuration etc...)
area/automation (Categorizes issue or PR as related to automation on top of the infra, prow jobs, release jobs, github actions etc...)
area/api/k8s (Categorizes issue or PR as related to kubernetes API)
area/api/aws (Categorizes issue or PR as related to aws API)
area/multi-vesion (Categorizes issue or PR as related to multi version support)
area/documentation
area/security (Categorizes issue or PR as related to security aws or k8s side)
area/example (Categorizes issue or PR as related to published examples)
area/community-meeting (thinking meeting minutes etc...)

Kind labels (PRs and Issues):
(issues or PRs can have one or more of those)

kind/bug  Categorizes issue or PR as related to a bug.
kind/feature  Categorizes issue or PR as related to a bug.
kind/cleanup  Categorizes issue or PR as related to cleaning up code, process, or technical debt.
kind/deprecation  Categorizes issue or PR as related to a feature/enhancement marked for deprecation.
kind/design  Categorizes issue or PR as related to design.
kind/documentation  Categorizes issue or PR as related to documentation.
kind/regression  Categorizes issue or PR as related to a regression from a prior release.
kind/support  Categorizes issue or PR as a support question.
kind/flake  Categorizes issue or PR as related to a flaky test.
kind/failing-tests  Categorizes issue or PR as related to a consistently or frequently failing test.
kind/cve  Categorizes issue or PR as related to a CVE

Milestone labels (for runtime and code-generator related issues/PRs)

milestone/incomplete-labels
milestone/needs-approval
milestone/needs-attention
milestone/removed

Triage labels (Issues only)

triage/accepted
triage/duplicate Indicates an issue is a duplicate of other open issue.
triage/needs-information  Indicates an issue needs more information in order to work on it.
triage/not-reproducible  Indicates an issue can not be reproduced as described.
triage/unresolved  Indicates an issue that can not or will not be resolved.

Rare but can be usefull labels:

¯\_(ツ)_/¯ when things are just out of control

Newly created issues should be automatically tagged with needs-triage, needs-kind,  needs-area.

kubernetes org have a periodic prow job that calls label_sync  to sync labels from a labels.yaml file. We can either adopt the same script or build something simpler (label_sync was built to sync labels a cross multiple organizations and repositories and support deprecation)

@A-Hilaly I love this.


Clean up package.json and update dependencies

Still haven't seen the coveralls comment. Is there a way to check the status of that?

LGTM


refactor snowpack/src/commands/dev.ts into smaller files/classes

Changes
No functional change, no test change, only internal implementation is refactored. While working on #1122 (in turn, as a result of https://github.com/snowpackjs/snowpack/pull/2051#issuecomment-748519763), I feel that  snowpack/src/commands/dev.ts:

is too big (~1400 lines)
has no unit test (only integration test at test/create-snowpack-app, but this integration test takes like ~30s, which is too long for productive quick feedback loop)
has too many levels of functional closure.

This is a best-attempt refactor, it's not ideal, but a start. Functional closures are refactored into classes.
Testing

CI passes (!?)

I like this cleanup! I think this does help readability; thank you for doing this.
I am looking at the Windows test, and it seems the test you just added is doing something unexpected:
FAIL snowpack/lib/commands/dev/file-getter.spec.js
  ● FileGetter#getFileFromUrl › with a `mount` entry that is also available from `attemptLoadFile` › returns that file

    TypeError: plugins is not iterable

      14 |     const srcFile = util_1.removeExtension(fileLoc, '.map'); // if this is a .map file, try loading source
      15 |     const potentialInputs = new Set([srcFile]);
    > 16 |     for (const plugin of plugins) {
         |                          ^
      17 |         if (!plugin.resolve) {
      18 |             continue;
      19 |         }

      at Object.getInputsFromOutput (snowpack/lib/build/build-pipeline.js:16:26)
      at FileGetter.getFileFromUrl (snowpack/lib/commands/dev/file-getter.js:51:68)
      at Object.<anonymous> (snowpack/lib/commands/dev/file-getter.spec.js:25:23)

Is config.plugins somehow not being handled correctly in Windows? I have a feeling this is an underlying issue not introduced in your PR. I’ll look into it a little myself, but would also appreciate if you could take a look too if you have time

I'm nervous to spend much time on this so close to v3 (and also during the holidays):

lots of other changes/PRs are going on right now, which will make this hard to keep up-to date through review.
we won't have as much time to commit to reviewing quickly, which will compound issue 1.
lots of v3 changes means we'll most likely have bugs to squash, and I'm worried about chasing bugs across new codepaths/features and new refactoring, making it harder to track what changed/broke.

I'd love to tackle this post v3.0 release! In the meantime, hopefully this tweet makes us all feel better :) : https://twitter.com/devongovett/status/1178803258929774592

Sure, after v3 release, I'll go back to this refactor. I will also take a look at the failed test then. It's most likely my new added test is not properly init'ed (no plugins though required).


Update SSH deploy key

@conda-forge-admin, please update circle

Hmm. That didn't do anything, did it?

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I updated the circle-ci deploy key and followed the project.

Hi @hoechenberger -- Looks like the amended commit passed. Hope that triggers it!

Great, it seems to have worked!
[richard:~]$ conda search -c conda-forge pyosf
Loading channels: done
# Name                  Version           Build  Channel
pyosf                     1.0.4          py27_0  conda-forge
pyosf                     1.0.4          py35_0  conda-forge
pyosf                     1.0.4          py36_0  conda-forge
pyosf                     1.0.5            py_1  conda-forge

[richard:~]$ conda install -c conda-forge pyosf
Solving environment: done

==> WARNING: A newer version of conda exists. <==
  current version: 4.5.9
  latest version: 4.5.10

Please update conda by running

    $ conda update -n base -c defaults conda

## Package Plan ##

  environment location: /Users/richard/miniconda3

  added / updated specs:
    - pyosf

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    pyosf-1.0.5                |             py_1          21 KB  conda-forge
    conda-4.5.10               |           py36_1         625 KB  conda-forge
    certifi-2018.8.13          |           py36_0         138 KB  conda-forge
    openssl-1.0.2o             |       h470a237_1         3.3 MB  conda-forge
    ca-certificates-2018.8.13  |       ha4d7672_0         135 KB  conda-forge
    ------------------------------------------------------------
                                           Total:         4.2 MB

The following NEW packages will be INSTALLED:

    pyosf:           1.0.5-py_1        conda-forge

The following packages will be UPDATED:

    ca-certificates: 2018.03.07-0                  --> 2018.8.13-ha4d7672_0 conda-forge
    certifi:         2018.8.13-py36_0              --> 2018.8.13-py36_0     conda-forge
    conda:           4.5.9-py36_0                  --> 4.5.10-py36_1        conda-forge

The following packages will be DOWNGRADED:

    openssl:         1.0.2p-h1de35cc_0             --> 1.0.2o-h470a237_1    conda-forge

Proceed ([y]/n)?


Problem with updating my public filesystem......

Hey, so I reinstalled Linux to my computer and regenerated a new PGP key. Whenever I add a file to my /keybase/public/{username}/ directory, I don't see it come up in my keybase.pub website. In fact, when I deleted the old index.html from the directory, it still appeared on the site. I don't know if it's a bug or something I missed.
  (Two days ago, judging by your sigchain.)  In that case, keybase.pub probably still has your old, pre-reset public folder cached locally.  If that sounds right, let me know and I'll restart keybase.pub to pick up the new one.

@strib Yes, that's what I meant (I could have worded it better). If you could help me out then that would be nice. Thank you.

Done!  Sorry for the delay.


added spicinit web arg option to hiedr2mosaic.py

I have edited spice function to accept a new variable web and changed also the spiceinit command to accept this variable.
The variable web is linked to a new argument -w (--web) which enables the usage of spiceinit web kernels. Default is disabled.
Description

Related Issue

Related issue 389
Motivation and Context

As per described in  389:
Due to recent changes in ISISDATA structure, I cannot process anymore hiedr2mosaic.py since it crash at spice function due to missing kernels.
Running the hiedr2mosaic.py commands one by one, highlight exactly the probelm with spiceinit since if I use spiceinit WEB=True, it works flawlessly.
How Has This Been Tested?

Tested on few HiRISE EDR images.
Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

My change requires a change to the documentation.

Licensing:
This project is released under the LICENSE.

I claim copyrights on my contributions in this pull request, and I provide those contributions via this pull request under the same license terms that the pvl project uses.
I dedicate any and all copyright interest in my contributions in this pull request to the public domain.  I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this contribution under copyright law.

I brought this in, added a note to the release news about the new option, and an entry in the manual, and tweaked a bit the description of the option: https://github.com/NeoGeographyToolkit/StereoPipeline/commit/8e7ce4fbdf4d3d6e7d93fc96cae55f33984053f5.


pulseaudio: fix use of overrides

Fixes e5a2eb2f4409 (pulseaudio: guard the qcom-specific workaround
with 'qcom' override).
The order of the overrides was incorrect resulting in build failures.
Reported-by: Leonardo Sandoval<EMAIL_ADDRESS>Signed-off-by: Nicolas Dechesne<EMAIL_ADDRESS>

LGTM.


Doesn't work in Safari

Hello.
I'm opening the demo in a macOS Safari Version 14.0.1 (166<IP_ADDRESS>.8) using responsive mode (iPhone 8).  Both are fine.

I'm struggling with the same issue in my project using the iPad (iOS 14) device.

@roboxv Do the same media queries work when done in plain CSS? If so, then it is a bug we should look at - otherwise this is Safari interpreting media queries differently, and should be filed as a bug with their team.

Other possibility is the new Safari responsive testing mode doesn't work as well as it should, maybe it requires a page reload to reflect the dimension change?

@roboxv Do the same media queries work when done in plain CSS? If so, then it is a bug we should look at - otherwise this is Safari interpreting media queries differently, and should be filed as a bug with their team.

Yes, media queries in a plain CSS work. Just checked it.

Other possibility is the new Safari responsive testing mode doesn't work as well as it should, maybe it requires a page reload to reflect the dimension change?

I don't think so. Page reload has no effect. And the issue also affects real devices.

@roboxv That is really strange then - this library is just setting up browser media queries, it should be getting any different results between the CSS queries and the matchMedia JS queries. I just updated to big sur so I can test on the latest safari and see what the deal is.

Looks like the issue is just https://stackoverflow.com/questions/38220485/safari-responsive-design-mode-css-media-query-device-not-applied (Safari doesn't like device-width anymore).
I've updated the sample website to reflect that reality so it is consistent between browsers - it was last published years ago so it was pretty out of date, I updated the repo to auto publish so it doesn't happen again.


Issue with v3 Greenpipes.Payloads.PayloadCache

I used the Greenpipes v 3.0.0 with the
automatonymous v 4.2.0
masstransit as 5.5.6
masstransit.automatonymous as v 5.5.5
i received following error
Could not load type 'GreenPipes.Payloads.PayloadCache' from assembly 'GreenPipes, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b800c4cfcdeea87b'.
Could you please let us know how to resolve this one?

Don't upgrade past the required version for that version of MassTransit, which is 2.1.4.
https://www.nuget.org/packages/MassTransit/5.5.6


Work out business case societal cost; using AI to reduce costs of operating the grid

One of the assessment criteria of the POC is the 'Quality of the business model'.
Here we should include the business case of using AI to reduce the costs of operation the electricity grid.
For example;

Customers which cannot be connected; societal impact
Provide insights in development of costs of the grid (+80-120%  in 2023) (CAPEX)
Growing costs for congestion management, redispatch, balancing (OPEX)
And how AI can be used to enable the connection of additional customers and how to reduce these cost

@woutertromptennet , any progress updates on this issue? Let me know if there are any road blocks or if you could use some help.


Mconcat/stableswap bench

Closes: #XXX
Description

For contributor use:

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer

(also have to fix lint)


Test CI

As title

This failure is because of this change in sckit-learn 1.01 https://github.com/scikit-learn/scikit-learn/pull/21389.
Previously sklearn kept feature-names even if we called fit again on a numpy array.  PR https://github.com/scikit-learn/scikit-learn/pull/21389. fixed that.
See below:
In sckit-learn=1.0.0:
>>> import numpy as np
>>> import pandas as pd
>>> from sklearn.preprocessing import StandardScaler
>>>
>>> est = StandardScaler()
>>> est.fit(X=pd.DataFrame({'a':[0,1],'b':[2,3]}))
StandardScaler()
>>> est.fit(X=np.asarray([[0,1],[2,3]]))
StandardScaler()
>>>
>>> print(est.feature_names_in_)
['a' 'b']

In sckit-learn=1.0.1 after PR 21389 :
>>> import numpy as np
>>> import pandas as pd
>>> from sklearn.preprocessing import StandardScaler
>>>
>>> est = StandardScaler()
>>> est.fit(X=pd.DataFrame({'a':[0,1],'b':[2,3]}))
StandardScaler()
>>> est.fit(X=np.asarray([[0,1],[2,3]]))
StandardScaler()
>>>
>>> print(est.feature_names_in_)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'StandardScaler' object has no attribute 'feature_names_in_'

Thanks for investigating @VibhuJawa. Closing this PR in favor of https://github.com/dask/dask-ml/pull/872


Enable strict concurrency warnings

Hello! First-time, long-time.
You mentioned building this library for the long haul, so I wanted to suggest at least experimenting with the strict-concurrency-checking compile flag. I believe the intention is for the build warnings emitted by this flag to become errors in Swift 6. More information here.
(Feel free to close this PR if it's not how'd you like go about it just now; I mostly just wanted to demonstrate my suggestion if it's not something you'd come across before.)

Oh my god, this is like the "gift" of giving someone with a busy day of work an untrained Jack Russell puppy

Ah, yeah, I'm sorry; I should have been more explicit that it would do that. Maybe made it an issue rather than a PR. Mostly just wanted to put the tool on your radar so you can check it out at a better time.
Love the show. ✌


No detection result from detectNet() face detection model

I am using a real-live stream for the inference. The mechanism is, decode the received h264 using SW (as the jetson nx board h264_cuvid not working). Then I got the YUV420p data and converted it to BGR_NV21 and pushed it for the faceNet face detection. But the result is nothing!!! It even does not throw any error!!!.
What I have found for the inference it requires light!

Not really. Just saw an output for 1 time.


Use cups conda package like qt-main

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

See #24 instead


Gazebo install fails on Host

Dell laptop / Windows 10 /  Windows Subsystem for Linux (WSL) - Ubuntu 22.04.

I get the same error if I do "colcon build" without it.

following +1


”Ciuchici” is listed in the drop-down menu

Description:
"Ciuchici" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Ciuchici" in the search bar.

Expected results
The location is listed in the drop-down menu as "Ciuchici, Caraș-Severin".


Fully support prepared statements with pgbouncer 1.21.0

Problem
Today, the way prepared statements are supported with pgbouncer is suboptimal. Prisma will clear all prepared statements in the connection to avoid mismatches. Now that pgbouncer supports prepared statements as of 1.21.0, It would be great to understand if we need to append ?pgbouncer=true or if we can simply run prisma without being in "pgbouncer" mode.
Suggested solution
Clarity on how to fully take advantage of prepared statements with pgbouncer 1.21.0

I would assume Prisma needs to be updated to support this, based on the information here.
Would be great to have this prioritized, as currently we are facing some issues because of the extra latency.

Did anyone try running their test suites against a this new PgBouncer version either with or without pgbouncer=true? That would probably be a good first data point.

Did anyone try running their test suites against a this new PgBouncer version and max_prepared_statements configured, either with or without pgbouncer=true? That would probably be a good first data point.

I will try to test it this way and report back

Did anyone try running their test suites against a this new PgBouncer version and max_prepared_statements configured, either with or without pgbouncer=true? That would probably be a good first data point.

So I tested with this setup:

PG running locally withing docker + pgbouncer 1.21 running natively locally

Without the pgbouncer param, it does throw
With the pgbouncer param, it works fine

PG running from cloud, using the direct access url, connected thru the same pgbouncer 1.21 running natively, same results.

We actually have reports now that with pgbouncer=true you will get an error: https://github.com/prisma/prisma/issues/21635
That conflicts with your observations @MorenoMdz, correct?
What error message exactly are you getting in your testing?

We actually have reports now that with pgbouncer=true you will get an error: #21635 That conflicts with your observations @MorenoMdz, correct?
What error message exactly are you getting in your testing?

Can it be because of the Prisma version? We are using 5.4.2 but I would be surprised if it was only for my case. Here if I connect to my local PG or cloud PG without pgbouncer=true thru my local instance of pgbouncer, it will error.
This is the pgbouncer config I used, I don't know if this would have any affect.
[databases]
db = host=xxx dbname=xxx user=xxx password=xxx

[pgbouncer]
listen_addr = <IP_ADDRESS>
listen_port = 6432
auth_type = plain
auth_file = pgbouncer_users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
ignore_startup_parameters = extra_float_digits

How is your pgbouncer 1.21 configured? The new functionality is only enabled when max_prepared_statements is set to a non 0 value. Otherwise 1.21 behaves exactly like older PgBouncer versions (which would match your observations).

That might be the problem: The new functionality is only enabled when max_prepared_statements is set to a non 0 value. Otherwise 1.21 behaves exactly like older PgBouncer versions (which would match your observations).

That must be it them, I assumed incorrectly it was supported by default, going to try again.

Unfortunately not. I have not looked deeper into this.

Unfortunately not. I have not looked deeper into this.

Ok good news:
[databases]
db = host=xxx dbname=xxx user=xxx password=xxx

[pgbouncer]
listen_addr = <IP_ADDRESS>
listen_port = 6432
auth_type = plain
auth_file = pgbouncer_users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
ignore_startup_parameters = extra_float_digits
; max_prepared_statements = 1000

With this setup:

Pgbouncer running on my machine, targeting PG in the cloud (Aiven) using the direct access URL
Running Prisma 5.4.2 in Nest, calling the requests from Swagger
No pgbouncer=true param in the URL
Got consistent 400ms in a specific endpoint that before was always above 1000ms

(Keep in mind I am in LATAM right now and the server is in central-us so the extra latency is expected)
Before

After

I can run an artillery session from US to get a better load test if you want.
What was causing it to break first is that I had the pool URL of my cloud DB, changing it to the direct URL made it work. What I am not sure yet is why it was breaking against my local PG.
Note that having max_prepared_statements = 1000 or not didn't made any difference in this small test.

We also tested 1.21.0 with max_prepared_statements = 1000 and removing pgbouncer=true on prisma 5.4.2 and everything just works! We're seeing improved query latency as well and no issues. I think it would be a good idea to deprecate pgbouncer=true and/or recommend using pgbouncer 1.21.0 with prepared statements enabled. This one change has improved our query latency more than any change prisma has shipped (including all of the latest perf improvements). I wouldn't sleep on this.

Can you also test running Introspection and/or Migration via the PgBouncer you setup? Thanks @jineshshah36.
(We are now also starting to test this, but any help is welcome in figuring out the details.)

Our setup doesn't allow for that very easily. We have a separate proxy for that stuff that does not use pgbouncer.

Hm, after reading https://www.pgbouncer.org/config.html#max_prepared_statements in detail I would actually be surprised if this just works without pgbouncer=true. Multiple instances of Prisma Client would probably try to prepare different queries with the same name for the prepared statement, leading to an error message when actually executing the query. We'll have to get a reproduction for this scenario.

Seems that part is probably fine as PgBouncer deals with that properly.
A problem we found already is when you use schema=foo in your connection string, that leads to this error as PgBoucner fully does not support search_path still:
PrismaClientInitializationError: Error querying the database: FATAL: unsupported startup parameter: search_path

I'm not sure I follow. I'm not aware of this schema argument. We have one schema (public) and all works ok

Isn't the search_path problem an issue with pgbouncer=true as well? In any case it seems rather unrelated to prepared statements.
BTW, it is supported if you use PgBouncer together with Citus: https://www.pgbouncer.org/config.html#track_extra_parameters

Yes @JelteF, but it means that upgrading to PgBouncer 1.21.0 does not magically make pgbouncer=true (for our own PgBouncer mode) obsolete, as without it you will directly run into FATAL: unsupported startup parameter: search_path if you use a non standard "schema" (which with Prisma you configure in the connection string via ?schema=foo, that is then translated into a SET search_path query under the hood).
Seems @jineshshah36 is lucky enough that he is not using that. Many other users of Prisma are, so we need to find a solution there. (Which is very possible, Prisma fully qualifies most queries so the search_path is mostly used for raw queries and some other things that one probably would not want to do via PgBouncer anyway)

I guess part of my question was not clear: how does pgbouncer=true make ?schema=foo work? Does it start qualifying every table?
Also working around the search_path issue is fairly simple for an operator. They can either change the default search_path for the relevant postgres user. Or they can use connect_query to set the search_path: connect_query=set search_path=foo;

Ah, understood: pgbouncer=true makes Prisma skip the SET search_path = ... query basically only. We qualify tables by default - except for user-provided raw queries, which might not work as expected in PgBouncer mode.
Unfortunately, we have to assume that PgBouncer is out of control of most of our users as they just get a pre-configured instance by DigitalOcean, Supabase or Neon. We just need to make it work as well as possible. (Which is now pretty amazing, with the named prepared statement support - just need to cover it with tests now and make a call on how search_path will be handled)

Ah, understood: pgbouncer=true makes Prisma skip the SET search_path = ... query basically only. We qualify tables by default - except for user-provided raw queries, which might not work as expected in PgBouncer mode.

Ah okay, that makes sense. But if I understand correctly, then using pgbouncer=true in the connection string completely undoes the effect of the schema=foo argument in the same connection string. If that's indeed the case then it seems the easiest to simply say that people should not use the schema=foo argument in the connection string when connecting to pgbouncer 1.21.0. So where the connection string would first be:
postgresql://some-host-name.com?pgbouncer=true&schema=foo

It would now simply be:
postgresql://some-host-name.com

One thing to notice, upgrading your PG bouncer can be very tricky depending on your deployment pipeline. Even in the scenario that all your Prisma queries would work with pgbouncer 1.21 without the pgbouncer=true param, as soon as you upgrade your pooler to 1.21 your Prisma queries will start failing. On the other hand, if you remove pgbouncer=true first then upgrade your DB, your queries will also start failing.
In order to not have downtime and or have to do a full server swap deploy, ideally Prisma would support the new version of pgbouncer with or without pgbouncer=true, is it possible at all?
cc @janpio

One extra data point. Our cloud provider (Aiven) recently release support for the latest version of pgbouncer, I just tested for the last hour and the results are mixed.

Running Prisma without pgbouncer=true is indeed faster overall.
running with the pgbouncer param will cause all queries I tested to error.
Most of our queries work, including some prisma RAW queries, but a lot of queries will now fail with errors that still mention pgbouncer, for example:

Error occurred during query execution:
ConnectorError(ConnectorError { user_facing_error: None, kind: QueryError(PostgresError { code: "26000", message: "prepared statement \"PGBOUNCER_10\" does not exist", severity: "ERROR", detail: None, column: None, hint: None }), transient: false })

I triple-checked that our internal backend server is not using pgbouncer in the connection URL.

So, that error definitely means somehow pgbouncer thinks a query is prepared on the server connection, but somehow it isn't. Are you sure there are no clients at all using pgbouncer=true? Because if there's only one client with that enabled that setting it can "poison" all the server connections so that other clients start failing.

So, that error definitely means somehow pgbouncer thinks a query is prepared on the server connection, but somehow it isn't. Are you sure there are no clients at all using pgbouncer=true? Because if there's only one client with that enabled that setting it can "poison" all the server connections so that other clients start failing.

There could be some from our dev team pinging it as it is an internal dev db I am testing on, I will also double check our cloud functions.
Does that mean we can not have the same server in use with two different type of requests?

In order to not have downtime and or have to do a full server swap deploy, ideally Prisma would support the new version of pgbouncer with or without pgbouncer=true, is it possible at all?

The next PgBouncer release should support pgbouncer=true too since I merged the PR to support DEALLOCATE ALL there, but the next official release will probably be after the new years. (It's a new feature and so far only the prisma client are impacted, so I don't think rushing it out as a a patch release is worth the risk/hassle with holidays coming up).
For now as long as you keep max_prepared_statements at its default of 0 you can continue to use pgbouncer=true even with the new pgbouncer version (but you won't benefit from the new feature). Then when the next one releases you can try a rolling release.

In order to not have downtime and or have to do a full server swap deploy, ideally Prisma would support the new version of pgbouncer with or without pgbouncer=true, is it possible at all?

The next PgBouncer release should support pgbouncer=true too since I merged the PR to support DEALLOCATE ALL there, but the next official release will probably be after the new years. (It's a new feature and so far only the prisma client are impacted, so I don't think rushing it out as a a patch release is worth the risk/hassle with holidays coming up).
For now as long as you keep max_prepared_statements at its default of 0 you can continue to use pgbouncer=true even with the new pgbouncer version (but you won't benefit from the new feature). Then when the next one releases you can do a rolling deployment of your clients.

Do I need to explicitly set max_prepared_statements to 0? Because as soon as I updated to the v1.21.0 our queries started failing. I have requested to our provider to expose this setting so we can configure it.
As for the next release I do understand the concerns of testing it before the holidays, but at the same time I can assure the gains are large enough that as an end user being impacted by 200ms+ queries it feels important enough to have a patch :(

If you "set max_prepared_statements to 0" you disable the new named prepared statement support of PgBouncer and will need to keep using pgbouncer=true @MorenoMdz.
The problem of the new PgBouncer version failing with pgbouncer=true you describe is tracked at https://github.com/prisma/prisma/issues/21635 (which has links to the pgBouncer issues and PR) and will indeed need to be fixed before Prisma users can use the new version with the old pgbouncer=true configuration.

@JelteF From our side it would be highly desirable if the DEALLOCATE ALL fix could be released soon. Any cloud provider that updates to 1.21.0 will instantly break all Prisma Client application that use pgbouncer=true (which should be most to all, as it was necessary in the past) - see https://github.com/prisma/prisma/issues/21635 as a description what happened when Neon did that - and require an update of the application configuration to remove pgbouncer=true.
We'll try to handle the error in the next Prisma release to tell users in a nice error message what is going on, but that will only apply to future releases of course and many of our users will be running older versions.

So to recap:

PgBouncer < 1.21.0 => Needs pgbouncer=true to work correctly
PgBouncer 1.21.0, max_prepared_statements = 0 => Needs pgbouncer=true to work correctly
PgBouncer 1.21.0, max_prepared_statements > 0 => Will fail with pgbouncer=true (because of https://github.com/prisma/prisma/issues/21635)
PgBouncer 1.21.0, max_prepared_statements > 0 => Should work find without pgbouncer=true (still confirming)

Does that match what you are seeing @MorenoMdz?

Any cloud provider that updates to 1.21.0 will instantly break all Prisma Client application that use pgbouncer=true

To be clear, that should be "any cloud provider deploys 1.21.0 and changes the max_prepared_statements setting from its default".
The new prepared statement support was deliberately left as "off" by default in PgBouncer for now, specifically to not break existing users in case of any bugs, perf impact or weird interactions. If your cloud providers turns the feature on by default anyway for all their existing users, then that seems like something you should talk to your cloud provider about.
I do agree that the current breakage that has been happening for Prisma applications is not great though. But I'll be on honeymoon for a month soon, so that's why I'm quite hesitant at creating a new feature-release before that, since it could possibly introduce other bugs. Especially since the current issue described here can be considered a weird interaction, instead of a bug (i.e. current non-support for DEALLOCATE ALL with max_prepared_statetements >= 0 is explicitly documented).
P.S. Prisma is the only client that I know of that uses DEALLOCATE ALL to work around PgBouncer issue. All others use unnamed prepared statements instead. i.e. they use the empty string ("") as the name for all their prepared statements, this means that they don't need to be deallocated, because a prepared statement with the empty string name can be recreated without deallocating it.

So to recap:

PgBouncer <1.21.0 => Needs pgbouncer=true to work correctly
PgBouncer 1.21.0, max_prepared_statements = 0 => Needs pgbouncer=true to work correctly (same behavior as <1.21.0)
PgBouncer 1.21.0, max_prepared_statements > 0 => Will fail with pgbouncer=true (because of Prisma PgBouncer mode doesn't play nice with PGBouncer v1.21.0 #21635)
PgBouncer 1.21.0, max_prepared_statements > 0 => Should work fine without pgbouncer=true (still confirming)
PgBouncer >1.21.0 (future release) => Should work fine with and without pgbouncer=true

Does that match what you are seeing @MorenoMdz?

Yes, with a couple things to add.

Our cloud provider has max_prepared_statements set to 100 vs the default of 0.
Having clients with different configurations, one with pgbouncer=true and others without it, will cause pgbouncer to error out on some  of the prepared statements requests. info

@JelteF Congratulations!

All other clients use unnamed prepared statements instead. i.e. they use the empty string ("") as the name for all their prepared statements, this means that they don't need to be deallocated, because a prepared statement with the empty string name can be recreated without deallocating it.

If only this had been documented somewhere, we might have ended up with the same solution here :D

Would it be a too large of a lift to implement the empty string approach now?

Yes, and it is also not necessary anymore if we can confirm that case 4) ("4. PgBouncer 1.21.0, max_prepared_statements > 0") works fine without pgbouncer=true (when no other Clients still use that).

I am facing the same issue. What is the recommended fix to still be able to use pgbounce pool with prisma? (pgbounce set to transactional mode). I tried to remove pgbouncer=true or keep it - but none works for me.. max_prepared_statements is 0.
I am still getting error 26000 ERROR: prepared statement \"PGBOUNCER_36\" does not exist

You posted the same in 3 issues now @guyromb. Please open a new issue and describe your full situation and problem. Thank you.

I am facing the same issue. What is the recommended fix to still be able to use pgbounce pool with prisma? (pgbounce set to transactional mode). I tried to remove pgbouncer=true or keep it - but none works for me.. max_prepared_statements is 0. I am still getting error 26000 ERROR: prepared statement \"PGBOUNCER_36\" does not exist

Can you double check that running Prisma without pgbouncer=true connecting to pgbouncer v1.21.0 with max_prepared_statements = 0 you are still getting those errors?
Be 100% sure that NO other client is also connecting at the same time with a different mode, with pgbouncer=true or not and vice versa. We had a lot of issues with team members connecting from their local computers with the param in the URL still causing the whole pgbouncer server to start throwing these errors.

I created a specific issue for that https://github.com/prisma/prisma/issues/21877
max_prepared_statements=0 (That's the default in digitalocean managed postgres)
pgbouncer=true is removed in from the string of all applications.
Strangely enough it used to work before with pgbouncer=true without any issues before. The issue started a few hours ago.

@janpio @JelteF would this plan work for us to migrate?

At a low usage time, deploy everything to use the direct URL (no pgbouncer true, different port) so no pooling with be done. We can set the max connections in the DB server to a higher number temporarily and maybe also increase the server config for a couple hours.
Ask Aiven (our cloud provider) to change the max prepared statements setting to 100, a nso clients are going to be connecting to the pool, no issues would happen.
Redeploy our cloud functions to connect to the pool, without pgbouncer=true , check that no errors happened.
Redeploy our Node server to connect back to the pool.
Change the configuration/connections number down to what it is now.

Yes, that would probably a be a reasonable way to avoid any user facing errors or downtime.
If that is not 100% required, you can simplify a lot: Ask Aiven to increase max_prepared_statements to a non 0 value, then instantly redeploy all your Node servers to not use pgbouncer=true any more - that will probably still put PgBoucner into a bad state because before the deployment some DEALLOCATE ALL will be run. But then restart the PgBounce instance so it is in a clean state - and you should be fine.

Yes, that would probably a be a reasonable way to avoid any user facing errors or downtime.
If that is not 100% required, you can simplify a lot: Ask Aiven to increase max_prepared_statements to a non 0 value, then instantly redeploy all your Node servers to not use pgbouncer=true any more - that will probably still put PgBoucner into a bad state because before the deployment some DEALLOCATE ALL will be run. But then restart the PgBounce instance so it is in a clean state - and you should be fine.

The blocker is that we have a whole replication setup happening with cloud functions, we are finalizing a migration from Firestore to PG and there are a few hundred requests happening per second still just for the live replication from FS->PG. If we change the cloud functions and the Node server to use the direct URL there is the risk of issues due to rejected requests because of saturated connections from the DB server.
One extra issue is that deploying our Nest instance can take up to 10-30min depending on our provider (Render) and the cloud functions also need a redeploy to update the URL.
That said, we might go ahead and upgrade it tomorrow night as it will likely to be a low usage time in our systems due to the holidays. I will update here depending on how it goes 👍

Yes it does, with that fix the DEALLOCATE ALL is not only executed on the database connection, removing its prepared statements - but also the cache of those on Pgbouncer side is emptied. Running a manual DEALLOCATE ALL (or using pgbouncer=true) should not cause any problems any more when this is released. Really looking forward to that.

We have done the upgrade last night and we are seeing solid improvements on all our endpoints that do fetch single records already.
Interesting note, Aiven upgraded their PG configuration to already include the said fix, making it easier on our side to upgrade 👍
Thanks @janpio and @JelteF for the hard work here!

Is it still recommended to use transaction mode like suggested in the Prisma docs ?
For reference I removed pgbouncer=true alongside max_prepared_statements > 0 and I get a better latency too
I kept POOL_MODE=session but I am not too sure whether that is the right decision

The recommended is:

max_prepared_statement>0
pool_mode=transaction
remove pgbouncer=true

The recommended setup is:
* max_prepared_statements>0

* pool_mode=transaction

* **remove** pgbouncer=true

missing "s" on max_prepared_statements

FYI: I released PgBouncer 1.22.0 just now, which includes the support for DEALLOCATE ALL. So with that release using pgbouncer=true won't cause breakage anymore. But pgbouncer=true is not needed anymore and since 1.21.0 and it is slower, so it's recommended to remove it from your connection strings.
So I think all that's needed in this issue is actually updating the Prisma docs to reflect that new recommendation. In particular these two pages at least:

https://www.prisma.io/docs/orm/overview/databases/postgresql
https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections/pgbouncer

Thank you very much JelteF!

A note regarding custom schema usage with Prisma and PgBouncer. We use a different schema name than the Prisma default. PgBouncer will complain with the following error when the ?schema=X parameter is provided in the connection string:

FATAL: unsupported startup parameter: search_path

A workaround for this is to:

add the ?schema=X parameter in the connection string as usual
configure PgBouncer to ignore the search_path parameter
set the default search path on the database user role

# in PgBouncer config
ignore_startup_parameters=search_path,extra_float_digits

-- set the search path for database user
ALTER ROLE rolename SET search_path = 'X';

My understanding of this workaround is that we are tricking Prisma into thinking it is setting the search path via the query parameter in the connection string, when actually the search path is being set on the database user role. This allows Prisma to derive the schema used by the client.
It would be nice if Prisma accepted the schema name as part of the Prisma schema file, so that the client can be configured to use a custom schema without deriving this from the connection string.

It would be nice if Prisma accepted the schema name as part of the Prisma schema file, so that the client can be configured to use a custom schema without deriving this from the connection string.

The problem would unfortunately persist - as Prisma only uses the ?schema= to run a SET search_path TO ... statement upon connecting to the database - which it would also need to do when it was provided via the Prisma schema.
So I think telling PgBouncer not to react to the search_path query, but instead then setting the search path via another way (like setting it for the role) seems like the way to go.

FYI: I released PgBouncer 1.22.0 just now, which includes the support for DEALLOCATE ALL. So with that release using pgbouncer=true won't cause breakage anymore. But pgbouncer=true is not needed anymore and since 1.21.0 and it is slower, so it's recommended to remove it from your connection strings.
So I think all that's needed in this issue is actually updating the Prisma docs to reflect that new recommendation. In particular these two pages at least:

prisma.io/docs/orm/overview/databases/postgresql
prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections/pgbouncer

Hey @JelteF, I'm currently working on updating the Prisma docs to match this ticket, so I just wanted to double-check. Is it still recommended to do the above with the release of a newer PgBouncer?


The obj.map returned to the success callback is a string in Libsass 3.next

Disclaimer: I'm beta testing Libsass 3.2 (master).
The recent sourcemaps refactor must've have changed something because the obj.map returned to the success callback is '{}' (string) rather than {} (object) when sourceMap: false is set.

This is by design. We are forwarding the source-map string from libsass as is. This was an experimental change in beta that we were parsing the string (with JSON.parse(..)) and returning the object, but it doesn't make sense because the consumer can do the same if required.
This way the large JSON object parsing (no matter how fast it is) wouldn't be imposed on the consumer who just wanted to write source-map string to the file without any modification -- which in fact is a very viable use-case; they would have to JSON.strigify() it again and encounter the perf hit twice.
However, we do parse error JSON as object, so user gets a well-composed error object:
    error: function(error) {
        // error is an object: v2 change
        console.log(error.message);
        console.log(error.code);
        console.log(error.line);
        console.log(error.column); // new in v2
    },

Am I correct in understanding this change will land in the 2.0.0 stable?
Asking in regards to https://github.com/dlmanning/gulp-sass/pull/168

Yes this is correct. 2.0.0-stable will bring this behavior to the mix. :)
Regarding gulp-sass, I am not sure why is it required to post-process path resolution? In principle, node-sass should manufacture correct options (even altering those coming from upstreams) before passing to  libsass, so to get correct paths for source-map and sourceMappingURL (CSS comment) in return.
Can you shed some light what are the input options and expected result? The canonical path functionality in libsass is very promising. No matter how many times I tried to prove it wrong, it always turns out to node-sass fault, @mgreter has covered all bases there! :wink:. So after trial and error, we have perfected that part (but we never know). :warning:
PS: this will be a great time to fix the last moment bugs, when we are waiting for someone to stepup and build Linux binaries.

Can you shed some light what are the input options and expected result

Frankly I had no clue :) this is square @mgreter territory.

this will be a great time to fix the last moment bugs

do you have any particular bugs in mind? A lot of work has gone into Libsass since the 3.1.0 release so unless there is a critical bug the next release will be 3.2.0.

Nops, I was just asking; why are you post-processing source-map's sources[] array in gulp-sass commit? libsass via node-sass should emit the correct path in first place (hint: configurable node-sass options). :)

That code was already there, I just changed indenting because I wrapped it in an if :)
I've closed that PR now since this is going to be API change in 2.0.0 stable it needs to be fixed properly in gulp-sass.

The stringly-typed source-map has landed with v2. :sunglasses:


Add m365 and microsoft365 executables

Related to #1598
Preparing for renaming Office 365 CLI to Microsoft 365 CLI, we can already add m365 and microsoft365 executables to allow everyone to start preparing for upgrading their scripts.

@waldekmastykarz  - Is this suggesting that I would be able to do m365 anywhere in place of what was o365 as if so, I just tried and it just came back with: m365 : The term 'm365' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try
again.
At line:1 char:1

m365

  + CategoryInfo          : ObjectNotFound: (m365:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

@waldekmastykarz Thank you for this, it was killing my OCD having to still do o365

😁 the rename is coming soon as well. We just want to do it right and give everyone enough time to prepare.


Modifiers don't apply when rolling the Recall Knowledge (Esoteric Lore) macro

undry.js:68326 Unsupported modifier object (slug: int) passed
fetch @ foundry.js:68326
foundry.js:68326 Unsupported modifier object (slug: proficiency) passed
fetch @ foundry.js:68326
foundry.js:68326 Unsupported modifier object (slug: diverse-lore) passed
fetch @ foundry.js:68326
foundry.js:68326 Unsupported modifier object (slug: cha) passed
fetch @ foundry.js:68326

Something probably changed in an update. I'll look when I get a sec.


Add device add command

Allows adding new devices from definitions contained in TOML
files, similar to current device service functionality.
Implements #15
(Note that an additional "Service" entry is required in the files to identify which device service is to manage the device)
Signed-off-by: Iain Anderson<EMAIL_ADDRESS>

Awesome, thank you @iain-anderson


stream_settings: Fix invisible view stream btn for private streams.

If new stream is created as one of the two private options, the view stream button is not visible immediately. It is only visible after page refresh. This pull request will make view stream button immediately.
Fixes:  #22556

Screenshots and screen captures:
Video screenshot of testing:
https://user-images.githubusercontent.com/53159963/207503114-9ebc63d1-8c73-450e-81e1-ea1e8173ce57.mov
Screenshot of passed tests after running tests:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Merged, after changing the commit message to explain the research you'd done that explains why this change is correct. Please try to include that sort of detail in commit messages.
Thanks @Rixant!


latest version for react-server seems... not correct?

➜  react-server-test-pages git:(better-frameback) npm view react-server dist-tags.latest
0.3.0-hackathon-5

so if I just run npm install --save react-server, that's what I get.

dougwade code/city-story ‹master*› » npm config get registry
https://registry.npmjs.org/
dougwade code/city-story ‹master*› » npm view react-server dist-tags.latest
0.1.4

?

Doh. Apparently I was pointing to the private registry in that terminal... Ignore me.


get_dump(dump_format='json') and dump_model(..., dump_format='json') return invalid JSON strings when special characters are present in feature names

Bug description
Rationale:
At the end of the model training workflow we need to convert xgboost booster to coremltools MLModel. For that we use coremltools converter, which under the hood calls get_dump(dump_format='json') to perform conversion. It looks like get_dump(dump_format='json') returns invalid JSON strings if special characters are present in feature names.
Detailed bug description:
Feature names which contain 'non standard' characters (e.g. double quotes ' " ', tab '\t', newline '\n' symbols) are not properly dumped to JSON by get_dump(dump_format='json') and dump_model(..., dump_format='json') methods. All feature names (no matter which characters they contain) seem to just be wrapped with double quotes which leads to invalid JSON strings if a feature name contains a 'special' character.
I'm not 100% sure but my guess is that JsonGenerator class (localed in xgboost/src/tree/tree_model.cc) is responsible for dumping trees to JSONs so maybe replacing "" wrapping  (..., "split": "{fname}", ...)  with a json.dumps() statement would solve this issue?
save_model('*.json') always dumps model to a valid JSON representation.
Environment

xgboost: 1.4.2 and 1.7.6
ubuntu 22.04, Amazon Linux 2
installed via pip

Minimum reproducible example:
import numpy as np
import json
import xgboost as xgb

if __name__ == '__main__':

    x = np.random.rand(100, 3)
    y = np.random.rand(100, 1)

    # set dummy params
    params = {'objective': 'reg:squarederror', 'eval_metric': 'rmse', 'max_depth': 4}

    # following feature names will not cause problems when calling .get_dump(dump_format='json') or dump_model(..., dump_format='json')
    correctly_dumped_feature_names = ['feature 0', 'feature 1', 'feature 2']
    dm_correctly_dumped_feature_names = xgb.DMatrix(x, label=y, feature_names=correctly_dumped_feature_names)
    correctly_dumped_booster = xgb.train(params=params, dtrain=dm_correctly_dumped_feature_names, num_boost_round=3)

    # get dump and attempt to iterate over trees JSONs
    correct_model_dump = correctly_dumped_booster.get_dump(dump_format='json')

    for tree_json_index, tree_json in enumerate(correct_model_dump):
        # all trees correctly loaded
        json.loads(tree_json)

    # dump_model dumps model to valid JSON format only if feature names  do not contain any special characters
    # for current feature names correctly_dumped_booster will be dumped to a valid JSON
    correctly_dumped_booster.dump_model('correctly_dumped_booster_dump_model.json', dump_format='json')
    # save_model always saves model to valid JSON format
    correctly_dumped_booster.save_model('correctly_dumped_booster_save_model.json')

    # following feature names will cause problems when calling .get_dump(dump_format='json') or dump_model(..., dump_format='json')
    incorrectly_dumped_feature_names = ['"feature 0"', '\tfeature\n1', 'feature 2']
    dm_incorrectly_dumped_feature_names = xgb.DMatrix(x, label=y, feature_names=incorrectly_dumped_feature_names)
    incorrectly_dumped_booster = xgb.train(params=params, dtrain=dm_incorrectly_dumped_feature_names, num_boost_round=3)

    # get dump and attempt to iterate over trees JSONs
    incorrect_model_dump = incorrectly_dumped_booster.get_dump(dump_format='json')

    for tree_json_index, tree_json in enumerate(incorrect_model_dump):
        try:
            json.loads(tree_json)
        except json.JSONDecodeError as exc:
            print(f'Error when parsing tree with id: {tree_json_index}')
            print(exc)

    # dump_model dumps model to valid JSON format only if feature names  do not contain any special characters
    # for current feature names incorrectly_dumped_booster will be dumped to a invalid JSON
    incorrectly_dumped_booster.dump_model('incorrectly_dumped_booster_dump_model.json', dump_format='json')
    # save_model always saves model to valid JSON format
    incorrectly_dumped_booster.save_model('incorrectly_dumped_booster_save_model.json')

Hello @KWiecko , thanks for the detailed explanation. I can work on this. Let's see if the repository owners will approve the PR.

Apologies for the slow reply, here's a quick fix https://github.com/dmlc/xgboost/pull/9474 .


Fixed typo in BillboardCollection

Thanks for the pull request @IanLilleyT!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

:woman_facepalming:

This is the typo of issue that makes me scratch my head and wonder how we never noticed it or how many bugs it fixes that we didn't realize were caused by this typo.
Did you have a bug that was triggering this, or did you just noticed it in the code?

It looks like ComponentType.FLOAT is the default in VertexArrayFacade, which explains why this typo didn't completely break things.
https://github.com/CesiumGS/cesium/blob/4603fd33e40db78c0baf9531ad301f64d9d63049/Source/Renderer/VertexArrayFacade.js#L110-L112

Also thankfully componentDatatyps doesn't show up anywhere else in the code 😄


fcft: add missing scdoc dep

fcft needs scdoc make dep to build succesfully

Guess I didn't notice since I already had it installed, thanks!


The project cannot be opened with AS

If inscribe

@Moosphan Can the content of MaterialProgressView-master be moved to the root (up one level) so that the project can be opened directly with Android Studio?
mv MaterialProgressView-master/* .

@Sonphil okey, i will update this project recently.


additional tweaks

notes

adds a couple of more repos
disallows log files from showing up in the repo

Thanks!