profile
viewpoint
James Gilles kazimuth Cambridge, MA irrelevant sadboy

jdf/processing-py-site 128

Site for processing.py.

jdf/Processing.py-Bugs 36

A home for all bugs and feature requests about Python Mode for the Processing Development Environment.

kazimuth/baked_fluent 7

Easy i18n for serverside rust

kazimuth/askama 1

Type-safe, compiled Jinja-like templates for Rust

kazimuth/dwarffortress.vim 1

Dwarf Fortress raw file plugin for Vim

kazimuth/gandyloo 1

Curses client for MIT 6.005 Minesweeper server

kazimuth/.spacemacs.d 0

MOVED: see kazimuth/dotfiles

push eventkazimuth/nannou

James Gilles

commit sha 4a6fb0d3ecfe598d50cb73ba7cdb342e4687511b

rustfmt

view details

push time in a day

PR opened nannou-org/nannou

wgpu 0.6, third time's the charm

This is a PR building on @alekspickle's work in #655. All major issues fixed, I had to make some fairly large changes to cope w/ wgpu adding an alignment requirement on buffers used in texture-buffer copies.

Remaining work:

  • [ ] new API bikeshedding
  • [ ] address remaining TODOs
  • [ ] get wgpu texture sequence example working (currently crashing with OOM for some reason)
  • [ ] add tests for a variety of image sizes on new alignment logic (how should I write tests that use GPU?)
+956 -774

0 comment

35 changed files

pr created time in a day

push eventkazimuth/nannou

James Gilles

commit sha 236efb605f403919a3d381a8027a637c7a4f3910

More work integrating RowPaddedBuffer

view details

James Gilles

commit sha f85974c50231e36d4c009a7d7fccd78f4d983b60

wip

view details

James Gilles

commit sha 8a1a3c2738476198c2cc7691c262c6c1979417df

Get wgpu examples working!

view details

James Gilles

commit sha 46d721a70bcf9b7e7be8407f256a9567e887f8f8

A couple texture array fixes

view details

push time in a day

push eventkazimuth/nannou

James Gilles

commit sha 0f2a35f81aa930dff980b7eac260461b6a4cb4ad

WIP: Add RowPaddedBuffer to comply with new wgpu invariants

view details

push time in 2 days

push eventkazimuth/nannou

James Gilles

commit sha 8a8f958ddf5a79ba465a741b99fccb38a20b38d1

WIP: Add RowPaddedBuffer to comply with new wgpu invariants

view details

push time in 2 days

push eventkazimuth/nannou

James Gilles

commit sha bcfc42120adf8415adaa6947f9ee51a016c7eda1

Start work on handling buffer pitch

view details

James Gilles

commit sha afa77a6411825b454a6ca50d59e590517b38b02f

WIP: Add RowPaddedBuffer to comply with new wgpu invariants

view details

push time in 2 days

issue openednannou-org/nannou

Consider moving wgpu helpers to separate module

Currently, nannou reexports a modified version of wgpu with a bunch of extra features added, including renaming some wgpu structs. I think this could be confusing for someone e.g. reading the wgpu documentation. It's definitely been confusing to me while working on the code for #655 :)

Since #655 involves a bunch of breaking changes for the wgpu API anyway, I think (after #655 is merged) it might be reasonable to do another PR after it's merged that changes nannou's wgpu reexport to be just wgpu::*, and then make a separate module with helper functionality.

created time in 5 days

issue closedgfx-rs/wgpu

`wgpu_render_pass_insert_debug_marker` outputs garbled text for multiple markers

Description I'm debugging a wgpu application with RenderDoc, I noticed that inserting multiple debug markers into a single render pass results in strange output.

Repro steps Note: I found this via wgpu-rs but I believe the issue is with wgpu-core. I ran the following code, integrated into a larger example that submitted and ran the render pass every frame.

render_pass.insert_debug_marker("this is a test");
render_pass.insert_debug_marker("hello");
render_pass.insert_debug_marker("how are you");
render_pass.insert_debug_marker("i love to walk on the beach and feed seagulls to the clams");

Expected vs observed behavior When I run the example and capture a frame with RenderDoc, I see the following debug output:

this is a test
this 
this is a t
this is a testhellohow are youi love to walk on the beach

As opposed to what it should be.

Extra materials The error is in the following pieces of code:

https://github.com/gfx-rs/wgpu/blob/f963193be193022fb02ac85d5d0fb3088bf7373e/wgpu-core/src/command/render.rs#L1943-L1957

https://github.com/gfx-rs/wgpu/blob/f963193be193022fb02ac85d5d0fb3088bf7373e/wgpu-core/src/command/render.rs#L1523-L1528

Because the InsertDebugOutput struct only keeps track of the length of the message and not its starting point, subsequent debug messages after a first one will slice through previous messages before getting to their own content.

Platform OpenSUSE Tumbleweed, Mesa Vulkan, wgpu-rs 0.6.0, wgpu-core 0.6.4, wgpu-types 0.6.1

closed time in 6 days

kazimuth

delete branch kazimuth/wgpu

delete branch : fixdebug

delete time in 6 days

push eventkazimuth/nannou

James Gilles

commit sha 8c76f31f5eab66cd1fa72ab9e51f36641aba6382

Fix images not rendering, add some more labels to Nannou wgpu items.

view details

push time in 7 days

push eventkazimuth/nannou

James Gilles

commit sha 3d335983647068e0f449374808d2f8dca0ecf463

Fix images not rendering.

view details

push time in 7 days

PR opened gfx-rs/wgpu

Fix debug markers in render passes (#981)

Hey, that was easy. Didn't change anything in the debug groups markers / command pass markers, since afaict they work correctly.

I didn't add a test here because I'm not sure how to use the player testing apparatus, but I figure since I'm just adding a line of code that's already there for compute passes (here) it should be alright. Let me know if there's anything else I should add.

+1 -0

0 comment

1 changed file

pr created time in 7 days

push eventkazimuth/wgpu

James Gilles

commit sha 05c58e805b6c5735f6eece263d2ec4969a4f642f

Fix garbled debug markers in render passes

view details

push time in 7 days

create barnchkazimuth/wgpu

branch : fixdebug

created branch time in 7 days

fork kazimuth/wgpu

Native WebGPU implementation based on gfx-hal

fork in 7 days

issue openedgfx-rs/wgpu

`wgpu_render_pass_insert_debug_marker` outputs garbled text for multiple markers

Description I'm debugging a wgpu application with RenderDoc, I noticed that inserting multiple debug markers into a single render pass results in strange output.

Repro steps Note: I found this via wgpu-rs but I believe the issue is with wgpu-core. I ran the following code, integrated into a larger example that submitted and ran the render pass every frame.

render_pass.insert_debug_marker("this is a test");
render_pass.insert_debug_marker("hello");
render_pass.insert_debug_marker("how are you");
render_pass.insert_debug_marker("i love to walk on the beach and feed seagulls to the clams");

Expected vs observed behavior When I run the example and capture a frame with RenderDoc, I see the following debug output:

this is a test
this 
this is a t
this is a testhellohow are youi love to walk on the beach

As opposed to what it should be.

Extra materials The error is in the following pieces of code:

https://github.com/gfx-rs/wgpu/blob/f963193be193022fb02ac85d5d0fb3088bf7373e/wgpu-core/src/command/render.rs#L1943-L1957

https://github.com/gfx-rs/wgpu/blob/f963193be193022fb02ac85d5d0fb3088bf7373e/wgpu-core/src/command/render.rs#L1523-L1528

Because the InsertDebugOutput struct only keeps track of the length of the message and not its starting point, subsequent debug messages after a first one will slice through previous messages before getting to their own content.

Platform OpenSUSE Tumbleweed, Mesa Vulkan, wgpu-rs 0.6.0, wgpu-core 0.6.4, wgpu-types 0.6.1

created time in 7 days

pull request commentnannou-org/nannou

Wgpu 0.6

Update: all compile errors fixed on my branch!

...Now we just have to address the runtime errors :sweat_smile:

Things that need to be addressed:

  • All of the examples result in blank screens. I'll do some poking around in RenderDoc, bet there's a new flag somewhere with the wrong value.
  • There's now a 256-byte alignment requirement for texture-to-buffer and buffer-to-texture copies, which breaks Capturer. We might be able to fix this by just... padding and reshaping the textures? Not sure.
  • In general, the tires should probably get kicked a little more. Going through and running different examples is probably a good idea.
alekspickle

comment created time in 7 days

push eventkazimuth/nannou

James Gilles

commit sha a835061121e53e3346bd19142b77ce23084fc49b

Fix all compile errors?

view details

James Gilles

commit sha 50fb0d66924f21cb548f355fde4763a62a50c42e

Fix remaining warnings

view details

James Gilles

commit sha 14b1a3cfd40718a0702355b578fdd0d4b7840256

Update nannou_timeline to use conrod 0.71

view details

James Gilles

commit sha abb885959b0dd18b97bf3e933495c3b239a55aab

Add nannou::util::{DeviceExt, BufferInitDescriptor} to prelude

view details

James Gilles

commit sha 0ec7d4aaf9a9b745f307d1ccce7187b388a790b1

Fix all example compile errors

view details

push time in 7 days

pull request commentnannou-org/nannou

Wgpu 0.6

New work: https://github.com/alekspickle/nannou/compare/wgpu-0.6...kazimuth:wgpu-0.6-3

Don't merge it yet, I still need to make the changes with Buffer borrows.

alekspickle

comment created time in 7 days

push eventkazimuth/nannou

Aleks Pickle

commit sha f2971d19a760796fd35d78a5b4b5a9e19f540964

Merge pull request #1 from kazimuth/wgpu-0.6-redux Wgpu 0.6 redux

view details

Aleks Pickle

commit sha bee17800c4072fbc4fd22f8a5bd0bfcf6674c76d

fix spirv

view details

Aleks Pickle

commit sha 2cfd3dc3b1ca0f14453448e225f78455c3f626d1

create buffer new way; fix mapping field

view details

James Gilles

commit sha f05cd4fe4660b3e5350e5e1c4c5b7a7df010770f

Update for cosmetic wgpu API changes

view details

James Gilles

commit sha 5911b5a8c9ff603e01a62681d63c6d659acd3520

Fix almost all remaining errors

view details

James Gilles

commit sha df4d376a9d4287e7582becbc2c731a7552681960

Add wgpu::Instance to App

view details

push time in 7 days

push eventkazimuth/nannou

James Gilles

commit sha bcbb3cb72f9b66de607156569810225f4aa74e3b

Add wgpu::Instance to App

view details

push time in 8 days

push eventkazimuth/nannou

James Gilles

commit sha d47537c4ee7b8d810b25c58fe3e8dc33048cf0ef

Add wgpu::Instance to App

view details

push time in 8 days

create barnchkazimuth/nannou

branch : wgpu-0.6-3

created branch time in 8 days

pull request commentnannou-org/nannou

Wgpu 0.6

Update: apparently array_layer_count now only exists on TextureViews. A Texture may be 1d, 2d, or 3d, but only a texture view can be an array, cubemap, or cube array. I think I'll update the API to reflect this.

alekspickle

comment created time in 8 days

pull request commentnannou-org/nannou

Wgpu 0.6

@mitchmindtree it's probably doable.

Other question: the array_layer_count attribute was removed from TextureDescriptor in 0.6, but it was kept on TextureViewDescriptor. Unfortunately the texture builder code seems to use that attribute a lot. I'm not sure what to substitute to keep the logic the same. Do you have any idea what's going on there? I'm not all that familiar with array textures. I'd read the spec, but... well...

alekspickle

comment created time in 9 days

startedscikit-hep/awkward-1.0

started time in 10 days

startedjpivarski/PartiQL

started time in 10 days

issue commentnannou-org/nannou

Reduce build times for both `nannou` and projects created via `nannou-new`

I use a single project with a set of examples for my sketches, which allows them to re-use compiled dependencies. A workspace would also work; you'd just need to make sure to modify the right

See also my comment on #387, allowing nannou-new to use lld should speed up initial as well as incremental compiles. It does require that the user install lld though.

mitchmindtree

comment created time in 11 days

issue commentnannou-org/nannou

hot/live reloading or faster compile?

See #387.

(I've had luck applying the instructions under "enable fast compiles" here.)

mlg556

comment created time in 11 days

startedraphlinus/crochet

started time in 11 days

issue commentnannou-org/nannou

Improving iterative compile times for projects depending on nannou

See also the "enable fast compiles" section of the Bevy setup guide: https://bevyengine.org/learn/book/getting-started/setup/

mitchmindtree

comment created time in 11 days

pull request commentnannou-org/nannou

Wgpu 0.6

@alekspickle I think that's because rustc was dying before it got to those errors, so you wouldn't get the error messages. I get them too, will hold off on trying to fix if you're working on it. (You're welcome to merge my changes into this PR if you want, no pressure though.)

@mitchmindtree Doing a more in-depth read of the code, lifetimes will need to be added to:

  • BufferBytes
  • BufferImage
  • Snapshot
  • Rgba8ReadMapping
  • Rgba8AsyncMappedImageBuffer Specifically, they all need to have the lifetime of the Buffer that is being read. That Buffer is ultimately created in Capturer::capture(). So unfortunately, there isn't really a way to pass them back to the user while using that lifetime. You'd need to either:
  1. use one of those monstrosity crates that allow self-referential structs and return them as a bundle
  2. make the api two-step: have the user call one thing to hold the Buffer, and then another call receives that as a reference and returns a Snapshot that borrows it... asynchronously.
  3. switch the API to only use callbacks that receive a Snapshot.

Of these options, I think the third is probably the simplest, both from an implementation and use perspective.

alekspickle

comment created time in 11 days

pull request commentnannou-org/nannou

Wgpu 0.6

I was interested in this for my own reasons (wanted to try some new wgpu-0.6 stuff in my sketches :), spent some time poking through this PR.

@alekspickle:

But it would be cool if someone point me out on why it is stuck compiling nannou...

This happens on my machine too. It looks like rustc is hanging! Somewhere in the texture management code. It's weird, I've never seen that happen before. I think it's because type resolution gets confused inside one of the async methods? Definitely a compiler bug of some kind.

I made some changes here to fix that. I also went and changed some of the lifetimes assuming that the wgpu Descriptor objects would have 'static labels, which simplifies things a lot. There's a fresh wall of errors to dig through now, which is exciting :) I'm thinking of poking at that some more this weekend, but if you'd rather be in charge let me know @alekspickle .

