primordic/IssueDupesLite huggingface dataset:
Repository: vuetifyjs/vuetify

Issue #10856: [Bug Report] Content behind overlay scrolling
Created: 2020-03-16T08:59:59Z
Environment
Vuetify Version: 2.2.15
Vue Version: 2.6.11
Browsers: Chrome 80.0.3987.132
OS: Mac OS 10.15.0
Steps to reproduce
Scroll when an overlay is open on top of a large body of text.
Expected Behavior
Content should not scroll when an overlay is open.
Actual Behavior
Content scrolls even when an overlay is open.
Reproduction Link
https://codepen.io/dakshshah/pen/xxKWLgb

Duplicate issue #10661: [Bug Report] v-overlay scrolling behavior inverted
Created: 2020-02-24T15:14:03Z
Environment
Vuetify Version: 2.2.11
Vue Version: 2.6.11
Browsers: Chrome 80.0.3987.116
OS: Linux x86_64
Steps to reproduce
scroll down
Expected Behavior
while overlay is visible, the overlay isn't scrollable, making it impossible to see overflowing text thereof. Instead, the body behind it is scrollable
Actual Behavior
The reverse - body scrolling is locked and only the overlay is scrollable
Reproduction Link
https://codepen.io/tobiasfeil/pen/ExjZXVd

Closing comment (2020-03-16T16:30:15Z): Duplicate of #10856
If you have any additional questions, please reach out to us in our Discord community.
Repository: vuetifyjs/vuetify

Issue #3999: [Feature Request] v-select aria roles
Created: 2018-05-07T08:23:29Z
Problem to solve
Select options are not accessible for screen reader users.
Proposed solution
Please add option for aria-label, so  screen readers can more easily navigate it.

Duplicate issue #5394: [Feature Request] Aria attributes for Autocomplete/Combobox components
Created: 2018-10-23T11:35:30Z
Problem to solve
Hello in Autocomplete and Combobox components, I can't see any of aria attributes describe in W3C :
https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html
Proposed solution
It would be nice to have have aria attributes in the components Autocomplete/Combobox
On the combobox container :
• role="combobox"
• aria-haspopup="listbox"
• aria-expanded="true/false" (compute ?)
• aria-owns="IDREF"
On the Input :
• aria-autocomplete="list"
• aria-activedescendant="IDREF" : (compute ?)
On the listbox Popup :
• role="listbox"
• aria-labelledby="IDREF" :  (compute ?)
• role="option"

Closing comment (2018-10-23T12:00:50Z): Actually this is duplicate of #3999
Please add your comment with proposed solution to that issue. Thank you
Repository: vuetifyjs/vuetify

Issue #1656: Parallax can't find image - based on the parallax demo project
Created: 2017-09-10T15:48:14Z
Steps to reproduce
I setup a new project with vue init vuetifyjs/webpack-advanced and adding the Parallax demo. I wanted to split each parts (header/footer/sections) as standalone components.
The 2 sections with the parallax cannot find the source image. I have two 404 errors on the console.
I'm sure about the relative path I put because the main LOGO  has the same base path than the two others and it rendered (../assets/vuetify.png vs ../assets/hero.jpeg, see below)
Versions
Vue : 2.4.2
Vuetify: 0.15.0
MacOS: 10.12.6
Chrome: 60.x
What is expected ?
Can see the source img in the 2 parallax sections.
What is actually happening ?
Can't see the source img in the 2 parallax sections.
Reproduction Link
I don't know how to give you reproduction link so here the code I have.
img available on /src/assets/hero.jpeg
/src/components/Hero.vue
<template>

  <div class="">

    <section>
      <v-parallax src="../assets/hero.jpeg" height="600">
        <v-layout column align-center justify-center class="white--text">
          <img src="../assets/vuetify.png" alt="Vuetify.js">
          <h1 class="white--text mb-2 display-3">Golf Watcher</h1>
          <div class="headline mb-3 text-xs-center">Powered by Vuetify</div>
          <v-btn class="blue lighten-2 mt-5" dark large href="/pre-made-themes">
            Get Started
          </v-btn>
        </v-layout>
      </v-parallax>
    </section>

  </div>

</template>

<script>
export default {
  data () {
    return {

    }
  }
}
</script>

<style scoped>

</style>
Do you think the issue is here because of vue-router that cannot give the path or something ?
EDIT: I made a test. If I just change the <v-parallax> for a <img> I have the img. So there is a real problem with the src props of v-parallax

Duplicate issue #4668: Parallax component doesn't work when src linked to local assets folder
Created: 2018-07-19T15:35:07Z
Versions and Environment
Vuetify: 1.1.7
Vue: 2.5.16
Browsers: Chrome and Edge
OS: Windows 10

Previously worked in:
Vuetify:
Vue:
Steps to reproduce

Use the Vuetify Parallax component inside of a Vue component and link the src to an image inside of the assets folder, import the component in App.vue and use it.
Expected Behavior

Parallax to show the image
Actual Behavior

No image, just an icon appears in the middle
Reproduction Link

Can't reproduce on Codepen.io, needs vue-cli and the asset folder to see the bug.

Additional Comments:

Closing comment (2018-07-19T16:13:49Z): Duplicate of #1656
Repository: vuetifyjs/vuetify

Issue #6294: [Bug Report] VMenu absolute positioning does not respect viewport
Created: 2019-01-30T12:00:43Z
Versions and Environment
Vuetify: 1.4.4
Last working version: 1.4.2
Vue: 2.5.22
Browsers: Chrome 72.0.3626.81
OS: Linux x86_64
Steps to reproduce
Click on button to trigger menu show
Expected Behavior
Menu should adjust it position respecting current viewport.
Same demo for v1.4.2 https://codepen.io/darkside73/full/pGNdwe
Actual Behavior
Menu is positioning out of viewport
Reproduction Link
https://codepen.io/darkside73/full/ZwBaeJ

