Endpoint URL not created eventhough the deployment was successful

Even though I got the successful deployment message, endpoint url is blank. Also in the output log, i see this error:
The Ingress "kmgs-ingress" is invalid: spec.tls[0].hosts[0]: Invalid value: "": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is 'a-z0-9?(.a-z0-9?)*')

Hello @pwine123, Thank you for bringing this to our attention. We have noticed that the endpoint URL was not created despite the deployment being marked as successful. We are currently investigating the root cause of this issue and will keep you updated on our progress.
Thank you for your patience and understanding. If you have any additional information or questions, feel free to share them here.

Hello @pwine123,  Did you make any changes to the deploy.ingress.yaml.template file or any other deployment files before proceeding with the deployment?

No change done to any of those files.

Hello @pwine123, The error you're encountering with the Ingress kmgs-ingress is caused by an issue with the spec.tls[0].hosts[0] field. Specifically, the host value was found to be empty (""), which is not allowed according to RFC 1123 standards for domain names. A valid domain name must consist of lowercase alphanumeric characters and can include hyphens or periods, but it must start and end with an alphanumeric character.
After reviewing the process, it seems that the Fully Qualified Domain Name (FQDN) for the public IP was not generated properly. This could be due to a network or intermittent issue while retrieving the DNS settings, which may have caused a delay or failure during the DNS name assignment process. As a result, the FQDN was not correctly populated in the Ingress configuration.
We kindly request you to redeploy the accelerator to trigger the FQDN generation again. This will help resolve the issue, as it could have been caused by a transient issue during the previous deployment.
Once you’ve redeployed, please let us know the result, and if the issue persists, we will investigate further.
Thank you.
FYI @Prajwal-Microsoft @Roopan-Microsoft

Same issue when i redeployed, no URL generated. Here is the screenshot.

@pwine123  I think our team (Prasanjeet) would be connecting with you offline next week to discuss about this Issue. We are here to help !!!! Just putting an update here for visibility.

@pwine123 Just a reminder, we have a meeting scheduled for today at 8:00 PM IST to discuss this issue.
FYI @Roopan-Microsoft  @Prajwal-Microsoft

Hello @pwine123, As we discussed in yesterday's meeting, we got to know that when running the deployment script, you encounter an error at the following line:
$publicIpName=$(az network public-ip list --query "[?ipAddress=='$externalIP'].name" --output tsv)
The error message displayed is: "--name expected one argument". We will now investigate why this error is occurring on your machine and get back to you with our findings.
Thank you.

Hello @pwine123, could you please check and let us know which roles are assigned to you at the Azure Subscription level?

@pwine123, Could you please let us know which version of Kubernetes you are using by running the following command. Also please let us know if you have successfully deployed any other CSA CTO Solution Accelerator?
--> kubectl version
Thank you.

Hello @pwine123, Could you please provide an update on the comment above?

@pwine123, Could you please let us know which version of Kubernetes you are using by running the following command. Also please let us know if you have successfully deployed any other CSA CTO Solution Accelerator?
--> kubectl version
Thank you.

Hello @pwine123, Could you please provide an update on the comment above?

Hello @pwine123, I just wanted to follow up on the comment above. Could you please provide an update when you have a moment?
Thank you.

I am out of office at the moment. I will respond back to you by tomorrow US
time.
Thanks
Siva.
On Wed, Nov 27, 2024, 12:24 AM Prasanjeet-Microsoft <
@.***> wrote:

@pwine123 https://github.com/pwine123, Could you please let us know
which version of Kubernetes you are using by running the following command.
Also please let us know if you have successfully deployed any other CSA CTO
Solution Accelerator?
--> kubectl version
Thank you.
Hello @pwine123 https://github.com/pwine123, Could you please provide
an update on the comment above?
Hello @pwine123 https://github.com/pwine123, I just wanted to follow up
on the comment above. Could you please provide an update when you have a
moment?
Thank you.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Document-Knowledge-Mining-Solution-Accelerator/issues/17#issuecomment-2502852312
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJF7QL752T2PSRQUDGFXWFD2CVJQRBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVE4DMMBQGY4DKMBUQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSGY2TANBVG42TGMNHORZGSZ3HMVZKMY3SMVQXIZI
.
You are receiving this email because you were mentioned.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
.

I am out of office at the moment. I will respond back to you by tomorrow US time. Thanks Siva.
…
On Wed, Nov 27, 2024, 12:24 AM Prasanjeet-Microsoft < @.***> wrote: @pwine123 https://github.com/pwine123, Could you please let us know which version of Kubernetes you are using by running the following command. Also please let us know if you have successfully deployed any other CSA CTO Solution Accelerator? --> kubectl version Thank you. Hello @pwine123 https://github.com/pwine123, Could you please provide an update on the comment above? Hello @pwine123 https://github.com/pwine123, I just wanted to follow up on the comment above. Could you please provide an update when you have a moment? Thank you. — Reply to this email directly, view it on GitHub <#17 (comment)> or unsubscribe https://github.com/notifications/unsubscribe-auth/AJF7QL752T2PSRQUDGFXWFD2CVJQRBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVE4DMMBQGY4DKMBUQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSGY2TANBVG42TGMNHORZGSZ3HMVZKMY3SMVQXIZI . You are receiving this email because you were mentioned. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

Hello @pwine123, Any update on previous comment?
Thank you

i have v1.30.5.
This is my first csa-cto accelerator.

Hello @pwine123, Just an update: we are still working on a workaround for this issue and will update you as soon as we have any progress.
Thank You.

Hello @pwine123, I wanted to update you that we are still in the process of finding a workaround for this issue and will update you as soon as we have any developments.
Thank You.

Hello @pwine123, I wanted to update you that we have found an alternative solution and are currently in the development and testing phase. Once it is completed, we will provide you with an update.
Thank You.

Hello @pwine123, Just a quick update: we are still in the development and testing phase. We will provide an update once it's completed.
Thank you.

Hello @pwine123, As discussed offline, you mentioned that due to time constraints and the current status of the accelerator, you plan to move beyond this accelerator and explore other options for the customer scenario.
So, could you please confirm if we can proceed with closing this issue?
Thank you!

Hello @pwine123, As we haven't received any updates from you for a while and you mentioned that you plan to move beyond this accelerator and explore other options for the customer scenario, we are proceeding with closing this issue. However, if you encounter any further problems, please feel free to reopen this issue or create a new one. We're here to assist you!
Thank You.
FYI @Prasannakatakam-Microsoft


Enable JavaScript smoketest

According to the smoketest script, we should uncomment the JavaScript smoketest if checked in.
If I understood correctly, this is already done, and can be activated?
Happy to open a PR!

@ramonh This looks like it's done; am I able to close this?

Yes please! Thank you


Add syscall table for Linux sparc64

r? @alexcrichton

@bors: r+

:pushpin: Commit 34aa991 has been approved by alexcrichton

:hourglass: Testing commit 34aa99112338a8dba9b493373338262e77309952 with merge c1068cd82ae55907e8fd4457b98278a3aaa9162b...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing c1068cd82ae55907e8fd4457b98278a3aaa9162b to master...


python3Packages.pysdcp: init at 1

Motivation for this change
Python library to control SONY projectors
https://github.com/Galala7/pySDCP
This is a Home Assistant dependency.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 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 139398 run on x86_64-linux 1

2 packages built:

python38Packages.pysdcp
python39Packages.pysdcp

Result of nixpkgs-review pr 139398 at c4fc5f5d run on aarch64-linux 1

2 packages built successfully:

python38Packages.pysdcp
python39Packages.pysdcp


Add debug-generated files to .gitignore