Also, it does appear that there are some architectural changes in 0.6 that need to be handled.

  • create_surface is now an unsafe function on Instance. So I think we'll need to take the Instance created here and store it... somewhere, not sure where that should go. Maybe just in App, or as part of the device map? @mitchmindtree , do you have thoughts?
  • BufferReadMapping and BufferWriteMapping have been replaced with BufferSlice, which carries a lifetime. That means that ImageReadMapping and Rgba8ReadMapping will need to grow lifetimes as well. Not sure if that'll have any larger impact.
alekspickle

comment created time in 11 days

create barnchkazimuth/nannou

branch : wgpu-0.6-redux

created branch time in 11 days

delete branch kazimuth/nannou

delete branch : wgpu-0.6-2

delete time in 11 days

push eventkazimuth/nannou

Stephan Lagerwaard

commit sha 041602b50951b3ceedea73165d9a3fcee2ab91d9

Fix orientation of the teapot y axis in wgpu_instancing example

view details

jozanza

commit sha 8ff9a4ab8ab6cbcaa295f6727a45f56f396adeb1

Add tutorial for drawing images

view details

jozanza

commit sha a9a22ac620f7a3ef6d7076591f6a566b145c4743

Fix drawing images tutorial linting

view details

Josiah Savary

commit sha fb9769a58744680d1b0f627e5af993c106927ebb