Duplicate issue #6421: [Feature Request] menuable updateDimensions dosent take into account right of the activator / window menus goes offscreen
Created: 2019-02-08T14:18:35Z
Problem to solve
Adapt menu popups so they dont go off screen.
Proposed solution
  var _this = this;
            this.checkForWindow();
            this.checkForPageYOffset();
            var dimensions = {};
            // Activator should already be shown
            if (!this.hasActivator || this.absolute) {
                dimensions.activator = this.absolutePosition();
            } else {
                var activator = this.getActivator();
                dimensions.activator = this.measure(activator);
                dimensions.activator.offsetLeft = activator.offsetLeft;
                 // IMPLEMENTATION SUGGESTION
                //TODO:CHECK THAT ACTIVATOR menu element is within the screen showing by the user. 
                //https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect
                // thinking something like this.
                // if(offsetLeft + widthOfElemnt > window.innerWidth){
                //     detachedElementOffsetLeft: (offsetLeft - ( offsetLeft + widthOfElemnt - windowInnerWidth)
               //}
               
 

                if (this.isAttached) {
                    // account for css padding causing things to not line up
                    // this is mostly for v-autocomplete, hopefully it won't break anything
                    dimensions.activator.offsetTop = activator.offsetTop;
                } else {
                    dimensions.activator.offsetTop = 0;
                }
            }
            // Display and hide to get dimensions
            this.sneakPeek(function () {
                dimensions.content = _this.measure(_this.$refs.content);
                _this.dimensions = dimensions;
            });

Closing comment (2019-02-08T14:34:08Z): Looks like it's supposed to be a bug report, possible duplicate of #6294. If it's a bug report check for existing issues first and use the correct template with a reproduction link, and if you want to suggest code changes then open a PR because that's unreadable.
Repository: vuetifyjs/vuetify

Issue #17573: [Bug Report][3.3.2] v-autocomplete selection slot not shown while control has focus
Created: 2023-06-09T19:29:14Z
Environment
Vuetify Version: 3.3.2
Vue Version: 3.3.3
Browsers: Chrome 114.0.0.0
OS: Windows 10
Steps to reproduce
Select a Building.  Then click whitespace.  Then select another building.  The selection slot is not shown when control has focus as it did in V2.
Expected Behavior
Always show selection slot template while an item is selected.
Actual Behavior
Selection slot template hidden while control has focus. When focused, item.title is shown instead.
Reproduction Link
https://stackblitz.com/edit/vuetify3-krppgl?file=README.md
Other comments
Not sure if this is different by design, but if it is, the part that makes this bad UX is the user must backspace out the current text, or must click the closeable button to enter a new search,

Duplicate issue #18454: [Bug Report][3.3.21] VAutocomplete selection slot not used while dropdown is open
Created: 2023-10-12T15:07:38Z
Environment
Vuetify Version: 3.3.21
Vue Version: 3.3.4
Browsers: Safari 17.0
OS: Mac OS 10.15.7
Steps to reproduce
When creating a VAutocomplete with objects as items and using the selection slot, the selection slot is only used when the automcomplete dropdown is not open. If the dropdown is open, the selection is displayed using the item-title prop.
Expected Behavior
When the selection slot is defined it should be used whether the dropdown is open or not.
Actual Behavior
The defined slot is used when the dropdown is closed. The item-title prop is used when the dropdown is open.
Reproduction Link
https://play.vuetifyjs.com/#...
Other comments
This makes for a confusing UI if the slot definition differs from the item-title. Note that this does not happen with the chip slot. There the slot definition is used whether the dropdown is open or not.

Closing comment (2023-10-24T12:46:38Z): Duplicate of #17573
Repository: vuetifyjs/vuetify

Issue #10140: [Bug Report] expension panels open laggy
Created: 2020-01-07T12:51:19Z
Environment
Vuetify Version: 2.2.1
Vue Version: 2.6.11
Browsers: Chrome 79.0.3945.88
OS: Windows 10
Steps to reproduce
In the codepen click on the blue blocks to open the next expansion panel
Expected Behavior
open fluently
Actual Behavior
it opens laggy, perhaps because the v-for is still rendering
Reproduction Link
https://codepen.io/ricardovanlaarhoven/pen/WNbwvev
Other comments
perhaps the expension panel is just missing an eager prop?

Duplicate issue #11534: [Bug Report] v-expansion-panels - v-model change, animation does not work, on the first pass.
Created: 2020-06-01T09:14:07Z
Environment
Vuetify Version: 2.2.30
Vue Version: 2.6.11
Browsers: Chrome 83.0.4103.61, Mozilla Firefox
OS: Windows 10
Steps to reproduce
Open reproduction link;
Click button "+1".
Expected Behavior
Animation is working.
Actual Behavior
Animation working in from the second pass.
Reproduction Link
https://codepen.io/dinver/pen/JjGPKWe?editable=true&editors=101%3Dhttps%3A%2F%2Fvuetifyjs.com%2Fen%2Fcomponents%2Fexpansion-panels%2F

Closing comment (2020-06-01T09:29:13Z): Duplicate of #10140
Repository: vuetifyjs/vuetify

Issue #14733: [Bug Report][3.0.0-alpha.12] v-text-field :rules are not applied when input changes
Created: 2022-02-17T06:51:46Z
Environment
Vuetify Version: 3.0.0-alpha.12
Vue Version: 3.2.31
Browsers: Chrome 98.0.4758.80
OS: Mac OS 10.15.7
Steps to reproduce
Provided sample example itself is not working. Rules are not applied while changing input
https://next.vuetifyjs.com/en/components/inputs#rules
Expected Behavior
Rules should be applied and error messages should be shown incase of invalid input
Actual Behavior
Rules are not applied and there is no error incase of invalid input
Reproduction Link
https://codepen.io/wshgziva/pen/NWwXGjw?editors=1011

