From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id gI4/FgKMJ2c1cgAAe85BDQ:P1 (envelope-from ) for ; Sun, 03 Nov 2024 14:43:14 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id gI4/FgKMJ2c1cgAAe85BDQ (envelope-from ) for ; Sun, 03 Nov 2024 15:43:14 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fr61dx4R; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1730644994; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=LZMAe+WOB9W2kjNThmp5Md1NpYdAKB4JTZPLYv6/s6c=; b=Mh1rlsHOfdPBNQpZMiTf5jmz++9N1PF/cM3eVc/6p15Yz20Xlzbq6ncsgilPnK6HrWEqrm Q/X1s11wXE4eq93o59KZeT4aHfIwp2NbIlUQMkruWb/Pk3oooox+PjILfxNbUeL04I+bzv VsJxUoqdqOJ+NHI8bAMs3q2ZYzUhhTr3/8VTwUBaIIyTm6eMwFNFcV5BLw34h/13hpHKUp k5tFF6DhyQZJDfbDjD4FNplkoy+EUiChBBgkEfuCbiNXzr7T1A7nTEZ1xE0bzECMkUQHP0 ULmbLIUgad3fmOmXVBv06aZoLNh1xhk2l+4In37sOjVQm59jdOY0gdl1fG/nxA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1730644994; a=rsa-sha256; cv=none; b=eXj1QfYuzK8sub9F6O6rMBtOXhWDmN61HxIcngG9quOllGVPiBFT27V/3x5rE+QoAEJsKC gbN9KTMhtmIWZZW9ZPeFs/cCnahMhIOcfXR8JMn585niuSwk1B9bU865g1N6YjBcEbxMJ4 V0ldckpKHnp8PZDRAncnVzPWdMoS/kt/C+zwDvYWv49o2/9Obcv0h1yXQP4DIDkFqRw4OR wBvzawUyLBS4vGKkbZ22kIBpyYN6BItC9RQP005R0JNFlxar6JnXWc5aZOP31/MdQL7uJ8 D7ieumk9+RmW5vo8ZaJIOpu8RRy8OlGMJ2e3LGb5sWDDJrJaKLwJhL5MkdHDDA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fr61dx4R; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 933075CD4A for ; Sun, 03 Nov 2024 15:43:13 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t7boA-0006QK-RB; Sun, 03 Nov 2024 09:42:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t7bo9-0006Q1-9Q for guix-devel@gnu.org; Sun, 03 Nov 2024 09:42:25 -0500 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t7bo7-0003U7-8g for guix-devel@gnu.org; Sun, 03 Nov 2024 09:42:25 -0500 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-37d5689eea8so1936135f8f.1 for ; Sun, 03 Nov 2024 06:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730644941; x=1731249741; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LZMAe+WOB9W2kjNThmp5Md1NpYdAKB4JTZPLYv6/s6c=; b=fr61dx4RH/w/hBOhaCTjRYxqIbhi8IT29MyBS1MUB2NBgT9sKDbEmoIrPbJuIv+ssT VGj+eyuQD/UhpG4FWEtwdEmiKpTYiYtYBQz5AqO4NxCwfkj6dun5OK6gX8FVM/usM7Qw cHo5SZL31bU8Ewrper5pI1OV+67kOqIeE1BBExXWEXY/L/gOZrrtkG+Xh7U4AQHrhck/ 7cPDQgeGm8VndC1JE9jpccvgXzMHETSEzM+XJFLD7PoOk8o1u58FJO7ZkT5ZwEAtYZIE 7okFmlpSnatDQ7ra2W2cAvezwVM9t+UAnA67EJVdKf6Nzikdv0MTzZ+RR7X5oiRQSNXM DMDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730644941; x=1731249741; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LZMAe+WOB9W2kjNThmp5Md1NpYdAKB4JTZPLYv6/s6c=; b=i6CKbIk24uxJbTYNb9sM75CvhUVEmQKThklSu7u0mu31kfZLxCYe8osWpAL6g9aoJG NxaoFo7vRh1CB4ThgN/IWrVg39UOIxcLmsWZZVY48ts2xNW5pe9UDhNkqs4eQa+nQMqU CYT11nRTrP1xa+L+Ukt+H9+Gc75SxgG1/8h0mRRwGCVj3pfFBg3LgAu1OZ/H18+N5mR8 cycUgIcsSXvj9TmhdHX0tX8k15eT+NGmJl/cM5M0qm/f+jAEkiz/GiX7FkTA5OdIRoaq C3v9TImR5fqG/iEHHL33rfazSnGwj318oLDz5D9f7QTy+dF7N6/dUluIRzD8MSUnPeij LPOQ== X-Gm-Message-State: AOJu0Yy4L+6HCjCWb35azP8vY+xphRVNrbKDEPgWAnZgCvWrDK3arZGF xfrYA3w7XSSL9P9TGa+icNVVQBjKMg+482cEqtAk/swgi+/2aLcn3ou5j23zVDOiyVjCLAmwoNn i5ntlkW9FL7GxvcnSFuEv3Qx5+g7ChA== X-Google-Smtp-Source: AGHT+IFdhOVl1oup4qM66VE8SU2NvmJz0HDvgvGHeB5d1TiB74+1XLhHTsgIyVehzdZ3hMVsrM1psEAwGY8hJ3tR3yo= X-Received: by 2002:a05:6000:d4f:b0:37d:45c3:3455 with SMTP id ffacd0b85a97d-38061163803mr20726301f8f.30.1730644940875; Sun, 03 Nov 2024 06:42:20 -0800 (PST) MIME-Version: 1.0 References: <9NADMS.TKTW30GMLFXA2@gmail.com> <875xp47b97.fsf@fsfe.org> In-Reply-To: <875xp47b97.fsf@fsfe.org> From: Ashvith Shetty Date: Sun, 3 Nov 2024 14:42:08 +0000 Message-ID: Subject: Re: State of JS runtime environment in Guix To: Jelle Licht Cc: guix-devel@gnu.org Content-Type: multipart/alternative; boundary="000000000000eeefa60626032cd3" Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=ashvithshetty10@gmail.com; helo=mail-wr1-x429.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -4.72 X-Spam-Score: -4.72 X-Migadu-Queue-Id: 933075CD4A X-Migadu-Scanner: mx13.migadu.com X-TUID: M6rGmHCwZN4q --000000000000eeefa60626032cd3 Content-Type: text/plain; charset="UTF-8" Hello Jelle, I've just sent a patch series (https://issues.guix.gnu.org/74187) bumping our node-lts package to 20.18.0. This would be a first step to bumping it to 22.X.Y, after which I think it should be fairly easy to create and maintain an up-to-date node-current package. Thank you for your patches. This will also be a good exercise for me to read package definitions for `node-lts`. AFAICT node@10 is the last version that can still be used to properly bootstrap the llhttp packages without itself depending on llhttp; We use esbuild to compile all the TypeScript to JS, and subsequently use node@10 to run this JS which in turn generates the C code that is used to build llhttp (and subsequently, Node versions after 10). If this all sounds like an example of the XY problem, that's because it is :). What we really need is _some_ way to (re)generate the C code that is a part of llhttp. If there is some other (minimalist) JS runtime that could do this, that would be a major improvement over what we currently do. I had this in my head for quite a while, and maybe I could be wrong here, but could we use anything like QuickJS, tinyJS, etc? Since they do not support NPM, I highly doubt if they can be used as a substitute. WDYM exactly? Perhaps I have misread your comments at https://issues.guix.gnu.org/71581#13 . I was under the impression that llhttp may have some TypeScript/JavaScript/C code meddling with building `node-lts`. Are there any things you've already started working on? I'd love to see what we can do to make this happen. Unfortunately, no. Working with compilers and interpreters is beyond my expertise. I have just recently started to delve into system programming seriously. I don't use any of the non-npm options, but could you check if they can be installed using (e.g.) `npm install -g --prefix="$HOME/.local` after applying the patch series that bumps node to v20? Not really relevant for guix proper, but earlier this year I pushed the npm-binary importer that could perhaps be used to package some of {yarn,pnpm,lerna} in a channel or local guix.scm. Personally, I liked using `pnpm`, but I guess that this is not that serious of an issue. I think I'll try the command you've shared. I was also of the opinion that we may remove `http_parser`, but it looks like there are several dependencies - some have moved over to `llhttp`, but some packages, like `psi` and `psi-plus` are still dependent on `qhttp`, which in turn depends on `http_parser`. With respect to removing internal source dependencies, do you think it would be possible to remove dependency for `simdutf` and `uvwasi`? I think I've written package definitions for both of them earlier - maybe I could rewrite them again, and try adding them as inputs this time. Regards, Ashvith --000000000000eeefa60626032cd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div>
Hello Jelle,
I've just sent a patch series (https://issues.guix.gnu.org/74187) bumping our node-lts package to 20.18.0. This would be a first step to bumping it to 22.X.Y, after which I think it should be fairly easy to create and maintain an up-to-date node-current package.