Those files are generated during debugging (actually cmake, but they're generated under "x64-Debug" folder) using the latest version of Visual Studio, so they should be added to .gitignore.

Hi @Howard-C, I haven't seen Visual Studio generate these files. Calculator builds with MSBuild, not CMake. Can you share more specifics about what you're doing which causes these files to be generated?

I literally did nothing, I opened the repo in Visual Studio and CMake automatically began. Then these files were generated.


Dropwizard 1.0.0 doesn't support the subdirectory template inheritance

Hey,
We just updated the DropWizard from 0.9.3 to 1.0.0. But found the subdirectory mustache inheritance will fail. Below is the detailed behaviour.
Note: In the local development environment it is working, but when we deploy it via java -jar project-SNAPSHOT.jar server integration, we found it is not working anymore.
The main layout template: views/layout.mustache
<!DOCTYPE html>

    <meta charset="utf-8">
    <title>Hello DropWizard</title>

{{$body}}{{/body}}

The sub page which inherent the layout but located in the subdirectory: views/error-pages/not_found.mustache
{{<../layout}}
{{$body}}

            Error 404 - page not found

We couldn't find the page you're looking for.

{{/body}}
{{/../layout}}

And this is the view we rendered it: NotFoundView.java
public class NotFoundView extends View {
    public NotFoundView() {
        super("error-pages/not-found.mustache");
    }
}

It was working in DropWizard 0.9.3. But we got the error when trying to reach this page when we upgraded it to 1.0.0.
The error message is below:
Caused by: javax.ws.rs.WebApplicationException: HTTP 500 Internal Server Error
	at io.dropwizard.views.ViewMessageBodyWriter.writeTo(ViewMessageBodyWriter.java:89)
	at coop.membership.portal.helpers.ViewMessageBodyWriterWithGlobalContext.writeTo(ViewMessageBodyWriterWithGlobalContext.java:63)
	at coop.membership.portal.helpers.ViewMessageBodyWriterWithGlobalContext.writeTo(ViewMessageBodyWriterWithGlobalContext.java:24)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
...

We suspect it's cause  by the magic {{<../layout}} ..., cause it's the only difference with other pages. We solved this problem by pulling the not_found.mustache out of the error_pages subdirectory.
But this should be an issue introduced by the newest 1.0.0 version.

I can't replicate this with either relative or absolute paths. See gist

Hey Nick, how did you launch this App?
It works in our local environment where we launch it via Intellij.
But it failed in the integration env where we start it via java -jar test-SNAPSHOT.jar server integration.

Thanks for the info. I was testing the dropwizard test cases locally in intellij.

Hey,
I'm working alongside @gongmingqm10 and carried out a little more research.
Dropwizard 0.9.2 has a dependency on spullara/mustache.java version 0.8.17 but Dropwizard 1.0.0 uses 0.9.2
I've created a simple application mustache-resolution to test the two versions of spullara/mustache.java in isolation and it appears as though versions 0.9.x don't support partial imports such as  {{ ../partials/header }} although 0.8.x versions do.
We've found a similar thread in the mustache.java forum and posted an update here.


Don’t use GLES 3.1 features on GLES 3.0 contextes

Fixes #309

remove some currently unused code that requires
GLES 3.1 headers. It’s not technically a problem,
but it makes the code less confusing. We can
put that back, when we need it.

Turn off multi-sampling on GLES 3.0

Add support for EXT_multisampled_render_to_texture

This will allow us to compile filament on iOS with the GL backend btw.


Using moviepy AudioClip to load in audio data

Addresses #88 by using moviepy (already a requirement) to load in audio files.
Potential improvements:
-Support both mono and stereo data
-Modify the VideoToAudioConverter to simply use the VideoClip's audio property to construct a new AudioStim rather than writing a new audio file. This would require making sure no extractors or converters rely on the filename to work

Coverage decreased (-4.3%) to 73.288% when pulling 53bfc77e4eb1a8b89627bd12d4aed6b6cf2c2681 on qmac:audio-inputs into 0378ad8ad29feba3129d110f81a5a1c109e338d5 on tyarkoni:master.

Thanks @qmac--I think all of the improvements you suggest are well worth adding, but this addresses the basic issue, so I'm happy with it. Closing.


Bug: Generics are not handled correctly in TypeScript definition output

Thank you for updating Tsify project! 😃
I encountered an issue while using the tsify_next::Tsify derive macro.
When defining a struct with generics, the generated TypeScript definition does not handle the generics correctly.
Specifically, when I define:
#[derive(tsify_next::Tsify)]
pub struct Polyline<const D: usize> {
    pub points: Vec<Point<f64, D>>,
}

the index.d.ts file incorrectly outputs:
export interface Polyline {
    points: Point<number, D>[];
}

The generic D is not handled properly, which causes type definition issues in TypeScript.

Yes, it appears const generics should be handled differently!
If you're interested in attempting a PR for this feature, please let me know.


Missing data typings, filled with any

Report
Plugin Version
6.4.40
On what Platform are you having the issue?
ios and android
What did you do?
Everything works correctly I just think you should add some documentation that is missing
What did you expect to happen?
I expect to be able to see an interface for the data onDeepLink callback receives
What happened instead?
There's no documentation or typescript types. It is a black box.
Please provide any other relevant information.
I think the documentation for react native plugin needs some attention. It is extremely hard to integrate the SDK. The docs seem to be outdated and not maintained actively. A lot of typing are missing and there's not even a slight hint of how to retrieve a deeplink value out of the callback parameter. Either Typescript declarations or just updated docs will help a lot in this case.

Hi @jkadamczyk and thank you! we have similar feature request here and we are working on it


[#1267] fix: Add missing headers and license

What changes were proposed in this pull request?
add missing headers and license
Why are the changes needed?
Fix: #1267
Does this PR introduce any user-facing change?
N/A
How was this patch tested?
N/A (no code change, only add missing license)

Thanks @brandboat @brandboat , merged to master & branch 0.3.


Prevent scrolling when scrolled up

Description of the new feature/enhancement

When running a long-running script, I sometimes scroll up to see something that whizzed by. Windows terminal keeps scrolling down by an amount equivalent to the new lines written (does not scroll all the way down to the bottom). I'd like it to not scroll at all if I've scrolled up even a little bit.
Proposed technical implementation details (optional)

Not sure. You'll have to detect when we're scrolled all the way to the bottom to engage autoscroll, and then disable autoscroll when scrolled up.
Alternatively, a readily discoverable scroll-lock option would be acceptable. Perhaps by right-clicking the tab? I was so desperate I tried the "Scroll Lock" button on my keyboard hoping it would do something useful for the first time in my life (no luck).

This sounds like a duplicate of #3863.

Yea I'd definitely say that this is a /dup of #3863. Thanks!


Steam plus

Description
App is showing an error in the Tidbyt store. Everything is working locally, so I suspect it's an issue with the secret. Updated the secret and merging again.
Copilot

🤖 Generated by Copilot at 49e5b59
Summary
📄🐍🎮

This pull request adds the Steam Plus applet, which displays the user's Steam profile and current game on the Tidbyt device. It adds the manifest.yaml file for the applet metadata and configuration, and the steam_plus.star file for the applet code, which uses the Steam API and the Starlark modules.

Steam Plus applet
Starlark code and manifest
Winter gaming fun

Walkthrough

Add the Steam Plus applet, which displays the user information and status from Steam (link, link)
Define the main function, which returns the applet layout and content based on the config object (link)
Import the http, render, schema, and secret modules for making API requests, creating UI elements, defining input fields, and decrypting the API key (link)
Define the get_schema function, which returns the schema.Schema object for the user input fields, such as the Steam ID and the small text toggle (link)
Define some constants, such as the Steam logo, status, and endpoints, for the applet (link)
Use the http module to make requests to the Steam API and get the user information, such as the avatar, name, status, and currently playing game (link)
Use the render module to create the UI elements, such as the images, text, marquee, row, and column, for the applet (link)
Use the secret module to decrypt the API key from the config object (link)
Handle some error cases, such as invalid user ID or API response, and display an error message (link)

I'll merge this, but I suspect this secret won't work either. If you shoot me a DM on discord I'll help you troubleshoot this. I think the correct command line to encrypt the secret for your app will be:
pixlet encrypt "steamplus" "your-secret-here"


setup-maas.yml takes a long time to run

THIS IS A PUBLIC FACING ISSUE.
Do not include private or confidential information in this issue.

Is this a feature or a bug?

[x] Feature (request for enhancement, new functionality)
[ ] Bug (something is broken)

Which version of rpc-openstack does this issue relate to?

[ ] master

Run git log --pretty=oneline | head -n 1 and provide the output below between
the backtick lines:
c10c556e5b2f2c897b6cff773b89adc7cb8e0183 Remove RabbitMQ default version (#2168)

What happened?
The setup-maas.yml playbook takes approximately 13 - 16min to complete, and has no way to just run parts(i.e. just run local checks, or swift checks, via tags).
What were you doing when it happened?
Data can be found on the gating jobs:
https://rpc.jenkins.cit.rackspace.net/job/RPC-AIO_master-swift-periodic/
Also, the following data was taken from my local build:
TASK: rpc_maas : Install pip packages to venv ------------------------- 197.78s
TASK: rpc_maas : Install local checks --------------------------------- 166.54s
TASK: rpc_maas : Install remote checks --------------------------------- 76.09s
TASK: rpc_maas : Install remote checks --------------------------------- 75.50s
TASK: rpc_maas : Wait for checks to register --------------------------- 60.11s
TASK: rpc_maas : Chmod listed plugin files ----------------------------- 55.41s
TASK: rpc_maas : Install local checks ---------------------------------- 54.65s
TASK: pip_install : Install PIP ---------------------------------------- 39.54s
TASK: rpc_maas : Install process checks -------------------------------- 39.49s
TASK: pip_install : Install external repo key with package ------------- 36.05s

What did you expect to happen instead of what actually happened?
It might be possible to reduce the setup-maas.yml execution time by being smarter about the way we target hosts. It would also be nice to have the ability to target specific tasks via tags.

I think this becomes something that we should work on once the role is extracted from RPC-O which is happening within the IRR PR found here: https://github.com/rcbops/rpc-openstack/pull/2166


2045 add createdat changedat timestamp for courses to api v1

Context
v1 api courses endpoint
created at and changed at timestamp for courses
Changes proposed in this pull request
Added created at and changed at timestamp for courses to api v1
Amended docs to reflect changes
Guidance to review
/api/v1/2019/courses
Checklist

[ ] Make sure all information from the Trello card is in here
[ ] Attach to Trello card
[ ] Rebased master
[ ] Cleaned commit history
[ ] Tested by running locally

 Add "created_at" & "changed_at" timestamp for courses to API V1


replace WriteConfStep with lctl replace_nids

Replace the WriteConfStep with lctl replace_nids in Rust, and then delete the corresponding action plugin writeconf_target.

So I found writeconf_target, it definitely looks like a lot more than simply setting up the nids.
So, next are several questions.

Since we want to replace that, is that correct that we would replicate it's entire API?

def writeconf_target(
    device=None,
    target_types=(),
    mgsnode=(),
    fsname=None,
    failnode=(),
    servicenode=(),
    param=None,
    index=None,
    comment=None,
    mountfsoptions=None,
    network=(),
    erase_params=False,
    nomgs=False,
    writeconf=False,
    dryrun=False,
    verbose=False,
    quiet=False,
)

The old plugin invokes tunefs.lustre rather than lctl - does it mean in the new one we have to do all the same actions just not with tunefs but with lctl?

The task entails implementing a new action plugin in Rust like those I've developed previously - is that correct?

writeconf_target is exposed as an action plugin from that repo.
On the manager side, the one place it's invoked is in the WriteConfStep here:
https://github.com/whamcloud/integrated-manager-for-lustre/blob/77426759c79efa59347376e274586daea9e825b0/chroma_core/models/host.py#L1596
WriteConfStep is also only used in one place and that's within the UpdateNidsJob here:
https://github.com/whamcloud/integrated-manager-for-lustre/blob/77426759c79efa59347376e274586daea9e825b0/chroma_core/models/host.py#L1686-L1698
We can replace that one usage with lctl replace_nids using the rust action plugin that already exists here:
https://github.com/whamcloud/integrated-manager-for-lustre/blob/77426759c79efa59347376e274586daea9e825b0/iml-agent/src/action_plugins/action_plugin.rs#L37
Once that's done, all the code referencing write_conf can be removed, as it's single usage will also have been removed.
In order to invoke the rust action plugin, you will need to create a step that wraps it, and then use that step where WriteConfStep was previously being used.
Here are some very simple Steps that invoke rust plugins as a reference point:
https://github.com/whamcloud/integrated-manager-for-lustre/blob/77426759c79efa59347376e274586daea9e825b0/chroma_core/models/ntp.py#L39-L76
More info on the replace_nids command can be found here:
http://doc.lustre.org/lustre_manual.xhtml#lustremaint.changingservernid

Needs Python agent code removal.


Support looking through lights

This is highly WIP, but I thought I'd put it here so John can offer feedback.
First 2 commits are hopefully good to go - a simple edge case fix, and support for a lens radius parameter on the light ( I do still need to remember to register this for ai:light:spotlight in
ArnoldLightUI ).
The third commit is definitely not ready for merge.  I wanted to make sure it works the way I want before I worried about where to put it.  Still need to handle lensRadius properly, but the trickier part is just where to put it.  I was originally going to make a separate public cameraFromLight() method in SceneAlgo, but then I realized that a bunch of the code would be duplicated from camera(), and I figured that if someone did specify a path with no camera and a light as a render camera, it probably doesn't hurt to render from the light, so I just added a couple extra lines in camera() to trigger the conversion.
But I realized that this probably violates a rule about metadata not influencing render results?  So I guess I need to move all this code into SceneView or something?

Hi Daniel,
So, I think our approach should mostly be dictated by how much time you want to spend on this, and how much we want to use this feature to drive other development (and how confident we are in knowing what that other development should look like).
We've talked a bit in the past about introducing a LightAccessor class, to provide a more concrete API for setting/getting parameters associated with defined properties of lights. So it would have methods like setIntensity()/getIntensity() and setColor()/getColor(), and StandardLightAccessor would implement those using the current metadata scheme, allowing StandardLightVisualiser to then be implemented in terms of LightAccessor. If we did this, perhaps virtual CameraPtr LightAccessor::camera() would be a reasonable method to add for our purposes here?
If we don't want to get into that now (I suspect we will have to eventually, but perhaps now is not the time), then I think a public lightToCamera() method in SceneAlgo would be fine, and we can live with the duplication of the parameter private utility.
I think we'll have to live with the "metadata affects rendering" thing, and I don't think that's too bad. In this case, the metadata being used isn't related to nodes/plugs, so it's not a case of graph metadata affecting graph computation. We're simply using generic metadata (string targets, rather than plug/node targets) as a handy preexisting mechanism for registering some information about lights, and additionally that metadata will not change during a process.
A couple of general questions :

Does applying the render resolution and overscan to lights really make sense? It feels odd to me, particularly since only square resolutions really make any sense for spotlights. Perhaps it makes sense to treat lights as always having the "resolutionOverride" we currently allow for cameras?
Would it make more sense for lightToCamera() to be passed the light shader via a const ObjectVector * than it would the whole attribute state via const CompoundObject *? I'm not sure on this one, but perhaps you have some insights...

Cheers...
John

I am feeling fairly enthusiastic about implementing LightAccessor - the more of this stuff I do, the more it makes sense.  But we probably do need to get a release out before then.  Not sure what user-facing feature we should use to drive the implementation of LightAccessor though.

Does applying the render resolution and overscan to lights really make sense?

I could go either way on this.  Usually you wouldn't want to render through a light anyway, so it doesn't matter.
If you were just rendering a daily out from the perspective of a light ( maybe as a quick automation thing because you happened to already have a lightrig that tracked your character nicely from an alternate perspective ), then you might want resolution and overscan to affect it.  Even if you were rendering out a shadow map, you would want some way to specify resolution, and could probably figure out that it makes sense to set a square resolution.
I don't see much advantage to hardcoding a particular square resolution, but this is all edge case stuff, and I'm fine with doing it if you prefer it.

Would it make more sense for lightToCamera() to be passed the light shader via a const ObjectVector *

Hmm, then the code to list all attributes ending with ":light" and check if they have shader ObjectVectors would live in GafferScene::camera?  I figured it makes sense to keep GafferScene::camera as simple as possible, and have lightToCamera be responsible for identifying which attributes might represent a light.
One question of my own:  I need to add an offset to the transform of the camera in order to support the lensRadius parameter.  Currently GafferScene::camera just calls camera->setTransform with the transform at the path.  I can think of a few options, none of which seems super convenient and elegant:
A) GafferScene::camera does a camera->getTransform and somehow tries to munge any existing transform on the camera together with the scene camera ( this seems quite messy given that the transform could be anything inheriting from Transform )
B) Add support in GafferScene::camera for a new optional camera->parametersData()->member( "transformOffset" ), which gets appended onto the transform
C) Add support for transformOffset somewhere lower level, like in the renderer backend.
I'm leaning towards B) - not feeling totally confident it's the most elegant approach, but it seems easy?

