Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id p2HEo07r021975 for ; Thu, 17 Mar 2011 15:50:02 +0100 Received: (qmail 28749 invoked by alias); 17 Mar 2011 14:49:55 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 17 Mar 2011 14:49:55 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx086) with SMTP; 17 Mar 2011 15:49:55 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p2HElgVK024478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2011 15:47:42 +0100 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p2HEiKwK021942; Thu, 17 Mar 2011 15:47:32 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1260481 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 17 Mar 2011 15:47:32 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id p2HElWPa008515 for ; Thu, 17 Mar 2011 15:47:32 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id p2HElSqN024348 for ; Thu, 17 Mar 2011 15:47:31 +0100 Received: from morse.mittelbach-online.de (p3EE3EBBF.dip.t-dialin.net [62.227.235.191]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Mf6s9-1QOkXm3cO9-00OTXd; Thu, 17 Mar 2011 15:47:28 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id D1DCC7227B; Thu, 17 Mar 2011 15:47:24 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <905C5ED0-6639-4DEB-95AC-A2FCB2C4491D@gmail.com> <935A1EA2-C971-4A3A-8DF4-6F890E0CFB32@gmail.com> <5256FD2C-CD53-4FF0-A405-5B8B2781E5EC@gmail.com> <19841.6013.376122.141695@morse.mittelbach-online.de> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V02:K0:ZlEUjQBCxiUiVhAMJEXAHmJBW1JIv/b5YFUYTytU67i Qo+IzlxJha3YNrS3S74nVOj3omM2wndQEdj4+zxqtd2Ls8YVih lnEKPwZhbgZKVPbrd4kw547Z0inidBvSM9sRn41YU/Wj7EK5MC VCuPqd0++HGKhAoUOrTXjLR+KS7M8cnDx4qSJX14hclkgUxkLD 42LGSI4LKY6HPjiw2r4fQ== X-Spam-Whitelist-Provider: Message-ID: <19842.7932.690909.484106@morse.mittelbach-online.de> Date: Thu, 17 Mar 2011 15:47:24 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: expl3's seq_pop_right etc. To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (Mail was not recognized as spam); Detail=5D7Q89H36p77e5KAPs1l6v/Sb97LojnDtMgfETrECMLUO9erHzOJe+OynZRhvlGqb5A0X bbiCt2rAnnct/NAlbHMvoAL6GY+23tB3khNK7Y6oT1sPizBjJUAOds0oJBO/5TIz9C5741aj9GOJ bE70Q==V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 6679 Hi Bruno, > > I took your package pushed it into my environment and first of all tried > > to > > run our test suite against it. Of course that ended up in a huge number of > > failures. > > I'm sorry about that. I'm couldn't get "make check" to work (on a > clean svn download), and I'm investigating that (I probably misplaced > some file, or permissions). it is also quite likely that we have incorrectly built in some assumptions that don't hold. perhaps we should offline try to sort out what goes wrong at your end. > Right. I should have double-checked: I lost quite a few variants along > the way as well, and unfortunately, I was working from a version of > l3seq which was a few weeks old. don't think that there have been much change here so that shouldn't be a problem > > there are a number of advantages to this most importantly for me that we can > > run the test suite against the new code. So far I added > > After a manual grep (more or less), I think we need to add the following. I'll check what that gives me. > % Auxiliary functions (needed?). aux functions should not be needed. the idea is that [aux] is internal to a module, so if you replace the implementation no outside module should be affected (in theory :-). > Hopefully that's ok. Of course, if other modules happen to try and > define their own seq functions using \seq_elt:w, then that's not going > to work. yeah tough. > If possible, could you send me a log of those tests that fail? It > would help me find all the missing functions. sure once I've run it > > So I propose we first make your implementation support the current > > interfaces (even if only by compatibility code) so that the files > > m3seq00... are properly processed and in parallel discuss its individual > > merrits and preferably we should at the same time write some additional > > tests for any functionality that has changed or is additionally there > > (Joseph will tell you that I'm pestering him about writing test cases in > > parallel wil code, but it really helps to nail down interfaces and ensure > > that they aren't violated later) > > As I said, I can't run "make check" right now. Is it possible to run > single tests "by hand"? in theory, something like make checklvt F=m3seq003 should run the test on a single file, but you probably see the same issues (whatever they are) > Then there is the issue of l3candidates, which I have not > re-programmed yet, as well as the quicksort defined in l3prg.dtx one step at a time i'd say. frank