profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/endel/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Endel Dreyer endel @colyseus Brazil endel.dev Software Engineer & Game Developer

colyseus/schema 65

An incremental binary state serializer with delta encoding for games.

colyseus/colyseus-haxe 57

⚔ Colyseus Multiplayer SDK for Haxe

acarapetis/vim-colors-github 50

Github color scheme for vim (light)

colyseus/colyseus-defold 42

⚔ Colyseus SDK for Defold Engine

colyseus/colyseus-monitor 36

Web Monitoring Panel for Colyseus

endel/awesome-wordpress 32

A curated list of awesome WordPress plugins for developers.

endel/.vim 28

My awesome VIM configuration

endel/behaviour.js 28

Plugable Entity Component System for Games

colyseus/proxy 22

🔀⚔ Proxy and Service Discovery for Colyseus (0.10+)

colyseus/colyseus-social 20

Authentication and Social features

startedskylersaleh/SkyBoy

started time in 12 minutes

release GoogleChromeLabs/css-paint-polyfill

3.3.0

released time in 2 hours

startedSunilWang/node-os-utils

started time in 2 hours

pull request commentWebAssembly/WASI

Fix path canonicalization in witx `use` statements

It looks like the crate was last published at 7ec4b1a65621ed3dd98fb67ab3746b4f29b4a62b (diff from main), and if we'd like to make an 0.9.1 release (ideally just a bugfix release), I think there's another breaking change we merged in the meantime, notably the deletion of tools/witx/src/phases.rs, which I think happened as https://github.com/WebAssembly/WASI/pull/398. I think we may need to revert that as well before publishing 0.9.1?

cratelyn

comment created time in 2 hours

push eventWebAssembly/WASI

katelyn martin

commit sha 931c62af53bc086f82cf161e79e92077fe63d6ee

Fix path canonicalization in witx `use` statements (#434) * Add a (failing) test case This test case demonstrates a bug identified with the semantics of `use` statements in witx documents. No fix is provided in this commit, so `cargo test` will fail at this commit. * Add some temporary printlns Because who doesn't love println debugging? Now, running the (failing) test case added in the previous commit, we'll see: ``` ---- toplevel::test::multi_use_with_layered_dirs stdout ---- parsing file at path='"root.witx"' root='"/"' canonical-path='"/root.witx"' found a use statement, parsing file at "subdir/child.witx" parsing file at path='"subdir/child.witx"' root='"/"' canonical-path='"/subdir/child.witx"' found a use statement, parsing file at "sibling.witx" parsing file at path='"sibling.witx"' root='"/"' canonical-path='"/sibling.witx"' thread 'toplevel::test::multi_use_with_layered_dirs' panicked at 'parse: Io("/sibling.witx", Custom { kind: Other, error: "mock fs: file not found" })', src/toplevel.rs:151:10 ``` Note that root is always `/` even when we're evaluating the paths found in a document that lives in a subdirectory! See how the canonical path in the last block resolves to '/sibling.witx'? We found you, Mr. Bug 🐛 🔍😃 * Fix the bug * Remove temproary printlns This reverts commit 07c1ae9dc3f59cd1994786e0aaadda0ccb0bdcb3. * oh no, windows paths * add review suggestion Co-authored-by: Pat Hickey <phickey@fastly.com> Co-authored-by: Pat Hickey <phickey@fastly.com>

view details

push time in 3 hours

PR merged WebAssembly/WASI

Fix path canonicalization in witx `use` statements

:bat: :sparkles: Hello!

This branch fixes a bug I have found in the witx crate, involving use statements.

:bug: The Bug

Paths in ..transitive(?) use statements (e.g. document A imports document B, which imports document C) are evaluated relative to the original root document, rather than the import-er document B.

This is better understood with an example (see below), or consulting the test case added here, multi_use_with_layered_dirs. Note that unlike the existing multi_use test, these documents do not all live within the same directory in the file system.

:scroll: Example

;; /root.witx
(use "subdir/child.witx")
;; /subdir/child.witx"
(use "sibling.witx")
(typename $b_float f64)
;; /subdir/sibling.witx
(typename $c_int u32)

Today, when root.witx is loaded, we'll run into an error that /sibling.witx does not exist.

☭ The Fix

The fix for this turns out to be a single line of code! That can be found in 963c5cf.

It turns out that when we were recursing in witx::toplevel::parse_file upon the discovery of a use statement, we'd pass the original root along, rather than providing the directory of the given document.

+36 -4

8 comments

2 changed files

cratelyn

pr closed time in 3 hours

pull request commentWebAssembly/WASI

Fix path canonicalization in witx `use` statements

This looks great, suggest adding one more check to the tests (which it passes!)

Great idea! I've added that in 5148a1b. :sparkles:

cratelyn

comment created time in 3 hours

release microsoft/vs-threading

v17.0.17-alpha

released time in 3 hours

release microsoft/vs-threading

v17.0.15-alpha

released time in 3 hours

release microsoft/vs-threading

v17.0.13-alpha

released time in 3 hours

release microsoft/vs-threading

v16.10.56

released time in 3 hours

release microsoft/vs-threading

v16.10.51-alpha

released time in 3 hours

startedejmahler/rust_dct

started time in 3 hours

release paulmillr/noble-bls12-381

0.12.0

released time in 4 hours

startedThakeeNathees/pocketlang

started time in 6 hours

issue commentsfosc/sfosc

MongoDB not FOSS

Hello,

I personally don't think we can say that MongoDB is not FOSS if the "F" in FOSS has not spoken, the Free Software Foundation. I contacted them about the license and I hope they will be able to provide an official answer soon.

Beanow

comment created time in 7 hours

startedendel/NativeWebSocket

started time in 7 hours

fork mattt/Yams

A Sweet and Swifty YAML parser.

https://jpsim.com/Yams

fork in 7 hours

release OptimalBits/bull

v3.22.9

released time in 7 hours

issue commentcolyseus/colyseus-unity3d

Schema-derived types will have their default constructors stripped by Unity's Managed code stripping setting medium or above

Not so fast. This issue affects all C# types generated by schema-codegen. It will be fixed when schema-codegen is fixed.

tonygiang

comment created time in 7 hours

release sindresorhus/normalize-url

v6.1.0

released time in 8 hours

startededriang/use-context-selection

started time in 9 hours

release lensapp/lens

v5.0.0-beta.10

released time in 9 hours

startedprathyvsh/models-of-interaction

started time in 9 hours

Pull request review commentw3c/webtransport

Specify SendStream algorithms

 or <dfn for=stream>bidirectional</dfn>.  </tbody> </table> +[=WebTransport stream=] has the following events:++<table class="data" dfn-for="stream-event">+ <thead>+  <tr>+   <th>event+   <th>definition+   <th>incoming+   <th>outgoing+   <th>bidirectional

I can replace "incoming" with "incoming unidirectional" and "outgoing" with "outgoing unidirectional", in a separate change.

yutakahirano

comment created time in 10 hours

startedblurymind/tilemap-editor

started time in 10 hours

issue commentcolyseus/colyseus-unity3d

Schema-derived types will have their default constructors stripped by Unity's Managed code stripping setting medium or above

@endel @tonygiang I fixed this issue https://github.com/colyseus/colyseus-unity3d/pull/163

tonygiang

comment created time in 10 hours

PR opened colyseus/colyseus-unity3d

fixed MissingMethodException errors

Fixed MissingMethodException errors

  • MsgPackExtensionTypeSerializer
  • ReflectionField, ReflectionType and ColyseusReflection
+7 -0

0 comment

2 changed files

pr created time in 11 hours

startedneverRare/butter

started time in 11 hours