profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jwintz/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.
Julien Wintz jwintz Inria Sophia-Antipolis Julien Wintz received his PhD in algebraic geometry in 2008, and became a research engineer at INRIA Sophia-Antipolis the same year.

fredboudon/lpy 6

An open source python version of the Lindenmayer Systems.

jwintz/qtrace 3

Proof of concept project aiming at using concurrency to render fractal images with Qt and Qml

fredboudon/plantgl 1

An open-source graphic toolkit for the creation, simulation and analysis of 3D virtual plants.

issue openedwasmerio/wasmer

WASI VirtualFS can't open read-only files

https://github.com/wasmerio/wasmer/blob/master/lib/wasi/src/syscalls/mod.rs#L1745

                let write_permission = adjusted_rights & __WASI_RIGHT_FD_WRITE != 0;

Notably this is using the write permission, not the open flag to determine if a file is opened with write capabilities or not. This is likely intentional. The intent here seems to have been that our own VirtualFS will manage read/write access via our own fds. This is fine, but we don't check if we can open a file with write permissions, we just assume that we can. The fix should be relatively simple: we should succeed if the open flag does not have write permissions and open without write permissions. If the open flags have write enabled, then we should fail indicating a lack of underlying write permission on the FS.

Additionally, we can revisit the extent to which we manage our own permissions in regards to fd read/write in the new context of the WASI FS not trying to provide a fully platform agnostic abstraction.

created time in 19 minutes

issue commentkoekeishiya/yabai

Migration Guide: macOS 10.15 Catalina

