From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Aleix_Conchillo_Flaqu=C3=A9?= Newsgroups: gmane.lisp.guile.devel Subject: Re: (ice-9 base64)? Date: Tue, 16 Aug 2022 10:21:43 -0700 Message-ID: References: <33556713-c85b-ab0f-554e-94a40f9d418e@telenet.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001e88e705e65efc10" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13823"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Tue Aug 16 19:22:44 2022 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oO0H5-0003NA-QA for guile-devel@m.gmane-mx.org; Tue, 16 Aug 2022 19:22:43 +0200 Original-Received: from localhost ([::1]:33856 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oO0H4-0005dS-TM for guile-devel@m.gmane-mx.org; Tue, 16 Aug 2022 13:22:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oO0GL-0005bR-QZ for guile-devel@gnu.org; Tue, 16 Aug 2022 13:22:01 -0400 Original-Received: from mail-vs1-xe2e.google.com ([2607:f8b0:4864:20::e2e]:44005) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oO0GK-0000Cx-0R for guile-devel@gnu.org; Tue, 16 Aug 2022 13:21:57 -0400 Original-Received: by mail-vs1-xe2e.google.com with SMTP id v128so10787393vsb.10 for ; Tue, 16 Aug 2022 10:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=VoFWHqrLzlLyAGOrsrE+aZ5FlyGRMHH/qRch4kaLfpM=; b=E/3RFFBvkWaPS3VcJVZ8b6xub399k0uri9pVPOmK+O9310U2S6Zj7TUq5+m0ymXXEn TMnpwbhlqGIJzXiQ21/Hd4QMRoO3egNrBe9zcaqSe/q1EVfxbcVVCsASp/m5kl3AeKcP I12tmiD1ZRvRIau56SvZo6gjd7gk9XgD6E1FGTocUwF+vo5SfjhytFnUoQeYnx5trDyG J3e4CYaBg6B5p0ugcfXFZmg9GcAx0FTWdCtDG8nJksjawtzrnEc6q/2+h+E9VPz+ckdX g3QNlAVfkPmC4VK9NUGQv0TbRJ/0wixuViVWUS9GqNGzlas6twobjFVRzsAhQIzPFHHd RG3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=VoFWHqrLzlLyAGOrsrE+aZ5FlyGRMHH/qRch4kaLfpM=; b=wTFXQTpAUs4kPeXJd/P+Et0CWESGNqg7Gm9vETJuwEOJqtcwgHQrb2fCTc+rRIJbkt 47C2XvBEuekQNrIBYlyDrpXcU5okQC9XrWCjjeGGJmqmYGk6wasxhiJ6XOqwdfn6c9Mm E+ki14H0tKEKGcgweSzyQb7lgfPsGyXNLAH6WMjLJfZg8Ju/DKyvDdJ6f7joqP2gu5r4 imiPPxkGssQM/VPh6Udx3JLiiGrJ1+l0tFO9bgnJfuRACfGEypTMQ1tJ74mfJFgcPLMp TcJQFVpjr6ok52oTCsKnTKlW4+MADz0td7o+GBMpd8pQvdtojPaQqOEmi82s2M0c7Ssa f7Cg== X-Gm-Message-State: ACgBeo3LdvBP1deYaXVa/UXR+JX087KBQkonKmPlphPXFUXcTcLseaoG iJTRFuXLA2nZOU6SY2mVh77WLpE3FSQ4pL7zfus= X-Google-Smtp-Source: AA6agR5W19yk5de+dxERNbNAiQJxX0XNgklN4jgdYMqFP8+LXXpew8w84uONlDvJUSvwWvFXHps99PFHYCZzVvyDRv8= X-Received: by 2002:a67:b303:0:b0:38a:b12f:cbc4 with SMTP id a3-20020a67b303000000b0038ab12fcbc4mr7522262vsm.46.1660670514725; Tue, 16 Aug 2022 10:21:54 -0700 (PDT) In-Reply-To: <33556713-c85b-ab0f-554e-94a40f9d418e@telenet.be> Received-SPF: pass client-ip=2607:f8b0:4864:20::e2e; envelope-from=aconchillo@gmail.com; helo=mail-vs1-xe2e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:21302 Archived-At: --0000000000001e88e705e65efc10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos wrote= : > > On 16-08-2022 18:10, Aleix Conchillo Flaqu=C3=A9 wrote: > > Hi, > > In many projects I've been copying G=C3=B6ran Weinholt's base64 implement= ation > and I've also seen it in other projects, would it make sense to include i= t > in Guile's standard library? [...] > > If we do this, we should contact the various other projects to make them > use (ice-9 base64). > > I think they could switch whenever they want (i.e. whenever this was added to Guile) or even not switch at all. > I think it would be simpler though to consider the base64 in guile-gcrypt > to be 'canonical', it would avoid problems with old versions of Guile not > having the base64 module and newer version having it, which would prevent > using the proposed (ice-9 base64) in Guile because it would break > build-aux/build-self.scm when pulling or time-machining from old Guix tha= t > have an old Guile. > > I've been waiting on a guile-gcrypt release for a while now (Ludo, Chrisitine... any help here? :-) ). I ported guile-jwt to use guile-gcrypt but I need a release to have latest base64 changes: https://notabug.org/cwebber/guile-gcrypt/commit/f8934ec94df5868ee8baf1fb0f8= ed0f24e7e91eb But you are right that this would cause a backward compatible problem, but I guess that would depend on each project. Can we do conditional module loading? I've done this in the past with Python... if we are in Python 2 load this module, otherwise load this other one. So projects could do that. > Whether we simply replace (guix base64) by (gcrypt base64) depends on how > old (gcrypt base64) is compared to the earliest 'supported' Guix for > pull/time-travel, but even if it is not present in the old gcrypt, we can > work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.sc= m, > so we can easily have a (define gcrypt-base64 [some copy])). Or simply > update the local guile-gcrypt in buid-aux/build-self.scm. > > guile-gcrypt base64 is pretty new with the patch above (but no release after that), I have no idea if Guix has added anything else. > OTOH a similar replacement can be done for (ice-9 base64), but > transitioning to (ice-9 base64) would take much longer, at least until th= e > various distributions are updated to a Guile that has (ice-9 base64), > whereas (gcrypt base64) could be switched to immediately. > > > Maybe this could be handled by each project independently. Best, Aleix --0000000000001e88e705e65efc10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 16, 2022 at 9:59= AM Maxime Devos <maximedevos@= telenet.be> wrote:
=20 =20 =20