After talking to Andrew, we're maybe leaning towards A).  Supporting local transforms with setTransform() would match how CoordinateSystems currently work.
It could be implemented by adding a new IECore::ComposedTransform class inheriting from Transform, and then GafferScene::camera could do something like:
IECore::TransformPtr locationTransform = transform( scene, cameraPath, shutter( globals ), cameraBlur );
if( camera->getTransform().get() )
{
    camera->setTransform( new IECore::ComposedTransform( locationTransform, camera->getTransform() );
}
else
{
    camera->setTransform( locationTransform );
}

If I can't think of something better to do today, maybe I'll prototype that.

After talking to Andrew, we're maybe leaning towards A). Supporting local transforms with setTransform() would match how CoordinateSystems currently work.
If I can't think of something better to do today, maybe I'll prototype that.

It's after hours here, so I haven't thought this through fully, but I'd suggest not spending time on this today if there's anything else to be done. I see the setTransform() stuff on cameras and coordinate systems disappearing over time - it's not used in the new renderer backends, and it's always been awkward passing cameras/coordinate systems through Gaffer when they can contain transforms which contradict the separate transform gaffer computes.

I am feeling fairly enthusiastic about implementing LightAccessor - the more of this stuff I do, the more it makes sense. But we probably do need to get a release out before then. Not sure what user-facing feature we should use to drive the implementation of LightAccessor though.

Perhaps some sort of LightSpreadsheet node or a LightTool (manipulator) might be the obvious choices - something that needs the semantics that the metadata provides, but also requires writing back to lights as well as reading from them. The LightAccessor wouldn't be strictly necessary to achieve that, but it might be a logical time to improve our abstraction there.

Does applying the render resolution and overscan to lights really make sense?

I could go either way on this. Usually you wouldn't want to render through a light anyway, so it doesn't matter.

The main reason for rendering through a light is to generate a shadow map. That is largely all in the past, but I suspect we'll end up using this new light-camera stuff to generate shadow maps for the GL view, at which point we'll have to care about resolutions and aspect ratios.
Personally I am inclined to hardcode a "resolutionOverride" type thing to a square format. Whatever we do now won't be the solution for when we do start caring about the resolution, but this would at least be closer to the final thing in terms of aspect ratio.

Would it make more sense for lightToCamera() to be passed the light shader via a const ObjectVector *?

Hmm, then the code to list all attributes ending with ":light" and check if they have shader ObjectVectors would live in GafferScene::camera? I figured it makes sense to keep GafferScene::camera as simple as possible, and have lightToCamera be responsible for identifying which attributes might represent a light.

The thing I didn't like was the ambiguity of which light would be picked, since there can be more than one. Perhaps we just add an overload so there was a lightToCamera( attributes ) and a lightToCamera( shaderNetwork )? That keeps the details out of camera() but provides more control for anything that needs it.
Although, I'm beginning to suspect this addition to camera() may not necessarily be the solution anyway...

One question of my own: I need to add an offset to the transform of the camera in order to support the lensRadius parameter. Currently GafferScene::camera just calls camera->setTransform with the transform at the path. I can think of a few options, none of which seems super convenient and elegant:

Bear in mind that the transforms specified via setTransform() are totally ignored in the new renderer backends - they get the transform via the regular means instead. It has always been weird that IECore Cameras and Lights had their own transform where in IECore you'd normally use a Group to add a transform to a Primitive and in Gaffer everything intrinsically has a transform via ScenePlug anyway. We need to totally do away with all that setTransform() stuff rather than rely on it further.

A) GafferScene::camera does a camera->getTransform and somehow tries to munge any existing transform on the camera together with the scene camera ( this seems quite messy given that the transform could be anything inheriting from Transform )

I'd rule this out on the grounds above.

B) Add support in GafferScene::camera for a new optional camera->parametersData()->member( "transformOffset" ), which gets appended onto the transform

This too.

C) Add support for transformOffset somewhere lower level, like in the renderer backend.

This isn't impossible, but it's a real pity to force the work onto multiple renderer backends. It also introduces a coupling between object and transform which makes efficient IPR much more of a pain.
I'll throw another couple of options into the mix. I'm not sure I like them, but let's see...
D) Add support for a "scene:lightsAsCameras" context variable within GafferScene::Light. If this is set, the node outputs cameras (using the implementation of your lightToCamera() function internally) instead of lights. This has the benefit of not using the legacy setTransform() stuff, and being able to affect the results for both the transform and the object (and the sets). The downside would be that lights coming from a cache (or from Caribou I guess) wouldn't work. I guess this rules that out straight away then.
E) Add a LightToCamera node, which encapsulates all of your lightToCamera() stuff. This has the same benefits of D), but also works with stuff being sourced from a cache. It could be used only internally to the SceneView for now, but might have uses as a render adaptor in the future, or as a user-visible node for the kind of "render through light" daily workflows you mentioned.
I'm actually quite liking E), so it'd be good to get your thoughts, since you'll know more about the requirements than me. But as a general point, I'll add that Gaffer's main abstraction is the node graph, and I'm often finding that solutions making use of that turn out to be preferable to solutions which add additional custom APIs outside of it.

Perhaps some sort of LightSpreadsheet node or a LightTool (manipulator) might be the obvious choices

Yeah, sounds good.

Add a LightToCamera node, which encapsulates all of your lightToCamera() stuff

I can't think of any problem with this.  I'll try implementing it today.
In the meantime, should I separately pull request the first two little commits here to get into today's build?  They seem pretty straightforward, and useful as a first step.

Closing this since it has been superseded by later PRs.


Ignore permission denied errors when reading local files

Output of restic version
restic 0.11.0 compiled with go1.15.3 on linux/amd64

What should restic do differently? Which functionality do you think we should add?
restic fails with
signal interrupt received, cleaning up

when local files cannot be read, e.g.
scan: Open: open /home/vortico/pkg/atom-editor/pkg: permission denied
scan: Open: open /home/vortico/pkg/visual-studio-code-git/pkg: permission denied

By default, restic should fail, but in my case, I don't care about backing up files I can't read.
If there was an option --ignore-read-errors or something similar, restic could continue with the backup while omitting the files it can't read locally.

What are you trying to do? What problem would this solve?
In some developers' home directories, there will be several "weird" files created by build scripts, Docker, VirtualBox, webservers, etc that cannot be read by my normal user UNIX account. I can safely ignore these files and my backups will be just as useful to me. rsync prints errors to stderr but continues to copy files. It would be nice if restic did the same.

Did restic help you today? Did it make you happy in any way?
Yes. Currently evaluating a number of backup programs and this one looks promising.

signal interrupt received, cleaning up means that a SIGINT signal was sent to restic. restic already happily ignores files it cannot read and will finish with a non-zero exit code. So I wonder where that signal originates from?
You could also tell restic to --exclude files you don't care about.

signal interrupt received, cleaning up means that a SIGINT signal was sent to restic. restic already happily ignores files it cannot read and will finish with a non-zero exit code. So I wonder where that signal originates from?
You could also tell restic to --exclude files you don't care about.

@MichaelEischer Interesting, thanks for the information. If restic continues but fails, it already has the best behavior (IMO). I will investigate again tonight when I have access to my backup drive again and update the issue with what's really happening. In the above example, restic indeed exited 30% through the backup.

@MichaelEischer Interesting, thanks for the information. If restic continues but fails, it already has the best behavior (IMO). I will investigate again tonight when I have access to my backup drive again and update the issue with what's really happening. In the above example, restic indeed exited 30% through the backup.

Shortly after I created the issue but before your response, I deleted several folders that caused permission denied messages, and now after re-running the backup, it succeeds (even while there are other permission denied messages for other folders).
So now I can't reproduce the signal interrupt received, cleaning up exit. Will re-open if I can reproduce again.

Shortly after I created the issue but before your response, I deleted several folders that caused permission denied messages, and now after re-running the backup, it succeeds (even while there are other permission denied messages for other folders).
So now I can't reproduce the signal interrupt received, cleaning up exit. Will re-open if I can reproduce again.


Protobuf compatibility findings and suggestions

As a side quest to #1482, I've been experimenting with trying to update the Protobuf library beyond version 21.7, released 2022-09-29. The reason is that I anticipate potential complications after the Bzlmod update lands if users have later Protobuf versions in their MODULE.bazel dependency graph.
I've discovered the following details, which we may need to communicate to users through release notes and/or other documentation. Here are the combinations of various dependencies that work with one another. The first row is the current combination.

Protobuf
abseil-cpp
Bazel 6
ScalaPB
Scala

v21.7
20220623.1
✅
0.9.0
All

v21.7
20220623.1
✅
0.9.8
All

v21.7
20220623.1
✅
0.11.17
>= 2.12

v25.5
20240722.0
with --cxxopt
0.9.8
All

v25.5
20240722.0
with --cxxopt
0.11.17
>= 2.12

>= v28.2
20240722.0
with --cxxopt
1.0.0-alpha.1
>= 2.12