Duplicate issue #14799: [Bug Report][3.0.0-alpha.12] Form validation errors do not display reactively when validation fails
Created: 2022-03-08T04:46:51Z
Environment
Vuetify Version: 3.0.0-alpha.12
Vue Version: 3.2.31
Browsers: Chrome 98.0.4758.80
OS: Mac OS 10.15.7
Steps to reproduce
Break a form rule (ex: typing more than 6 characters) and rule error is not applied to form input.
Expected Behavior
Breaking input/form rule will reactively show error for input (ex: if validation has failed, the string value will be presented as an error message)
Actual Behavior
Error never shows once validation fails
Reproduction Link
https://codepen.io/integrateus/pen/qBVGdGX?editors=101
Other comments
Example pulled straight from current next vuetify docs.

Closing comment (2022-03-08T05:26:23Z): Duplicate of #14733
Repository: vuetifyjs/vuetify

Issue #7283: [Feature Request] Prepend label for switch
Created: 2019-05-24T09:38:03Z
Problem to solve
It would be possible to have the text on the left side and the switch itself on the right side
Proposed solution
My suggestion would be to add a prepend-label property so you could decide to have the switch element the default way
switch - label
or
label - switch

Duplicate issue #12999: [Feature Request] Multiple Labels on VSwitch
Created: 2021-01-21T15:20:04Z
Problem to solve
A potential use case for a switch is to label it on either side with two mutually exclusive options (e.g. a light/dark mode switch). This differs from a checkbox by explicitly labelling the separate states, rather than expecting the user to know the default state (e.g. a dark mode checkbox expects the user to know that the default is light mode). For 3 or more mutually exclusive options, radio buttons are fine, but they use a lot of vertical space for only 2 options, which could be solved with a switch. This is beyond the Material design spec for switches, but I believe it's a common enough pattern to be addressed.
Proposed solution
Currently, VSwitch supports both a label prop and a label slot. This can remain the same, allowing for backward compatibility and consistent default behavior according to Material Design.
I'm proposing the introduction of two new prop/slot pairs, named label-left and label-right, allowing developers to describe their default option and the alternate option. label will continue to fill the label-right slot by default. This would also solve the use case of Issue #7283.

Closing comment (2021-11-23T19:05:00Z): duplicate of #7283
Repository: vuetifyjs/vuetify

Issue #8120: [Bug Report] VDataTable - slot for footer.page-text doesn't work
Created: 2019-07-28T13:59:05Z
Environment
Vuetify Version: 2.0.1
Last working version: 1.5.16
Vue Version: 2.6.10
Browsers: Chrome 75.0.3770.142
OS: Linux x86_64
Steps to reproduce
See Code Pen for sample code.
Expected Behavior
Footer should show: "Items: 1 - 1"
Actual Behavior
Footer shows default: "1-1 of 1"
Reproduction Link
https://codepen.io/piotrbulinski/pen/OKbKpN