Remove color of empty window Seems like it is probably not consistent across different platforms

view details

Josiah Savary

commit sha 438547ef6eb5a2a195f5e4d2a4b81f286ac027f2

Convert -type to type Avoid breaking IntelliJ's markdown renderer

view details

Josiah Savary

commit sha f2e15c22e320f749f5ee38219730e2cf10a54a98

Merge scaffolding code with windowing code block

view details

Josiah Savary

commit sha 70b77226e7d94fe3a8fb4f7e51922542bf43291a

Describe expected result of Setting up a Texture

view details

Josiah Savary

commit sha d3044ee18791d70a77dd6cf5714ae0a7b93f34cb

Add a note about the assets_path method

view details

Josiah Savary

commit sha a71a7eba5c562d85d76f65ecd0518b0963900687

Fix typo

view details

Josiah Savary

commit sha 30c182db2f5c1cd53d423e90ec431d068201906d

Update drawing-images.md

view details

Josiah Savary

commit sha 6353068a5d7af35a0ebe6c986112db9407209e6d

Briefly explain textures

view details

mitchmindtree

commit sha c140324495207c37656cad8c134b4772c0c14ef8

Add CONTRIBUTING.md. Add Contributing chapter to guide. This new chapter provides the following: - A small overview of nannou's codebase and how it is managed (git and PRs). - A **PR Checklist** page for use as a reference/reminder before opening PRs. - A **PR Reviews** page for tips on how to speed up reviews and make sure they go smoothly. - A **Publishing New Versions** page to inform contributors how they can get a new version of nannou published. I think a lot of this could be improved and fleshed out a little further, but hopefully this makes for a decent start! Related to #553 but still some good ideas there that are not quite implemented. Maybe it could be closed in favour of opening up specific issues for each "contributing chapter" feature?