Suggestions
I'd suggest updating the .bazelversion to 7.4.0 and bumping Protobuf to v25.5. My reasoning is that these changes would bring rules_scala closer to recent Bazel and Protobuf updates, without potentially breaking existing users.
If we decide to build with Bazel 7 by default instead of Bazel 6, the Protobuf recompilation sensitivity won't be as much of an issue. In my experience, after merging #1619, #1620, and #1622, I haven't found any other Bazel 6 and 7 incompatibilities outside of building newer Protobuf versions.
It would be nice to bump to ScalaPB 1.0.0-alpha.1 to use the latest Protobuf v28.3. However, it seems like that might be too big a bump for existing users right now.
Takeaways
ScalaPB and the scala_proto_aspect are sensitive to the Protobuf version
The scala_proto_library rule uses an aspect that delegates to the protoc-bridge generator framework to generate code. protoc-bridge itself isn't very sensitive, but the ScalaPB.ScalaPbCodeGenerator implementations to which it delegates are very sensitive to the Protobuf library version.
See the protoc-bridge explanation section below for details on why this is the case.
The Protobuf Bazel module remaining at compatibility_level 1 is a problem
All current versions of the Protobuf Bazel module, from before 21.7 and up to the current 29.0-rc2.bcr.1, have a compatibility_level of 1. This means that all modules in the Bzlmod/MODULE.bazel dependency graph will resolve to a single Protobuf version, regardless of its major version number.
This means that rules_scala locks scala_proto users to the maximum Protobuf version that it supports (or to a minimum of v28.2 with ScalaPB 1.0.0-alpha.1). While already true when using WORKSPACE, this will also be the case under Bzlmod, until a Protobuf module release with a different compatibility_level.
Protobuf >= v22 requires C++14 or greater, --cxxopt flags in Bazel 6
Protobuf v22 dropped C++11 support, requiring C++14 or greater. This corresponds to the update in abseil-cpp from 20220623.2, the last to support C++11, to 20230125.0, the first to require C++14.
This is not a problem for Bazel 7. Bazel 6, however, does not use a C++14 or greater toolchain out of the box.
To build these more recent versions of abseil-cpp and Protobuf under Bazel 6, I've added these .bazelrc flags from bazelbuild/bazel#20785 in commit 03d4e20 from mbland/rules_scala:
build:linux --cxxopt=-std=c++17
build:linux --host_cxxopt=-std=c++17
build:macos --cxxopt=-std=c++17
build:macos --host_cxxopt=-std=c++17
build:windows --cxxopt=/std=c++17
build:windows --host_cxxopt=/std=c++17

--cxxopt flags in Bazel 6 cause Protobuf to rebuild more frequently
Protobuf is already notoriously sensitive to recompilation.

Stack Overflow: bazel recompiles protobuf more than necessary suggests a sensitivity to build config flags in particular.
bazelbuild/bazel#7095 explains the sensitivity of C++ toolchains in general to PATH, not just the Protobuf toolchain.

This recompilation became so bad, I thought test_scalafmt from test_cross_build.sh was hanging. It was actually recompiling Protobuf on every bazel run invocation. (I've since filed #1646 to resolve this.)
Protobuf v25.5 is the highest version compatible with ScalaPB 0.9.8, 0.11.17
I was able to confirm this by iterating through different configurations of the test_scala_version test case from test_version.sh. I used the RULES_SCALA_TEST_ONLY environment variable from #1646 and the test_version.sh changes from commit ff1a079 from mbland/rules_scala to do this fairly easily.
There is no combination that works with Protobuf v26 or v27
I was able to confirm this using the same methodolgy...
No Protobuf version < v28.2 works with ScalaPB 1.0.0-alpha.1
...as I was able to confirm this as well.
Working branches
I was able to reach the above conclusions by building up changes in the following branches:

bzlmod-update-protocbridge-and-grpc: bumps ScalaPB to 0.9.8 for Scala 2.11 and 0.11.17 for Scala 2.12 and above
bzlmod-update-abseil-cpp-and-protobuf:

first bumps Protobuf to v25.5 and abseil-cpp to 20240722.0, with Bazel 6 compiler flags in .bazelrc
then bumps ScalaPB to 1.0.0-alpha.1 and Protobuf to v28.3

protoc-bridge explanation
scala_proto_library uses scala_proto_aspect, which uses the scripts.ScalaPBWorker class from src/scala/scripts/ScalaPBWorker.scala, which calls ProtocBridge.runWithGenerators. This function ultimately runs generator classes in separate threads via Futures. It then runs protoc with --plugin flags pointing at shell wrappers communicating with these generator Futures over a local pipe.
The ScalaPB jars required by the generators (not so much the protoc-bridge framework itself) must be compatible with the current Protobuf library version. Not just with the protobuf-java Maven artifact, which can be a new as you like, but with the build's actual Protobuf repository that provides protoc. Otherwise, ScalaPB code will throw exceptions like java.lang.NoSuchMethodError or java.lang.IllegalAccessError.
For example, from the #1624 commit message:
Exception in thread "main" java.lang.NoSuchMethodError:
  'boolean com.google.protobuf.GeneratedMessageV3.isStringEmpty(java.lang.Object)'

From the #1630 commit message:
--jvm_extra_protobuf_generator_out: java.lang.NoSuchMethodError:
  'java.lang.Object com.google.protobuf.DescriptorProtos$MessageOptions.getExtension(com.google.protobuf.GeneratedMessage$GeneratedExtension)'
    at scalapb.compiler.DescriptorImplicits$ExtendedMessageDescriptor.messageOptions(DescriptorImplicits.scala:532)

From the #1637 commit message:
--jvm_extra_protobuf_generator_out: java.lang.IllegalAccessError:
  class scalapb.options.Scalapb$ScalaPbOptions tried to access method
  'com.google.protobuf.LazyStringArrayList
    com.google.protobuf.LazyStringArrayList.emptyList()'
  (scalapb.options.Scalapb$ScalaPbOptions and
   com.google.protobuf.LazyStringArrayList are in unnamed module
   of loader 'app')

From commit 6f702a6 from mbland/rules_scala, which I plan to submit when bumping to ScalaPB 0.11.17:
--scala_out: java.lang.NoSuchMethodError:
  'void com.google.protobuf.Descriptors$FileDescriptor.internalBuildGeneratedFileFrom(java.lang.String[],
    com.google.protobuf.Descriptors$FileDescriptor[],
    com.google.protobuf.Descriptors$FileDescriptor$InternalDescriptorAssigner)'
      at scalapb.options.compiler.Scalapb.<clinit>(Scalapb.java:10592)

The changes from #1637 and the last commit above catch ScalaPB generator exceptions and return the stack trace as a proper error response. This is how I collected the stack traces above. Without these changes, the build hangs on uncaught exceptions, since the scripts.ScalaPBWorker will wait forever for a dead generator to respond.
Here's an example of a scripts.ScalaPBWorker command generated when building scala_proto_library targets in //test/proto/..., with long path prefixes and many jar paths elided:
.../scalapb_worker.runfiles/io_bazel_rules_scala/../remotejdk11_.../bin/java
  -classpath
    .../io_bazel_rules_scala/src/scala/scripts/scalapb_worker.jar:
    .../io_bazel_rules_scala/src/scala/scripts/scalapb_worker_lib.jar:
    [ ...protobuf, core Scala, and ScalaPB jars... ]
  -DGEN_jvm_extra_protobuf_generator=
   scalarules.test.extra_protobuf_generator.ExtraProtobufGenerator
  -DGEN_scala=scripts.ScalaPbCodeGenerator
  -DPROTOC=bazel-out/.../bin/external/com_google_protobuf/protoc
  -DJARS=
    .../bin/test/src/main/scala/scalarules/test/extra_protobuf_generator/extra_protobuf_generator.jar:
    [ ...protobuf, core Scala, and ScalaPB jars... ]
  scripts.ScalaPBWorker --persistent_worker

The scripts.ScalaPBWorker class calling ProtocBridge.runWithGenerators launches protoc processes like this, with $VARDIR representing the generated /var path:
bazel-out/.../bin/external/com_google_protobuf/protoc
  --plugin=protoc-gen-scala=$VARDIR/protocbridge11068409970088580527
  --plugin=protoc-gen-jvm_extra_protobuf_generator=
    $VARDIR/protocbridge7908074065015031242
  --jvm_extra_protobuf_generator_out
    bazel-out/.../bin/test/proto/
    test2_jvm_extra_protobuf_generator_scalapb.srcjar
  --jvm_extra_protobuf_generator_opt grpc,single_line_to_proto_string
  --scala_out bazel-out/.../bin/test/proto/test2_scala_scalapb.srcjar
  --scala_opt grpc,single_line_to_proto_string
  --descriptor_set_in
    bazel-out/.../bin/test/proto2/test-descriptor-set.proto.bin:
    bazel-out/.../bin/test/proto/test2-descriptor-set.proto.bin
  test/proto/test2.proto

Notice the --plugin= flags above, which specify scripts generated by protoc-bridge that look like this:
#!/bin/sh
set -e
cat /dev/stdin > "$VARDIR/protopipe-14656650241271353812/input"
cat "$VARDIR/protopipe-14656650241271353812/output"

This command will show the scripts.ScalaPBWorker parent process, all the plugin script child processes, and the cat "$VARDIR/protopipe-.../output" grandchild processes if they're still running:
ps -ef | grep -E '[p]roto(cbridge|pipe)'

Without the aforementioned changes, you have to kill the build with CTRL-C when it hangs. bazel shutdown will then clean up the processes that haven't yet become zombified, but such zombified processes must be cleaned up with:
ps -ef | grep -E '[p]roto(cbridge|pipe)' | awk '{print $2}' | xargs kill

I just ran a small experiment to confirm my understanding of how potential Bzlmod users could accommodate our Protobuf dependency and theirs, whereby they rely on a version that isn't currently compatible with rules_scala. The mechanism relies on:

the repo_name parameter of bazel_dep
the multiple_version_override directive

I created a new repo consisting of only the following three files:
.bazelversion (for Bazelisk):
7.4.1

MODULE.bazel:
module(name = "multiple-module-repo-experiment")

bazel_dep(
    name = "protobuf",
    version = "21.7",
    repo_name = "com_google_protobuf",
)

bazel_dep(
    name = "protobuf",
    version = "28.3",
)

multiple_version_override(
    module_name = "protobuf",
    versions = ["21.7", "28.3"],
)

BUILD:
load("@com_google_protobuf//:protobuf.bzl", "cc_proto_library")
load("@protobuf//bazel:proto_library.bzl", "proto_library")

This builds successfully and produces the following repos:
$ ls -ld "$(bazel info output_base)"/external/protobuf*
drwxr-xr-x  54 user  group  1728 Nov 19 14:18 .../external/protobuf~v21.7/
drwxr-xr-x  66 user  group  2112 Nov 19 14:18 .../external/protobuf~v28.3/

So we'd need to put in the release notes or documentation something like the following:

If your repository doesn't use Protobuf, uses Protobuf v21.7 to v25.5, or doesn't use the scala_proto or scalafmt toolchains from rules_scala, there's nothing to do.
Projects using Protobuf v26 and higher must use something like the MODULE.bazel stanza above to accommodate both its own required Protobuf version and that required by rules_scala.
The bazel_dep for the rules_scala version must specify repo_name = "com_google_protobuf", or some other name not used by the host project.
Per the multiple_version_override documentation, this only applies to the main repository; it does not convey to other repositories that depend on the repository using the multiple_version_override.

