text:
Normalized (not pixel-sized) orthographic projection

It is a common use case for 2D games to have an orthographic projection that scales the world to the window (so the same content is always displayed, regardless of window size).
One logical/sensible way to define such a projection is to make Y span -1.0..1.0 (if 0.0 is at the center of the screen) or 0.0..1.0 (if 0.0 is at the bottom left). To not stretch the image, X is then scaled to the aspect ratio.
This results in the same amount of content displayed vertically, regardless of aspect ratio, but a variable amount of content horizontally.
There are other possible ways to do it, but this seems like a simple and sane approach that should suit most people.
Other things we need to discuss:
Naming? Now that there are two built-in orthographic projection types, they need to be named clearly. Perhaps the old OrthographicProjection should be renamed to make it clear that it is pixel-sized? I would guess that both usecases would be roughly equally commonly desired, so one should not feel more difficult to use than the other.
What should we do with the Camera2dComponents bundle? It should be made easy for the user to select either projection.

Could you make this an external crate instead? It wouldn't need to be fancy

Could you make this an external crate instead? It wouldn't need to be fancy

Yeah an external crate would be easier to prove out an approach. Non-pixel-sized rendering is absolutely something we need in bevy, theres just many ways to do it (ex: render to texture, fit to screen, add letterboxing)

Yeah an external crate would be easier to prove out an approach. Non-pixel-sized rendering is absolutely something we need in bevy, theres just many ways to do it (ex: render to texture, fit to screen, add letterboxing)

@DJMcNab thanks for digging out this PR! i had kinda forgotten about it. sure, i'll move this to a separate crate, to make it usable for people who want it
(assuming @cart isn't interested in merging it (it is a pretty simple thing that IMO should be built into bevy), or i'll rebase/update this PR instead)

render to texture

that sounds very heavyweight for something that can be easily solved with different values on the orthographic projection, like shown in this PR
ofc nothing is stopping people from rendering to texture, if they have other benefits from that (like postprocessing effects)
i think a simple/normalized orthographic projection like this PR proposes should be merged into bevy regardless

add letterboxing

yes, this could be a useful addition, to limit the aspect ratio
otherwise, games need to take into consideration that some players might try to run them on ultrawide monitors or other funky aspect ratios, which might lead to undesirable effects
but that is separate from this issue; control over the aspect ratio (letterboxing) should be useful regardless of whether your projection is pixel-sized or normalized

prove out an approach
theres just many ways to do it

really? i don't like to plainly dismiss conversations, but i don't think this is that controversial; this is the simplest way to do it and i can't see why other approaches would be preferred
i think this normalized projection should be offered by bevy regardless
although, perhaps it would be useful to add an option to choose which axis to fix it to (whether X or Y should be mapped to -1.0 .. 1.0), because games intended to be played in portrait mode (like mobile games) might want to choose to keep the horizonal axis fixed, rather than the vertical.

@DJMcNab thanks for digging out this PR! i had kinda forgotten about it. sure, i'll move this to a separate crate, to make it usable for people who want it
(assuming @cart isn't interested in merging it (it is a pretty simple thing that IMO should be built into bevy), or i'll rebase/update this PR instead)

render to texture

that sounds very heavyweight for something that can be easily solved with different values on the orthographic projection, like shown in this PR
ofc nothing is stopping people from rendering to texture, if they have other benefits from that (like postprocessing effects)
i think a simple/normalized orthographic projection like this PR proposes should be merged into bevy regardless

add letterboxing

yes, this could be a useful addition, to limit the aspect ratio
otherwise, games need to take into consideration that some players might try to run them on ultrawide monitors or other funky aspect ratios, which might lead to undesirable effects
but that is separate from this issue; control over the aspect ratio (letterboxing) should be useful regardless of whether your projection is pixel-sized or normalized

prove out an approach
theres just many ways to do it

really? i don't like to plainly dismiss conversations, but i don't think this is that controversial; this is the simplest way to do it and i can't see why other approaches would be preferred
i think this normalized projection should be offered by bevy regardless
although, perhaps it would be useful to add an option to choose which axis to fix it to (whether X or Y should be mapped to -1.0 .. 1.0), because games intended to be played in portrait mode (like mobile games) might want to choose to keep the horizonal axis fixed, rather than the vertical.

BTW, can i somehow change the branch in my fork that this PR is based on? I shouldn't have made the changes in master ...

BTW, can i somehow change the branch in my fork that this PR is based on? I shouldn't have made the changes in master ...

You can't change the head branch of a PR, unfortunately
One approach would be to main as your new main branch for the time being.

You can't change the head branch of a PR, unfortunately
One approach would be to main as your new main branch for the time being.

