In reply to @Ericson2314:matrix.org
the idea is that one one hand, we can't really be sure what approach is going to work best, so there just is some fundamental uncertainty. However, on the other hand, we can commit to getting smaller PRs merged throughout

In reply to @Ericson2314:matrix.org
indeed, some of then perhaps should stay std::string because they are for CanonPath

I'd have to do some more reading of the source to understand where and how CanonPath is used but I think I generally got the idea. CanonPath is for nix's view of paths and we want to use std::filesystem::path only where we interact with the real fs so that it's portable on unix and windows.

Thanks for clarifying

In reply to @eureka-cpu:matrix.org

Hello, my name is Chris and I'm an open source Rust developer. This is my third year writing software, and second year using Nix/NixOS for personal and work use. Until 2021 I was a full time music instructor, I learned entirely via online resources and have been working on language compilers and blockchain networks for about 2 years now. I'm interested in taking on a small to medium sized task for GSoC, and the proposals that interest me the most are nixpkgs library networking functions and Nix Internals: Use std::filesystem::path for Path. I also have a personal Nix project I'm working on, though I feel that it's more of a community project than something that would make for a good proposal. Nonetheless, it's called mynixui (My Nix UI), and it aims to give those developing their own desktop environments (or rices) robust scripts written in rust, and allow users to quickly and seamlessly switch between different desktop interfaces. It's currently a flake for convenience, though I could see it being integrated with home-manager later on. Writing Nix is extremely exciting to me, and I've also been using it to package and cross compile binaries for work using crane, lately.

I'm happy to take on any challenge, and I would greatly appreciate the mentorship.

In reply to @eureka-cpu:matrix.org

Hello, my name is Chris and I'm an open source Rust developer. This is my third year writing software, and second year using Nix/NixOS for personal and work use. Until 2021 I was a full time music instructor, I learned entirely via online resources and have been working on language compilers and blockchain networks for about 2 years now. I'm interested in taking on a small to medium sized task for GSoC, and the proposals that interest me the most are nixpkgs library networking functions and Nix Internals: Use std::filesystem::path for Path. I also have a personal Nix project I'm working on, though I feel that it's more of a community project than something that would make for a good proposal. Nonetheless, it's called mynixui (My Nix UI), and it aims to give those developing their own desktop environments (or rices) robust scripts written in rust, and allow users to quickly and seamlessly switch between different desktop interfaces. It's currently a flake for convenience, though I could see it being integrated with home-manager later on. Writing Nix is extremely exciting to me, and I've also been using it to package and cross compile binaries for work using crane, lately.

I'm happy to take on any challenge, and I would greatly appreciate the mentorship.

In reply to @eureka-cpu:matrix.org
In my application, can I apply for both, or only one or the other?

IHi everyone! I'm Rafael Girão from Portugal (rafaelsgirao on GitHub), and I'm finishing a Bsc. in Computer Science & Engineering @ Técnico Lisboa this spring.

I've been daily driving NixOS for almost two years now and I really enjoy tinkering with my Nix(OS) systems. While I'm a new contributor to nixpkgs (I only have one contribution so far: a PR which is currently work in progress :slight_smile:), I have a personal flake with contains (among other things) 15 packages I've created for personal use, and have some other software I packaged spread throughout other repositories.

Although I'm interested in the nixpkgs pnpm tooling idea, since it's a project I stumbled upon when I attempted to package Ferdium from source instead of using a .deb as it's done at the moment; I also I have an idea proposal of my own.

Are ideas outside the list something being considered? If so, who should I talk to about my own idea proposal?

Thanks in advance!

Hi everyone! I'm Rafael Girão from Portugal (rafaelsgirao on GitHub), and I'm finishing a Bsc. in Computer Science & Engineering @ Técnico Lisboa this spring.

I've been daily driving NixOS for almost two years now and I really enjoy tinkering with my Nix(OS) systems. While I'm a new contributor to nixpkgs (I only have one contribution so far: a PR which is currently work in progress :slight_smile:), I have a personal flake with contains (among other things) 15 packages I've created for personal use, and have some other software I packaged spread throughout other repositories.

Although I'm interested in the nixpkgs pnpm tooling idea, since it's a project I stumbled upon when I attempted to package Ferdium from source instead of using a .deb as it's done at the moment; I also I have an idea proposal of my own.

Are ideas outside the list something being considered? If so, who should I talk to about my own idea proposal?

Thanks in advance!

Are ideas outside the list something being considered? If so, who should I talk to about my own idea proposal?

Yes. Just post it here or open a issue in https://github.com/NixOS/GSoC/issues/ and if it's a good idea we can try to find a potential mentor.

In reply to @janik0:matrix.org

Are ideas outside the list something being considered? If so, who should I talk to about my own idea proposal?

Yes. Just post it here or open a issue in https://github.com/NixOS/GSoC/issues/ and if it's a good idea we can try to find a potential mentor.