I also confirmed that multiple_version_override would be required even if the compatibility_level of the Protobuf module versions were different. I extended my experiment to try it with rules_erlang. I added the following to MODULE.bazel:
bazel_dep(
    name = "rules_erlang",
    version = "2.5.2",
    repo_name = "rules_erlang_v2",
)

bazel_dep(
    name = "rules_erlang",
    version = "3.16.0",
)

and the following to BUILD:
load("@rules_erlang_v2//:erlang_app.bzl", "test_erlang_app")
load("@rules_erlang//:erlang_app.bzl", "erlang_app")

Without multiple_version_override, the build failed with:
$ bazel build //:all

ERROR: Error computing the main repository mapping:
  <root> depends on<EMAIL_ADDRESS>with compatibility level 3,
  but <root> depends on<EMAIL_ADDRESS>with compatibility level 2
  which is different

Then I added the following to MODULE.bazel, and it worked:
multiple_version_override(
    module_name = "rules_erlang",
    versions = ["2.5.2", "3.16.0"],
)

And we can see the different repo versions in this case, too:
$ ls -ld "$(bazel info output_base)"/external/rules_erlang*

drwxr-xr-x  34 user  group  1088 Nov 19 16:07 .../external/rules_erlang~v2.5.2/
drwxr-xr-x  60 user  group  1920 Nov 19 16:07 .../external/rules_erlang~v3.16.0/

At least in the rules_erlang case, where the compatibility_levels were different, we got an error message up front pointing at the problem. Without it, we potentially have to decipher a cryptic build breakage and diagnose the root cause, as I demonstrated in the original issue description.

Bazel 8 further complicates things. See #1652 for details, and bazelbuild/bazel#24235 for a cross reference.
Repeating most of my summary from the latter issue for convenience:

Most of the Bazel 8 and rules_java 8 incompatibilities can be easily addressed once Bzlmodification lands, and what I think is the only remaining one may be resolved by a protobuf-java:4.29.0 release (without -RC2).
The tradeoffs are that users will be forced to upgrade to Protobuf v28.3 under Bazel 6 and 7, and Protobuf v29 under Bazel 8, and the load("@rules_java") statements required by Bazel 8 will break WORKSPACE users for good. Then again, that may be all the more reason to suggest folks migrate to Bzlmod sooner than later.

I've confirmed in my replace-custom-scalapb-wrappers-with-protoc-bridge-0.9.8 branch that the recently released protoc-bridge 0.9.8 resolves scalapb/ScalaPB#1771 (i.e., protoc-bridge catches scalapb.ScalaPbCodeGenerator errors, so we don't have to). I've since closed that issue, and will send a pull request containing the changes from this branch eventually.

Here are some detailed findings from my replace-custom-scalapb-wrappers-with-protoc-bridge-0.9.8 branch, specifically https://github.com/mbland/rules_scala/commit/2d7b891abf35ef0fb18aac4fc21bb617fef7672b, regarding our handling of ScalaPB's compilerplugin, protoc-gen, and protoc-bridge artifacts. Please see that commit message for even more  details.
Scala 3 artifacts and compilerplugin_3's dependency on protoc-gen_2.13
The _3 versions of the most recent ScalaPB artifacts are only available for Scala 3.3 and later, and compilerplugin_3 currently still depends on protoc-gen_2.13.
Building Scala 3.3 and later versions with compilerplugin_3 and protoc-bridge_3 artifacts (instead of protoc-bridge_2.13 artifacts) produces the following build failure:
$ RULES_SCALA_TEST_ONLY="test_scala_version 3.6.2" \
    ./test_thirdparty_version.sh

[ ...snip... ]

ERROR: third_party/test/proto/BUILD.bazel:4:14:
  ProtoScalaPBRule
  third_party/test/proto/proto_jvm_extra_protobuf_generator_scalapb.srcjar
  failed: (Exit 1): scalapb_worker failed: error executing command
  (from target //third_party/test/proto:proto)
  bazel-out/darwin_arm64-opt-exec-2B5CBBC6/bin/src/scala/scripts/scalapb_worker
    ... (remaining 2 arguments skipped)

--scala_out: java.lang.NoClassDefFoundError:
  Could not initialize class scalapb.ScalaPbCodeGenerator$
    at scripts.ScalaPbCodeGenerator$.process(ScalaPbCodeGeneratorWrapper.scala:8)
    at protocgen.CodeGenApp.run(CodeGenApp.scala:48)
    at protocgen.CodeGenApp.run$(CodeGenApp.scala:41)
    at scripts.ScalaPbCodeGenerator$.run(ScalaPbCodeGeneratorWrapper.scala:5)
    at protocgen.CodeGenApp.run(CodeGenApp.scala:33)
    at protocgen.CodeGenApp.run$(CodeGenApp.scala:32)
    at scripts.ScalaPbCodeGenerator$.run(ScalaPbCodeGeneratorWrapper.scala:5)
    at protocbridge.frontend.PluginFrontend$.runWithBytes(PluginFrontend.scala:48)
    at protocbridge.frontend.PluginFrontend$.runWithInputStream(PluginFrontend.scala:113)
    [ ...snip... ]

protoc-bridge 0.9.8 with a new try/catch block vs. 0.7.14 for Scala 2.11
The initial motivation for that commit was to try to eliminate the need for the custom scripts.ScalaPbCodeGenerator implementation by upgrading to protoc-bridge 0.9.8. This version contains a change to catch any Throwable objects raised by a generator implementation in protocbridge.frontend.PluginFrontend.runWithInputStream().
This change originally came from scalapb/protoc-bridge#367 (exact lines).
I closed scalapb/ScalaPB#1771 as a result, and reexamined the try/catch blocks added in bazelbuild/rules_scala#1630 and bazelbuild/rules_scala#1637, and the scripts.ScalaPBCodeGenerator implementations added in bazelbuild/rules_scala#1648.
However, the last protoc-bridge version to support Scala 2.11 is 0.7.14. Scala 2.11 won't be able to use protoc-bridge 0.9.8, so we still need to catch any Throwables ourselves. This includes the catch blocks from the Scala 2.11 scripts.ScalaPbCodeGenerator and scalarules.test.extra_protobuf_generator.ExtraProtobufGenerator.run.
try/catch blocks
In protoc-bridge 0.9.7 and 0.9.8, protocbridge.ProtocCodeGenerator declares a run() method with no implementation (and no try/catch block).
In protoc-gen 0.9.7 and 0.9.8, protogen.CodeGenApp implements protocbridge.ProtocCodeGenerator, and CodeGenApp.run() wraps a call to CodeGenApp.process() inside a try/catch block.
scalapb.ScalaPbCodeGenerator from compilerplugin 0.11.17 extends CodeGenApp and implements process(). For this version of ScalaPbCodeGenerator, available in Scala 2.12 and later, there's no need for a try/catch wrapper on our end.
However, the last available compilerplugin version for Scala 2.11 is 0.9.8. scalapb.ScalaPbCodeGenerator from that version implements protocbridge.ProtocCodeGenerator and has a try/catch in its run() method. However, the Scalapb.registerAllExtensions(registry) call on line 14 lies outside this block, producing the crash described in bazelbuild/rules_scala#1648 (https://github.com/bazelbuild/rules_scala/commit/23ae356557b1e1103acc28409aa5c41cabf32b52). This is why we need the Scala 2.11 implementation of scripts.ScalaPbCodeGenerator.
https://github.com/bazelbuild/rules_scala/blob/23ae356557b1e1103acc28409aa5c41cabf32b52/src/scala/scripts/ScalaPbCodeGeneratorWrapper_2_11.scala#L5-L18
$ bazel build --repo_env=SCALA_VERSION=2.11.12 //proto:test_proto

ERROR: .../test_version/test_scala_version_1731169107/proto/BUILD:14:14:
  ProtoScalaPBRule proto/test3_scala_scalapb.srcjar failed: (Exit 1):
  scalapb_worker failed: error executing command
  (from target //proto:test3)

bazel-out/.../bin/external/io_bazel_rules_scala/src/scala/scripts/scalapb_worker
  ... (remaining 2 arguments skipped)

--scala_out: java.lang.NoSuchMethodError:
  'void com.google.protobuf.Descriptors$FileDescriptor.internalBuildGeneratedFileFrom(java.lang.String[],
    com.google.protobuf.Descriptors$FileDescriptor[],
    com.google.protobuf.Descriptors$FileDescriptor$InternalDescriptorAssigner)'
      at scalapb.options.compiler.Scalapb.<clinit>(Scalapb.java:10592)
====> at scalapb.ScalaPbCodeGenerator$.run(ScalaPbCodeGenerator.scala:14)
      at scalapb.ScalaPbCodeGenerator$.run(ScalaPbCodeGenerator.scala:10)
      at scripts.ScalaPbCodeGenerator$.run(ScalaPbCodeGeneratorWrapper_2_11.scala:8)
      at protocbridge.frontend.PluginFrontend$$anonfun$runWithBytes$2.apply(PluginFrontend.scala:52)
      at protocbridge.frontend.PluginFrontend$$anonfun$runWithBytes$2.apply(PluginFrontend.scala:52)
      at scala.util.Try$.apply(Try.scala:192)
      at protocbridge.frontend.PluginFrontend$.runWithBytes(PluginFrontend.scala:51)
      at protocbridge.frontend.PluginFrontend$.runWithInputStream(PluginFrontend.scala:103)
      [ ...snip...]

scalarules.test.extra_protobuf_generator.ExtraProtobufGenerator, also extends ProtocCodeGenerator directly, instead of implementing CodeGenApp (so it also builds with Scala 2.11). This is why ExtraProtobufGenerator.run() hangs when we remove the try/catch block and run with protoc-bridge 0.9.7 and protobuf > v25.5, even with later Scala versions.
https://github.com/bazelbuild/rules_scala/blob/23ae356557b1e1103acc28409aa5c41cabf32b52/test/src/main/scala/scalarules/test/extra_protobuf_generator/ExtraProtobufGenerator.scala#L47-L67
Keeping scripts.ScalaPbCodeGenerator for Scala 2.11 compatibility
Since scalapb.ScalaPbCodeGenerator from compilerplugin 0.11.17 implements CodeGenApp, scripts.ScalaPbCodeGenerator for Scala 2.12 should be unnecessary. The only reason we need it is to maintain the same interface as the Scala 2.11 implementation.
https://github.com/bazelbuild/rules_scala/blob/23ae356557b1e1103acc28409aa5c41cabf32b52/src/scala/scripts/BUILD#L26-L36
https://github.com/bazelbuild/rules_scala/blob/23ae356557b1e1103acc28409aa5c41cabf32b52/scala_proto/scala_proto_toolchain.bzl#L83-L85
https://github.com/bazelbuild/rules_scala/blob/23ae356557b1e1103acc28409aa5c41cabf32b52/scala_proto/scala_proto_toolchain.bzl#L113-L120


[ja] Translate reference/glossary/addons.md & kubeadm.md into Japanese

This is a Feature Request
What would you like to be added
Translate content/en/docs/reference/glossary/addons.md &  content/en/docs/reference/glossary/kubeadm.md into Japanese.
Why is this needed
This page has not been translated.
Comments
/language ja
/assign

Almost LGTM.
Could you squash multiple commits to one commit?

Thank you for quick update!! 😄

/lgtm

/assign @nasa9084
Could you review this?

/approve


Fix error adding log entry with no body

Description
Fixes https://github.com/dotnet/aspire/issues/6703
Checklist

Is this feature complete?

[x] Yes. Ready to ship.
[ ] No. Follow-up changes expected.

Are you including unit tests for the changes and scenario tests if relevant?

[x] Yes
[ ] No

Did you add public API?

[ ] Yes

If yes, did you have an API Review for it?

[ ] Yes
[ ] No

Did you add <remarks /> and <code /> elements on your triple slash comments?

[ ] Yes
[ ] No

[x] No

Does the change make any security assumptions or guarantees?

[ ] Yes

If yes, have you done a threat model and had a security review?

[ ] Yes
[ ] No

[x] No

Does the change require an update in our Aspire docs?

[ ] Yes

Is this introducing a breaking change?

[ ] Yes

Link to aspire-docs issue (please use this breaking-change template):

[ ] No

Link to aspire-docs issue (please use this doc-idea template):

[x] No

Microsoft Reviewers: Open in CodeFlow

/azp run

/backport to 9.0

/backport to release/9.0


Remove dynamic object tweak on TwigBundleFilesystemLoaderToTwigRector

Already covered in rector-src on PR:

https://github.com/rectorphp/rector-src/pull/4936

All checks have passed 🎉 @TomasVotruba I am merging it ;)