On 16-08-2022 18:10, Aleix Conchillo Flaqu=C3=A9 wrote:
Hi,

In many project= s I've been copying G=C3=B6ran Weinholt's base64 i= mplementation and I've also seen it in other projects, would it make sense to include it in Guile's standard library? [...]

If we do this, we should contact the various other projects to make them use (ice-9 base64).


I think they could switc= h whenever they want (i.e. whenever this was added to Guile) or even not sw= itch at all.
=C2=A0

I think it would be simpler though to consider the = base64 in guile-gcrypt to be 'canonical', it would avoid problems with = old versions of Guile not having the base64 module and newer version having it, which would prevent using the proposed (ice-9 base64) in Guile because it would break build-aux/build-self.scm when pulling or time-machining from old Guix that have an old Guile.


I've been waiting = on a guile-gcrypt release for a while now (Ludo, Chrisitine... any=C2=A0hel= p here? :-) ).=C2=A0 I ported guile-jwt to use guile-gcrypt but I need a re= lease to have latest base64 changes:

https://notabug.org/cwebber/guile-gcrypt/commit/f8934ec94df5= 868ee8baf1fb0f8ed0f24e7e91eb

But you are right that this would cause a backward= compatible problem, but I guess that would depend on each project. Can we = do conditional module loading? I've done this in the past with Python..= . if we are in Python 2 load this module, otherwise load this other one. So= projects could do that.

Whether we simply replace (guix base64) by (gcrypt base64) depends on how old (gcrypt base64) is compared to the earliest 'supported' Guix for pull/time-travel, but even if it is not present in the old gcrypt, we can work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.scm, so we can eas= ily have a (define gcrypt-base64 [some copy])).=C2=A0 Or simply update th= e local guile-gcrypt in buid-aux/build-self.scm.

guile-gcrypt base64 is pretty new wit= h the patch above (but no release after that), I have no idea if Guix has a= dded anything else.
=C2=A0

OTOH a similar replacement can be done for (= ice-9 base64), but transitioning to (ice-9 base64) would take much longer, at least until the various distributions are updated to a Guile that has (ice-9 base64), whereas (gcrypt base64) could be switched to immediately.


Maybe this could be handled by = each project independently.

= Best,

Aleix
=C2=A0
--0000000000001e88e705e65efc10--