In reply to @Ericson2314:matrix.org

Hi Eric! Glad you are interested:

1. Yes libgcc, but also the other gcc runtime libraries. (libssp, libstdc++ are two of them off hand)

2. Don't worry about "bootstrapping" too much, just consider that before we build libgcc we may not have a libgcc, etc. A lot of compiler devs are working on regular machines and doing builds where they already have 1 copy of everything, which allows being more sloppy about depedencies and breaking cycles. Building compiler and libraries together is bad for a few reasons, but those reasons might mainly be in my head haha. Examples:

   • cross compiling mean can mean the libraries are for one platform and the compiler itself is for another. But having the installed outputs of a package involve two platforms that way is really messy and breaks assumptions in other packaging infra
   • That fact that some of the libraries do need a libc, and the libc is a separate package, means we have zig-zag problem (finishing the compiler build depeneds on downstream package build which depends on the compielr build) we can get around this by building things twice but that is ugly and wasteful

Ah, I see. I looked around a bit more at Exherbo's GCC build script and it looks like they just turn off a lot of features in the source tree before configuring the project, along with explicitly specifying many of the build tools (https://gitlab.exherbo.org/exherbo/arbor/-/blob/master/packages/sys-devel/gcc/gcc.exlib?ref_type=heads#L172). Also, I think I found an old thread talking about Exherbo that you created a while ago and I'll look into that for more info on Exherbo's relevance to Nix (https://github.com/NixOS/nixpkgs/issues/21471). One thing I'm still a bit confused about though, is how the gcc-${version}-lib and gcc-${version}-libgcc packages are currently being built. From what I can tell, they are the dynamic versions (which aren't included in the gcc-${version} package). Are they simply a recompilation of the packages after the big monorepo GCC is compiled? Is this what you're referring to in terms of building things twice being wasteful?

Also, is it okay if I direct message you if I have any more questions? I'd prefer not to clog up the chat here.

In reply to @Ericson2314:matrix.org

Hi Eric! Glad you are interested:

1. Yes libgcc, but also the other gcc runtime libraries. (libssp, libstdc++ are two of them off hand)

2. Don't worry about "bootstrapping" too much, just consider that before we build libgcc we may not have a libgcc, etc. A lot of compiler devs are working on regular machines and doing builds where they already have 1 copy of everything, which allows being more sloppy about depedencies and breaking cycles. Building compiler and libraries together is bad for a few reasons, but those reasons might mainly be in my head haha. Examples:

   • cross compiling mean can mean the libraries are for one platform and the compiler itself is for another. But having the installed outputs of a package involve two platforms that way is really messy and breaks assumptions in other packaging infra
   • That fact that some of the libraries do need a libc, and the libc is a separate package, means we have zig-zag problem (finishing the compiler build depeneds on downstream package build which depends on the compielr build) we can get around this by building things twice but that is ugly and wasteful

Ah, I see. I looked around a bit more at Exherbo's GCC build script and it looks like they just turn off a lot of features in the source tree before configuring the project, along with explicitly specifying many of the build tools (https://gitlab.exherbo.org/exherbo/arbor/-/blob/master/packages/sys-devel/gcc/gcc.exlib?ref_type=heads#L172). Also, I think I found an old thread talking about Exherbo that you created a while ago and I'll look into that for more info on Exherbo's relevance to Nix (https://github.com/NixOS/nixpkgs/issues/21471). One thing I'm still a bit confused about though, is how the gcc-${version}-lib and gcc-${version}-libgcc packages are currently being built. From what I can tell, they are the dynamic library versions of each, and the static library versions are included in the gcc-${version} package. Are they simply a recompilation of the packages after the big monorepo GCC is compiled? Is this what you're referring to in terms of building things twice being wasteful?

Also, is it okay if I direct message you if I have any more questions? I'd prefer not to clog up the chat here.

In reply to @thatliuser:matrix.org

Ah, I see. I looked around a bit more at Exherbo's GCC build script and it looks like they just turn off a lot of features in the source tree before configuring the project, along with explicitly specifying many of the build tools (https://gitlab.exherbo.org/exherbo/arbor/-/blob/master/packages/sys-devel/gcc/gcc.exlib?ref_type=heads#L172). Also, I think I found an old thread talking about Exherbo that you created a while ago and I'll look into that for more info on Exherbo's relevance to Nix (https://github.com/NixOS/nixpkgs/issues/21471). One thing I'm still a bit confused about though, is how the gcc-${version}-lib and gcc-${version}-libgcc packages are currently being built. From what I can tell, they are the dynamic library versions of each, and the static library versions are included in the gcc-${version} package. Are they simply a recompilation of the packages after the big monorepo GCC is compiled? Is this what you're referring to in terms of building things twice being wasteful?

Also, is it okay if I direct message you if I have any more questions? I'd prefer not to clog up the chat here.