Metrics not displayed in reports for the customData parameter

Hi,
I'm trying to create a metric for the click events on CoveoResult item, but i have some issues, always getting 0 counts.
On click event, I can see custom data value on networks tab in the browser:

I also created dimension in Dimensions:

But with this metric and filter, always getting 0 count.

Thanks in advance.

I'm closing this issue, as it's not related to the tracking library itself. For Coveo product related questions there are other support channels.


fix: push snapshots before updating intervals

Prior to this we would add a reference to the intervals tables to a snapshot that doesn't exist when doing forward-only changes. This flips the order so we first add the snapshot and then start adding intervals.

I think the same problem exists in case of Airflow https://github.com/TobikoData/sqlmesh/blob/main/sqlmesh/schedulers/airflow/plan.py#L104 but there the fix is a lot more involved potentially. What's the problem with interval being created before the snapshot?


Cannot subtract bevy::utils::Instant beyond the moment of app startup on WebAssembly

Bevy version
0.10
Relevant system information
WebAssembly
What you did
Attempted to represent an Instant that is before app startup by subtracting a Duration.
What went wrong
A panic due to subtraction with overflow!
Additional information
I have a feature in seldom_pixel that pre-simulates particles when you spawn an emitter. So, when something that emits particles gets close to being on-screen or a scene is spawned with an emitter already on-screen, you can spawn an emitter at that moment, and it will look like the particles were already there. Particles store the time they were spawned for their functionality, which means that pre-simulated particles may store a time before they were actually spawned.
On wasm, I can't represent particles that were spawned with pre-simulation too close to app startup, since that moment is not representable with Instant. Not a major issue, but it's hacky to workaround. A possible solution on my end would be to use f32s instead, or add a buffer to every time.last_update call. If it's possible, a solution on Bevy's end would be to start time somewhere after 0. A minute should suffice for me, but I think it wouldn't be a dent on Instant's range to start many years in.

Was discussed here in detail: https://github.com/sebcrozet/instant/issues/45#issuecomment-1485240689

[..] The starting point of the underlying clock is not defined by Rust.
The reason this currently works on Linux is because std uses clock_gettime:

All implementations support the system-wide realtime clock, which is identified by CLOCK_REALTIME. Its time represents seconds and nanoseconds since the Epoch.

So the starting time is since the UNIX epoch. So unless your computer boots with a time set to 1970 it will always be much bigger then 0.
On Windows for example, std uses QueryPerformanceCounter, which doesn't start from the UNIX epoch, 0 can be the start of when you boot. [..]

We've moved from instant to web-time, is this still an issue?

It still is. Repro: https://github.com/Seldom-SE/testetst/blob/4f1dc50d873868821104f5990edfddaefb17c5a9/src/main.rs
ERROR app: panicked at /home/seldom/.cargo/registry/src/index.crates.io-6f17d22bba15001f/web-time-0.2.4/src/time/insta
nt.rs:93:14:
overflow when subtracting duration from instant

As pointed out in https://github.com/bevyengine/bevy/issues/8483#issuecomment-1523535260 this isn't an issue with instant or web-time, but with the guarantees std::time::Instant gives, which both libraries try to emulate as closely as possible.
If Bevy wants to resolve this issue, it has to move away from std::time::Instant.


Create Custom error pages, set-up mailing for errors

Is your feature request related to a problem? Please describe.
We should have some custom error pages for different common errors. At least for 404 (not found), 401 (access denied), 500 (internal server error).
Describe the solution you'd like
Create custom error pages with nice graphics and maybe display some debug information if 500 occurs. Set-up the mailing service to receive debugs for <=500.
Additional context
Add any other context or screenshots about the feature request here.

Implemented in last commit.


Add CORS middleware and example

PUT, DELETE testing failed. (in web brower, not open directly, run in server)

Pull Request Test Coverage Report for Build 333

0 of 103 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-13.8%) to 86.193%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

middlewares/cors.go
0
103
0.0%

Totals

Change from base Build 332:
-13.8%

Covered Lines:
643

Relevant Lines:
746

💛  - Coveralls

Please, fix the issues and coverage!

Please, fix the issues and coverage!

👌 Learing golangci docs.,

Sorry for the trouble, just learned GO for a few days,
PUT, DELETE are not successed, missing unit tests.
Contact later, GN. 🌙

PUT, DELETE testing failed. (in web brower, not open directly, run in server)

Oh.I missed the coveralls, me will improve again  tomorrow

Sorry, but I couldn't review it now.
Tomorrow I will check it and help you ;)

Sorry, but I couldn't review it now.
Later I will check it and help you ;)

I am starting to complete the coverage test now. If you have free time, take the time to confirm whether PUT, DELETE is BUG please 😄


fix: improve PR description and title field descriptions for clarity

PR Type
Enhancement

Description

Enhanced PR template field descriptions for better clarity and usability:

Updated description field to explicitly mention support for sub-bullet points and prioritization of changes
Refined title field description to emphasize conciseness while maintaining descriptiveness

Changes walkthrough 📝
Relevant filesDocumentation

pr_description_prompts.tomlImprove field descriptions clarity in PR template

pr_agent/settings/pr_description_prompts.toml
Updated field descriptions for better clarity:   - Modified description field to explicitly allow sub-bullet points   - Refined title field description to emphasize conciseness and descriptiveness

+2/-2

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

Preparing PR description...

PR Description updated to latest commit (https://github.com/Codium-ai/pr-agent/commit/6fbd95e1a9d9f69c830da201a38867e6c55d6d98)

/describe


[Recorded test] Response with binary stream data doesn't work

The response is saved in the json recording.  However during playback.  The binary data is not in the form expected by the test.
Might be related to encoding/decoding of the data.
Form Recognizer browser test recordings:

sdk/formrecognizer/ai-form-recognizer/recordings/browsers/formrecognizerclient_browser_only/recording_recognizes_receipt_from_a_blob.json
sdk/formrecognizer/ai-form-recognizer/recordings/browsers/formrecognizerclient_custom_form_recognition_browser_only/recording_recognizes_form_from_a_blob_using_model_trained_without_labels.json

Closing this, as the new recorder seems to address it (BodilessMatcher) and we have another issue to track eliminating POST bodies from the recording files as well.


Unable to debug AppHost

Describe the bug
I am able to debug other projects in the solution but breakpoints don't get trigger in the AppHost.
This happens when using the AppHost configuration, but breakpoints get trigger when I use the ".NET Launch settings profile" instead
To Reproduce

Create a new Aspire starter application
Set a breakpoint in the appHost Program.cs

Expected behavior
Screenshots
If applicable, add screenshots to help explain your problem.
Reproducing sample
Link to a test project to reproduce the bug.
System information:

OS: MacOS
.NET version: 8
JetBrains Rider version: 2024.2.3
Aspire plugin version: 1.3.0
Aspire workload version: 8.2.0

@cecilphillip Thank you for the feedback. Actually, "it's not a bug, it's a feature". I intentionally run the Host project without a debugger attached to simplify the user experience. From what I understand, Host project is more like docker-compose.yml with the dependencies described, and you probably don't need to debug it. What are your thoughts on this? Do you have scenarios where the debugger is necessary?

Thank you! I'll consider to support debugging

In other Rider configurations (without Aspire), Multilaunch configs allow the user to choose what they want and what they don't want to debug.
Perhaps we can add a checkbox to the Aspire configuration (unchecked by default if we consider it a better choice), to create a separate debug session for the Host projects?

Nice idea!

I decided to keep it simple. Just enable host debugging if it's a debugging session. I think this is the clearest option.


Autocompletion not working in IntelliJ 2019.2

Description:
Auto completion not working in IntelliJ 2019.2 with ballerina plugin 991.1

@paramids you don't get completions at all or is it only in some cases? If so will you be able to share a sample you are trying?

@paramids Could you please also provide your ballerina SDK version to reproduce the issue? :)

Closing the issue as per the above comment.


Log on INFO level instead of ERROR given null value in TrackerPayload.

Super simple fix related to this issue https://github.com/snowplow/snowplow-java-tracker/issues/186#event-957481722

Thanks for your pull request @kimnilsson. Is this your first contribution to a Snowplow open source project? Before we can merge your pull request, you'll need to sign a Contributor License Agreement (CLA).
📝 Please visit https://github.com/snowplow/snowplow/wiki/CLA to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

Thank you for your contribution. We've decided to go in a slightly different direction with this fix, see #186 comments for more info.


prolificdreamer result is strange ...

PROMPT: Cute little red cat sleeping on floor with window on background.
CONFIG: prolificdreamer-scene
https://github.com/threestudio-project/threestudio/assets/12405578/7ec56c47-b65e-4603-a81e-65aecfe40e16
The result is strange ...

This scene generation configuration is for scenes without foreground objects. If you want to generate scenes with both foreground objects and background, you may want to implement the "scene with a centric object" initialization as in Sec.4.2 in the ProlificDreamer paper:

OK


Any OPTIONS request causes "MethodError: merge" (needed for CORS)