Duplicate issue #8507: [Bug Report] v-data-table slot="page-text" is not propagated to v-data-footer
Created: 2019-08-13T15:25:19Z
Environment
Vuetify Version: 2.0.5
Vue Version: 2.6.10
Browsers: Chrome 76.0.3809.100
OS: Windows 10
Steps to reproduce
add a page-text slot to the v-data-table
Expected Behavior
the page text. especially: 1-20 of 500 should display the content of the page-text slot.
Actual Behavior
slot not propagated (as of 2.0.5)
Reproduction Link
https://codepen.io/steinmiller/pen/NWKxaVL
Other comments
I fixed the issue locally by propagating the scopedSlots to the footer props in the genFooters(props) function
like here on line 483 of VDataFooter.js, I added scopedSlots: this.$scopedSlots
 genFooters(props) {
   const data = {
      props: {
        options: props.options,
        pagination: props.pagination,
        itemsPerPageText: '$vuetify.dataTable.itemsPerPageText',
        ...this.footerProps
      },
      on: {
        'update:options': value => props.updateOptions(value)
      },
      widths: this.widths,
      headers: this.computedHeaders,
      scopedSlots: this.$scopedSlots
    };

Closing comment (2019-08-13T16:55:28Z): Duplicate of #8120
Repository: vuetifyjs/vuetify

Issue #9580: [Bug Report] VFileInput prepend slot doesn't work
Created: 2019-11-05T13:51:28Z
Environment
Vuetify Version: 2.1.9
Vue Version: 2.6.10
Browsers: Chrome 78.0.3904.70
OS: Mac OS 10.15.1
Steps to reproduce
See reproduction link.
Add a <template v-slot:prepend> to a <v-file-input>.
Expected Behavior
The set prepend slot should be used instead of the default value '$file' of the prepend-icon prop.
Actual Behavior
The prepend slot appears to be ignored completely.
Reproduction Link
https://codepen.io/Aukemid/pen/gOOXNGZ
Other comments
It seems impossible to use the prepend slot in a v-file-input. You can remove the default icon by giving the prepend-icon an empty string value, but setting a custom prepend slot has no effect. It does work for prepend-inner, append and append-outer.

Duplicate issue #12403: [Documentation] The prepend Slot feature is available in the the document of VFileInput , but it is not actually supported
Created: 2020-10-12T00:57:10Z
Environment
Browsers: Chrome 86.0.4240.75
OS: Windows 10
Steps to reproduce
    <v-file-input multiple label="File input">
      <v-icon slot="append" color="red">mdi-plus</v-icon>
      <v-icon slot="prepend" color="green">mdi-minus</v-icon>
    </v-file-input>

Expected Behavior
prepend insert mdi-minus
Actual Behavior
mdi-minusis not work
Reproduction Link
https://v2.vuetifyjs.com/en/components/file-inputs/
Other comments
    genPrependSlot() {
      if (!this.prependIcon) return null;
      const icon = this.genIcon('prepend', () => {
        this.$refs.input.click();
      });
      return this.genSlot('prepend', 'outer', [icon]);
    },

The writing method in the source code does not support this feature, but prepend feature is support in the document

Closing comment (2020-10-12T01:19:32Z): duplicate #9580
Repository: vulkano-rs/vulkano

Issue #890: Emit throwaway `include_bytes!()` in shader-derive so changes to shader files trigger recompilation
Created: 2017-12-06T00:50:03Z
In this Reddit discussion, the asker was unsure of how to get Cargo to recognize shader files as source files to trigger recompilation. I suggested either emitting rerun-if-changed from a build script or using include_bytes!("<shader file>") in their Rust code in order for Cargo to detect changes to shader files when deciding whether or not to recompile.
It occurred to me that shader-derive could be doing the latter automatically, but I haven't found any discussion on why it doesn't currently. The additional data would inflate debug builds, but the unused rvalues should be optimized out in release builds.

Duplicate issue #1231: vulkano_shaders::shader! "path:" parameter doesn't incorporate changes to the referenced file by default
Created: 2019-08-18T19:57:05Z
Version of vulkano: 0.14
rustc 1.39.0-nightly
OS: Windows 10
GPU (the selected PhysicalDevice): GTX 1080
GPU Driver: GeForce GRD 431.60
See this demo repo for an easy example, though any file using shader! with the path argument should work.

Issue
When using vulkano_shaders::shader! macro with the path variant, the file indicated by path is not watched by cargo. Changes to the shader file must then be coordinated with a change in the rust file the shader macro runs in (or with a clean build) for the changes to be reflected by the executable.
It appears to be possible to add an arbitrary file dependency to cargo in some cases as indicated by this code which appears to be intended for use in a cargo build script. I'm unsure if a similar technique could work for a macro, or if there's a different API the macro could use that would result in more consistent behavior.
If it isn't currently possible to make this work reliably the docs should at least include a warning of some sort, I think.
This obviously doesn't affect the src variant of shader!, which by nature changes the file when the shader code changes.

Closing comment (2019-10-22T20:57:13Z): Dupe of/related to #890
Repository: vulkano-rs/vulkano

Issue #1383: macOS: BufferUsage::all() breaks examples
Created: 2020-06-09T11:27:51Z
Running the triangle example on a fresh install of macOS with the vulkan SDK, I get a blue screen but no triangles:

My laptop is a 2020 macbook air, still with the new computer smell, and an integrated GPU.
I'm more than happy to debug myself, given some direction! I'm not really sure where to start.

Duplicate issue #1393: Documentation -> Guide -> Example Operation: Demo code error
Created: 2020-07-01T01:50:56Z
Version of vulkano: 0.19.0
OS: macOS 10.15.5
GPU (the selected PhysicalDevice): PhysicalDevice { instance: <Vulkan instance 140443660619264>, device: 0 }
GPU Driver: ?

Following the code on page http://vulkano.rs/guide/example-operation. The assert_eq! at the end fails with error message:
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63]`,
 right: `[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]`', src/main.rs:56:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The assert_eq! passes when changing the host_cached argument of CpuAccessibleBuffer::from_iter() from false to true in the following lines.
    let source_content = 0..64;
    let source =
        CpuAccessibleBuffer::from_iter(device.clone(), BufferUsage::all(), false, source_content)
            .expect("failed to create source buffer");
    let dest_content = (0..64).map(|_| 0);
    let dest =
        CpuAccessibleBuffer::from_iter(device.clone(), BufferUsage::all(), false, dest_content)
            .expect("failed to create dest buffer");
main.rs.txt

Closing comment (2020-07-01T04:55:07Z): Duplicate of #1383
Related to KhronosGroup/MoltenVK@25a1e05
Repository: vulkano-rs/vulkano

Issue #1558: Make shader data generation available at runtime
Created: 2021-04-17T13:25:16Z
Vulkano-shaders does two things: it compiles the shader (if you're not using bytes) and it generates a bunch of data structures and types from the shader. Since the second step is applied to finished SPIR-V code, some of it could in theory be done for shaders that are loaded at runtime. Of course it is still unsafe to actually load these shaders, but there's no good reason to deny users the convenience of having things like pipeline layouts generated for them.
Therefore I propose to add some way to call on Vulkano-shaders to generate shader information at runtime. The shader! macro currently defines new types and implements traits on them, which is not possible at runtime: the runtime function has to return a single known type that can represent any pipeline layout, descriptor layout, etc. This would make it similar to the change made to RenderPassDesc that was merged recently. However, in this case we have the option to keep shader! working as it does now, or also generate a runtime type like the proposed system here.

Duplicate issue #1673: Improve vulkano-shaders to actually become runnable at runtime and not just proc macros
Created: 2021-08-16T04:34:53Z
vulkano-shaders is able to do a lot of introspection into a spirv blob and it would be nice to pull out that information dynamically at runtime rather than being forced to use macros at compile time, although keeping the option to use compile time macros would be great. i find myself writing my own spirv blob parser and having to inspire myself a lot from the vulkano-shaders internals to understand what is actually going on.

Closing comment (2021-08-16T08:07:09Z): I think you're proposing the same as #1558?
Repository: vulkano-rs/vulkano

Issue #890: Emit throwaway `include_bytes!()` in shader-derive so changes to shader files trigger recompilation
Created: 2017-12-06T00:50:03Z
In this Reddit discussion, the asker was unsure of how to get Cargo to recognize shader files as source files to trigger recompilation. I suggested either emitting rerun-if-changed from a build script or using include_bytes!("<shader file>") in their Rust code in order for Cargo to detect changes to shader files when deciding whether or not to recompile.
It occurred to me that shader-derive could be doing the latter automatically, but I haven't found any discussion on why it doesn't currently. The additional data would inflate debug builds, but the unused rvalues should be optimized out in release builds.

Duplicate issue #961: vulkano-shader-derive does not always detect shader changes at path
Created: 2018-05-26T23:11:15Z
Some times shaders declared with the #[path] attribute will not cause the crate to be recompiled once the shader contents have been changed.
A work-around is to just resave a rust file without modifying it.

Closing comment (2018-05-27T02:31:49Z): I believe this is a dupe of #890 which has a proposed solution.
Repository: vulkano-rs/vulkano

Issue #1354: Vulkano shader macro/shader IO blocks
Created: 2020-05-05T05:58:47Z
Version of vulkano: 0.18
Upload of a reasonably minimal complete main.rs file that demonstrates the issue: TODO

Issue
The vulkano shader! macro doesn't support blocks for vertex output or fragment input. I get "Type #9/#43 not found or invalid" (9 for vertex output, 43 for fragment input) as a proc macro panic when using blocks.

Duplicate issue #2164: vulkano_shaders::shader! macro can't handle interface block
Created: 2023-03-28T18:59:52Z
Version of vulkano: vulkano = "0.32.3" vulkano-shaders = "0.32.0"
OS: n/a
GPU (the selected PhysicalDevice): n/a
GPU Driver: n/a
Upload of a reasonably minimal complete main.rs file that demonstrates the issue:

vulkano_shaders::shader! {
    ty: "vertex",
    src: "
#version 450

layout(location = 0) out Vertex { vec3 pos; }
vertex;

void main() {}
",
}

fn main() {}
Issue
error: proc macro panicked
 --> src\main.rs:1:1
  |
1 | / vulkano_shaders::shader! {
2 | |     shaders: {
3 | |         shared_constants: true,
4 | |         vertex: {
... |
8 | |     },
9 | | }
  | |_^
  |
  = help: message: Type %8 not found or invalid

Closing comment (2023-07-07T05:35:02Z): Closing as a duplicate of #1354.
Repository: vulkano-rs/vulkano

Issue #867: How to read from CpuBufferPool/CpuBufferPoolChunk
Created: 2017-10-15T19:22:35Z
I am currently using a compute shader to write to a buffer, I was previously using a CpuAccessibleBuffer but from the documentation this may be removed from Vulkano in future so I am moving to using a CpuBufferPool.
I have a problem though, I cannot see any API methods which would allow me to read the data back out of the CpuBufferPoolChunk.
The documentation implies that reading from the CpuBufferPool on the CPU should be possible:

if a buffer is under constant access by the GPU but you need to read its content on the CPU from time to time, it may be a good idea to use a DeviceLocalBuffer as the main buffer and a CpuBufferPool for when you need to read it. Then whenever you need to read the main buffer, ask the GPU to copy from the device-local buffer to the CPU buffer pool, and read the CPU buffer pool instead.

Duplicate issue #1850: No examples of how to use CpuBufferPool
Created: 2022-02-27T09:33:34Z
It would be good to have simple examples of how to use CpuBufferPool to get data from a computation.

Closing comment (2022-11-27T17:51:17Z): Might be related to #867
Repository: vulkano-rs/vulkano

Issue #1054: AutoCommandBufferBuilder doesn't allow specifying index ranges
Created: 2018-09-29T20:48:52Z
It's often desirable to draw a sub-range of the indices in a mesh (i.e. rendering a single tile out of a tileset). SyncCommandBufferBuilder allows specifying the number of indices and the index offset, but AutoCommandBufferBuilder does not expose this functionality.
Is this an oversight, or is there an alternate approach that is recommended?

Duplicate issue #1004: Allow drawing a subset of a buffer
Created: 2018-07-29T19:34:26Z
The raw Vulkan draw commands, such as vkCmdDraw, have parameters to specify which vertex to start drawing at, and how many to draw. These parameters are exposed by SyncCommandBufferBuilder, and the implementation of AutoCommandBufferBuilder provides these values based on the size of the buffer. But there is no way to specify these directly in AutoCommandBufferBuilder other than by using indirect drawing. This makes it impossible to draw only a subset of a buffer, which is useful when a single buffer contains data for many different objects. Can this feature be exposed somehow?

Closing comment (2018-09-30T07:36:17Z): Same as #1054, a valid solution has been provided. I'll make a PR to document this on the draw_* methods
Repository: vulkano-rs/vulkano

Issue #2455: Support for `VK_KHR_ray_tracing_pipeline`
Created: 2024-01-19T14:44:24Z
I'm interested in contributing towards adding support for VK_KHR_ray_tracing_pipeline, but I don't 100% understand what would be required to make this happen.
VK_KHR_acceleration_structure is already supported, and it's obvious that a RayTracingPipeline struct would be required.
Would anyone be able to advise what other work would need to be done for pipelined ray-tracing support?
Many thanks!

Duplicate issue #2521: [Question] Is hardware Ray tracing supported yet?
Created: 2024-04-20T21:02:57Z
Is hardware ray tracing using the VK_KHR_ray_tracing_pipeline extension supported yet or is support planned for the near future?

Closing comment (2024-04-20T21:05:41Z): Duplicate of #2455 and yes the author of the issue is working on it to my knowledge. As for whether something is planned, everything is planned.
Repository: w3c/csswg-drafts

Issue #542: [css-values] String concatentation
Created: 2016-09-28T16:03:34Z
As discussed with @tabatkins during TPAC last week.
Now with variables (custom properties), string concatenation is coming up in more and more use cases. Constructing URLs from variables for instance (see #541) is useless without concatenation.
Also, building SVG paths from variables.
Tab suggested a concat() function. I wonder if we can reuse the syntax from content which already allows for concatenation in a simple and elegant way, and special case the few cases where existing widely used property values accept <string>+ (e.g. quotes) if they are sufficiently few and concatenation isn't needed there. Sure, it's weird if concatenation doesn't work in a few places, but I think the usability benefits of doing concatenation in the same simple way that authors are already used to, are worth it. Otherwise, CSS will end up like LISP with all the parentheses (imagine things like concat(var(--text), calc(1% * var(--foo))), which will be pretty common).
Related specs:

https://www.w3.org/TR/css-values/
https://www.w3.org/TR/css-variables/

Duplicate issue #6226: [css-images-4] image() fragment cannot be created from var()
Created: 2021-04-20T02:11:48Z
The currently proposed image fragment syntax cannot be created from a css variable since css variables can't be used to create larger tokens.
Firefox's old -moz-image-rect syntax allows construction from css variables:
https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-image-rect
Codepen comparing -moz-image-rect() with the current proposed image():
https://codepen.io/jsnkuhn/pen/JjEpbwy?editors=1100
https://drafts.csswg.org/css-images-4/#image-fragments

Closing comment (2021-04-21T20:53:09Z): Yup, this is basically a dup of #542
Repository: w3c/csswg-drafts

Issue #3386: [css-nav-1] Revise selecting best candidate policy
Created: 2018-12-03T07:53:44Z
Migrated from WICG/spatial-navigation#94
Originally created by @junhoseo on Mon, 20 Aug 2018 01:57:40 GMT

Currently we consider distance and order in DOM structure. But sometimes these are not sufficient for reasonable choice.
Case 1:

In above case, distance with active element is same each other. So blue element will be selected if it is earlier element in DOM tree, and yellow element will be selected on the contrary.
Case 2:


Sometimes a focusable element can be placed inside another focusable element. In this case, should we allow focus moving to opposite element? Opposite element is not placed in direction, but partially.

Duplicate issue #3367: Revise selecting best candidate policy
Created: 2018-12-03T07:41:53Z
Migrated from WICG/spatial-navigation#94
Originally created by @junhoseo on Mon, 20 Aug 2018 01:57:40 GMT

Currently we consider distance and order in DOM structure. But sometimes these are not sufficient for reasonable choice.
Case 1:

In above case, distance with active element is same each other. So blue element will be selected if it is earlier element in DOM tree, and yellow element will be selected on the contrary.
Case 2:


Sometimes a focusable element can be placed inside another focusable element. In this case, should we allow focus moving to opposite element? Opposite element is not placed in direction, but partially.

Closing comment (2018-12-04T00:29:00Z): The issue migration script created some duplicates. #3386  is the same as this one.
So I'll close this issue.
Repository: w3c/csswg-drafts

Issue #1088: Define which subresources block the DOM load event
Created: 2017-03-08T16:31:49Z
Moving this over from https://www.w3.org/Bugs/Public/show_bug.cgi?id=17011, given that's apparently appropriate nowadays.
CSS should somewhere (hence the lack of any tagged spec!) define which subresources block the load event; at least when that bug was filed IE, Firefox, and Opera blocked the load event on background images and on web fonts loading (which is therefore related to #1082), Safari and Chrome (and this is pre-fork!) didn't, blocking only on @import.
I believe someone claimed recently that Edge matches Safari and Chrome, making Firefox the odd one out. Someone should, however, test that.

Duplicate issue #2095: [css-images] Add a way to indicate that a CSS image should be decoded asynchronously
Created: 2017-12-08T16:49:00Z
Similarly to how we're adding a way for authors to specify that content images should be able to be decoded asynchronously by the UA (whatwg/html#1920), we should add a way for authors to say that CSS images can be decoded async.
Async decoding here implies that there may be frames rendered after the time that the "load" event for an Image with the same URL as the CSS image in which the image does not appear.
This would probably be some kind of new argument to the image() function.

Closing comment (2018-06-12T17:53:03Z): Related to #1088, which is about defining what blocks the load event and what doesn't. (At the moment, per spec, CSS images can be decoded async because the spec says nothing about what blocks the load event; I believe Edge doesn't block the load event on images in CSS.)
Repository: w3c/csswg-drafts

Issue #6528: https://drafts.csswg.org/ broken
Created: 2021-08-19T17:26:55Z
2022-09-10 Update: https://w3c.github.io/csswg-drafts/ now exists as an alternative (thanks to @tabatkins and based on @andreubotella’s system from https://github.com/andreubotella/csswg-auto-build/).
So if you can’t access a CSS spec at a particular drafts.csswg.org URL, replace drafts.csswg.org in the URL with w3c.github.io/csswg-drafts and you’ll have what you need.

Duplicate issue #7275: Deployment of drafts broken?
Created: 2022-05-13T09:36:33Z
Apologies if this is the wrong place or a duplicate (I tried searching, I swear!), but:
Is the deployment of drafts currently broken?
Tried looking up https://drafts.csswg.org/css-color/ but I currently get the index:

Even went to the archive, looks like it was like that on 2022-05-07
https://web.archive.org/web/20220507061245/https://drafts.csswg.org/css-color/
but on 2022-05-05 it was fine
https://web.archive.org/web/20220505175340/https://drafts.csswg.org/css-color/
Additionally the index of all specifications linked in this repos README appears to be empty:

Closing comment (2022-05-13T10:44:18Z): This is indeed a duplicate of #6528. And unfortunately, it's not the first time this happens.
Sebastian
Repository: w3c/csswg-drafts

Issue #1198: [css-text-decor] text-underline-position auto in vertical text
Created: 2017-04-10T15:47:53Z
2.6. Text Underline Position: the text-underline-position property > Auto
https://drafts.csswg.org/css-text-decor-3/#underline-auto
If you apply text-underline-position: auto, should the underline appear on the right of Japanese (and Mongolian) text, as is recommended for the default text-decoration(-line):underline values?
If so, it would be good to make that clear (and btw how 'alphabetic baseline' relates to cjk positioning of an underline in vertical text).

Duplicate issue #10488: [css-text-decor-3] language sensitivity of text-underline-position: auto
Created: 2024-06-24T20:47:26Z
It seems that Firefox (and maybe Chrome?) implement the initial value of text-underline-position in a way that's sensitive to the language, and interprets it as right for Japanese and Korean.
This is currently not allowed per spec; instead the spec has UA rules that set the behavior per language.
Do we want to

Update the definition of auto to match Firefox?
Or update implementations to match the spec?

Closing comment (2024-06-24T20:51:22Z): Closing as dup of #1198 which is largely about this.
Repository: w3c/csswg-drafts

Issue #633: [css-fonts-4] @font-family src: should accept a specifier which lists font requirements
Created: 2016-10-21T20:14:59Z
When discussing the format() specifier with regards to font variations, we came across diverging behavior between different browsers.
There are two possible mechanisms (that I know of) for fallback:
@font-face {
    ...
    src: url("file-novariations.otf") format("opentype");
    src: url("file-variations.otf") format("opentype", "variations");
}
and
@font-face {
    ...
    src: url("file-variations.otf") format("opentype", "variations"), url("file-novariations.otf") format("opentype");
}
Currently, with either of the above examples, Edge and Firefox would download the variation font even when though those browsers don't (currently) understand variations.
The spec states:

The format hint contains a comma-separated list of format strings that denote well-known font formats. Conformant user agents must skip downloading a font resource if the format hints indicate only unsupported or unknown font formats.

This seems to imply that the format() identifier will be used if any of the arguments are known. Instead, in order to support modern and future font behaviors, web authors should be able to list the requirements that the browser needs to understand in order to use a font.
This could either be changing how format() works, adding a new specifier, or something completely different.

Duplicate issue #512: [css-fonts-4] [varfont] local() and variation fonts
Created: 2016-09-21T22:37:45Z
Migrated on behalf of @kuettel:
https://github.com/w3c/csswg-drafts/blob/master/css-fonts-4/Overview.bs#L342
While format() is being refined to support variation fonts, e.g. format ("woff-variations") or via an additional parameter (see: #513), similar consideration should be given to local().
Specifically, one should be able to use locally available variation fonts but fallback to downloading the font when the locally available font does not support variations. Perhaps via an additional parameter as well? e.g. local("full name", "variation"), which then would only use "full name" if it was variation ready.

Closing comment (2018-03-06T10:38:43Z): Duplicate of #633
Repository: w3c/csswg-drafts

Issue #1332: [css-images] Add easing functions to color stops
Created: 2017-05-08T16:10:40Z
A recent CSS-Tricks article (https://css-tricks.com/easing-linear-gradients/) and subsequent Twitter discussion (https://twitter.com/stubbornella/status/861603397677359104) spurred me to file this request for Level 4.
In summary, linear gradients are not always visually acceptable.  This is particularly true when “fading out” a dark color to transparent.  The article describes how to set up a bunch of color stops to ease out the gradient.  A much better solution would be to add easing functions to all color stops after the first, with a linear default for backward compatibility.
The example in the article could be approximated like this:
linear-gradient(to bottom, black 0%, transparent 100% ease-in-out);

…instead of the 11 color stops used to get the effect.  (Note that I don’t claim this would be a precise match; a cubic-bezier() easing would most likely be required for that.  But it would be close.)
This would change the definition of <color-stop> (https://drafts.csswg.org/css-images-3/#typedef-color-stop) from:
<color-stop> = <color> <length-percentage>?

…to the following at a minimum:
<color-stop> = <color> <length-percentage>? <timing-function>?

As an author, I would probably prefer:
<color-stop> = <color> [ <length-percentage> || <timing-function> ]?

…since that would allow me to write the easing and distance in whichever order I liked.  (For that matter, I’d prefer to be able to write all three in any order, but I don’t know if that would upset any implementors’ apple carts.)

Duplicate issue #4754: [css-images-4] Gradients need more than piecewise-linear interpolation
Created: 2020-02-07T05:50:15Z
@jrus wrote:

If you really want to make a more capable gradient capability, the most useful addition in terms of raw power/flexibility isn’t changing the color space where interpolation happens, but instead adding some facility for non-linear interpolation on each segment. For instance, allowing arbitrary cubic (or even just quadratic) polynomial segments would give the tool dramatically more flexibility for a given number of specified colors, comparable to the difference between polylines vs. Bézier splines for specifying 2D shapes.

Closing comment (2020-02-08T00:56:54Z): Yeah, closing as a dupe of #1332.
Repository: w3c/csswg-drafts

Issue #7413: [css-contain-3] Should style() queries allow !important flag?
Created: 2022-06-24T10:23:14Z
According to the current draft[1], the syntax for style features are the same as for declarations which means !important is allowed as part of the feature. I don't think that would have an effect, but would it still make sense to change the syntax to not allow it?
[1] https://drafts.csswg.org/css-contain-3/#style-container

Duplicate issue #9986: [css-contain-3] Style feature parsing should disallow !important
Created: 2024-02-21T15:52:23Z
The text says

The syntax of a <style-feature> is either the same as for a valid declaration [CSS-SYNTAX-3], a supported CSS property, or a <custom-property-name>.

and a valid declaration allows !important so I suppose it is allowed. There are even WPT subtests for it (in https://github.com/web-platform-tests/wpt/blob/master/css/css-contain/container-queries/at-container-parsing.html and https://github.com/web-platform-tests/wpt/blob/master/css/css-contain/container-queries/custom-property-style-queries.html).
Using !import here is useless and confusing though so should not be allowed.
It would probably be better to define the syntax in terms of a property name and an optional <declaration-value> instead, analogous to normal container queries. This will also easily expand to allowing range syntax for registered custom properties.

Closing comment (2024-02-22T00:20:38Z): Duplicate of #7413
Repository: watchexec/cargo-watch

Issue #52: Support for workspaces
Created: 2017-01-30T19:54:57Z
Consider adding support to use cargo watch in a workspace project.
You can see with cargo +nightly build --help the kind of options for workspace projects.

Duplicate issue #230: Support for selecting workspace package
Created: 2023-01-08T17:14:33Z
Hey! I have a workspace that contains ~5 different services, I run all of them on cargo watch. Up until 8.2.1 each command had specified directories to watch explicitly and if dependencies changed I tried to keep it relatively up to date manually.
With new release and support for local dependencies detection, I was hoping I could move away from this.
One caveat I have is that my services currently rely on being started from the root of workspace. I used to do this:
 (cd .. && cargo watch -w path/to/specific/dep --why -- cargo run -p my-service)
In the new version I'm in kind of a pickle since cargo watch relies on working directory being of a package I want to watch, but cargo run that follows must run in the root (or generally binary needs to be started with CWD being root of workspace).
In a sense this is what I'd like to achieve.
# ran from specific package 
cargo watch --why -- (cd .. && cargo run -p foo)
or
# ran from root
cargo watch -p foo --why -- cargo run -p foo
To my understanding of docs, the second one is not supported. The first one seems not to work, I couldn't figure out proper syntax that would let subshell slide.
My proposal for long term is to support specifying observed package via parameter. I am looking for advices for short term though. I'm attaching a minimal project that makes it easier to test with. The project has binary foo, and libraries a, b, c. Foo depends on a, a depends on b, c is unused. Touching particular files in the libraries helps test watch invocations of the workspace dependent on how the command was started.
temp-watch.zip

Closing comment (2023-01-08T23:42:24Z): For anything but the most basic shell shenanigans you'll want to quote the entire thing, otherwise your shell parses and runs subshells etc before even passing to cargo watch.
You're right -p isn't supported at the moment, though as the flags are already reserved, they don't throw "unknown option!" errors, a bit unfortunate. Your current workaround with manual -w should keep working for the root case. -p support is tracked in #52 though of course a lot has changed since that was first filed.
Repository: watchexec/cargo-watch

Issue #25: workflow for server development
Created: 2016-01-12T23:56:05Z
when building a server (eg: a webserver that listen on port 3000), it could be useful to automatically kill the already running server (after successful re-compilation) before starting the new one. otherwise, the server cannot start again because the old one still listen to the same port.
here is a log of what is going, if the server is not killed:
# run rshello cargo watch run
$ cargo run
   Compiling hello_world v0.0.1 (file:///app)
     Running `target/debug/hello_world`

$ cargo run
   Compiling hello_world v0.0.1 (file:///app)
     Running `target/debug/hello_world`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Os { code: 98, message: "Address already in use" } })', ../src/libcore/result.rs:738
Process didn't exit successfully: `target/debug/hello_world` (exit code: 101)
-> exit code: 101

$ cargo run
   Compiling hello_world v0.0.1 (file:///app)
     Running `target/debug/hello_world`
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Io(Error { repr: Os { code: 98, message: "Address already in use" } })', ../src/libcore/result.rs:738
Process didn't exit successfully: `target/debug/hello_world` (exit code: 101)

Duplicate issue #63: Watch isn't re-running
Created: 2017-04-15T00:34:40Z
Cargo watch doesn't appear to be working. It will compile/run my code at first, but subsequent saves to the file or touching them from the cli doesn't trigger a recompile.
I'm trying out gtk-rs and it would be great to have cargo watch recompile and run my binary each time I save my file, so I can save time iterating on the view.
I'm on Linux.
>  ~/dev/rust/clientfile-rs/uploader-gtk [master] ⚡ cargo watch --version
cargo-watch 4.0.3
>  ~/dev/rust/clientfile-rs/uploader-gtk [master] ⚡ cargo watch -x run
[Watching for changes... Ctrl-C to stop]
[Running cargo run]
   Compiling uploader-gtk v0.1.0 (file:///home/leshow/dev/rust/clientfile-rs/uploader-gtk)
warning: unused imports: `CheckMenuItem`, `IconSize`, `Image`
 --> src/main.rs:8:30
  |
8 | use gtk::{Button, ButtonExt, CheckMenuItem, ContainerExt, IconSize, Image, Inhibit, Label, Menu,
  |                              ^^^^^^^^^^^^^                ^^^^^^^^  ^^^^^
  |
  = note: #[warn(unused_imports)] on by default

    Finished dev [unoptimized + debuginfo] target(s) in 1.89 secs
     Running `target/debug/uploader-gtk`

(.:14491): Gtk-WARNING **: Attempting to add a widget with type GtkBox to a container of type GtkWindow, but the widget is already inside a container of type GtkWindow, please remove the widget from its existing container first.
^C

Closing comment (2017-04-15T07:47:03Z): For that first issue (not working with the native backend), can you provide logs with RUST_LOG=cargo_watch=debug set? For that second issue (no stoppage), that's a duplicate of #25.