Thank you for your patches. This will also be a good exerc= ise for me to=C2=A0
read packa= ge definitions for `node-lts`.
AFAICT node@10 is the last version that can still be used to pr= operly bootstrap the llhttp packages without itself depending on llhttp; We use=20 esbuild to compile all the TypeScript to JS, and subsequently use=20 node@10 to run this JS which in turn generates the C code that is used=20 to build llhttp (and subsequently, Node versions after 10). If this all sounds like an example of the XY problem, that's because it= =20 is :). What we really need is _some_ way to (re)generate the C code that=20 is a part of llhttp. If there is some other (minimalist) JS runtime that could do this, that would be a major improvement over what we currently=20 do.

I had thi= s in my head for quite a while, and maybe I could be=C2=A0wrong here,=C2=A0=
but could we use anything lik= e QuickJS, tinyJS, etc? Since they do not=C2=A0
support NPM, I highly doubt if they can be used as=C2=A0a= substitute.
WDYM exactly?

Perhaps I have misread= your comments at https://issues.guix.gnu.org/71581#13.
I was under the impression that llhttp may have som= e TypeScript/JavaScript/C=C2=A0
code meddling with building `node-lts`.
Are there any things you've already started working on? I&#= 39;d love to see what we can do to make this happen.

Unfortunatel= y, no. Working with compilers and interpreters is beyond my=20 expertise. I have just recently started to delve into system programming=C2= =A0
seriously.
I don't use any of the non-npm options, but could you check= if they can=20 be installed using (e.g.) `npm install -g --prefix=3D"$HOME/.local` af= ter=20 applying the patch series that bumps node to v20? Not really relevant for guix proper, but earlier this year I pushed the npm-binary importer that could perhaps be used to package some of {yarn,pnpm,lerna} in a channel or local guix.scm.

Personally, I liked using `pnpm`, but I guess that this is= not that serious of=C2=A0
an = issue. I think I'll try the command you've shared.

I was also of the opinion that we may remove `http_parser`, but it loo= ks like
there are several depe= ndencies - some have moved over to `llhttp`, but some
packages, like `psi` and `psi-plus` are still depe= ndent on `qhttp`, which in turn
depends on=C2=A0`http_parser`.

With respect to remov= ing internal source dependencies, do you think it would be=C2=A0
possible to remove dependency for `simdu= tf` and `uvwasi`? I think I've written
package=C2=A0definitions for both of them earlier - maybe I c= ould rewrite them again, and
= try adding them as inputs this time.

Regards,
Ashvith
--000000000000eeefa60626032cd3--