Whenever I make an OPTIONS request I get a 500 Internal Server Error:
Distributed.RemoteException(1, CapturedException(MethodError(merge, (Pair{SubString{String},SubString{String}}["Server"=>"Genie/0.7.0/Julia/1.0.0", "Content-Type"=>"text/html"], Dict("Access-Control-Allow-Headers"=>"","Access-Control-Allow-Methods"=>"","Access-Control-Allow-Credentials"=>"","Access-Control-Allow-Origin"=>"","Access-Control-Expose-Headers"=>"","Access-Control-Max-Age"=>"86400")), 0x0000000000006225), Any[(set_headers!(::Request, ::Response, ::Response) at AppServer.jl:110, 1), (handle_request(::Request, ::Response, ::IPv4) at AppServer.jl:96, 1), (handle_request(::Request, ::Response) at AppServer.jl:95, 1), (#14 at macros.jl:108 [inlined], 1), (run_work_thunk(::##14#17{Request,Response}, ::Bool) at process_messages.jl:56, 1), (#remotecall_fetch#148(::Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Function, ::LocalProcess) at remotecall.jl:364, 1), (remotecall_fetch(::Function, ::LocalProcess) at remotecall.jl:364, 1), (#remotecall_fetch#152(::Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Function, ::Int64) at remotecall.jl:392, 1), (remotecall_fetch(::Function, ::Int64) at remotecall.jl:392, 1), (setup_http_handler(::Request, ::Response) at AppServer.jl:60, 1), (setup_http_handler at AppServer.jl:59 [inlined], 1), (#6 at AppServer.jl:40 [inlined], 1), (handle at Handlers.jl:248 [inlined], 1), (handle(::RequestHandlerFunction{##6#12}, ::Stream{Request,Transaction{TCPSocket}}) at Handlers.jl:271, 1), (#4 at Handlers.jl:339 [inlined], 1), (macro expansion at Servers.jl:352 [inlined], 1), ((::##13#14{##4#5{RequestHandlerFunction{##6#12}},Transaction{TCPSocket},Stream{Request,Transaction{TCPSocket}}})() at task.jl:259, 1)])) in C:\Users\Robin\.julia\packages\Genie\AxLFn\src\AppServer.jl:71

######################### ERROR STACKTRACE #########################
Distributed.RemoteException(1, CapturedException(MethodError(merge, (Pair{SubString{String},SubString{String}}["Server"=>"Genie/0.7.0/Julia/1.0.0", "Content-Type"=>"text/html"], Dict("Access-Control-Allow-Headers"=>"","Access-Control-Allow-Methods"=>"","Access-Control-Allow-Credentials"=>"","Access-Control-Allow-Origin"=>"","Access-Control-Expose-Headers"=>"","Access-Control-Max-Age"=>"86400")), 0x0000000000006225), Any[(set_headers!(::Request, ::Response, ::Response) at AppServer.jl:110, 1), (handle_request(::Request, ::Response, ::IPv4) at AppServer.jl:96, 1), (handle_request(::Request, ::Response) at AppServer.jl:95, 1), (#14 at macros.jl:108 [inlined], 1), (run_work_thunk(::##14#17{Request,Response}, ::Bool) at process_messages.jl:56, 1), (#remotecall_fetch#148(::Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Function, ::LocalProcess) at remotecall.jl:364, 1), (remotecall_fetch(::Function, ::LocalProcess) at remotecall.jl:364, 1), (#remotecall_fetch#152(::Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Function, ::Int64) at remotecall.jl:392, 1), (remotecall_fetch(::Function, ::Int64) at remotecall.jl:392, 1), (setup_http_handler(::Request, ::Response) at AppServer.jl:60, 1), (setup_http_handler at AppServer.jl:59 [inlined], 1), (#6 at AppServer.jl:40 [inlined], 1), (handle at Handlers.jl:248 [inlined], 1), (handle(::RequestHandlerFunction{##6#12}, ::Stream{Request,Transaction{TCPSocket}}) at Handlers.jl:271, 1), (#4 at Handlers.jl:339 [inlined], 1), (macro expansion at Servers.jl:352 [inlined], 1), ((::##13#14{##4#5{RequestHandlerFunction{##6#12}},Transaction{TCPSocket},Stream{Request,Transaction{TCPSocket}}})() at task.jl:259, 1)])) in C:\Users\Robin\.julia\packages\Genie\AxLFn\src\AppServer.jl:71

@Helveg Thanks for letting me know - I'll check it out.
Also, probably won't fix, but it looks like you're not on the latest Genie (nor the latest Julia). It should be in the line of "Server"=>"Genie/0.8.2/Julia/1.1.0"

@Helveg Fixed - available in the newly pushed Genie v0.8.3.
You can either set up an OPTIONS route and handle the request yourself (maybe using the "*" route to catch all OPTION requests) — or do nothing and Genie will respond automatically with the Configuration.Settings.cors_headers Dict (which you can overwrite)

Thanks!


Figure out why PAR occasionally takes 2.5 hours when it normally only takes 30 minutes

@CarlFK just had this happen. It occasionally happens on Travis-CI too.

Since setting PYTHONHASHSEED=0 it seems like this is reasonably reproducible. The following build at https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/jobs/83922006 is reliably hitting this case.

It should no longer happen since buf_fifo of the jpeg encoder is refactored (https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/53)  and was the one using too much ressources.

This issue continues to occur after the buf_fifo has been removed (but less frequently).


Das_Geek: Watch acmethemes(?:@gmail.com)?

Das_Geek requests the watch of the watch_keyword acmethemes(?:@gmail\.com)?. See the MS search here and the Stack Exchange search here.

acmethemes(?:@gmail\.com)? has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Can't link to the question because it was deleted. There was a weird, spam-seedy post on MSE that contained the website and email in the question and answer.

Approved by double-beep in Charcoal HQ

@DasGeek  This watch actually needs to be a bit different. Given that you're also watching acmethemes\.com, this needs to be adjusted so that it does not detect acmethemes\.com.


Matrix entry with fractions failing

As in the MWE here: https://numbas.mathcentre.ac.uk/question/34818/minimal-working-example-fractional-matrices/
Despite the "Allow student to enter fractions" option being ticked, upon submission of an answer for part (b) with fractions in it, student is faced with "Cannot submit answer; check for errors". Will accept and correctly mark if, eg, 0.5 is entered instead of 1/2. Is this a bug, or has the means by which we mark matrices that include fractions moved to the new marking features of NUMBAS v3.0?
My current workaround is, for example, https://numbas.mathcentre.ac.uk/question/34283/simplex-method/ part (b), using a custom JS marking script, but I'm aware this is neither elegant nor in the spirit of the update!
P.S. Apologies for laxity of commenting in variables and/or JS code in my questions.

I've fixed this in f85d0a4dc6e6831b1e5f37941e0bd24b3a2ced6e.
I had indeed forgotten to put the fraction stuff in the new marking algorithm, so I've now put that in, and while I was there I did some more work to match the way number entry parts now behave with respect to precision restrictions.
Thanks for pointing this out, and for the very helpful example.


File isn't declared.

Godot version
4.0 commit e5c5447
System information
Linux 64bit
Issue description
I'm getting this error with a custom build of Godot using the latest commit on master when trying to use File.new().
SCRIPT ERROR: Parse Error: Identifier "File" not declared in the current scope.
Tried building from the commit of the official beta as well and that runs fine.
Steps to reproduce

Build Godot (on Linux) from this commit e5c5447.

Create an empty scene with a script that uses File

Minimal reproduction project
No response

This is intended, File and Directory wrappers have been replaced by directly exposing the underlying FileAccess and DirAccess: #65271.
So you should now use it like var file = FileAccess.open("user://save_game.dat", FileAccess.READ) (see the FileAccess docs in the engine).
I'll pin this issue for others who might be similarly surprised by the change.

Thank you for the info!

there's little purpose to such a wrapper class, the new usage is pretty much identical, just less code:
var file := FileAccess.open(path, FileAccess.READ)
var text := file.get_as_text()


Error with FaceAPI Keys

Getting an error message: Microsoft.ProjectOxford.Face.FaceAPIException: 'Access denied due to invalid subscription key. Make sure you are subscribed to an API you are trying to call and provide the right key.(Unspecified)'. I created a new FaceAPI service on my azure account, and was able to use the keys to run this tutorial successfully: https://docs.microsoft.com/en-us/azure/cognitive-services/Face/tutorials/faceapiincsharptutorial
Does the code here, https://docs.microsoft.com/en-us/azure/cognitive-services/Face/face-api-how-to-topics/howtoidentifyfacesinimage require a different subscription and keys?

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

ID: f5f087f4-64bd-ebda-e5b9-540bf9cd041e
Version Independent ID: 9885cd90-3d7c-1ede-4992-e8408f048d9a
Content: Example: Identify faces in images - Face API - Azure Cognitive Services
Content Source: articles/cognitive-services/Face/Face-API-How-to-Topics/HowtoIdentifyFacesinImage.md
Service: cognitive-services
GitHub Login: @SteveMSFT
Microsoft Alias: sbowles

@JohnStraumann66
We will now proceed to close this thread. If there are further questions regarding this matter, please respond here and @YutongTie-MSFT and we will gladly continue the discussion.


Asymmetric / symmetric encryption

Currently we use an Ed25519 key pair to encrypt/decrypt photos and files, mostly because it was already available in the OB code base, along with the mnemonic phrase mapping for recovery. However, realizing now that's a bit silly since we should treat the public key as public (surprise), and in doing so we'd be letting anyone publish (valid!!) updates to our data rooms.
Here's one solution: a combination of symmetric and asymmetric (encryption + signing). Each room gets a 32 byte key to go with photo/file AES-256 encryption, and then each update is signed with an Ed25519 private key, and then verified with the public key. This solves our glaring security issue.
Another related solution: two Ed25519 key pairs, one for encryption, and one for signing. We should do this if we're foreseeing the need to let 3rd parties encrypt.
As a first pass, I'd like to use the same key pair for encryption and signing... so everything as is now, but we sign the update payload, which is currently just a cid.

closing in favor of #123


optimize: Combine Global and Local

Following some offline discussions with @vladimir-ch , I think optimize.Global and optimize.Local should be combined into a single call, optimize.Minimize. The two function calls use a largely overlapping code and interface at the moment. The two major differences are that 1) Local is only serial 2) Local takes in an initial location while global does not. The second is easily adjusted  by adding a field to Settings, and saying that all 0s is the initial location by default. The first will add a bit of overhead to calls to local, but I think this cost will be made up for by making the optimize package easier to use (a single function rather than two, a single Method interface rather than two, etc.), making there be less code overall, and I suspect there will be significant improvement in the legibility of Local methods that comes along.

A couple weeks ago I spent a bit of time with this. I decided that doing this all at once would be a massive change that would be extremely difficult to review. I suggest a couple of steps

Replace the code in Local with a call to Global, and adding a shell GlobalMethod. Add an InitLocation field to GlobalSettings to allow this to happen
Remove all of the Local specific code, much of this will just be moving to Global
Fix the current Local methods to "natively" use the Global interface
Delete Method, Settings, etc. and rename GlobalMethod to Method etc.

SGTM
On Tue, May 8, 2018, 06:32 Brendan Tracey<EMAIL_ADDRESS>wrote:

A couple weeks ago I spent a bit of time with this. I decided that doing
this all at once would be a massive change that would be extremely
difficult to review. I suggest a couple of steps

Replace the code in Local with a call to Global, and adding a shell
GlobalMethod. Add an InitLocation field to GlobalSettings to allow
this to happen
Remove all of the Local specific code, much of this will just be
moving to Global
Fix the current Local methods to "natively" use the Global interface
Delete Method, Settings, etc. and rename GlobalMethod to Method etc.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gonum/gonum/issues/482#issuecomment-387281294, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABwJvpHNODHGJD3aWHs1U0q_xVXlmkf0ks5twR_tgaJpZM4T1-0L
.

I'm going to update the above list as PRs are submitted and I find things to add to the list


Remove python 3.3 support

xref #219
xref #235

After this is integrated, I will update #219 so that we can move forward.

I restarted the failed jobs. One error seems real: https://github.com/symengine/symengine.py/issues/239, but obviously unrelated to this PR.

@isuruf Considering that the failure of the one test is unrelated, do you think we could move forward with the integration of this PR ?  Thanks

Thanks for the Pr


Refactor(api): Allow presses and increment arguments in engine core when issuing pick-up-tip command

Overview
closes https://opentrons.atlassian.net/browse/RCORE-530.
wire up presses and increment arguments when using pick_up_tip in PAPI via engine/core.
Test Plan
Test Plan (PAPI Change)

Test on an OT-2 and OT-3 with core ff on.
Upload a python protocol and make sure pick-up-tip command works as expected.

from opentrons import protocol_api, types

metadata = {
    "apiLevel": "2.12",
}

def run(ctx: protocol_api.ProtocolContext) -> None:
    tip_rack = ctx.load_labware("opentrons_96_tiprack_300ul", 5)
    pipette = ctx.load_instrument("p20_single_gen2", types.Mount.RIGHT, [tip_rack])
    well = tip_rack.wells()[0]

    # offset the well to something obvious
    # to observe that the offset is not respected
    location = types.Location(point=types.Point(x=9, y=-9, z=0), labware=well)

    pipette.pick_up_tip(location, presses=3, increment=2.0)
    pipette.drop_tip()

POST a basic http pick-up-tip command and make sure it works as expected.

Changelog

Added presses and increment to PickUpTipParams
pass presses and increment from core/engine/instument to engine_client
pass presses and increment from command implementation  to pipette handler.
pass presses and increment from pipette handler to hardware_api.
updated 7.json commands schema with the additional arguments.

Review requests
Changes looks good?
Risk assessment
low. wiring up arguments that are expected but were not implement in the engine/core.

After conversations with @Laura-Danielle and @mcous we will deprecate these fields in PAPI. These properties are configurable via pipette settings and should be changed just for testing purposes.


Can't run on school compute...

Hi, I've been going back and forth with a system admin trying to get this to run, but we can't get passed an OpenGL error. This is is how we installed everything:
module load mesa
module load glfw/3.3.2/b2
module load mujoco/200

git clone git@github.com:facebookresearch/drqv2.git
cd drqv2

conda env create -f conda_env.yml
conda activate drqv2

python train.py task=quadruped_walk

Then this returns the following error no matter what we do:
OpenGL.raw.EGL._errors.EGLError: EGLError(
        err = EGL_BAD_PARAMETER,
        baseOperation = eglGetPlatformDisplayEXT,
        cArguments = (
                12607,
                <OpenGL._opaque.EGLDeviceEXT_pointer object at 0x2ab4078bd240>,
                None,
        ),
        result = <OpenGL._opaque.EGLDisplay_pointer object at 0x2ab4078bd5c0>
)
(/s

Here is what the system admin sent me:
hi Sam unfortunately I’ve had no luck getting this to work besides spending quite a bit of time on it today.  I get the same EGL error unless I’m on a visual node (bhx nodes..)  but if I do everything (including the build/install) on a visual node I get a core dump with Illegal Instruction.   it is possible that’s due to one of the dependencies from pip/conda and if it were compiled from source on a bhx node that might go away but I have no idea which one...
Any ideas?

Glad to hear that!
This command forces to use EGL for rendering. You can find more information here:https://github.com/deepmind/dm_control


support to select deploying server

should support to select deploying server by command arguments.

We can specify deploying server by editing isucontinuous.yaml.
I determined not to support this feature because not declaretive.


ASB Event/Club Sign-in

Done via scanning a QR Code or entering a string.

Closed by 039735567a0fb13486a6eeff6e7d093b67ce078d


[encoded data, 41451 characters]","accessList":null}, error={"reason":"processing response error","code":"SERVER_ERROR","body":"{\"jsonrpc\":\"2.0\",\"id\":45,\"error\":{\"code\":-32000,\"message\":\"out of gas\"}}\n","error":{"code":-32000},"requestBody":"{\"method\":\"eth_call\",\"params\":[{\"to\":\"0x5ba1e12693dc8f9c48aad8770482f4739beed696\",\"data\":\"[encoded data, 86221 characters]


fix robustness test and inference

Fix #2727

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


firebase_dynamic_links: Frequent Crashes on Startup Due to Firebase Initialization Issue

Is there an existing issue for this?

[X] I have searched the existing issues. (https://github.com/firebase/flutterfire/issues/10747)

Which plugins are affected?
Other
Which platforms are affected?
Android
Description
I am experiencing the same issue as reported by @dmitry-fbm in issue #10747. The crash is not reproducible locally, but according to the Google Play Console, 5.5% of our users have encountered this crash in the last 28 days, affecting at least 135 users. There have been no negative ratings mentioning the crash, but the crash rate remains high on Google Play, resulting in reduced visibility in search results.
The response from @Lyokone that helped @dmitry-fbm did not resolve the issue for us.
Main.dart:
await Firebase.initializeApp(
  options: DefaultFirebaseOptions.currentPlatform,
);

Project Configuration:

The project contains the firebase.json file in the project directory.
google-services.json is in android/app.
GoogleService-Info.plist is in ios/Runner.
ios/firebase_app_id_file.json is present.

Versions:

Flutter: 3.22.2
flutterfire_cli: 1.0.0
firebase_core: 2.32.0
firebase_dynamic_links: 5.5.7

Reproducing the issue
Could not reproduce
Firebase Core version
2.30.0
Flutter Version
3.22.2
Relevant Log Output
Exception java.lang.RuntimeException:
  at android.app.ActivityThread.performResumeActivity (ActivityThread.java:4657)
  at android.app.ActivityThread.handleResumeActivity (ActivityThread.java:4690)
  at android.app.servertransaction.ResumeActivityItem.execute (ResumeActivityItem.java:52)
  at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2267)
  at android.os.Handler.dispatchMessage (Handler.java:107)
  at android.os.Looper.loop (Looper.java:237)
  at android.app.ActivityThread.main (ActivityThread.java:8167)
  at java.lang.reflect.Method.invoke
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:496)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1100)
Caused by java.lang.IllegalStateException:
  at com.google.firebase.FirebaseApp.getInstance (FirebaseApp.java)
  at com.google.firebase.dynamiclinks.FirebaseDynamicLinks.getInstance (FirebaseDynamicLinks.java)
  at io.flutter.plugins.firebase.dynamiclinks.FlutterFirebaseDynamicLinksPlugin.getDynamicLinkInstance (FlutterFirebaseDynamicLinksPlugin.java)
  at io.flutter.plugins.firebase.dynamiclinks.FlutterFirebaseDynamicLinksPlugin.onNewIntent (FlutterFirebaseDynamicLinksPlugin.java)
  at io.flutter.embedding.engine.FlutterEngineConnectionRegistry$FlutterEngineActivityPluginBinding.onNewIntent (FlutterEngineConnectionRegistry.java)
  at io.flutter.embedding.engine.FlutterEngineConnectionRegistry.onNewIntent (FlutterEngineConnectionRegistry.java)
  at io.flutter.embedding.android.FlutterActivityAndFragmentDelegate.onNewIntent (FlutterActivityAndFragmentDelegate.java)
  at io.flutter.embedding.android.FlutterActivity.onNewIntent (FlutterActivity.java)
  at android.app.Activity.performNewIntent (Activity.java:7977)
  at android.app.Instrumentation.callActivityOnNewIntent (Instrumentation.java:1407)
  at android.app.Instrumentation.callActivityOnNewIntent (Instrumentation.java:1420)
  at android.app.ActivityThread.deliverNewIntents (ActivityThread.java:3869)
  at android.app.ActivityThread.performResumeActivity (ActivityThread.java:4640)

Flutter dependencies

Expand Flutter dependencies snippet

- firebase_analytics 10.10.7 [firebase_analytics_platform_interface firebase_analytics_web firebase_core firebase_core_platform_interface flutter]
- firebase_auth 4.20.0 [firebase_auth_platform_interface firebase_auth_web firebase_core firebase_core_platform_interface flutter meta]
- firebase_core 2.32.0 [firebase_core_platform_interface firebase_core_web flutter meta]
- firebase_crashlytics 3.5.7 [firebase_core firebase_core_platform_interface firebase_crashlytics_platform_interface flutter stack_trace]
- firebase_dynamic_links 5.5.7 [firebase_core firebase_core_platform_interface firebase_dynamic_links_platform_interface flutter meta plugin_platform_interface]
- firebase_in_app_messaging 0.7.5+7 [firebase_core firebase_core_platform_interface firebase_in_app_messaging_platform_interface flutter meta]

firebase_options.dart firebase_options.dart  snippet

import 'package:firebase_core/firebase_core.dart' show FirebaseOptions;
import 'package:flutter/foundation.dart'
    show defaultTargetPlatform, kIsWeb, TargetPlatform;

/// Default [FirebaseOptions] for use with your Firebase apps.
///
/// Example:
/// ```dart
/// import 'firebase_options.dart';
/// // ...
/// await Firebase.initializeApp(
///   options: DefaultFirebaseOptions.currentPlatform,
/// );
/// ```
class DefaultFirebaseOptions {
  static FirebaseOptions get currentPlatform {
    if (kIsWeb) {
      throw UnsupportedError(
        'DefaultFirebaseOptions have not been configured for web - '
        'you can reconfigure this by running the FlutterFire CLI again.',
      );
    }
    switch (defaultTargetPlatform) {
      case TargetPlatform.android:
        return android;
      case TargetPlatform.iOS:
        return ios;
      case TargetPlatform.macOS:
        throw UnsupportedError(
          'DefaultFirebaseOptions have not been configured for macos - '
          'you can reconfigure this by running the FlutterFire CLI again.',
        );
      case TargetPlatform.windows:
        throw UnsupportedError(
          'DefaultFirebaseOptions have not been configured for windows - '
          'you can reconfigure this by running the FlutterFire CLI again.',
        );
      case TargetPlatform.linux:
        throw UnsupportedError(
          'DefaultFirebaseOptions have not been configured for linux - '
          'you can reconfigure this by running the FlutterFire CLI again.',
        );
      default:
        throw UnsupportedError(
          'DefaultFirebaseOptions are not supported for this platform.',
        );
    }
  }

  static const FirebaseOptions android = FirebaseOptions(
    apiKey: '*****',
    appId: '******',
    messagingSenderId: '******',
    projectId: '******',
    databaseURL: '****.firebaseio.com',
    storageBucket: '******.appspot.com',
  );

  static const FirebaseOptions ios = FirebaseOptions(
    apiKey: '*****',
    appId: '*****',
    messagingSenderId: '******',
    projectId: '*****',
    databaseURL: '****.firebaseio.com',
    storageBucket: '****appspot.com',
    androidClientId: '*****.apps.googleusercontent.com',
    iosClientId: '*******.apps.googleusercontent.com',
    iosBundleId: '****',
  );
}

Hey @LeonManolo - dynamic links has been deprecated and is no longer actively maintained. The service will be shut down next year, August 2025. See this link. I'd advise migrating away from dynamic links, here is the documentation of deep linking in Flutter.