view details

mitchmindtree

commit sha 1294e614badc2ceb6d412010ef65935357a8e223

Merge pull request #650 from jozanza/drawing-images-tutorial Add tutorial for drawing images

view details

mitchmindtree

commit sha c473e9bebf09ca7bb166090930191dedef4fdf3d

Merge pull request #656 from mitchmindtree/contributing Add CONTRIBUTING.md. Add Contributing chapter to guide.

view details

mitchmindtree

commit sha a69fc65f0d102d3f77bc2f0bf5e5f510c001315f

Merge pull request #622 from stephlow/wgpu-instancing-orientation Fix orientation of the teapot y axis in wgpu_instancing example

view details

mitchmindtree

commit sha c266d9e8ceec776131c82a7bce105495aca59677

Fix broken links in Contributing chapter overview

view details

mitchmindtree

commit sha 783570197230f778e50f9a91ae93ef64b95b0a7d

Publish version 0.15 See the changelog below for an overview of the changes included in this version. For the most part, this is an update for wgpu 0.5. @alekspickle already has a WIP for wgpu 0.6 at #655! I'm more than happy to publish a new version again as soon as that lands, but figured this one is already well overdue :) Also, find out how you can get new nannou versions published quicker in the new Contributing chapter of the guide [here](https://guide.nannou.cc/contributing/publishing-new-versions.html)).

view details

mitchmindtree

commit sha e6c44ff88e6ab618f7e8c1f8d86f284c91afcc22

Merge pull request #658 from mitchmindtree/0.15 Publish version 0.15

view details

James Gilles

commit sha 40e6e3bcc0ebe715c9e55fed98c64d831fa9d3a2

Borrow wgpu-0.6 work from nannou-org/nannou#655

view details

James Gilles

commit sha e8980a71cbaaf84a51b215b4126e3047ef485636

Kill BufferBytes::read() + fix lifetimes to get to next error wall

view details

push time in 11 days

push eventkazimuth/nannou

James Gilles

commit sha 69078cffa4f49794069a29cae2898a2d03b476c4

Rename wgpu dependency to `wgpu_upstream` to make error messages less confusing

view details

push time in 11 days

push eventkazimuth/nannou

jozanza

commit sha 23389973f6b36a7f663278482b16348ff9b6818d

Add tutorial for drawing images

view details

jozanza

commit sha 4d5f0a413a21e04a840675280b9831e8fee6d46e

Fix drawing images tutorial linting

view details

Josiah Savary

commit sha 6767b5e713697635000d9adaee1b486a72657b83

Remove color of empty window Seems like it is probably not consistent across different platforms

view details

Josiah Savary

commit sha 74b063011d0e725756062e5c9085916bcd766929

Convert -type to type Avoid breaking IntelliJ's markdown renderer

view details

Josiah Savary

commit sha 6a1c69752cb72c382ce5c33ef59c42e5b1dd6849

Merge scaffolding code with windowing code block

view details

Josiah Savary

commit sha 6105918e53b52c17c4de2d85347d10124e0f63dc

Describe expected result of Setting up a Texture

view details

Josiah Savary

commit sha 3d99323af54f689cac87d3b4f4d091502b69881c

Add a note about the assets_path method

view details

Josiah Savary

commit sha 079c347198457fd8587db39cb53e84bd003a38db

Fix typo

view details

Josiah Savary

commit sha 082b2f9d4ee61e5f88b6f3bfbc7617147c4f450e

Update drawing-images.md

view details

Josiah Savary

commit sha 8985a9fc7440958317ef58b00ab75c23c563f762

Briefly explain textures

view details

mitchmindtree

commit sha 7b8913660d04c72b0736b7f01635ed0ec8c72280