The current OrthographicProjection is mostly in-tree only for UI and 2d purposes, where 1 pixel = 1unit is sensible.
But the space for other kinds of orthographic projections is big enough that we don't want to support them all in-tree at this early stage moment (even just the suggestions of fixed-x, fixed-y, letterboxing). That is, if someone wants to use an orthographic projection in their game, then a good enough solution would be to just apply a 1./100. scale to their camera entity, which has the effect of making the 'virtual screen' smaller, i.e. making objects appear larger. I think that the gap between that being good enough and this solution being flexible enough is likely to be too small at the moment.
That is, this mechanism is probably a bit too niché to be in-engine at the moment, as orthographic games are relatively rare. Although if we did find that the external crate was seeing widespread adoption we'd certainly reconsider.
(Usage of we here is more in a general sense, since I can't speak officially)

The current OrthographicProjection is mostly in-tree only for UI and 2d purposes, where 1 pixel = 1unit is sensible.
But the space for other kinds of orthographic projections is big enough that we don't want to support them all in-tree at this early stage moment (even just the suggestions of fixed-x, fixed-y, letterboxing). That is, if someone wants to use an orthographic projection in their game, then a good enough solution would be to just apply a 1./100. scale to their camera entity, which has the effect of making the 'virtual screen' smaller, i.e. making objects appear larger. I think that the gap between that being good enough and this solution being flexible enough is likely to be too small at the moment.
That is, this mechanism is probably a bit too niché to be in-engine at the moment, as orthographic games are relatively rare. Although if we did find that the external crate was seeing widespread adoption we'd certainly reconsider.
(Usage of we here is more in a general sense, since I can't speak officially)

Correct me if I am wrong, but letterboxing cannot be done with projection/camera parameters alone, right?
It needs to be done by adjusting the viewport (in opengl terms, idk if modern apis have that), or something else in the render pipeline, correct?

Correct me if I am wrong, but letterboxing cannot be done with projection/camera parameters alone, right?
It needs to be done by adjusting the viewport (in opengl terms, idk if modern apis have that), or something else in the render pipeline, correct?

Yeah, I don't think letterboxing is a projection issue as such.

I updated the PR with some new commits to implement these extra features.
It seems like a very simple thing to attach to this implementation.

But the space for other kinds of orthographic projections is big enough

I think this already covers basically all uses for a scaled orthographic projection. It's not that big, as you can see it can very easily be covered by a single projection type with a few configurable parameters.

letterboxing

Again, isn't that a separate feature / irrelevant to this PR?

I updated the PR with some new commits to implement these extra features.
It seems like a very simple thing to attach to this implementation.

But the space for other kinds of orthographic projections is big enough

I think this already covers basically all uses for a scaled orthographic projection. It's not that big, as you can see it can very easily be covered by a single projection type with a few configurable parameters.

letterboxing

Again, isn't that a separate feature / irrelevant to this PR?

Yeah, I don't think letterboxing is a projection issue as such.

Also added a commit for a new general orthographic camera bundle, using this new projection.
IDK if the same "far" trick as found in the Camera2dBundle makes sense here, see the note in the commit.

Also added a commit for a new general orthographic camera bundle, using this new projection.
IDK if the same "far" trick as found in the Camera2dBundle makes sense here, see the note in the commit.

I always forget to run cargo fmt before committing, sorry for the duplicate commits / force push.

I always forget to run cargo fmt before committing, sorry for the duplicate commits / force push.

Letterboxing / fixed non-pixel sized scales

I'll admit that these aren't identical solves and I that I was thinking too much about a specific application of "non-pixel sized scales" in my last comment. The "render to texture" / letterboxing / scale-to-fit approach I mentioned doesn't handle "dynamic" orthographic scaling or projection scaling where the "output" image should not be scaled. There are legitimate use cases for that (which have been discussed above).
That set of use cases is common enough that its worth supporting in-tree and I agree that (other than surface level api stuff) the implementation is not particularly controversial.
I'll do another pass and start thinking about the problem in general.
Off the top of my head: Before creating a new bundle, I think its worth discussing alternatives. The "most interesting" one i can think of is:

Rename Camera3dBundle to PerspectiveCameraBundle. Rename Camera2dBundle to OrthographicCameraBundle. Delete CameraUiBundle.
Add 2d() and 3d() constructors to each bundle. Add ui() constructor to OrthographicCameraBundle. Internally these constructors set the camera name to the relevant value. By doing this we have decoupled the Camera bundles from their render pipelines and reduced the need to fork out new "basically identical" bundles.
Add "scale" directly to OrthographicProjection. This type of field is common on orthographic projections:

blender (orthographic scale)
godot (size)

Letterboxing / fixed non-pixel sized scales

I'll admit that these aren't identical solves and I that I was thinking too much about a specific application of "non-pixel sized scales" in my last comment. The "render to texture" / letterboxing / scale-to-fit approach I mentioned doesn't handle "dynamic" orthographic scaling or projection scaling where the "output" image should not be scaled. There are legitimate use cases for that (which have been discussed above).
That set of use cases is common enough that its worth supporting in-tree and I agree that (other than surface level api stuff) the implementation is not particularly controversial.
I'll do another pass and start thinking about the problem in general.
Off the top of my head: Before creating a new bundle, I think its worth discussing alternatives. The "most interesting" one i can think of is:

Rename Camera3dBundle to PerspectiveCameraBundle. Rename Camera2dBundle to OrthographicCameraBundle. Delete CameraUiBundle.
Add 2d() and 3d() constructors to each bundle. Add ui() constructor to OrthographicCameraBundle. Internally these constructors set the camera name to the relevant value. By doing this we have decoupled the Camera bundles from their render pipelines and reduced the need to fork out new "basically identical" bundles.
Add "scale" directly to OrthographicProjection. This type of field is common on orthographic projections:

blender (orthographic scale)
godot (size)

The downside to the approach above is adding cameras from the editor. I expect Bundles to have a nice "autocomplete" ui for codeless scene composition (think godot "nodes"). Separate bundles for each context would mean that you could easily search for a CameraUiBundle and add it to a scene.
If we decouple bundles from 2d/3d contexts, it adds an extra step where you need to manually select the camera name in the editor.

The downside to the approach above is adding cameras from the editor. I expect Bundles to have a nice "autocomplete" ui for codeless scene composition (think godot "nodes"). Separate bundles for each context would mean that you could easily search for a CameraUiBundle and add it to a scene.
If we decouple bundles from 2d/3d contexts, it adds an extra step where you need to manually select the camera name in the editor.

@cart Ok, so now that we are discussing the camera bundles, I want to bring up some points:

If we decouple bundles from 2d/3d contexts, it adds an extra step where you need to manually select the camera name in the editor.

I think that is actually a good thing, both for the editor and for the code API ...

Add 2d() and 3d() constructors to each bundle. Add ui() constructor to OrthographicCameraBundle. Internally these constructors set the camera name to the relevant value. By doing this we have decoupled the Camera bundles from their render pipelines and reduced the need to fork out new "basically identical" bundles.

... we should also add a constructor that lets the user specify a custom camera name.
Here is the motivation:
As it is, only trivial games with a single camera for main rendering can use the existing bundles.
There are many use cases for having multiple cameras for more advanced rendering / render passes. For example, a friend of mine is currently working on a FPS game, and he will want to have a separate camera and render pass for rendering the gun/hands in front of the player in the first person view, or for the view inside of the scope of a weapon.
Right now, Bevy's bundles are useless for these secondary cameras, because there is no way to specify a custom name. It is necessary to either spawn the camera without using a bundle (just as a tuple of components), or roll your own bundle. This can be error-prone.
If there was a general PerspectiveCameraBundle that allowed the user to specify the name, it would be useful for these secondary cameras too. Ditto for having some sort of name selection UI in the editor.
Of course, the default 3D/2D camera should have its own special constructor.
This fits nicely here, as we are discussing decoupling 2D/3D from the type of camera anyway.

Rename Camera3dBundle to PerspectiveCameraBundle. Rename Camera2dBundle to OrthographicCameraBundle.

I like this.

Delete CameraUiBundle.

I don't like this. I think we should keep it, just for clarity. It is nice for users to be able to just easily spawn their "ui camera" without knowing what it really is.

Add "scale" directly to OrthographicProjection.

I hadn't considered this. Now that I think about it, I like it, because it would make the two types of orthographic projection more similar and unify their feature-set. Then, the choice of projection for the user becomes simply:

Do I want a pixel sized projection that scales with window size? (the old one)
Do I want to fit the same content to the screen, regardless of window size? (the new one)

That said -- some more bikeshedding:
I don't like the current names: Orthographic and ScaledOrthographic, at all. They are confusing. What is being scaled? The names could easily be swapped around and they would be equally ambiguous.
(actually, if i were to go by my intuition, I'd call the old projection "scaled" (because it scales with the window) and the new one the normal, because it is fixed and behaves similarly to the perspective projection)
Also, the simple name Orthographic implies that it should be the default, and the longer name of the other one implies that it is somehow more specialized.
I think we should come up with new names for both of the projections, to clearly indicate the difference.
Some suggestions for names:

for the old one: WindowOrthographic, PixelOrthographic, or maybe even ScaledOrthographic
for the new one: maybe FixedOrthographic or SimpleOrthographic?

(the words could also be swapped: OrthographicSimple, OrthographicPixel, but I think that's worse)
I don't particularly like any of these names that much, let me know what you think or if you have better suggestions.

@cart Ok, so now that we are discussing the camera bundles, I want to bring up some points:

If we decouple bundles from 2d/3d contexts, it adds an extra step where you need to manually select the camera name in the editor.

I think that is actually a good thing, both for the editor and for the code API ...

Add 2d() and 3d() constructors to each bundle. Add ui() constructor to OrthographicCameraBundle. Internally these constructors set the camera name to the relevant value. By doing this we have decoupled the Camera bundles from their render pipelines and reduced the need to fork out new "basically identical" bundles.

... we should also add a constructor that lets the user specify a custom camera name.
Here is the motivation:
As it is, only trivial games with a single camera for main rendering can use the existing bundles.
There are many use cases for having multiple cameras for more advanced rendering / render passes. For example, a friend of mine is currently working on a FPS game, and he will want to have a separate camera and render pass for rendering the gun/hands in front of the player in the first person view, or for the view inside of the scope of a weapon.
Right now, Bevy's bundles are useless for these secondary cameras, because there is no way to specify a custom name. It is necessary to either spawn the camera without using a bundle (just as a tuple of components), or roll your own bundle. This can be error-prone.
If there was a general PerspectiveCameraBundle that allowed the user to specify the name, it would be useful for these secondary cameras too. Ditto for having some sort of name selection UI in the editor.
Of course, the default 3D/2D camera should have its own special constructor.
This fits nicely here, as we are discussing decoupling 2D/3D from the type of camera anyway.

Rename Camera3dBundle to PerspectiveCameraBundle. Rename Camera2dBundle to OrthographicCameraBundle.

I like this.

Delete CameraUiBundle.

I don't like this. I think we should keep it, just for clarity. It is nice for users to be able to just easily spawn their "ui camera" without knowing what it really is.

Add "scale" directly to OrthographicProjection.

I hadn't considered this. Now that I think about it, I like it, because it would make the two types of orthographic projection more similar and unify their feature-set. Then, the choice of projection for the user becomes simply:

Do I want a pixel sized projection that scales with window size? (the old one)
Do I want to fit the same content to the screen, regardless of window size? (the new one)

That said -- some more bikeshedding:
I don't like the current names: Orthographic and ScaledOrthographic, at all. They are confusing. What is being scaled? The names could easily be swapped around and they would be equally ambiguous.
(actually, if i were to go by my intuition, I'd call the old projection "scaled" (because it scales with the window) and the new one the normal, because it is fixed and behaves similarly to the perspective projection)
Also, the simple name Orthographic implies that it should be the default, and the longer name of the other one implies that it is somehow more specialized.
I think we should come up with new names for both of the projections, to clearly indicate the difference.
Some suggestions for names:

for the old one: WindowOrthographic, PixelOrthographic, or maybe even ScaledOrthographic
for the new one: maybe FixedOrthographic or SimpleOrthographic?

(the words could also be swapped: OrthographicSimple, OrthographicPixel, but I think that's worse)
I don't particularly like any of these names that much, let me know what you think or if you have better suggestions.

I think that is actually a good thing, both for the editor and for the code API ...

I don't think its clear cut for the editor. I think the "constructor approach" is almost certainly better for the in-code api. And as long as the bundle defaults are as expected (ex: Perspective defaults to 3d pipelines, Ortho defaults to 2d pipelines) we're probably good on the editor side. But imo Camera2d and Camera3d (with configurable projections) is really nice (and visually self-documenting) in the editor. It felt very natural to me. Of course consistency is important so we shouldn't do one thing in code and another thing in the editor.
I'm cool with continuing this discussion here, but we can also table it if you'd prefer to just extend the Orthographic projection with a scale property in this pr.

... we should also add a constructor that lets the user specify a custom camera name.

I agree

Right now, Bevy's bundles are useless for these secondary cameras, because there is no way to specify a custom name

This is false:
.spawn(Camera3dBundle {
    camera: Camera {
        name: Some("custom name".to_string()),
        ..Default::default()
    },
    ..Default::default()
});

I don't like this. I think we should keep it, just for clarity and ergonomics. It is nice for users to be able to just easily spawn their "ui camera" without knowing what it really is.

How is the UI camera case any different from the 2d/3d case? They seem identical to me. If OrthographicCamera::2d() and OrthographicCamera::3d() is the "right" way to distinguish between the two, imo that should also be true for ui.
However on the topic of UI camera ergonomics, ideally we just don't require the UI camera (and fall back internally). The percentage of people who need to move the "ui camera" is almost zero.

I don't like the current names: Orthographic and ScaledOrthographic, at all. They are confusing. What is being scaled? The names could easily be swapped around and they would be equally ambiguous.

When I said "add "scale" directly to OrthographicProjection", I meant that we would have a single consolidated OrthographicProjection. Window width and height would be the base "scale == 1". This is how both blender and godot handle it, and I think thats the best behavior for something named OrthographicProjection. This satisfies the common use case of providing a "zoomable camera".
The "corner case" of ignoring pixel size entirely could be handled by any of these:

dividing the "scale" by something like window height (works without adding a new projection)
adding a custom projection / bundle
using "output scaling" (ex: rendering to a texture / letterboxing) if you really want to code to a specific "pixel size".

I think that is actually a good thing, both for the editor and for the code API ...

I don't think its clear cut for the editor. I think the "constructor approach" is almost certainly better for the in-code api. And as long as the bundle defaults are as expected (ex: Perspective defaults to 3d pipelines, Ortho defaults to 2d pipelines) we're probably good on the editor side. But imo Camera2d and Camera3d (with configurable projections) is really nice (and visually self-documenting) in the editor. It felt very natural to me. Of course consistency is important so we shouldn't do one thing in code and another thing in the editor.
I'm cool with continuing this discussion here, but we can also table it if you'd prefer to just extend the Orthographic projection with a scale property in this pr.

... we should also add a constructor that lets the user specify a custom camera name.

I agree

Right now, Bevy's bundles are useless for these secondary cameras, because there is no way to specify a custom name

This is false:
.spawn(Camera3dBundle {
    camera: Camera {
        name: Some("custom name".to_string()),
        ..Default::default()
    },
    ..Default::default()
});

I don't like this. I think we should keep it, just for clarity and ergonomics. It is nice for users to be able to just easily spawn their "ui camera" without knowing what it really is.

How is the UI camera case any different from the 2d/3d case? They seem identical to me. If OrthographicCamera::2d() and OrthographicCamera::3d() is the "right" way to distinguish between the two, imo that should also be true for ui.
However on the topic of UI camera ergonomics, ideally we just don't require the UI camera (and fall back internally). The percentage of people who need to move the "ui camera" is almost zero.

I don't like the current names: Orthographic and ScaledOrthographic, at all. They are confusing. What is being scaled? The names could easily be swapped around and they would be equally ambiguous.

When I said "add "scale" directly to OrthographicProjection", I meant that we would have a single consolidated OrthographicProjection. Window width and height would be the base "scale == 1". This is how both blender and godot handle it, and I think thats the best behavior for something named OrthographicProjection. This satisfies the common use case of providing a "zoomable camera".
The "corner case" of ignoring pixel size entirely could be handled by any of these:

dividing the "scale" by something like window height (works without adding a new projection)
adding a custom projection / bundle
using "output scaling" (ex: rendering to a texture / letterboxing) if you really want to code to a specific "pixel size".

Also, it looks like cameras don't actually update when Camera is mutated (only when the window is resized). We'll need to fix that if we add a scale field. (we should fix it anyway :smile: )

Also, it looks like cameras don't actually update when Camera is mutated (only when the window is resized). We'll need to fix that if we add a scale field. (we should fix it anyway :smile: )

The "corner case" of ignoring pixel size entirely ...

We seem to disagree about whether this is a "corner case". I don't think it is. A projection that fits the same content on screen regardless of window resizing seems to me like a common thing to want. That's why I set out to make this PR (and the OP got so many hearts :D ).

... could be handled by any of these:
...

Then we are back to where we started.
That is, having to do specialized trickery with the camera / projection / transform to account for the window size.
Rather than having it simply work out of the box.

The "corner case" of ignoring pixel size entirely ...

We seem to disagree about whether this is a "corner case". I don't think it is. A projection that fits the same content on screen regardless of window resizing seems to me like a common thing to want. That's why I set out to make this PR (and the OP got so many hearts :D ).

... could be handled by any of these:
...

Then we are back to where we started.
That is, having to do specialized trickery with the camera / projection / transform to account for the window size.
Rather than having it simply work out of the box.

How is the UI camera case any different from the 2d/3d case?

UI is kinda "special", conceptually. It's not really part of the game world, but a separate thing on top.
When you make your game, you build your game world, and you build your UI, they are separate parts of the game design and implementation.
I guess to me it feels special, so my intuition says it should have an independent API, rather than reusing the one for the game camera, but that's subjective. I can totally understand the opposite argument.
I don't want to continue this discussion about the UI Bundle. If you think we should remove it and unify it with the orthographic bundle, I'm fine with that.

How is the UI camera case any different from the 2d/3d case?

UI is kinda "special", conceptually. It's not really part of the game world, but a separate thing on top.
When you make your game, you build your game world, and you build your UI, they are separate parts of the game design and implementation.
I guess to me it feels special, so my intuition says it should have an independent API, rather than reusing the one for the game camera, but that's subjective. I can totally understand the opposite argument.
I don't want to continue this discussion about the UI Bundle. If you think we should remove it and unify it with the orthographic bundle, I'm fine with that.

@cart I figured out how to make this even better. I think you will like the new changes.
I made some updates based on the things we talked about:

Camera Bundle changes:

Rename camera bundles to PerspectiveCameraBundle and OrthographicCameraBundle.
OrthographicCameraBundle has constructors for the various use cases we talked about: new_3d, new_2d, and with_name. I removed the Default implementation, as the camera is used for both 3D and 2D and I don't think it makes sense to pick either one as the "default".
PerspectiveCameraBundle keeps its Default implementation (as this camera is specifically used for 3D). I also added new_3d and with_name constructors, just for consistency with the API of OrthographicCameraBundle.

Unify the orthographic projections!

I had the epiphany that the scaling behavior could be made selectable with an enum field, rather than having 2 separate projection types!
I like it this way a lot more, and I think you will, too. :smile:
Now there is a single orthographic projection type, with a scaling mode field, and a scale field.

UI camera

I did not remove the bundle, because I wasn't sure what to do about the crate boundaries. CameraUiBundle is defined in the bevy_ui crate, as well as the camera name that it uses. To unify it with OrthographicCameraBundle, the camera name constant and the constructor would need to be in the bevy_render crate.
I renamed CameraUiBundle to UiCameraBundle, for symmetry with the other bundle names.

@cart I figured out how to make this even better. I think you will like the new changes.
I made some updates based on the things we talked about:

Camera Bundle changes:

Rename camera bundles to PerspectiveCameraBundle and OrthographicCameraBundle.
OrthographicCameraBundle has constructors for the various use cases we talked about: new_3d, new_2d, and with_name. I removed the Default implementation, as the camera is used for both 3D and 2D and I don't think it makes sense to pick either one as the "default".
PerspectiveCameraBundle keeps its Default implementation (as this camera is specifically used for 3D). I also added new_3d and with_name constructors, just for consistency with the API of OrthographicCameraBundle.

Unify the orthographic projections!

I had the epiphany that the scaling behavior could be made selectable with an enum field, rather than having 2 separate projection types!
I like it this way a lot more, and I think you will, too. :smile:
Now there is a single orthographic projection type, with a scaling mode field, and a scale field.

UI camera

I did not remove the bundle, because I wasn't sure what to do about the crate boundaries. CameraUiBundle is defined in the bevy_ui crate, as well as the camera name that it uses. To unify it with OrthographicCameraBundle, the camera name constant and the constructor would need to be in the bevy_render crate.
I renamed CameraUiBundle to UiCameraBundle, for symmetry with the other bundle names.

@cart is there anything more to do here? or is this PR ready for merging?

@cart is there anything more to do here? or is this PR ready for merging?

I like it this way a lot more, and I think you will, too

Yup this is much better!
I dig all of the changes. My only nit is that I would prefer things like OrthographicProjection::2d() instead of OrthographicProjection::new_2d(). I think it looks/reads better, and there is precedence for that pattern (ex: glam uses it in some places). The new_x convention isn't used anywhere in the standard library that I know of, so this is a gray zone anyway.

I like it this way a lot more, and I think you will, too

Yup this is much better!
I dig all of the changes. My only nit is that I would prefer things like OrthographicProjection::2d() instead of OrthographicProjection::new_2d(). I think it looks/reads better, and there is precedence for that pattern (ex: glam uses it in some places). The new_x convention isn't used anywhere in the standard library that I know of, so this is a gray zone anyway.

@cart I wanted to call them 2d instead of new_2d, too. I agree it would have looked nicer.
However, Rust identifiers cannot start with a digit. :laughing: I got a compiler error.
Hence the current names.

@cart I wanted to call them 2d instead of new_2d, too. I agree it would have looked nicer.
However, Rust identifiers cannot start with a digit. :laughing: I got a compiler error.
Hence the current names.

::d2() 🤔

::d2() 🤔

So if there is no other criticism, can we merge this?

So if there is no other criticism, can we merge this?

Sounds like a plan!

Sounds like a plan!

If I was previously using in 0.4:
let camera = Camera2dBundle::default();
is the equivalent upgrade in 0.5 simply:
let camera = OrthographicCameraBundle::new_2d();?

authors: DJMcNab cart jamadazi johnpmayer


text:
Size::height sets width not height

Objective
pub const fn height(width: Val) -> Self {
        Self {
            width,
            height: Val::DEFAULT,
        }
    }

:sweat:
Solution
Swap width and height.

Can you rebase to give better clarity + fix conflicts?

Can you rebase to give better clarity + fix conflicts?

I tried, is this right now?

source: gharchive/pull-request

authors: alice-i-cecile ickshonpe

repo: bevyengine/bevy

license_type: permissive

license_source: github-api


text:
fix(shim-plugin): Skip source maps when shimming

Closes #11

Codecov Report

Merging #14 (7393712) into main (665a948) will increase coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #14      +/-   ##
==========================================
+ Coverage   93.07%   93.15%   +0.08%
==========================================
  Files          21       21
  Lines         491      497       +6
  Branches       43       45       +2
==========================================
+ Hits          457      463       +6
  Misses         34       34

Impacted Files
Coverage Δ

src/lib/plugins/shim.plugin.ts
100.00% <100.00%> (ø)

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

authors: beyerleinf codecov-commenter

repo: beyerleinf/esbuild-azure-functions

license: MIT


text:
fix: cluster worker tests

Description
fix: cluster worker tests
Verification Steps
Confirm that CI passes
Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has been created for changes required on the client side

Thanks for the quick fix @pawelpaszki


text:
ci: add workflow dispatch for manual running of update-openapi-spec w…

…orkflow

Description

Verification Steps

Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has been created for changes required on the client side

Hi @dimakis could you describe what is the effect / meaning of this?

Hey @miguelsorianod, so we are refactoring our SDKs and using the app-services-core SDK as our single source of truth for all openAPI spec files. This needed to be added to the openapi_update WF. The problem was the previous token did not have access to the app-services-core SDK repo. In order to update and test the new token, I enabled the manual running of those jobs with this PR.
There are still some issues, as we are now using a different type of token but as soon as those issues are resolved, these changes can be removed.

authors: dimakis miguelsorianod


text:
feat(certs): perform certificate management in async mannner

Description

The sync management of certificate can take 20s and up to a minute for each domain. If we've a large que of Kafkas this might problematic as the last Kafkas will see its certificate being processed after (20-60)s * numberOfKafkas. Since the processing of each domain is independent, we cna make the generation of a certificate async.
This follows up on https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/1620 & https://github.com/bf2fc6cc711aee1a0c2a/kas-fleet-manager/pull/1621
Verification Steps

Checklist (Definition of Done)

[ ] All acceptance criteria specified in JIRA have been completed
[ ] Unit and integration tests added that prove the fix is effective or the feature works (tested against emulated and non-emulated OCM environment)
[ ] Documentation added for the feature
[ ] CI and all relevant tests are passing
[ ] Code Review completed
[ ] Verified independently by reviewer
[ ] All PR comments are resolved either by addressing them or creating follow up tasks
[ ] Required metrics/dashboards/alerts have been added (or PR created).
[ ] Required Standard Operating Procedure (SOP) is added.
[ ] JIRA has been created for changes required on the client side

@miguelsorianod this is based on our latest investigation. Can you've a look? Thanks

@ziccardi @JameelB @miguelsorianod this should be ready for another round of reviews

One of the flaws of this implementation is that nothing prevents two pods in the KFM deployment to request the same certificate issue.
The locking mechanism implemented prevents the same certificate to be issued twice in the context of the KFM process. However, multiple pods run in different processes and therefore that locking mechanism does not apply between them.
It is true that KFM makes use of a leader election mechanism that prevents 2 pods from running simultaneously. However, there are other scenarios where multiple pods are involved, with only 1 being leader, where a simultanous certificate issuing might happen.
Example:
Sequence of events having 2 KFM Pods A, B:

Pod A reconciles is leader calls manage async and locks the name
We perform a deploy of a new KFM version
Pod B becomes leader
Pod B reconciles and calls manage async because even though pod A locked the name, that lock was stored in local Pod A storage

The way to solve that would be having some centralized synchronization point so we have a distribution lock mechanism that the pods make use of. For example, one option would be centralizing it at database level similarly to what is done with the leader election mechanism locks.
cc @machi1990 to try to understand better the implications, what happens if the same certificate issuing request is executed twice simultaneously? would we end up with 2 certificates? or one would end up erroring, or both?
Depending on what are the implications we can decide to go forward with the local implementation assuming this might happen in some scenarios and implement later the distributed locking mechanism.

to try to understand better the implications, what happens if the same certificate issuing request is executed twice simultaneously? would we end up with 2 certificates? or one would end up erroring, or both?

Thanks, without locking in place the implication is that there will be more than one certificate request for the same wildcard domain:
* this means a few extra calls to the backend storage e.g when checking if the certificate exists in storage if it has not been cached for example

* possibly, if the request are two many, we'll be seeing errors from LE due to rate limits: specifically the duplicate certificate limit https://letsencrypt.org/docs/duplicate-certificate-limit

Will that affect the functionality? In my opinion no. We'll only received the error alerts. Kafkas won't be affect as the certificate from whichever call that was successful and made it to the storage will be the one that's going to be used for a Kafka in question.

I am still not sure I understand the implications. If we leave aside the potential issues related to rate limiting, is it possible that we end up with 2 certificate issuing requests succeeding for the same name? or is it always guaranteed that one of the calls will fail?
Wouldn't the pod B always be trying to get the certificate even when it failed?

Depending on what are the implications we can decide to go forward with the local implementation assuming this might happen in some scenarios and implement later the distributed locking mechanism.

Ideally, the locking mechanism should be centralized as opposed to the current mechanism. I think we should continue to observe scenario for this and improve on top of this: if we notice that it is a recurring theme, and the load on the external systems becomes high.

Depending on the implications I agree with this reasoning. Before going forward with this I would like to understand the potential implications that I am trying to understand.

I am still not sure I understand the implications. If we leave aside the potential issues related to rate limiting, is it possible that we end up with 2 certificate issuing requests succeeding for the same name? or is it always guaranteed that one of the calls will fail?

The two calls will fail only if we have not reached the limits. The two calls could succeed and certificate will be updated to the storage twice i.e we won't end up with the two certificate in the storage, but one: the last successful processed request.

Wouldn't the pod B always be trying to get the certificate even when it failed?

The pod that failed will keep on trying to manage the certificate if and only if it remains as the leader pod and it hasn't received the newly generated certificate from pod A.

Thank you @miguelsorianod @ziccardi for the review.
I've opened https://issues.redhat.com/browse/MGDSTRM-10938 to improve locking further.


text:
Voxel edges should store material types

This has useful relevant stuff.

Procworld points out that whether or not we want to blend materials in transition areas depends on which materials they are.

It might be better to say that there is no blending between materials, but that they store extra attributes. E.g. instead of grass, dirt, snow, and stone materials, there would be a single terrain material that has extra data determining how much of each of these things it has.

There's also the more general approach of allowing multiple independent material layers on any edge. The time/space requirements might not work out though.

9104f052471941adf8031ddd616099fc04568ee2
9de7c26f2a50e65c280a02f896ea3e225cdd3184

source: gharchive/issue

repo: bfops/playform

license: mit

license_source: bigquery


text:
Support other default branches

Fixes #123
I've set the new default- default branch to main with this PR, it may be desired to not modify that behavior of the plugin, we could change which default is bundled with the install if that is preferred
I think the best was to fix this would be to create dynamic Command Palette entries with the exact branch name present as applicable, but I don't know if that is possible, so I've switched the descriptions from "View (master)" to "View (default branch)"

I tested this manually by loading the plugin directly
As far as I can tell, all functionality should be maintained, and if you now have a default branch configured that isn't present in the repository you are interacting with, you get the normal fatal: no such branch: 'main' error dialog

Looks good. Thank you!

@bgreenlee - does this plugin have a release schedule any longer? based on your other recent comment it seems maybe not :)
I'm interested in consuming this change beyond just sideloading the plugin. Could you let me know if there's anything I can assist with to prepare another release for package control? I'd be willing to help out as a repository maintainer if you are focusing on other things

Hmm, I thought just pushing to master was enough to update package control. It's been a while since I've done this, though.
I'm happy to add you if you'd like to help maintain this!

I updated the version to 1.4.0 and tagged it...and added you as a collaborator.

thanks for the add!
hm... I don't know how package control works. I see that the new README from this PR has made it to the Readme section here: https://packagecontrol.io/packages/sublime-github, but also the plugin version is still 1.3.1, and when I attempt to upgrade the package in my ST3 I don't have any upgrades available
in the package_control_channel, I see this plugin is added with tags: true https://github.com/wbond/package_control_channel/blob/master/repository/s.json#L4327 so based on packagecontrol docs I think we are just waiting for the new tag you created to be parsed ?

Yep, they've picked it up, so should be good now. Sorry for that!

authors: MaxPhilips bgreenlee

repo: bgreenlee/sublime-github


text:
训练中文模型的一些修改

修改experiment/模型名称/config/下的配置文件， 将built_in_set更改成为text_file并指定中文字符集路径。
配置文件中，attention_predictor下一定要将reverse修改为false
groundtruth中每个汉字中间加入分隔符，并修改core/label_map.py中的text_to_labels函数中的tf.string_split函数参数。
由于gt中加入了分隔符，需要相应修改utils/recognition_evaluation.py中相关部分使得评估正确。

reverse 不用改吧，正反向预测取大值

@Tracin 请问中文训练效果如何？

@Tracin 将built_in_set更改成为text_file 请问这里如何改啊 我将 ALLCASES_SYMBOLS 改成text_file结果报错了

@Tracin 您好，想请问一下你中文训练的结果如何了？能分享一下训练代码吗？

@王旭鹏 请问您后续有自己训练中文吗？

您好，请问utils/recognition_evaluation.py具体应该怎么修改呢，我修改了_normalize_text这里，除此之外还需要修改什么呢？谢谢！

您好，请问utils/recognition_evaluation.py具体应该怎么修改呢，我修改了_normalize_text这里，除此之外还需要修改什么呢？谢谢！

去掉gt中之前加入的分隔符

您好，请问utils/recognition_evaluation.py具体应该怎么修改呢，我修改了_normalize_text这里，除此之外还需要修改什么呢？谢谢！

@Pay20Y 去掉gt中之前加入的分隔符

好的，感谢

@Tracin
您好，请问gt应该是只指训练集的labels吧，我在每个中文都加了分隔符，text_file文件没有添加，我看了代码text_file可以正常的读取字典文件，但是输出结果gt一直是空白，recognition_text一直是乱码，想咨询下是否我gt添加分隔符方式错误了？谢谢！

@Tracin @loralyc 请问你用text_file训练是从已有checkpoint继续训练吗，会不会出现下面问题：

需要排除部分节点？

chars = tf.string_split(text, delimiter='UTF-8')
哈哈哈，谢谢

@Tracin @ChChwang @loralyc @Pay20Y 想请问大佬们对这个还有印象么，我按照楼主的方法进行了修改。但是发现只要label里面带中文，训练依然有问题，虽然不报错，但是收敛飞快，预测时会将所有输入预测成“0”。
感觉还是utf-8编码的问题，有人知道可能的原因吗。

@rfdeng 看不出来，具体细节？

@ChChwang 感谢回复，想请问大佬是在label中存在中文的情况下，切实训练成功了吗？效果大致如何？
我严格按照楼主的2,3,4步骤预处理了label，加入分隔符。我的label是车牌数据，所以同时包含中文英文，为了统一我每个字符之间都加了分隔符。只有第一步我偷了下懒，把label_map_builder.py里面的ALLCASES_SYMBOLS情况下，直接添加了我需要的中文字符。
character_set = list(string.digits + string.ascii_letters + ‘陕鲁皖....’)
然后我基本在迭代1k时loss就会降到1e-3量级，测试结果全部为‘0’.

@rfdeng 看不出来，具体细节？
方便的话可不可以加下微信讨论  funkydengdeng

@rfdeng，中文是三个字节，英文和数字是一个字节。我之前训练成功了，双向中文比单向中文没有提升多少，矫正网络学习的很好。想改分布式训练，分布式训练几步后，有几台会挂掉，如果你跑分布式成功告诉我一下，谢谢

@rfdeng，中文是三个字节，英文和数字是一个字节。我之前训练成功了，双向中文比单向中文没有提升多少，矫正网络学习的很好。想改分布式训练，分布式训练几步后，有几台会挂掉，如果你跑分布式成功告诉我一下，谢谢

中英文加分隔符之后，tf.string_split不会按字节分的，应该不是这个问题。我目前是把中文字符重新映射成其他非中文字符加到label里去了。这样分布式训练没问题。。。但是label里只要带中文就会挂。我和别人讨论，有个兄弟讲不同的中文label会全部被映射成1个character_set里面的同一个index，我还没来得及check。

@Tracin @ChChwang @rfdeng 小弟新手，请问中文加空格，只是在groundtruth 加 ？ 还是 中文字符集中也要加？我这边按照 @Tracin 说的修改了，但识别结果为0

@Tracin @ChChwang @rfdeng 小弟新手，请问中文加空格，只是在groundtruth 加 ？ 还是 中文字符集中也要加？我这边按照 @Tracin 说的修改了，但识别结果为0

groundtruth也要加，我们遇到的可能是同一个问题，我后来debug发现原因是原始的配置文件中对训练的输入数据有一个string_filtering的操作。这一步会导致你label中所有非预先定义的字符集字符被过滤掉，这本来是原文中为了过滤标点符号和大小写统一的，但是这里会导致我们添加的分隔符被过滤掉。
所以可以在字符集里添加你设定的分隔符，或者说直接注释掉string_filtering对应的那个data_augmentation_options。我选用的是第二种方法。

@Tracin @ChChwang @rfdeng 小弟新手，请问中文加空格，只是在groundtruth 加 ？ 还是 中文字符集中也要加？我这边按照 @Tracin 说的修改了，但识别结果为0
groundtruth也要加，我们遇到的可能是同一个问题，我后来debug发现原因是原始的配置文件中对训练的输入数据有一个string_filtering的操作。这一步会导致你label中所有非预先定义的字符集字符被过滤掉，这本来是原文中为了过滤标点符号和大小写统一的，但是这里会导致我们添加的分隔符被过滤掉。
所以可以在字符集里添加你设定的分隔符，或者说直接注释掉string_filtering对应的那个data_augmentation_options。我选用的是第二种方法。

请问您训练成功了吗？最终结果如何呢？我做了修改后训练的结果总是10个定长的输出...模型没法用

修改experiment/模型名称/config/下的配置文件， 将built_in_set更改成为text_file并指定中文字符集路径。
配置文件中，attention_predictor下一定要将reverse修改为false
groundtruth中每个汉字中间加入分隔符，并修改core/label_map.py中的text_to_labels函数中的tf.string_split函数参数。
由于gt中加入了分隔符，需要相应修改utils/recognition_evaluation.py中相关部分使得评估正确。

修改experiment/模型名称/config/下的配置文件， 将built_in_set更改成为text_file并指定中文字符集路径。
配置文件中，attention_predictor下一定要将reverse修改为false
groundtruth中每个汉字中间加入分隔符，并修改core/label_map.py中的text_to_labels函数中的tf.string_split函数参数。
由于gt中加入了分隔符，需要相应修改utils/recognition_evaluation.py中相关部分使得评估正确。

您好，针对中文字符的情况，请问有没有修改完的示例贴出来参考一下呢？感激不尽

修改experiment/模型名称/config/下的配置文件， 将built_in_set更改成为text_file并指定中文字符集路径。
配置文件中，attention_predictor下一定要将reverse修改为false
groundtruth中每个汉字中间加入分隔符，并修改core/label_map.py中的text_to_labels函数中的tf.string_split函数参数。
由于gt中加入了分隔符，需要相应修改utils/recognition_evaluation.py中相关部分使得评估正确。

@Tracin 您好，针对中文字符的情况，请问有没有修改完的示例贴出来参考一下呢？感激不尽

reverse 不用改吧，正反向预测取大值

@ChChwang  大佬有修改好的可用的示例可以参考一下吗？

这里中文字符集路径如何改呢？有最后的预测结果吗？

@Tracin @ChChwang @rfdeng 小弟新手，请问中文加空格，只是在groundtruth 加 ？ 还是 中文字符集中也要加？我这边按照 @Tracin 说的修改了，但识别结果为0

groundtruth也要加，我们遇到的可能是同一个问题，我后来debug发现原因是原始的配置文件中对训练的输入数据有一个string_filtering的操作。这一步会导致你label中所有非预先定义的字符集字符被过滤掉，这本来是原文中为了过滤标点符号和大小写统一的，但是这里会导致我们添加的分隔符被过滤掉。
所以可以在字符集里添加你设定的分隔符，或者说直接注释掉string_filtering对应的那个data_augmentation_options。我选用的是第二种方法。

您好，请问为什么在训练中文的时候要加入分隔符啊？

authors: 1037861070 ChChwang Ourano Pay20Y Tracin isyyzhang li675599061 loralyc luoqingyu pageedward rfdeng tangsipeng wangxupeng yongshuaihuang zhiweiguo

repo: bgshih/aster


text:
dtw values comparison with tslearn

Hi! Comparing the values of DTW (with euclidean distance) from traj-dist and tslearn library, weren't the values supposed to be the same?
Thanks in advance.

I'm also getting completely different numbers. The values from tdist are about 10 times bigger than the values from tslearn.metrics.dtw!
However, using soft-dtw with gamma=0 (which is exactly dtw) from https://github.com/mblondel/soft-dtw, I'm getting the same values as in tslearn.metrics.dtw.

authors: Danisodu aghababa

repo: bguillouet/traj-dist


text:
M1 Mac Tensorflow

Anyone able to get this to work on MacOS? I am trying to get this working in a virtual environment with Python 3.10 and have to use tensorflow-macos and tensorflow-metal.
Unsure what to change in requirements but I keep getting errors when trying to install all the dependencies.
On mobile right now but will update with full errors when I get back to my laptop.

I'm having the same problem the same problem. Hopefully someone can come up with a fix for Apple M1 users.

I had the same issue, you have to downgrade your version to python 3.9. Create the 3.9 version in your environment. instead.

Just an update, even though I no longer got the Tensorflow error, I got an illegal hardware error on my Mac M1 as well. I don't think his script works with M1's, since GPT-4 diagnosed the issue as a hardware incompatibility with Tensorflow.

The code was written to work on Huggingface, not localhost (win/mac).

The code was written to work on Huggingface, not localhost (win/mac).

Any plans to have it work on localhost (win/mac) or web server?

I will release a code working on Windows localhost. I am sorry, I do not have a Mac to test it.

Would be happy to have someone contribute the mac version of running code.

You can run this on localhost using docker:
docker run -it -p 7860:7860 --platform=linux/amd64 registry.hf.space/bhaskartripathi-pdfchatter:latest python app.py
Here is an example:
https://gradio.app/sharing-your-app/#embedding-hosted-spaces

Hey thanks so much for responding! I wasn't meaning to complain about it - I just shared a fix to the Tensorflow problem, but it created new ones and I suspected it was a Mac issue.
I wanted a local version cause I wanted to try to add a bunch of features to it, like multiple PDF support, and some prompt processing before it gets embedded into a vector. I'm not familiar with docker but I am sure I can figure it out.
How is this embedding free whereas OpenAI's embedding and Pinecone cost money? Who's processing and storing the vectors for free?

This embedding uses Google's universal sentence encoder which is free. Huggingface has hosted it for free but local might be faster as HF infra is free but little slow. You can download the embedding model on local and then try. My GPU is way too outdated for it to run on local. However,  if you have Rtx 3070 or above, it should work smoothly on local.

I can try and help with getting this running on a Mac. Also, I'm not quite understanding. What parts of the code would need changes/updates to get this to work on localhost (Mac, Linux or Windows - I have access to all and could help test)? Is the local model needed or can I just work with the hosted model but run the actual program locally?

I had the same issue, you have to downgrade your version to python 3.9. Create the 3.9 version in your environment. instead.

Odd, I tried that and I still was unable to install tensorflow.

Really sorry to hear that, not sure why.
I am also willing to try helping on a Mac too, I can give him access to it if that helps, but I am not sure how to convert his script into a Mac.
For what it's worth, dezerving, I wrote a separate script that uses Langchain + OpenAI embeddings + Chroma (to store the vectors) to achieve the same function - can share if you are interested. The only problem is that OpenAI embeddings are kinda expensive, which defeats the whole purpose of trying to run bhaskaripathi's script.

Really sorry to hear that, not sure why.
I am also willing to try helping on a Mac too, I can give him access to it if that helps, but I am not sure how to convert his script into a Mac.
For what it's worth, dezerving, I wrote a separate script that uses Langchain + OpenAI embeddings + Chroma (to store the vectors) to achieve the same function - can share if you are interested. The only problem is that OpenAI embeddings are kinda expensive, which defeats the whole purpose of trying to run bhaskaripathi's script.

Would love to take a look, thanks! Can we not just swap OpenAI embeddings for Universal Sentence Encoder? I'll admit I need to do a bit more research.

I got it to work on an apple silicone.
(my python version 3.10)
You need to
pip install tensorflow-macos
pip3 install sklearn
pip3 install -U scikit-learn scipy matplotlib

I got it to work on an apple silicone. (my python version 3.10) You need to pip3 install tensorflow-macos pip3 install sklearn pip3 install -U scikit-learn scipy matplotlib

Thanks for this. This worked, along with using pipreqs and pinning versions (pip took over 30m otherwise to try and install from requirements.txt).
This was the result from that:
gradio==3.27.0
numpy==1.23.5
openai==0.27.4
PyMuPDF==1.22.1
scikit_learn==1.2.2
tensorflow_hub==0.13.0

With the very helpful info found the above, I successfully installed in my macbook air (M2)!

Clone this repo
In this repo, edit the requirements.txt found below
pip3 install -r requirements.txt
Run the app python3 app.py
Access to http://localhost:7860

It works with Macbook Air M1!!!!
Thanks Mate!

thanks for resolving this issue

repo: bhaskatripathi/pdfGPT


text:
Handle Throughput::BytesDecimal

Fixes the panic when encountering the relatively new throughput variant:
thread 'main' panicked at ***/criterion-0.5.1/src/benchmark_group.rsError: :316:30:
called `Result::unwrap()` on an `Err` value: Io(Os { code: 32, kind: BrokenPipe, message: "Broken pipe" })
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Caused by:
    0: Failed to parse message from Criterion.rs benchmark
    1: unknown variant `BytesDecimal`, expected `Bytes` or `Elements`

Thanks for merging it quickly.
Can you consider also making a release with this and the other few changes since 1.1.0?

repo: bheisler/cargo-criterion


text:
0.3.2

Rearranging the sidebar

Sidebar Content

Getting Started
** What is Scribe SE? # Mention that hereafter in this document the app will be referred to as just 'Scribe'.
** System Requirements
** Installation
** Create a New Account
Basic Setup
** Profile
** App Language
** Notifications
Manage Project
** Create a Project
*** Advanced Settings
** Projects # Talks about listing, starring, searching and sorting
*** Edit Project Details
*** Import Project
*** Archive Project
*** Export Project
*** Backup and Sync
*** Sync
Modes # Overview of the concept of modes.
** Common Functionality
*** Layout # Adding columns and sections.
*** Resources # Importing resources, resource management, etc.
*** Menu Bar
*** Font Size
*** Sync
** Text Bible Translation
*** Editing Text # Example of drafting a few verses. Say data is stored in the backend as USFM.
*** Scroll Lock
*** Bookmarks
** Oral Bible Translation
*** Audio Toolbar # Describe functions of each of the buttons and settings on the toolbar
** Open Bible Stories
*** Drafting # Example of drafting a story.
Other Features
** # Anything that does not cleanly fit in the above categories
More Information
Technical Support

closed

authors: selvabenz vipinpaul

repo: bible-technology/scribe-docs