profile
viewpoint

tangmi/node-gameloop 31

an accurate game loop for nodejs

tangmi/animal-id 4

an generator for easily recognizable ids

tangmi/decors 2

a simple, temporary, and reusable reverse proxy, with benefits

tangmi/collab-sequencer 1

a collaborative music sequencer built for people who want to collaboratively sequence music

tangmi/hotswap-csharp 1

experiment to get hot swap code reloading in c#

tangmi/node-autohttp 1

dumb attempt to automatically make nice client-side function for calling server code

ElliotSchmelliot/Foodleator 0

Allows for recipe/meal/list creation

gglover/wow 0

Music app that lets you

tangmi/awesome-rust 0

A curated list of Rust code and resources.

startedperkeep/perkeep

started time in 10 days

issue openedmicrosoft/vscode-remote-release

Cannot connect to Windows host that has busybox installed

<!-- Please search existing issues to avoid creating duplicates. --> <!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

VSCode Remote SSH doesn't seem to want to connect to a Windows host that has busybox installed. Removing busybox resolves the issue.

  • VSCode Version: 1.46.1
  • Local OS Version: macOS Mojave 10.14
  • Remote OS Version: Windows 10.0.19041.330
  • Remote Extension/Connection Type: SSH/Docker/WSL: SSH

Steps to Reproduce:

  1. Install busybox on Windows host (I use scoop: scoop install busybox)
  2. Try to connect from the client, noting the output:
...
[11:24:27.982] stderr> Authenticated to hostname ([hostname]:22).
[11:24:28.008] > Microsoft Windows [Version 10.0.19041.330]
> (c) 2020 Microsoft Corporation. All rights reserved.
[11:24:28.009] > 
> user@HOST C:\Users\user>echo 'ready: a76b3d6ea503'
[11:24:28.011] > 'ready: a76b3d6ea503'
> 
> user@HOST C:\Users\user>
[11:24:28.013] > uname -rsv
[11:24:28.057] > Windows_NT 10.0 19041
[11:24:28.062] > 
> user@HOST C:\Users\user>
[11:24:44.563] Terminating local server
[11:24:44.566] Resolver error: Connecting with SSH timed out
[11:24:44.570] ------




[11:24:44.575] Local server exit: 15

I can tell from the log that the VSCode Remote calls uname (included in busybox), which seems to execute fine. I can even do echo uname -rsv | ssh hostname and get the same output as above. I'm not sure what VSCode Remote does next--I can't seem to find the source for this extension(?)--but it looks like it hangs with no output on the next prompt and times out.