Add CONTRIBUTING.md. Add Contributing chapter to guide. This new chapter provides the following: - A small overview of nannou's codebase and how it is managed (git and PRs). - A **PR Checklist** page for use as a reference/reminder before opening PRs. - A **PR Reviews** page for tips on how to speed up reviews and make sure they go smoothly. - A **Publishing New Versions** page to inform contributors how they can get a new version of nannou published. I think a lot of this could be improved and fleshed out a little further, but hopefully this makes for a decent start! Related to #553 but still some good ideas there that are not quite implemented. Maybe it could be closed in favour of opening up specific issues for each "contributing chapter" feature?

view details

Stephan Lagerwaard

commit sha 70ee382c958c883293b346ed4e691c90edd2ede0

Fix orientation of the teapot y axis in wgpu_instancing example

view details

mitchmindtree

commit sha 690474f695fb71b9ce6ec87fcb28e554ba326a27

Fix broken links in Contributing chapter overview

view details

mitchmindtree

commit sha 1cc2bcdbc9be4d47902932be6c7a70282faf1ffc

Publish version 0.15 See the changelog below for an overview of the changes included in this version. For the most part, this is an update for wgpu 0.5. @alekspickle already has a WIP for wgpu 0.6 at #655! I'm more than happy to publish a new version again as soon as that lands, but figured this one is already well overdue :) Also, find out how you can get new nannou versions published quicker in the new Contributing chapter of the guide [here](https://guide.nannou.cc/contributing/publishing-new-versions.html)).

view details

James Gilles

commit sha 61524c4ea0a5103e647dd67bc23cd5c11a405442

Borrow wgpu-0.6 work from nannou-org/nannou#655

view details

James Gilles

commit sha 86473774b31d828b72c46898deb22702c177588c

Kill BufferBytes::read() + fix lifetimes to get to next error wall

view details

push time in 11 days

create barnchkazimuth/nannou

branch : wgpu-0.6-2

created branch time in 11 days

fork kazimuth/nannou

A Creative Coding Framework for Rust.

https://nannou.cc/

fork in 11 days

starteddimforge/rapier

started time in 11 days

push eventkazimuth/VFDecrypt

James Gilles

commit sha 80c1d988f8318063227594b57e648dd1f6933ecc

Attempt to update for new OpenSSL API

view details

push time in 18 days

startedziglang/zig

started time in 22 days

issue commentkazimuth/baked_fluent

Project Maintenance

I'd suggest forking. I believe the code is most of the way there, but honestly I'm not sure I'd take this approach (baking i18n files directly into the app) anymore. Any app that needs internationalization probably has a way to distribute localization files as well, and it's nice for translators to be able to mess with files without having to compile anything. So, maybe try just using fluent by itself first? Depends on what your goals are.

saskenuba

comment created time in 24 days

push eventkazimuth/baked_fluent

James Gilles

commit sha b3f1f4c1f0a11f266b2129fef62aa04bf4a46848

Update README.md

view details

push time in 24 days

push eventkazimuth/kazimuth.github.io

James Gilles

commit sha 708f2a1b89fdb5a669bf0dce26d55b107416e570

Add files via upload

view details

push time in a month

push eventkazimuth/kazimuth.github.io

James Gilles

commit sha f233df34540fb6a67c19cf5d63edf7c6430a4e53

Update index.html

view details

push time in a month

issue commentmezz/JustEnoughItems

Suggestion: Keyboard shortcut to search all items that can be used in the recipe.

I was also going to request this feature :)

I think it would fix how you sometimes get stuck in loops -- say, clicking on kinds of glass over and over again and just getting "put dye on glass" instead of "put sand in a furnace".

I'd be willing to make a PR if you can point me in the right direction for an implementation.

yqx1110

comment created time in a month

startedmezz/JustEnoughItems

started time in a month

startedbaowenbo/DAIN

started time in a month

startedenjoy-digital/litex

started time in 2 months

push eventkazimuth/tendon

James Gilles

commit sha d66e755720cea00ca10769a41d33edbfda2445a5

Wait, that's unnecessary

view details

James Gilles

commit sha 739b844823425e929c181bcfff5c82631d8f1a19

Log resolution entry

view details

push time in 2 months

startedjonasrauber/eagerpy

started time in 2 months

startedlocuslab/robust_union

started time in 2 months

startedftramer/MultiRobustness

