Hacker News new | past | comments | ask | show | jobs | submit | legobmw99's comments login

If what I want is not an executable but a shared library, does this get me anything?

I currently have a use case that uses a server running an emscripten build (using SMODULARIZE and some exports, I suppose it’s not a true dylib)


Importing a wasm module from a wasm module is (non)surprisingly impossible to do -- you have to have a linker, abi and all that.

It is possible provided some care. I was looking into this with WAForth which compiles the wasm and loads it via a host function (ie. it is the hosts responsibility to make it available). I wanted to enable dynamic loading of words from disk which requires some book keeping and shuffling a bunch of bytes around during compilation to write out the bits necessary to have the host do that linking. It isn't impossible to do, just tedious and in my case, having to write it in WAT is a pain.

Yep, you need to do the nasty bits by hand, that's what I mean.


Thanks, I'm seeing but the documentation is so scarce and I'm not a proefficient C expert.

What syntax can be used to run emception? Thank you.


It’s sadly a bit more of a proof of concept than a hackable project. The docker build in the readme did work last time I tried, and there is a demo site at https://jprendes.github.io/emception/, but I’ve failed to modify it in the past to do other things

There is a fork at https://github.com/emception/emception that is trying to make it more production ready, but it looks like that may have stalled


The closest I’ve found in terms of description is https://github.com/feschber/lan-mouse, but the lack of encryption on the connection has discouraged me from using it.

I’m also a paid Synergy user, and it’s frankly comedic how long Wayland support has been on their road map. I’m not convinced it’s ever coming, which means I’m probably only 1-2 distro updates from being forced to use something else


I'm in the same boat.


Synergy core (aka synergy 1) just had Wayland support merged this week. “Next year” has finally come to pass


It seems a little odd to me that this is not just… a vscode extension pack?


A good question. The VS Code extension API is pretty powerful but extensions run separately from the main workbench process and they can't draw any meaningful UI on it. This was a great design decision IMHO as it is the core reason VS Code has a reputation for a minimalist UI and good performance despite being based on Electron.

However it also made it impossible to build the kinds of experiences we wanted to with Positron. Positron has a bunch of top-level UI as well as some integrated/horizontal services that don't make sense as extensions. We built those into the core of the system which is why a fork was necessary.

It's a goal for Positron to be extensible, so it has its own API alongside VS Code's API, and both the R and Python language systems are implemented as extensions.


I'm curious if you would be willing to elaborate on what your plans are for longer term feature parity with vscode? As in I can imagine as vscode receives continued development and new features you will have the development burden of having to integrate these updates into your fork. Are you planning to keep up-to-date with vscode or will the products essentially drift a part over time? If the latter would this mean extension developers have to build separate extensions for your IDE?


We merge upstream from VS Code every month and we plan to keep up to date with it, so extensions will continue to work and we'll continue to inherit new features as they become available.

It's a development burden for sure -- but still an order of magnitude cheaper than trying to build a good workbench surface from scratch.


I think a challenge to this evolution path is the same as what motivated Sutter’s cpp2: defaults

I think the premise that a lot of experienced programmers can write good C++ is at least somewhat valid. They know to not use raw pointers, which APIs to use for bound checking, whatever. The issue is that new users don’t, and the defaults are bad.

If I have to write #feature on safety in every file, it becomes possible to forget. Opting in vs opting out


extern “C” on everything, if you care about linking compatibility, gets you another chunk of the way there by also disabling overloading etc.


I feel like most RAII fans will openly admit that it’s the worst name in the world for such an idea. The idea is that any time you acquire a resource, you should initialize an object with said resource. But I guess “resource allocation should always lead to object initialization” is too long.

The reason to do this is precisely so that the resource can be cleaned up at destruction of the object. So even if you had an acronym like RASALTOI, it would still probably be misleading


If you’re very careful with forward-vs-back slashes and your username isn’t “Firstname Lastname”, sure. But in practice there are tons of issues especially for non expert users


I also wish I could make certain variables/flags part of the dependencies of a file, like if I have something with a lot of #defines that I really want to rebuild any time CPPFLAGS changes


I wouldn’t think they need to be if the releases are manually prepared and signed


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: