Re: Mixed Languages Programming
On Thu, 11 Mar 2021 00:26:41 +0100 Léo Le Bouter wrote: > On Thu, 2021-03-11 at 08:23 +0900, Yasuaki Kudo wrote: > > Hello! > > Hello! > > I think you can use JSON-RPC libraries as modern alternatives to that. > Also gRPC. The "micro-service" paradigm. > > > Is this a topic that is particularly interesting to the Guix > > community because of interoperability, mixing packages, etc? > > I don't think so, not in particular. > > > Cheers, > > Yasu > > Léo There is an interesting Nix based project that has some actual good use cases for a common intermediate representation: https://publish.illinois.edu/allvm-project/ Chris Webber's talk on Spritely also had some good ideas for using OCAP in Guix to enhance security by a whole lot. https://fosdem.org/2021/schedule/event/spritelygoblins/ And that is basically just cross-language remote procedure calls. Another interesting possibility is to run everything on WASM without an MMU. See the classic The Birth and Death of Javascript talk. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript Of course that one is pre-Spectre/Meltdown, so take it with a grain of salt.
Re: Black magic to pass around environment variables?
On Sat, 13 Mar 2021 10:05:44 +0100 Ricardo Wurmus wrote: > raingloom writes: > > > Motivation: > > xfce4-terminal runs as a terminal and doesn't propagate environment > > variables, which makes it a bit cumbersome to use it with complex > > `guix environment` setups. While an upstream fix would be nice, > > this is a general problem and one that shouldn't require special > > handling in every application. > > I’m sorry, I don’t understand the problem. Could you perhaps provide > an example to illustrate the issue? Sorry, I wrote that in a rather tired state. What I meant to write was: xfce4-terminal runs as a **server** and when it opens a new window, that inherits its environment from the server, not from the calling environment. What I want to do is open a new terminal from a guix environment shell that has the exact same environment variables. > What environment variables should be propagated from where to where? All of them, that's the point.
Re: Export PDFs in Emacs Org
Ricardo Wurmus writes:
>> this is what I use:
> […]
>>("texlive" ,texlive)
>
> This is the monolithic 3+GB package, not the modular texlive.
It is huge, but it got the job done - thanks Arne.
Having spent more hours than I'd like admit on this, I suspect the issue
may be similar to this:
http://issues.guix.gnu.org/40558#0
But I haven't proved this yet.
Re: setup c/c++ development environment
Hi, ‐‐‐ Original Message ‐‐‐ On Thursday, March 11, 2021 9:03 PM, Fredrik Salomonsson wrote: > > > Hi Ekaitz, > > CC:ing the rest of the help-guix mailing list, I hope you don't mind. Yeah sorry I messed up with the email. > Ekaitz Zarraga eka...@elenq.tech writes: > > > I have a question with all this you shared. > > Is this compiling only the needed parts or it recompiles the whole > > directory from scratch every time you run `guix build`? > > To my knowledge it will recompile everything every time you run > `guix build`. > > So this method might be better suited for CI (continuous integration). > > But benefit with the `guix.scm` file is that you can also use the same > file to setup the environment you need to build your package. > > `guix environment -l guix.scm` > or > `guix environment -l build-aux/guix.scm` > > Depending how you have layed out the guix.scm file. > > That will use guix to setup the environment needed to build the your > package. And in that shell you can use: > > meson build > meson compile -C build > meson test -C build > > Or equivalent for other build systems. Which will support partial > builds. > > Note that guix might have issues with build generated files for some > build systems when mixing guix environment and guix build. E.g. run > `guix environment`, generate the build files and then run `guix build`. > It seems fine with meson, even when not filtering out the build files. > But I have had issues with GNU autotools and permissions, > `make distclean` before calling `guix build` is a quick workaround. A > better option is probably to filter out those files when collecting the > source. > > I hope that answers your question. So the workflow with guix build is not very good for development but for CI and stuff like that because you are going to rebuild everything. Thanks for the explanations. Ekaitz
Re: Python, poetry, and pandas
Sébastien Lerique writes: > Now my wish is to find ways to collaborate with others on this kind of > project, who unfortunately often use macOS. I was exploring the > possibility of Guix on Darwin, but the best way to do that looks like > running Guix System inside Docker: > I haven't tried with MacOS yet but a few ideas: - Try using the QEMU image available (or create your own VirtualBox image - I've tried this and it worked OK). - If running a full graphical env is too clunky for you could experiment with multipass. I haven't tried this yet on multipass but I've had some success running Guix inside WSL2 (very similar to multipass) on Windows using busybox and these instructions: https://github.com/giuliano108/guix-packages/blob/master/notes/Guix-on-WSL2.md It's a bit 'beta', but I use this when I want fast local access to a Guix environment from a Windows desktop without having yet-another-foreign-distro (eg Ubuntu-on-WSL) in-between. - I'm not expert on this but I suspect you could produce a slimmed down version of Guix more akin to the WSL experience using the 'guix system vm-image' command. Check-out the manual. Having something that worked with multipass and WSL2 directly on the Guix website would be extremely useful in drawing a crowd from non-Linux users! So this would be a noble endeavour IMHO. If you get anything working I'd be very interested. Of course this isn't substitute for running on Darwin as a foreign distro, but I'm unaware of any current project to do that. I suspect it would be challenging to get package definitions working for substantially different compiler flags etc, it would almost become a separate project. It has been discussed tho - follow the links in this post to see discussions on guix-devel too: https://www.reddit.com/r/GUIX/comments/c2xei5/any_way_to_have_guix_running_as_a_package_manager/
Re: Black magic to pass around environment variables?
raingloom writes: > Motivation: > xfce4-terminal runs as a terminal and doesn't propagate environment > variables, which makes it a bit cumbersome to use it with complex `guix > environment` setups. While an upstream fix would be nice, this is a > general problem and one that shouldn't require special handling in > every application. I’m sorry, I don’t understand the problem. Could you perhaps provide an example to illustrate the issue? What environment variables should be propagated from where to where? -- Ricardo