FYI: I just wanted to add that for my upgrade from 10.15.6 -> 10.15.7 (I'm avoiding Big Sur :-)) I had exactly the same problem which was solved as above with the

sudo yabai --install-sa
dominiklohmann

comment created time in 23 minutes

issue commentwasmerio/wasmer

Linux: Missing SONAME in "libwasmer.so" hinders usage in CMake

Yes, I did a clean build.

I'm actually not surprised, because IHMO, the settings from Makefile override the otherwise provided settings.

You can try the Makefile build on your own:

make --directory=<repo-dir> build-capi 
make --directory=<repo-dir> package-capi 

After the two build steps, simply check with objdump if SONAME is present: objdump -p <repo-dir>/package/lib/libwasmer.so | grep SONAME

Thanks, Martin

MartinKolbAtWork

comment created time in an hour

issue commentwasmerio/wasmer

Linux: Missing SONAME in "libwasmer.so" hinders usage in CMake

Did you try to ˋcargo clean` before rebuilding the library? I'm surprised it doesn't work.

MartinKolbAtWork

comment created time in an hour

create barnchwasmerio/wasmer

branch : wasio-reboot-event-based

created branch time in an hour

issue commentwasmerio/wasmer

Linux: Missing SONAME in "libwasmer.so" hinders usage in CMake

Hi @Hywan,

Thanks for your fast response. I tried out your suggested change, but unfortunately it does not work when building wasmer with Makefile in the root directory of the repository.

To adjust the Makefile, change the capi-setup section to these lines:

capi-setup:
ifeq ($(IS_WINDOWS), 1)
  RUSTFLAGS += -C target-feature=+crt-static
else
ifeq ($(IS_LINUX), 1)
  RUSTFLAGS += -C link-arg=-Wl,-soname,libwasmer.so
endif
endif

Maybe you should consider using my original change in the build.rs file, because this would affect all build types and hence eliminate the need to modify two places.

Thanks, Martin

MartinKolbAtWork

comment created time in an hour

issue openedhlissner/emacs-doom-themes

Accented characters not correctly represented in Win10 terminal version

What happened?

Accented characters are replaced by other characters

What did you expect to happen?

Accented characters are correctly reproduced

Steps to reproduce

  1. In a win10 DOS command prompt run "emacs -nw"
  2. Open any file that contains accented characters

Note: a) When running simply "emacs" there is no problem (but I need the terminal version to work). b) In config.el, when I set the doom theme to a theme that doesn't exist, I will get a warning on startup "theme not found", however the characters are represented correctly. However the evil layer doesn't work. c) in gitbash SDK-64, when I run "winpty emacs -nw" the characters are displayed correctly. Gitbash has several environment variables / paths set differently. d) I tried several doom themes, to no avail

System Information

  • Emacs version: 28.0.50 native compiled
  • Emacs distro: Doom Emacs
  • Operating system: Windows 10
  • Installed commit of doom-themes: latest
  • Which theme are you using: doom-one

created time in an hour

issue commentwasmerio/wasmer

Linux: Missing SONAME in "libwasmer.so" hinders usage in CMake

We need to investigate to see if it's worth it :-). Thank you for the proposal!

MartinKolbAtWork

comment created time in 2 hours

issue commentwasmerio/wasmer

Linux: Missing SONAME in "libwasmer.so" hinders usage in CMake

@Hywan could you please consider using cargo-c? I can send you a patch if you need help in converting the c-api build system (it is mainly removing the build.rs since cargo-c does already everything for you :)).

MartinKolbAtWork

comment created time in 2 hours

issue commentwasmerio/wasmer

Linux: Missing SONAME in "libwasmer.so" hinders usage in CMake

See #2430 for the bug fix. Can you please help us to see if it fixes your issue? Thanks!

MartinKolbAtWork

comment created time in 2 hours

pull request commentwasmerio/wasmer

fix: Set the SONAME to `libwasmer.so` on Linux

Please @MartinKolbAtWork, can you try this patch and see if it works in your context?

Hywan

comment created time in 2 hours

PR opened wasmerio/wasmer

fix: Set the SONAME to `libwasmer.so` on Linux 🎉 enhancement

Description

See https://github.com/wasmerio/wasmer/issues/2429 for more context.

The idea is to use our .cargo/config.toml file to set the SONAME correctly to libwasmer.so only on Linux.

Fix #2429.

Review

  • [ ] Add a short description of the change to the CHANGELOG.md file
+2 -0

0 comment

1 changed file

pr created time in 2 hours

issue openedwasmerio/wasmer

Linux: Missing SONAME in "libwasmer.so" hinders usage in CMake

The shared library libwasmer.so does not have an SONAME specified. This can be checked using this command: objdump -p libwasmer.so | grep SONAME

When libwasmer.so is consumed in CMake, the linker produces a wrong output file due to the missing SONAME. There is a workaround for this in CMake, but according to a reply from the CMake folks, the missing SONAME is a bug that must be fixed by the library provider: https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562 “The libwasmer.so file should have a SONAME. If it doesn't, that's a bug in the wasmer package

The problem is inherent for all Rust builds of cdylibs: https://github.com/rust-lang/cargo/issues/5045 The Rust community did not fix this since 2018 (see issue above), but fortunately it’s easy to fix for library creators. You just need to put the following code into the build.rs of the library:

if cfg!(target_os = "linux") {
    println!("cargo:rustc-cdylib-link-arg=-Wl,-soname,libwasmer.so");
}

I tried putting these lines into lib/c-api/build.rs, and then libwasmer.so was built correctly, including a SONAME entry.

Could you please fix this issue?

Thanks Martin

created time in 2 hours

issue closedwasmerio/wasmer

WASMER_INSTALL_PREFIX will cause confusion in install

Summary

As a normal case in building from source on Linux/Unix. I will use

make 
sudo make install

to build and install from source code.

But follow these steps, there will be an error like this by default:

target/release/wasmer config --pkg-config | install -Dm644 /dev/stdin "/usr/local"/lib/pkgconfig/wasmer.pc
unset WASMER_DIR # Make sure WASMER_INSTALL_PREFIX is set during build
error: failed to retrieve the wasmer config
│   1: failed to retrieve the WASMER_DIR environment variables
╰─> 2: environment variable not found

Then, I need to find the document, and the document is not clear about this, https://github.com/wasmerio/wasmer/blob/master/PACKAGING.md. Actually, we need to add WASMER_INSTALL_PREFIX in the make stage, not make install stage.

By default, makefile use DISTDIR as the target directory. https://github.com/wasmerio/wasmer/blob/144300e0bc51d01290680a46cd30a6ca76ed0359/Makefile#L632

I saw the WASMER_INSTALL_PREFIX is introduced by this commit: https://github.com/wasmerio/wasmer/commit/80ec06ffab9d7af017a5a5490d153a2230f9374a

I don't get the point for this variable, and I think it makes some confusion.

If we want to configure the path, we need to add two environment variables, WASMER_INSTALL_PREFIX to recompile the whole project.

closed time in 3 hours

chenyukang

pull request commentwasmerio/wasmer

Don't fail make install if WASMER_INSTALL_PREFIX isn't set

Add a short description of the change to the CHANGELOG.md file: Seems like an irrelevant fix - Necessary?

Not needed in this case I believe.

jcaesar

comment created time in 3 hours

PR opened wasmerio/wasmer

Don't fail make install if WASMER_INSTALL_PREFIX isn't set

<!-- Prior to submitting a PR, review the CONTRIBUTING.md document for recommendations on how to test: https://github.com/wasmerio/wasmer/blob/master/CONTRIBUTING.md#pull-requests

-->

Description

Fixes #2413, also improves PACKAGING.md

Alternatively, I could make it so make install errors out with a nice and clean error message if that variable is not set (and tells people that they're not supposed to make install themselves?), or default WASMER_INSTALL_PREFIX to /usr/local (at the danger of being missed, resulting in incorrect installs).

Review

  • [ ] Add a short description of the change to the CHANGELOG.md file: Seems like an irrelevant fix - Necessary?
+10 -3

0 comment

2 changed files

pr created time in 4 hours

issue commentwasmerio/wasmer

WASMER_INSTALL_PREFIX will cause confusion in install

I don't get the point for this variable, and I think it makes some confusion.

I might have wanted to document that more. (In my defence, you're picking an undocumented installation route, I think.)

The intention behind having DESTDIR and WASMER_INSTALL_PREFIX is that many distros stage installation in some /tmp/foo/bar/usr path before building a package, and then install that to /usr. Problem is: When wasmer is being make installed to DESTDIR=/tmp/foo/bar/usr, how would it know that it's supposed to include its headers from /usr/include? So, WASMER_INSTALL_PREFIX must be compiled in.

If we want to configure the path, we need to add two environment variables, WASMER_INSTALL_PREFIX to recompile the whole project.

I'm not sure what you mean by this. Is this a change that needs to be contributed to wasmer's source, or something that a user needs to do to install/use wasmer?

Then, I need to find the document, and the document is not clear about this, https://github.com/wasmerio/wasmer/blob/master/PACKAGING.md.

That's the distro packaging manual, and unrelated to your case. Can I somehow make that clearer? (You're not packaging for a distro, are you?)

chenyukang

comment created time in 4 hours

issue commentwasmerio/wasmer

no std mode

I would say that maybe 50% of our crates can be used in no_std. I don't know how much work would be required to me it up to 100%. Anyone would like to help on that front? I can coordinate the project.

artit91

comment created time in 6 hours

push eventwasmerio/wasmer

Hywan

commit sha 304889bc8c9ef45f84e5bbef5f4d34880a0359cc

deploy: 29d7b4a5f1c401d9a1e95086ed85878c8407ec16

view details

push time in 6 hours

push eventwasmerio/wasmer

Ivan Enderlin

commit sha 29d7b4a5f1c401d9a1e95086ed85878c8407ec16

doc(c-api) Update links to documentation.

view details

push time in 6 hours

CommitCommentEvent

pull request commenthlissner/doom-emacs

getting_started.org: Gentoo Linux install guide

You might want to mention that the xft use flag must be enabled for app-editors/emacs in order for the fonts to render correctly.

See #4876

mjkalyan

comment created time in 10 hours

issue commenthlissner/doom-emacs

Broken icons on the dashboard

@savageCW

In order for the fonts to render correctly on Gentoo you need to enable the xft use-flag for app-editors/emacs.

This can be done like so...

# echo "app-editors/emacs xft" >> /etc/portage/package.use/emacs
savageCW

comment created time in 10 hours

issue commentkoekeishiya/yabai

focus_follows_mouse best practices?

Holding down mouse mod key disable focus follow temporary

yabai -m config mouse_modifier               ctrl
hypergig

comment created time in 14 hours

PR opened hlissner/doom-emacs

Point FAQ to Github, not Discourse

<!--

YOUR PR WILL NOT BE ACCEPTED IF IT DOES NOT MEET THE FOLLOWING CRITERIA:

  • [x] It targets the develop branch
  • [ ] I've searched for similar pull requests and found nothing
  • [ ] This change is NOT in Doom's do-not-PR list: https://doomemacs.org/d/do-not-pr (GRR, this requires Discourse also???)
  • [ ] If I've bumped any packages, I've done so according to https://doomemacs.org/d/how2bump
  • [x] I've linked any relevant issues and PRs below
  • [x] All my commit messages are descriptive and distinct

-->

This changes the FAQ link to a link that works for all users.

Is there a reason this currently points to Discourse which (seems to) force one to have a login to even see the content?

I tried to check the "do-not-PR" list but it has the same issue - of evidently being locked behind needing a Discourse account?

+1 -1

0 comment

1 changed file

pr created time in 18 hours

issue commentwasmerio/wasmer

no std mode

Any updates? This would be really fantastic for embedded platforms and kernels. Wasmer seems one of the most complete wasm engines.

artit91

comment created time in 20 hours

issue commentwasmerio/wasmer

wasmer fails to execute qjs.wasm on windows 10

Just to be clear since there are two issues in this thread, the HostFile::poll issue is still open on 2.0.0.

spullara

comment created time in 21 hours

pull request commenthlissner/doom-emacs

Add Selectrum module Round 2

@iyefrat - on the "bibtex-actions improvements?" todo issue about menus.

We actually have a WIP progress PR to add embark-act at-point functionality, which includes as well a keymap specific to that.

Ideally, I'd like to get these "simple menus" with descriptoins working in which-key and, by extension, Doom.

https://github.com/bdarcus/bibtex-actions/pull/57/commits/33a9617194b31dbfd036513a7cf05b6b8c2a534e

But I never had any success, and it seems it has to wait on an unmerged, and stagnant, which-key PR.

If necessary, I can just provide the Doom-specific mapping, so we get nice and consistent menus with embark-act both at-point and in-buffer.

Emiller88

comment created time in a day

push eventwasmerio/wasmer

Ivan Enderlin

commit sha 9d42538f66733558851c737ec33cb03f1a760280

fix(wapm) Fix the `wax` script generation. On macOS, `echo` always enables interpretation of backslach sequences (like `\n`). On Linux, the `-e` flag must be used. Even if this `-e` flag is absent from the macOS man's page for `echo(1)`, it is accepted and ignored, thus we can safely use it in our `Makefile`. To test this patch: ```sh $ # before $ make package-wapm $ cat package/bin/wax $ $ # after $ make package-wapm $ cat package/bin/wax wapm execute "$@" ```

view details

Ivan Enderlin

commit sha 76a856d3bd8287b1400a6b63aa4584d3aa4245d6

doc(changelog) Add #2426.

view details

Syrus Akbary

commit sha e315431cac0e1fb10874755239e88612e2c8cf85

Merge pull request #2426 from Hywan/fix-wax-bin-file-generation fix(wapm) Fix the `wax` script generation

view details

push time in a day

PR merged wasmerio/wasmer

Reviewers
fix(wapm) Fix the `wax` script generation 🐞 bug 📦 lib-cli

Description

On macOS, echo always enables interpretation of backslach sequences (like \n). On Linux, the -e flag must be used. Even if this -e flag is absent from the macOS man's page for echo(1), it is accepted and ignored, thus we can safely use it in our Makefile.

To test this patch:

$ # before
$ make package-wapm
$ cat package/bin/wax
#!/bin/bash\nwapm execute "$@"
$
$ # after
$ make package-wapm
$ cat package/bin/wax
#!/bin/bash
wapm execute "$@"

This patch fixes #2425.

Review

  • [x] Add a short description of the change to the CHANGELOG.md file
+4 -1

1 comment

2 changed files

Hywan

pr closed time in a day