started time in 2 months

issue openedholoviz/holoviews

Holoviews citation?

I've found Holoviews very useful in my research and would like to cite it. Is there a publication I can cite? If so, it would be good to add it to the main page / documentation. If not, I'll just cite the website.

created time in 2 months

issue commentbevyengine/bevy

Why use strings as labels?

There are some problems with serializing type IDs over time / across crates, see #32.

I think the const str approach is alright, those actually exist for the default stages. It's simple and straightforward to understand, and the user doesn't have to deal with wacky reflection issues / generics, which can be a big barrier for inexperienced rust users. Imo a good compromise would be strings + documentation of the "use a const string" best practice.

Plecra

comment created time in 2 months

issue commentbevyengine/bevy

Entity Ids currently have a risk of collision

if you look at the ahash readme it can hash a 128-bit int in 0.61 nanoseconds. For comparison, fxhash can hash a 64 bit int in... 0.62 nanoseconds. As I understand it hashing is the main operation applied to IDs. So, if we use ahash, there's no cost there

also, in an ecs that groups components into archetypes (like legion or bevy_ecs), you don't even need to look at IDs during iteration. So slightly larger IDs won't be a problem there. You only need to hash IDs for lookup-by-id, which is the rarer case -- and even then, we've got ahash.

so I suspect that for most workloads uuid ids won't penalize performance. unfortunately I don't have time to write actual benchmarks rn but could next week.

cart

comment created time in 2 months

issue commentbevyengine/bevy

Entity Ids currently have a risk of collision

FYI the hecs fork readme currently states that IDs are always UUIDs, that should be updated whenever a choice gets made here.

cart

comment created time in 2 months

issue commentbevyengine/bevy

Canvas API

Nannou has a very nice drawing API over wgpu as well.

cart

comment created time in 2 months

issue openedbevyengine/bevy

Benchmarks

It would be cool to have some benchmarks for different system components, to make it easier to avoid causing performance regressions. It seems like hecs has some, which is cool.

https://github.com/marketplace/actions/continuous-benchmark could also be fun to set up, it gives you graphs of performance over time like this. Not sure how much time that would add to CI builds though, I haven't used GitHub Actions much. Having a graph that measured average incremental-recompile time could be very helpful in preventing that from creeping up.

created time in 2 months

issue commentbevyengine/bevy

Create and use StableTypeId instead of TypeId

fyi, different versions of a single crate can be included in a dependency tree, so even without plugin loading I believe you can have multiple types with the same type_name but different layouts :/ you can't directly depend on multiple versions of the same crate but your dependencies can, which could cause an issue with e.g. third-party plugins.

one solution to speed up comparison + hashing would be to have a global type name interner at run time. it's not going to be written often so it doesn't need to be particularly fancy. it wouldn't speed up serialization, though. it also doesn't solve the uniqueness issue issue.

cart

comment created time in 2 months

startedbevyengine/bevy

started time in 2 months

startedlettre/lettre

started time in 2 months

startedPENGUINLIONG/spirq-rs

started time in 2 months

startedwilliamngan/pts

started time in 2 months

startedstanford-ppl/spatial

started time in 2 months

startedCorvimae/blaseball-api-spec

started time in 3 months

startednobodybutyou1/Edge

started time in 3 months

startedzuzkajelcicova/Async-Click-Library

started time in 3 months

startedasyncvlsi/AMC

started time in 3 months

startedarnetheduck/nbindgen

started time in 3 months

startedkrux02/opengl-sandbox

started time in 3 months

startedvnmakarov/mir

started time in 3 months

issue openedholoviz/holoviews

Holoviews PGF export

It's quite nice to be able to export to PGF for embedding in LaTeX documents. Currently this can be done like so:

import holoviews as hv

import matplotlib as mpl
mpl.rcParams['pgf.rcfonts'] = False # have matplotlib export to PGF using document fonts, not matplotlib fonts

def pgf(plot, file):
    fig = hv.render(plot, backend='matplotlib') # convert to matplotlib.figure.Figure
    fig.savefig(file)

pgf(hv.Scatter(([1,2,3], [4,5,6]), 'test.pgf'))

And then in your document, do:

\usepackage{pgf}
\input{test.pgf}

This is fairly easy, but it'd be nice if you could simply do hv.save(plot, 'test.pgf') instead.

created time in 3 months

more