In case it helps, busybox adds the following programs to the path: [, [[, ar, arch, ash, awk, base64, basename, bash, bunzip2, busybox, bzcat, bzip2, cal, cat, chmod, cksum, clear, cmp, comm, cp, cpio, cut, date, dc, dd, df, diff, dirname, dos2unix, dpkg, dpkg-deb, du, echo, ed, egrep, env, expand, expr, factor, false, fgrep, find, fold, fsync, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, hd, head, hexdump, httpd, iconv, id, inotifyd, ipcalc, kill, killall, less, link, ln, logname, ls, lzcat, lzma, lzop, lzopcat, man, md5sum, mkdir, mktemp, mv, nc, nl, od, paste, patch, pgrep, pidof, pipe_progress, pkill, printenv, printf, ps, pwd, readlink, realpath, reset, rev, rm, rmdir, rpm, rpm2cpio, sed, seq, sh, sha1sum, sha256sum, sha3sum, sha512sum, shred, shuf, sleep, sort, split, ssl_client, stat, strings, su, sum, tac, tail, tar, tee, test, time, timeout, touch, tr, true, truncate, ts, ttysize, uname, uncompress, unexpand, uniq, unix2dos, unlink, unlzma, unlzop, unxz, unzip, usleep, uudecode, uuencode, vi, watch, wc, wget, which, whoami, whois, xargs, xxd, xz, xzcat, yes, zcat.

<!-- Check to see if the problem is general, with a specific extension, or only happens when remote --> Does this issue occur when you try this locally?: Yes(?) Does this issue occur when you try this locally and all extensions are disabled?: Yes

Thanks!

created time in 11 days

push eventtangmi/scoop-extras

Michael Tang

commit sha 41c8b3ecda97ebae987532059a29f0e0b24333e5

joyshockmapper: Add version 1.6.0

view details

push time in 11 days

push eventtangmi/scoop-extras

push time in 11 days

create barnchtangmi/scoop-extras

branch : add-joyshockmapper

created branch time in 11 days

push eventtangmi/scoop-extras

Michael Tang

commit sha 0ca8fc7502643477c0003d1d782a534ae450f9c5

joyshockmapper: Add version 1.6.0

view details

push time in 11 days

PR opened lukesampson/scoop-extras

joyshockmapper: Add version 1.6.0
+17 -0

0 comment

1 changed file

pr created time in 11 days

push eventtangmi/scoop-extras

Michael Tang

commit sha 0093821f7acc8b75208244cd934dd013e12aef09

joyshockmapper: Add version 1.6.0

view details

push time in 11 days

fork tangmi/scoop-extras

"Extras" bucket for Scoop

fork in 11 days

issue commentservo/pathfinder

Shaders not easy to compile on windows

I believe it also needs spirv-cross (which I've learned is available along with glslangValidator via the Vulkan SDK), make, and some various coreutils tools.

I've been able to build with bash on WSL by appending .exe to glslangValidator and spirv-cross in the Makefile (I haven't installed either binary within WSL itself).

I've also been able to build on Windows (without WSL) with these steps:

  • Install the Vulkan SDK, ensuring the bin (e.g. C:\VulkanSDK\1.2.135.0\Bin\) folder in in my $PATH.
  • Install busybox (I did so with scoop: scoop install busybox)
  • Run ash -c 'make --jobs all' or sh -c 'make --jobs all'

This does change the line endings , but otherwise results in the same shaders.

I will note that I did not notice ./resources/shaders/README.md until now, instead expecting it to be at ./shaders/README.md. I'm happy to close this issue, since the docs do exist, but I'm also happy to add some docs detailing my Windows steps.

tangmi

comment created time in 11 days

startedathensresearch/athens

started time in 12 days

startednannou-org/nannou

started time in 20 days

startedturnage/valora

started time in 20 days

startediPlug2/iPlug2

started time in 23 days

issue commentservo/pathfinder

WebGPU backend

I've been hacking on this when I find the time, but no big progress to report. I'm still mostly stuck on the shaders-- @pcwalton would you consider using uniform buffers for pathfinder (as opposed to separate uniforms)? I believe while most APIs support free-standing uniform/constants, many prefer--at least in documentation--the buffer-based methods (I believe there's a perf argument as well, but I'll admit I don't know more than being told, "that's how GPUs work").

Unfortunately WebGPU doesn't seem to support the individual uniforms. If we stick to the current API, we'd have to modify the all the shaders with boilerplate to wrap each uniform in an interface block and rely on something like spirv-cross to flatten the buffers for non-WebGPU backends... I don't personally like any attempt I made at this, but I'd love your thoughts on the best way to make shaders work for WebGPU.

As a mostly unimportant aside: uniform blocks/constant buffers are technically a D3D10 feature level (well, SM4, I guess) so it could still fit with the Device::feature_level() reporting!

tangmi

comment created time in 23 days

issue openedgrovesNL/spirv_cross

Rerun spirv_cross/wasm and commit changes

@grovesNL This issue is a reminder to regenerate the pre-built wasm blobs for the additional GLSL options/functions added in https://github.com/grovesNL/spirv_cross/pull/145#pullrequestreview-420596647.

Thanks!

created time in a month

pull request commentgrovesNL/spirv_cross

Add missing GLSL compiler option fields/methods

@grovesNL Let me know if there's anything else I can do!

tangmi

comment created time in a month

push eventtangmi/spirv_cross

Michael Tang

commit sha 94d4595e4d7faf86e79c5502614a8522c96d869e

Explicitly specify variable values for Precision

view details

push time in a month

pull request commentrust-windowing/winit

Remove lifetime from `Event` type

@Osspial On macOS, EventProxy is unconditionally buffered, so we can either pass through the ScopedArcCell owner with the proxy or just create a new ScopedArcCell, since we're at the point where the user callback runs synchronously (and can resize the window with the user-specified size immediately following).

On Windows, the send_event here:

https://github.com/rust-windowing/winit/blob/03335cef851495e0a2843db7019516988740688b/src/platform_impl/windows/event_loop.rs#L1717

may happen synchronously or asynchronously, if the event_handler is currently in use. I think even if we pass the ScopedArcCell owner with the buffered event, the code that responds to the user-specified size may have already passed if the event ends up being buffered. Thoughts?

tangmi

comment created time in a month

startedtgjones/shader-playground

started time in a month

push eventtangmi/spirv_cross

Michael Tang

commit sha af1b1ddacc804d479ed31749d56d7499f9bab2f5

Add wasm functions

view details

push time in a month

push eventtangmi/spirv_cross

Michael Tang

commit sha 3df669ec64495c5c35c2b1944425df0f21df168b

Add CompilerGLSL functions: add_header_line, flatten_buffer_block

view details

push time in a month

push eventtangmi/pathfinder

Michael Tang

commit sha 28f6dc0f60a7514576cf9501cf7abe1dc70f18d8

Fix build from compute shader changes

view details

Michael Tang

commit sha 80d5fe642aa820b96d8924b138424de2a0a362c7

Add autogenerated notice to shader gen

view details

push time in a month

issue commentservo/pathfinder

WebGPU backend

@cart how did you end up dealing with "non-opaque uniforms outside a block"? Making all the uniforms into interface blocks will be a breaking change for the gl/webgl backends, even with spirv_cross' emit_uniform_buffer_as_plain_uniforms option. Additionally, many of the vertex and fragment shaders don't share the exact same set of uniforms, causing linking errors (e.g. "struct type mismatch between shaders for uniform (named globals)")

Apologies if this is pretty basic GL knowledge--most of my experience is in HLSL (and up-to-date GLSL literature seems hard for me to find :grin:)

tangmi

comment created time in a month

push eventtangmi/spirv_cross

Michael Tang

commit sha 15746b38bb6cc9280ccc5e188380765ec6bbf409

Fix build, add additional test

view details

push time in a month

PR opened grovesNL/spirv_cross

Add missing GLSL compiler option fields

Hi! I noticed that spirv_cross is missing some of the GLSL compiler options in the C++ header. Is this something spirv_cross is interested in?

Some design decisions to note (and nitpick!):

  • CompilerGLSL::Options::Precision is marshalled through wrapper.{cpp,hpp} as a uint8_t
  • This is a breaking change, as it adds fields to a pub struct.
    • I think there's a pattern that can avoid this in the future, involving an unused private field which forces users to do the ..Default::default().
  • I ran bindings_generator on a Windows machine, which changed all the enum representations to i32. I'm assuming it was originally generated on macOS (from __darwin_size_t), so I didn't commit the non-ScGlslCompilerOptions changes.
  • I've added a test for the extra field I needed, but I'm happy to add more.

Thanks for the awesome library!

+164 -6

0 comment

6 changed files

pr created time in a month

create barnchtangmi/spirv_cross

branch : add-glsl-compiler-options

created branch time in a month

issue commentlukesampson/scoop

When installing LLVM 10.0.0, no llvm-config shim is created

Not entirely sure why, but llvm-config doesn't seem to be included in the pre-build binaries for Windows: https://stackoverflow.com/a/60024490

The "solution" seems to be to build LLVM from source. :/

tommywalkie

comment created time in a month

issue commentservo/pathfinder

Shaders not easy to compile on windows

The build.rs could use crates that do the clone/build of dependant repos for you (to OUT_DIR), like shaderc (this still requires cmake and ninja, however). I have a build script like this working in my branch: https://github.com/tangmi/pathfinder/blob/23e23db0997db99a1ae34abe28f442416188a56e/shaders/build.rs using shaderc as the glsl -> spirv compiler and spirv-cross for cross-compilation. (sample output also commited on that branch: e.g. gl3/tile.fs.glsl).

The background for this change is that I need SPIR-V shaders for the WebGPU backend (for separate samplers/textures, uniform blocks, etc), but I'm much more comfortable writing Rust than I am writing Makefiles... Happy to change it back to a Makefile (with guidance!) if my WebGPU backend is successful!

tangmi

comment created time in a month

push eventtangmi/pathfinder

Michael Tang

commit sha 77c920d8c7aadd51f2fa08432aaa2cb7568dd3e9

Reorder formats

view details

Michael Tang

commit sha 6a79248d32d8a810bdeadece83d8b73e5a2660d3

Merge branch 'webgpu-backend' of github.com:tangmi/pathfinder into webgpu-backend

view details

Michael Tang

commit sha dc2d2f692c8d45393b20ab9c0dbc9b4394b561b6

Add env_log for vulkan debugging

view details

Michael Tang

commit sha 23e23db0997db99a1ae34abe28f442416188a56e

alternate shader pipeline

view details

push time in a month

issue openedservo/pathfinder

Shaders not easy to compile on windows

I'm trying to modify the shaders in pathfinder (for the webgpu backend) on a Windows machine and am running into issues running the Makefile (not pathfinder's fault, just the normal issues with running make on Windows, like missing unix tools, etc).

Would pathfinder consider letting this part of the pipeline be ported to Rust?

Some pros:

  • It could include the required compilers (through glslang_sys and spirv_cross or something like shaderc) through a crate, so contributors don't need to install a compatible version on their system
  • Could be configured as a build.rs script to automatically rebuild shaders if they change
  • Hopefully will be more cross-platform than a Makefile (and more approachable to Rust folks who may not have Makefile experience!)

Cons:

  • Would bloat the dependency size/build time for most contributors that do not need to modify shaders
  • This is potentially over-engineering a solution to a problem that I'm the only one experiencing. :smiley:

Thanks!

created time in 2 months

push eventtangmi/pathfinder

Patrick Walton

commit sha 84bf4341c253ae36756d27671a17cb44d59cd250

Micro-optimize line fill primitive generation to avoid calls to `floorf()` and `ceilf()`

view details

Patrick Walton

commit sha ac83f79d94cd8ab2c8186e5344a9225831fd7505

Add a compute shader path, optimize GPU memory management, and switch from SDL to `surfman`. This is a large commit; explanations of each change follow. This adds an optional compute shader path, off by default, for rendering fills to alpha masks. It usually does not improve performance at present, but it provides a good baseline for further optimizations. Later improvements will likely aim to avoid writes to the mask texture entirely. Supporting infrastructure for compute shader has been added to `pathfinder_gpu` for the OpenGL and Metal backends. The Metal backend has been optimized to avoid unneccessary buffer allocations and reflection. As part of this, argument buffers have been removed, as the current SPIRV-Cross compiler no longer requires them. The GPU renderer has been improved to avoid stalls. Now, separate buffers are allocated for each fill batch and for each frame. This can be extended in the future to allow for separate buffers for tile draw operations as well. SDL usage has been removed in favor of the native Rust `surfman` and `winit`. Because `surfman` allows for selection of the integrated GPU on multi-GPU system, it is chosen by default. The demo supports a new `--high-performance-gpu` option to opt into the discrete GPU.

view details

Patrick Walton

commit sha b335f79f7714aed9b111516e605b7650065dfb97

Remove references to SDL from the README

view details

Patrick Walton

commit sha da2f65ddf481df99a8ea45814d38abc92ac49eff

Fix `surfman` reference in `Cargo.toml`

view details

Patrick Walton

commit sha d0842f2f4dc0108c8fa775fcc22e839a6447f692

Generalize the buffer allocator to support multiple size classes, and use it for tile compositing too.

view details

Patrick Walton

commit sha 9ff3248e9eed781c52746b677774d07524d27c11

Merge pull request #314 from pcwalton/size-classes Generalize the buffer allocator to support multiple size classes, and use it for tile compositing too

view details

Patrick Walton

commit sha 0545d840dbd4719c11949cb004a8cb782c6791fc

Reduce timing jitter in the Metal backend

view details

Patrick Walton

commit sha a373a1fbc380264fbd38a866d5993b6358f0b926

Merge pull request #315 from pcwalton/metal-timing Reduce timing jitter in the Metal backend

view details

Patrick Walton

commit sha 6407bf58719729436e9e8dc33a596355a1863f55

Reduce the size of buffers

view details

Patrick Walton

commit sha f8405d81c02db180100b9b02055a295cbe7f595a

Bump the number of fills per batch up

view details

Patrick Walton

commit sha c7ce2153de7dc5f1d095aeb1f88676176102ef69

Merge pull request #316 from pcwalton/reduce-buffer-size Reduce the size of buffers for performance

view details

Patrick Walton

commit sha 478008dcf079656eb93f70bec26ec846b9ea2bad

Use all four channels in the mask texture. Each bundle of four pixels on a scanline is packed into the RGBA channels of the mask texture. The area LUT is also expanded to be RGBA so that four pixels' worth of areas can be looked up at once. Nice improvement on `paris-30k` from MPVG. Closes #262.

view details

Patrick Walton

commit sha cfc1d446381b3aeb519621a04042284990916c01

Merge pull request #317 from pcwalton/four-at-a-time Use all four channels in the mask texture.

view details

Patrick Walton

commit sha 520817e909e04b30a42da345c011bdd9b2938143

Add OpenGL 4.3 support to the GL backend, enabling compute shader on non-Metal platforms

view details

Patrick Walton

commit sha 371c8533700edc6974d77402be47cb31b906c361

Merge pull request #319 from pcwalton/gl4 Add OpenGL 4.3 support to the GL backend, enabling compute shader on non-Metal platforms

view details

Patrick Walton

commit sha 6299d2c36b96463962ad56903c80fefad184a3e7

Clear the canvas to the background color if no drawing command did so. Closes #318.

view details

Patrick Walton

commit sha 46070914be2962254c98965bf8513c5b0f8da428

Merge pull request #320 from pcwalton/painting-nothing Clear the canvas to the background color if no drawing command did so.

view details

Patrick Walton

commit sha e766721f37fe629bd9d8483a5fba1f55163aa868

Update `README.md`

view details

Patrick Walton

commit sha 2421de6616ddbc4b215aa911fb6a96be84b49596

Enable compute shader by default if the OpenGL version is high enough.

view details

Patrick Walton

commit sha 90fb36f1996389fb500e6c4101be1c1bf445196a

Switch to using surfman in X11 mode. Partially addresses #310.

view details

push time in 2 months

issue commenthecrj/iced

Hot reloading of layout

I think something like that world work! To support non-num-primitives, I think it'd still need Any... we're getting into weird territory, but maybe something like this?

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=082e30cb889efedf3b83d0b4e9471f51

PvdBerg1998

comment created time in 2 months

issue commenthecrj/iced

Hot reloading of layout

I think the attribute would need to take &dyn Any (+ Clone?), otherwise, I'm not sure what an implementation could look like

struct Foo {
    val: i32,
}

impl Attribute for Foo {
    fn set_attribute<T>(&mut self, attribute: String, value: T) {
        if attribute == "val" {
            self.val = value; // self.val expects `i32`, value is `T`. !!
        }
    }
}
PvdBerg1998

comment created time in 2 months

issue commentgodotengine/godot

WebGPU support

Also worth noting that many folks are hard at work on defining and implementing WGSL, which the cross-platform (yes, even Apple!) shading language WebGPU will adopt: https://gpuweb.github.io/gpuweb/wgsl.html

Type1J

comment created time in 2 months

issue commenthecrj/iced

Hot reloading of layout

(Be aware this is a half-baked idea)

I think I mean some consistent mapping from markup elements to code. E.g. If all widgets provide an "attribute setter" interface (e.g. Widget::set_attribute(attribute_name: &str, attribute_value: _)), then it's pretty feasible to go from

Button(
    content: Text("button"),
    on_click: "ButtonClicked",
    disabled: false, // <- I know this isn't how `Button` handles disabled currently!
),

to

let markup_element = todo!("deserialized from file");

let mut button = Button::with_state(widgets_state.get(markup_element.get_id()));
button.set_attribute("content", get_element(markup_element.get("content"));
button.set_attribute("on_click", get_callback(markup_element.get("on_click")));
button.set_attribute("disabled", markup_element.get("disabled"));

without any special understanding of Button. We just need to know that widgets have attributes that can be set (compared to my prototype, which needs to know about every widget, which is an unbounded set if we include user implementations of iced_native::widget::Widget).

...although I'm unsure how to make this typesafe! The widget might need to have some manifest declaring its attributes and the types of its attributes? Maybe through some code generation (this would require changes in iced)?

PvdBerg1998

comment created time in 2 months

issue commenthecrj/iced

Hot reloading of layout

@hecrj I'll keep poking at this when I can find time. I think the main takeaway from my investigation is that both a markup language and hotswapping can probably be developed as a library with no* changes in iced needed (great work on library design!).

*I think some mechanically consistent declaration of widgets and their state/attributes (not sure what this looks like!) can help simplify the markup language implementation and allow for custom widgets.

PvdBerg1998

comment created time in 2 months

issue commenthecrj/iced

Hot reloading of layout

Glad you like it! Thanks for the feedback!

I like the idea of hiding Hotswapo behind a separate Application trait opening up the possibility for transparent hotswapping in debug builds for the user.

For the markup side, I was imagining two "runtimes":

  • Dynamic: one with a similar lineage to the prototype--intended to load dynamically and have additional hot-swapping abilities at the cost of performance depredations.
    • This is the one hotswapping would use.
  • Static: a compile-time affair that generates rust code for the view (that includes the branching as rust control flow) and a struct that contains the ephemeral state (please correct me if there's a better name for this) of exactly the widgets that appear in the markup file.
    • In this case, I don't think the user needs to provide widget state, which is an otherwise very mechanical action (every widget one adds needs its associated state, it's very unlikely that two separate widgets want to share the same state, etc).
    • This is the one non-hotswapping (release builds?) would use.

In both cases, the result would be a function something like fn view(&loaded_layout, &mut user_state) -> Element<'_, M>. I might be handwaving the difficulty of implementation/maintaining cost this dual-action runtime, but I believe some combo dynamic/static layout file solution gets us both perf and flexibility.

PvdBerg1998

comment created time in 2 months

push eventtangmi/iced-hotswap-prototype

Michael Tang

commit sha 36f353be919a85fd397b4d781cbda32ae7fd0c59

Update README.md

view details

push time in 2 months

push eventtangmi/iced-hotswap-prototype

Michael Tang

commit sha aa4bdfebaab494a8973e38d7768f2eb055a8012c

Update README.md

view details

push time in 2 months

push eventtangmi/iced-hotswap-prototype

Michael Tang

commit sha 371d2afb3efe5e6b46a06c5d37ac4bedb4b3437e

wake the app every 500ms to pickup file changes

view details

push time in 2 months

push eventtangmi/iced-hotswap-prototype

Michael Tang

commit sha 6ce682f582bb867604ce9181a25042f853a0c980

edit ron file

view details

push time in 2 months

push eventtangmi/iced-hotswap-prototype

Michael Tang

commit sha 52bc01f20e07393d1e028ef2305eb171ba4bf0b8

remove unused field

view details

push time in 2 months

issue commenthecrj/iced

Hot reloading of layout

https://github.com/tangmi/iced-hotswap-prototype

Here's a working proof-of-concept of the following features:

  • Ron-based markup language templated with handlebars
    • currently supports what's in iml::Element: Column, Row, Text, Button, Slider (with minimal parameters)
    • resolves templates with user-provided state
  • automatically creates, owns, and maintains widget "ephemeral" state (i.e. button::State)
  • resolves callbacks with user-provided "message" struct
  • can read values from user-provided state

Some caveats:

  • I'm heavily leveraging serde's code generation to e.g. discover the variants of a user-provided messages enum.
  • A lot of features are missing
  • no errors are handled gracefully (if you spell your markup file wrong, it'll immediately crash).
  • I'm abusing std::mem::transmute in a couple places to avoid "solving" where to put lifetime annotations
  • After saving the file, one needs to interact with the app (mouseover) to get it to reload. This could be fixed by implementing a Subscription that watches the file system
PvdBerg1998

comment created time in 2 months

push eventtangmi/iced-hotswap-prototype

Michael Tang

commit sha c48479c17721d1d2392d1745aa77fcd87d4be7aa

comments

view details

push time in 2 months

create barnchtangmi/iced-hotswap-prototype

branch : master

created branch time in 2 months

created repositorytangmi/iced-hotswap-prototype

created time in 2 months

startedOTTO-project/OTTO

started time in 2 months

issue commenthecrj/iced

Hot reloading of layout

I'm taking a stab at this and I'll upload what I have once I get a bit more working, but I'll try and enumerate what I've learned so far.

I think this requires two main components:

  1. Markup/templating language: Something like XAML, JSX, Handlebars + HTML, etc. I think this is a very useful component for iced to have, regardless of hot swap capabilities.
    • The template engine needs to support some control flow (if, for each, etc) based on user state.
    • The runtime component of the markup language needs to:
      • Resolve custom widgets into iced::Elements.
        • This might need widgets to have some declarative metadata describing attributes and events, which would allow custom and "builtin" widgets to be treated the same
      • Store/reference widget state. (Note: This could happen automatically! It'd be an awesome gain for iced user producivity!)
      • Reference message construction functions for callbacks.
        • This probably needs reflection (codegen or runtime).
          • I'm currently playing around with a HashMap<String, &dyn Any> that the app fills on initialization and downcasting to the exact function pointer type, but am running into an issue with Any::downcast to a function pointer.
          • Also going to look into leveraging serde's codegen to generate messages.
    • This could probably be built as a library, given changes in iced for support.
  2. Hot reload runtime component: This will actually do the hotswapping of the resolved markup and ends up being pretty trivial (file watcher with an optional code recompiler) once we have the markup language.
    • This can probably be done as a library, with minimal or no support needed in iced itself.
    • I can imagine a setup where the layout itself is reloaded from the markup language (almost) instantly and when state/callbacks change the entire app could be recompiled and the binary hotswapped in, preserving app state.

Some additional notes:

  • My current prototype uses ron as the markup "language" and can currently generate/reload non-interactive stateless views. Most features I described above are not implemented.
  • It'd be nice to eventually include the markup language and reloading as "blessed" crates.
  • I'm currently ignoring the issue of how to make this zero/low overhead in release builds.

@hecrj What are your thoughts on an iced layout markup language? I'll happily file an issue with all the details/prototype I have if you're into it.

PvdBerg1998

comment created time in 2 months

issue commentrust-windowing/winit

WinRT instead of Win32

If MS wants apps to move towards WinRT going forward, having winit support seems to me like a "nice to have".

I don't imagine (just guessing, though!) other targets like mobile, xbox, hololens, etc are built on Win32 like the desktop target is, so supporting those platforms with winit would need a WinRT backend. It might be worth it to revisit WinRT support when Rust/WinRT has all the needed interfaces exposed.

davidhewitt

comment created time in 2 months

issue commentrust-windowing/winit

WinRT instead of Win32

@tim-weis Does winit's Win32 backend allow one to build for a uwp target (and, for example, publish on the Microsoft Store)? If not, would a WinRT backend allow for that?

davidhewitt

comment created time in 2 months

issue commentrust-windowing/winit

`raw_window_handle`

I think the intention is to have your library consume raw_window_handle::HasRawWindowHandle (which winit::Window is), then match on the resulting raw_window_handle::RawWindowHandle:

// Note this code doesn't need to know about winit directly!
fn get_hwnd(has_raw_window_handle: impl raw_window_handle::RawWindowHandle) -> HWND {
  match has_raw_window_handle.raw_window_handle() {
    raw_window_handle::RawWindowHandle::Windows(windows_handle) => windows_handle.hwnd,

    // If you'd like to handle other operating system's window handles, you can match on other `RawWindowHandle` variants.
    _ => panic!("unsupported os"),
  }
}

At first glance, this seems a lot more clunky than what was previously there, but it lets the rust-windowing and gfx-rs ecosystems iterate without codepending on specific versions of each other and allows compatibility with external, unrelated libraries.

kulicuu

comment created time in 2 months

pull request commentrust-windowing/winit

Remove lifetime from `Event` type

Open questions:

  • Should the iOS/macOS event proxies be removed? Do types like this exist in the linux/android backends?
  • Untested on the linux/ios/android backends
tangmi

comment created time in 2 months

push eventtangmi/winit

Michael Tang

commit sha 9c0490316c1a4ff55f6da18da48d0089a59720ff

Fix x11 build

view details

push time in 2 months

push eventtangmi/winit

Michael Tang

commit sha a7f96fd7962cfbeaa85d95101fd04d90975985da

Whoop! Fix some missed build breaks

view details

push time in 2 months

push eventtangmi/winit

Michael Tang

commit sha 28684cd230b78c9d8f66fdb35d181cda2d2752e2

Make web target build

view details

Michael Tang

commit sha c28fc7690e52bcc0b5738c8e5e53b479a2e2542e

windows: rename of variable names

view details

Michael Tang

commit sha 3477339646c9f3477705423f9940c73a5c315e13

Merge remote-tracking branch 'origin/remove-lifetime-from-event-proto' into remove-lifetime-from-event-proto

view details

Michael Tang

commit sha 2fa7e68d1e757f798928e977ee026a26e6c39d1f

Use scopes instead of std::mem::drop for iOS/macOS/Windows backends

view details

Michael Tang

commit sha 428455c4482ccc120d094e865ef38d4186ad8515

Attempt implementation at linux/andoid backends

view details

push time in 2 months

push eventtangmi/winit

Michael Tang

commit sha fef925dca8d7af64019579d10683d80afc7a4620

Implement macOS backend support

view details

Michael Tang

commit sha 1841bd6023e2fec8563ef4a78d2d184974726632

Implement iOS backend support

view details

push time in 2 months

Pull request review commentrust-windowing/winit

Remove lifetime from `Event` type

 pub enum WindowEvent<'a> {     ThemeChanged(Theme), } -impl<'a> WindowEvent<'a> {-    pub fn to_static(self) -> Option<WindowEvent<'static>> {+use std::{+    cell::Cell,+    fmt::Debug,+    sync::{Arc, Mutex},+};++// TODO naming+#[derive(Debug, Clone)]+pub struct NewInnerSizeInteriorMutCoolThing {+    inner: Arc<Mutex<NewInnerSizeInteriorMutCoolThingInner>>,+}++#[derive(Debug, Clone)]+struct NewInnerSizeInteriorMutCoolThingInner {+    /// TODO doc this uses interior mutability in `set_inner_size`!+    new_inner_size: Cell<PhysicalSize<u32>>,++    /// If the event that this originated from was handled, this struct is essential read-only. Once this field is `true`, no further calls to `set_inner_size` will succeed.+    is_readonly: bool,

Is it sufficient to require all backends to call some function to mark this as "consumed" and thus immutable (including any stray clones)? If Event is passed to the user by reference, we could hijack the Clone impl here to only allow the original value to be mutable... but each implementation of EventLoop::run would need to know of that requirement.

tangmi

comment created time in 5 months

Pull request review commentrust-windowing/winit

Remove lifetime from `Event` type

 pub enum WindowEvent<'a> {     ThemeChanged(Theme), } -impl<'a> WindowEvent<'a> {-    pub fn to_static(self) -> Option<WindowEvent<'static>> {+use std::{+    cell::Cell,+    fmt::Debug,+    sync::{Arc, Mutex},+};++// TODO naming+#[derive(Debug, Clone)]+pub struct NewInnerSizeInteriorMutCoolThing {+    inner: Arc<Mutex<NewInnerSizeInteriorMutCoolThingInner>>,+}

I think your ScopedArcCell's owner/ownee split types is definitely better than what I have. For the time being I plan on copy/pasting it into my winit branch just to reduce friction, but I'm happy to resolve where it should live before this branch is published

tangmi

comment created time in 2 months

Pull request review commentrust-windowing/winit

Remove lifetime from `Event` type

 struct EventLoopRunner<T: 'static> {     runner_state: RunnerState,     modal_redraw_window: HWND,     in_modal_loop: bool,-    event_handler: Box<dyn FnMut(Event<'_, T>, &mut ControlFlow)>,+    event_handler: Box<dyn FnMut(Event<T>, &mut ControlFlow)>,     panic_error: Option<PanicError>,     redraw_buffer: Rc<RefCell<VecDeque<WindowId>>>, } pub type PanicError = Box<dyn Any + Send + 'static>; +// TODO can this be consolidated if we dont have a lifetime?

I'll be honest, I don't remember what I meant here... is it that BufferedEvent existed to separate out a static lifetime'd Event and the potentially un-static lifetime'd ScaleFactorChagned event, but now we don't have a need for BufferedEvent and any users can use Event directly?

tangmi

comment created time in 2 months

Pull request review commentrust-windowing/winit

Remove lifetime from `Event` type

 pub enum WindowEvent<'a> {     ThemeChanged(Theme), } -impl<'a> WindowEvent<'a> {-    pub fn to_static(self) -> Option<WindowEvent<'static>> {+use std::{+    cell::Cell,+    fmt::Debug,+    sync::{Arc, Mutex},+};++// TODO naming

InnerSizeCell or something?

Semantics are: "A cell containing a PhysicalSize<u32>. It can only be mutated with Self::set_inner_size during the event loop callback in which it originated."

tangmi

comment created time in 5 months

Pull request review commentrust-windowing/winit

Remove lifetime from `Event` type

 pub enum WindowEvent<'a> {     ThemeChanged(Theme), } -impl<'a> WindowEvent<'a> {-    pub fn to_static(self) -> Option<WindowEvent<'static>> {+use std::{+    cell::Cell,+    fmt::Debug,+    sync::{Arc, Mutex},+};++// TODO naming+#[derive(Debug, Clone)]+pub struct NewInnerSizeInteriorMutCoolThing {+    inner: Arc<Mutex<NewInnerSizeInteriorMutCoolThingInner>>,+}++#[derive(Debug, Clone)]+struct NewInnerSizeInteriorMutCoolThingInner {+    /// TODO doc this uses interior mutability in `set_inner_size`!+    new_inner_size: Cell<PhysicalSize<u32>>,++    /// If the event that this originated from was handled, this struct is essential read-only. Once this field is `true`, no further calls to `set_inner_size` will succeed.+    is_readonly: bool,+}++pub struct NewInnerSizeInteriorMutCoolThingIsReadonlyNowError;++impl Debug for NewInnerSizeInteriorMutCoolThingIsReadonlyNowError {+    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {+        write!(f, "todo error message, but this new_inner_size cell is being mutated after winit has consumed it, so there will be no effect on the window")+    }+}++/// Manually implement `PartialEq` to treat `Self` like just a `PhysicalSize<u32>`.+///+/// Ignores the `Mutex` (i.e. unconditionally locks).+impl PartialEq<NewInnerSizeInteriorMutCoolThing> for NewInnerSizeInteriorMutCoolThing {+    /// Note: will deadlock when `other` == `self`!

can be avoided with Arc::ptr_eq(&self.inner, &other.inner)?

tangmi

comment created time in 5 months

Pull request review commentrust-windowing/winit

Remove lifetime from `Event` type

+use winit::dpi::LogicalSize;

This file should probably include a more realistic example of how to use the ScaleFactorChanged event that shows why it exists.

tangmi

comment created time in 5 months

pull request commentrust-windowing/winit

Remove lifetime from `Event` type

@Osspial: turns out most of my changes was just the "interior mut cool thing", which you've greatly improved.

Latest changes:

  • rebased onto master
  • copy Osspial/scoped_arc_cell into code and modify for winit usage
  • remove unused/obsolete code (mostly clone/to_static impls)

I'll try and work my way through the various backends, may need some help with e.g. android (or permission to spam you with github actions emails)

tangmi

comment created time in 2 months

push eventtangmi/winit

Kirill Chibisov

commit sha 83b60beba6ef53a10e3fa63eb0716372268ba199

on Wayland, Add HiDPI cursor support (#1454) Fixes #727.

view details

Philippe Renon

commit sha f0093d3c54b3e03a154c14f24555ed7df1c166e7

rename dpi_factor to scale_factor where appropriate (#1463) fixes https://github.com/rust-windowing/winit/issues/1457

view details

Philippe Renon

commit sha 505f312d5f1ef303e219c3293cf64c8cdb573cd6

Add new example that demonstrates the different control flow schemes (#1460) User can switch between Wait, WaitUntil and Poll modes with key '1', '2' and '3' respectivly. User can toggle request_redraw calls with the 'R' key. Helpful for testing all control flow modes and use of request_redraw.

view details

Philippe Renon

commit sha bc29931434a6c6c445f382fce9731311ebfbbf7f

Add an example that calls request_redraw() from a thread (#1467) reproduces https://github.com/rust-windowing/winit/issues/1466

view details

Héctor Ramón

commit sha e88e8bc1942865098b98419f6f7f07f73fc26179

Map `UserEvent` properly in `Event::to_static` (#1468)

view details

daxpedda

commit sha d1073dcecb4590a9764435f5e5bf01e3e7c5fd91

Implement ThemeChanged for web target. (#1462) * Implement ThemeChanged for web target. * Add TODO upstream to stdweb. Co-authored-by: Ryan G <ryanisaacg@users.noreply.github.com>

view details

Kirill Chibisov

commit sha 76d0dd7ec36dc129f39dc201d490f6cd1dd457c4

On Wayland, Hide CSD for fullscreen windows (#1473)

view details

Philippe Renon

commit sha 522a6e329873720899241ca5516aae7138b351c3

fix issues in wait_until_time_or_msg function (#1423) also removed unused return value

view details

Murarth

commit sha 9999f533291f3964721fa7a4677fc425b0463bb7

X11: Fix deadlock when an error occurs during startup (#1475)

view details

Murarth

commit sha 2b14ec23d54384d574a23dca4d73dc44a072bd46

Fix GitHub Actions (#1479) * Replaces `actions/checkout@v1` with `actions/checkout@v2` to get a bug fix

view details

HeroicKatora

commit sha ece2e70a53fd469341e89e2bbc293910882d6d6c

Update image to 0.23 (#1485) Also makes use of a few ergonomics improvements that were introduced or optimized in the more recent version.

view details

Philippe Renon

commit sha b8326f6452550908fd79b76084450a688b0cc41e

In control_flow example, don't schedule a new WaitUntil if wait was cancelled (#1482)

view details

Philippe Renon

commit sha 71bd6e73caac91b3be46d42545e40918a8d2ca70

windows: ignore spurious mouse move messages (#1435) Fixes https://github.com/rust-windowing/winit/issues/1428

view details

Murarth

commit sha e707052f66045a096a391e8d23cc41cba100db5f

Move `ModifiersChanged` variant to `WindowEvent` (#1381) * Move `ModifiersChanged` variant to `WindowEvent` * macos: Fix flags_changed for ModifiersChanged variant move I haven't look too deep at what this does internally, but at least cargo-check is fully happy now. :) Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * macos: Fire a ModifiersChanged event on window_did_resign_key From debugging, I determined that macOS' emission of a flagsChanged around window switching is inconsistent. It is fair to assume, I think, that when the user switches windows, they do not expect their former modifiers state to remain effective; so I think it's best to clear that state by sending a ModifiersChanged(ModifiersState::empty()). Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * windows: Fix build I don't know enough about the code to implement the fix as it is done on this branch, but this commit at least fixes the build. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * windows: Send ModifiersChanged(ModifiersState::empty) on KILLFOCUS Very similar to the changes made in [1], as focus is lost, send an event to the window indicating that the modifiers have been released. It's unclear to me (without a Windows device to test this on) whether this is necessary, but it certainly ensures that unfocused windows will have at least received this event, which is an improvement. [1]: f79f21641a31da3e4039d41be89047cdcc6028f7 Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * macos: Add a hook to update stale modifiers Sometimes, `ViewState` and `event` might have different values for their stored `modifiers` flags. These are internally stored as a bitmask in the latter and an enum in the former. We can check to see if they differ, and if they do, automatically dispatch an event to update consumers of modifier state as well as the stored `state.modifiers`. That's what the hook does. This hook is then called in the key_down, mouse_entered, mouse_exited, mouse_click, scroll_wheel, and pressure_change_with_event callbacks, which each will contain updated modifiers. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * Only call event_mods once when determining whether to update state Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * flags_changed: Memoize window_id collection Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * window_did_resign_key: Remove synthetic ModifiersChanged event We no longer need to emit this event, since we are checking the state of our modifiers before emitting most other events. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * mouse_motion: Add a call to update_potentially_stale_modifiers Now, cover all events (that I can think of, at least) where stale modifiers might affect how user programs behave. Effectively, every human-interface event (keypress, mouse click, keydown, etc.) will cause a ModifiersChanged event to be fired if something has changed. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * key_up: Add a call to update_potentially_stale_modifiers We also want to make sure modifiers state is synchronized here, too. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * mouse_motion: Remove update_potentially_stale_modifiers invocation Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * Retry CI * ViewState: Promote visibility of modifiers to the macos impl This is so that we can interact with the ViewState directly from the WindowDelegate. Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * window_delegate: Synthetically set modifiers state to empty on resignKey This logic is implemented similarly on other platforms, so we wish to regain parity here. Originally this behavior was implemented to always fire an event with ModifiersState::empty(), but that was not the best as it was not necessarily correct and could be a duplicate event. This solution is perhaps the most elegant possible to implement the desired behavior of sending a synthetic empty modifiers event when a window loses focus, trading some safety for interoperation between the NSWindowDelegate and the NSView (as the objc runtime must now be consulted in order to acquire access to the ViewState which is "owned" by the NSView). Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com> * Check for modifiers change in window events * Fix modifier changed on macOS Since the `mouse_entered` function was generating a mouse motion, which updates the modifier state, a modifiers changed event was incorrectly generated. The updating of the modifier state has also been changed to make sure it consistently happens before events that have a modifier state attached to it, without happening on any other event. This of course means that no `CursorMoved` event is generated anymore when the user enters the window without it being focused, however I'd say that is consistent with how winit should behave. * Fix unused variable warning * Move changelog entry into `Unreleased` section Co-authored-by: Freya Gentz <zegentzy@protonmail.com> Co-authored-by: Kristofer Rye <kristofer.rye@gmail.com> Co-authored-by: Christian Duerr <contact@christianduerr.com>

view details

Christian Duerr

commit sha cbb60d29a21401461e23aa86d71c733076046476

Remove assertions from Windows dark mode code (#1459) * Remove assertions from Windows dark mode code In general, winit should never assert on anything unless it means that it is impossible to continue the execution of the program. There are several assertions in the Windows dark mode code where this is not the case. Based on surface level inspection, all existing assertions could be easily replaced with just simple conditional checks, allowing the execution of the program to proceed with sane default values. Fixes #1458. * Add changelog entry * Format code * Pass dark mode by mutable reference * Format code * Return bool instead of mutable reference * Fix dark mode success reply Co-Authored-By: daxpedda <daxpedda@gmail.com> * Fix dark mode success reply * Replace magic integers with constants Co-authored-by: daxpedda <daxpedda@gmail.com>

view details

Philippe Renon

commit sha 2f27f64cdb69978151e6b8e941658b7e742b1135

On Windows, fix request_redraw() related panics (#1461) * On Windows, fix request_redraw() related panics These panics were introduced by https://github.com/rust-windowing/winit/commit/6a330a2894873d29fbbfdeebfc1a215577213996 Fixes https://github.com/rust-windowing/winit/issues/1391 Fixes https://github.com/rust-windowing/winit/issues/1400 Fixes https://github.com/rust-windowing/winit/issues/1466 Probably fixes other related issues See https://github.com/rust-windowing/winit/issues/1429 * On Windows, replace all calls to UpdateWindow by calls to InvalidateRgn This avoids directly sending a WM_PAINT message, which might cause buffering of RedrawRequested events. We don't want to buffer RedrawRequested events because: - we wan't to handle RedrawRequested during processing of WM_PAINT messages - state transitionning is broken when handling buffered RedrawRequested events Fixes https://github.com/rust-windowing/winit/issues/1469 * On Windows, panic if we are trying to buffer a RedrawRequested event * On Windows, move modal loop jumpstart to set_modal_loop() method This fixes a panic. Note that the WM_PAINT event is now sent to the modal_redraw_method which is more correct and avoids an unecessary redraw of the window. Relates to but does does not fix https://github.com/rust-windowing/winit/issues/1484 * On Window, filter by paint messages when draining paint messages This seems to prevent PeekMessage from dispatching unrelated sent messages * Change recently added panic/assert calls with warn calls This makes the code less panicky... And actually, winit's Windoww callbacks should not panic because the panic will unwind into Windows code. It is currently undefined behavior to unwind from Rust code into foreign code. See https://doc.rust-lang.org/std/panic/fn.catch_unwind.html * add comments to clarify WM_PAINT handling in non modal loop * made redraw_events_cleared more explicit and more comments

view details

David Hewitt

commit sha 098fd5d602ee3b20372048db35aa3de432884aaa

Add ability to create Icons from embedded resources on Windows (#1410) * Add IconExtWindows trait * Move changelog entries to unreleased category Co-authored-by: Osspial <osspial@gmail.com>

view details

Osspial

commit sha b1d8ce24e901ef813064defe3c62f7d23d1fe04c

Use i32 instead of u32 for position type in WindowEvent::Moved (#1502) * Use i32 instead of u32 for position type in WindowEvent::Moved * Mark change as breaking

view details

Imberflur

commit sha e85a80dd65945bebc22c19736b92713ffc20c06d

Fix freeze when pressing modifier keys on Windows (#1503)

view details

Kirill Chibisov

commit sha b208daa271c8840a8c767601656944df57cfb520

Revert "on MacOS, Fix not sending ReceivedCharacter event for s… (#1501) This reverts commit 9daa0738a9aeb60768d9b7d19f4e3deddd55958b. This commit introduced other bug #1453 with likely much more common bindings, so reverting it for now. Fixes #1453. Co-authored-by: Osspial <osspial@gmail.com>

view details

push time in 2 months

pull request commentrust-windowing/winit

Remove lifetime from `Event` type

@Osspial no worries at all for the response times! I know we're all busy (and the world is especially weird right now!).

I'll need to take some time myself to re-review this changelist to remember what I was doing and clean it up. If my "todo" list is accurate, I need to finish the remaining platforms, and do some bookkeeping/docs/tests.

tangmi

comment created time in 2 months

startedpksunkara/cargo-workspaces

started time in 2 months

Pull request review commentrust-unofficial/awesome-rust

Add link to the RustAudio/cpal library, group RustAudio libraries together

 See also [About Rust’s Machine Learning Community](https://medium.com/@autumn_ * [jpernst/alto](https://github.com/jpernst/alto) — OpenAL 1.1 bindings [<img src="https://api.travis-ci.org/jpernst/alto.svg?branch=master">](https://travis-ci.org/jpernst/alto) * [musitdev/portmidi-rs](https://github.com/musitdev/portmidi-rs) — [PortMidi](http://portmedia.sourceforge.net/portmidi/) bindings [<img src="https://api.travis-ci.org/musitdev/portmidi-rs.svg?branch=master">](https://travis-ci.org/musitdev/portmidi-rs) * [hound](https://crates.io/crates/hound) — A WAV encoding and decoding library [<img src="https://api.travis-ci.org/ruuda/hound.svg?branch=master">](https://travis-ci.org/ruuda/hound)-* [RustAudio/rodio](https://github.com/RustAudio/rodio) — A Rust audio playback library [![Build Status](https://api.travis-ci.org/RustAudio/rodio.svg?branch=master)](https://travis-ci.org/RustAudio/rodio) * [RustAudio](https://github.com/RustAudio)+  * [RustAudio/cpal](https://github.com/RustAudio/cpal) - Low-level cross-platform audio I/O library in pure Rust. [![Actions Status](https://github.com/RustAudio/cpal/workflows/cpal/badge.svg)](https://github.com/RustAudio/cpal/actions)

Thanks for the review, I've added a branch specification

tangmi

comment created time in 2 months

push eventtangmi/awesome-rust

Michael Tang

commit sha 785424e174b7c0a885ae5c412524bb691fa4a45b

Add branch to cpal badge image

view details

push time in 2 months

push eventtangmi/awesome-rust

Michael Tang

commit sha 7c559439ef2db0a44025902edf26877fb68e264e

Specify branch in CI badge

view details

push time in 2 months

PR opened rust-unofficial/awesome-rust

Add link to the RustAudio/cpal library, group RustAudio libraries together

cpal is the library that powers the higher-level rodio. It is a pure Rust alternative to something like PortAudio.

+2 -1

0 comment

1 changed file

pr created time in 2 months

push eventtangmi/awesome-rust

Michael Tang

commit sha 387d05d87e23fa57e80e1e8124af0e5f1739e25d

Add link to the RustAudio/cpal library `cpal` is the library that powers the higher-level `rodio`. It is a pure Rust alternative to something like PortAudio.

view details

push time in 2 months

PR opened rust-unofficial/awesome-rust

Add link to gfx-rs/wgpu library

The gfx-rs group is investing a lot of effort in WebGPU with their library, wgpu. wgpu is the lowest-level "safe" graphics available, runs both on and off the web, and is generally more approachable to more kinds of users than gfx-hal.

+1 -0

0 comment

1 changed file

pr created time in 2 months

push eventtangmi/awesome-rust

Michael Tang

commit sha 7142d38da321973783c624b25a29c01af8dd4f89

Add link to gfx-rs/wgpu library The gfx-rs group is investing a lot of effort in WebGPU with their library, wgpu. wgpu is the lowest-level "safe" graphics available, runs both on and off the web, and is generally more approachable to more kinds of users than gfx-hal.

view details

push time in 2 months

fork tangmi/awesome-rust

A curated list of Rust code and resources.

fork in 2 months

pull request commentservo/pathfinder

Support Strict 32 Bit Alignment Platforms

My plan for the wgpu backend (untested!) was to use Char2 and UChar2 where pathfinder wants the scalar variants (same with Char3, etc) and just let the let the extra components of one value overlap the next value (hopefully none of the wgpu/gfx-hal implementations with check and complain!). If this doesn't work, @kvark's proposal of splatting (or zeroing) the pathfinder buffers to a supported WebGPU format would work fine, I think.

I'm also hoping to take advantage of some of the jank of shader inputs binding... in my experience the cpu vertex attribute layout and shader declarations don't need to agree. I think this quickly goes into undefined behavior territory, but should (??) be safe if the shader declares fewer components than the cpu vertex attribute. @kvark do you have thoughts/ideas on this? My goal here is to avoid needing to modify the shaders for WebGPU if I can.

cart

comment created time in 2 months

startedP1start/drawille-rs

started time in 2 months

startedRustAudio/rust-lv2

started time in 2 months

issue commentservo/pathfinder

WebGPU backend

It looks like some of the texture formats should be supported by the spec (https://gpuweb.github.io/gpuweb/#texture-formats), but e.g. WebGPU doesn't seem to have support for many 3-component formats, like rgb8

tangmi

comment created time in 2 months

push eventtangmi/pest

Michael Tang

commit sha 12de8dcbb977fbd59965711c2870feaadb26031b

Expose LinesSpan

view details

push time in 2 months

push eventtangmi/pest

Michael Tang

commit sha 3dc681e2b53d428a549e1b94f7ddbe31b9097d76

Fix case in LinesSpan iterator when the end of iteration is a partially covered line

view details

push time in 2 months

push eventtangmi/pest

Michael Tang

commit sha 5c6546e082531f3bc837b46d5ec52e4e04010934

Make lifetime restrictions less strict

view details

push time in 2 months

issue openedservo/pathfinder

WebGPU backend

Hi, I've been playing around with implementing a WebGPU backend using wgpu-rs. I'm basing my current work a lot off the metal backend (in my mind, WebGPU is a very slightly more spartan version of Metal...).

I have some questions:

  • Is a WebGPU backend something that pathfinder is interested in?
  • Is the Metal backend a reasonable basis for implementation ideas? (I've noticed there's some issues building the shaders due to missing parts in the Metal steps)

My current progress is here: https://github.com/servo/pathfinder/compare/master...tangmi:webgpu-backend, and I've run into some issues like: WebGPU doesn't support some attribute types pathfinder uses (e.g. Char1, Short1, etc) and needing SPIR-V (wgsl, maybe?) shaders and reflection info (which either needs a runtime solution or a way to pack that info into the compiled shader resources).

Thanks for your time and for working on this awesome project!

created time in 2 months

push eventtangmi/pathfinder

Michael Tang

commit sha 62f682939cda7364d448ac309933e7f9af4628ef

wip

view details

push time in 2 months

push eventtangmi/pathfinder

Michael Tang

commit sha 770ffe947882c85c8a9c90ebc6367a5e3ef69a0c

Compile and add spir-v shaders

view details

push time in 2 months

issue openedfish-shell/fish-shell

Autosuggestions do not appear when cursor passes the fish_right_prompt

<!--i Please tell us which fish version you are using by executing the following:

fish --version echo $version

Please tell us which operating system and terminal you are using. The output of uname -a and echo $TERM may be helpful in this regard although other commands might be relevant in your specific situation.

Please tell us if you tried fish without third-party customizations by executing this command and whether it affected the behavior you are reporting:

sh -c 'env HOME=$(mktemp -d) fish'

Tell us how to reproduce the problem. Including an asciinema.org recording is useful for problems that involve the visual display of fish output such as its prompt. -->

$ fish --version
  echo $version
fish, version 3.1.0
3.1.0

$ uname -a
Darwin Mac.local 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64

$ echo $TERM
xterm-256color
function fish_prompt
    echo -n "\$ "
end

function fish_right_prompt
    set --local pwd (prompt_pwd)
    set --local prompt_len 2
    set --local rpadding (math -- $COLUMNS - (string length $pwd) - $prompt_len - 2)
    set_color $fish_color_autosuggestion
    echo -n $pwd(string repeat --count $rpadding " ")
    set_color normal
end

created time in 2 months

create barnchtangmi/pathfinder

branch : webgpu-backend

created branch time in 2 months

fork tangmi/pathfinder

A fast, practical GPU rasterizer for fonts and vector graphics

fork in 2 months

pull request commentpest-parser/pest

Implement `Span::sub_span` and `Span::lines_span`.

Some concerns I have (that may not actually be real issues):

  • Is Span intended to be consumable by users in this way? My assumption is that pest expects/allows users to create Span, given that Span::new is exposed (although I'm proposing this PR because Span::new is difficult to use with a parsed document since Span::input is not exposed).
  • I didn't put much thought into the naming of new members
    • Span::sub_span would be called Span::get to parallel str::get (there is no "substring" method in std, just range indexing)
    • LinesSpan was just named as such to avoid changing the name of Lines.
tangmi

comment created time in 2 months

PR opened pest-parser/pest

Implement `Span::sub_span` and `Span::lines_span`.

Prototype implementation for #455

+99 -4

0 comment

1 changed file

pr created time in 2 months

issue openedpest-parser/pest

Expose more ways for users to manipulate Span

I often find myself reaching for pest::span::Span to keep a mapping back to the parsed source file. I sometimes run into issues because Span::input is not pub.

I'd like to propose adding two methods to Span to give it more flexibility for users:

  • fn sub_span(&self, range: impl std::ops::RangeBounds<usize>) -> Option<Span>
    • Allows one to sub-slice a Span, returning a smaller span (or "substring") which preserves the original Span's input.
  • pub fn lines_span(&self) -> LinesSpan
    • where LinesSpan is an iterator, much like pest::span::Lines, but returns Span instead of &str.
    • Lines can be implemented as span.lines_span().map(|span| span.start_pos().line_of())

Thanks for your time!

created time in 2 months

push eventtangmi/pest

Michael Tang

commit sha 3450f7d3ad5b18a8f29f74d5f76b64c55a4bd340

Fix subspan range bug

view details

push time in 2 months

create barnchtangmi/pest

branch : span_extras

created branch time in 2 months

fork tangmi/pest

The Elegant Parser

https://pest.rs

fork in 2 months

push eventtangmi/dotfiles

Michael Tang

commit sha e6d2f40e1d77876fbe27b03fcfc7e7fc6c7a70a2

Simplify, switch to fish

view details

push time in 3 months

issue commentrust-lang/rustfmt

[unstable option] report_todo

I wonder if something changed (I haven't followed the history pre-crate split)?

Here is where rustfmt matches on the "todo" string:

https://github.com/rust-lang/rustfmt/blob/1e9af9fa2eb6ba4e0ad1e2e275003ada7e5a27e2/rustfmt-core/rustfmt-lib/src/issues.rs#L123-L137

... and where it calls into that code:

https://github.com/rust-lang/rustfmt/blob/1e9af9fa2eb6ba4e0ad1e2e275003ada7e5a27e2/rustfmt-core/rustfmt-lib/src/formatting.rs#L523

It seems like in formatting.rs/issue.rs needs to keep track of whether or not the TODO exists in a comment (or if doing something like unimplemented!("TODO(#1234): ...") or todo!("TODO(#1234): ...") is intended behavior...

scampi

comment created time in 3 months

more