From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Cuirass news Date: Sat, 10 Feb 2018 12:18:56 +0100 Message-ID: <874lmpw0rj.fsf@gnu.org> References: <877es6x5xj.fsf@gnu.org> <87lggmjjgo.fsf@gmail.com> <87k1w6jjak.fsf@gmail.com> <87h8raxeym.fsf@gnu.org> <20180126153005.259a75e8@scratchpost.org> <87zi4z1eb0.fsf@gnu.org> <20180127181852.42f0bcbf@scratchpost.org> <87fu6bwqix.fsf@gnu.org> <20180208172905.19e9e789@scratchpost.org> <871shvt94p.fsf@gnu.org> <20180209000526.5b9ea8e7@scratchpost.org> <87wozm4i12.fsf@gnu.org> <20180209122931.5a47e63e@scratchpost.org> <877ermyuj2.fsf@gnu.org> <20180209180608.79fb856b@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ekTBX-0003nz-0l for guix-devel@gnu.org; Sat, 10 Feb 2018 06:19:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ekTBT-0004uZ-Nf for guix-devel@gnu.org; Sat, 10 Feb 2018 06:19:10 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:47992) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ekTBT-0004t7-Cb for guix-devel@gnu.org; Sat, 10 Feb 2018 06:19:07 -0500 In-Reply-To: <20180209180608.79fb856b@scratchpost.org> (Danny Milosavljevic's message of "Fri, 9 Feb 2018 18:06:08 +0100") 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+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel Hi Danny, Danny Milosavljevic skribis: > the patch LGTM! Pushed! >>I=E2=80=99d reluctant to =E2=80=98sqlite-uncache!=E2=80=99 though. > > I was thinking if you are in the REPL and actually want it to forget the > statement which you cached before, it would be good to be able to do that. > I wonder what I was thinking that was good for, though. > > User can always just close the database connection. Yeah. :-) Now I have another problem: with HTTP requests are now processed concurrently for real. But that brings its own set of problems, in particular the fact that access is not thread-safe, as discussed earlier. Thinking about it, it wouldn=E2=80=99t matter that HTTP requests are proces= sed sequentially if database queries run really fast. I=E2=80=99m not sure if = we can achieve it. WDYT? Thanks, Ludo=E2=80=99. PS: I=E2=80=99ll be away for the next few days.