From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MyU8F-0006Cp-56 for qemu-devel@nongnu.org; Thu, 15 Oct 2009 13:28:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MyU8A-0006CJ-H9 for qemu-devel@nongnu.org; Thu, 15 Oct 2009 13:28:54 -0400 Received: from [199.232.76.173] (port=36500 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MyU8A-0006CG-Co for qemu-devel@nongnu.org; Thu, 15 Oct 2009 13:28:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22012) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MyU89-00045g-VU for qemu-devel@nongnu.org; Thu, 15 Oct 2009 13:28:50 -0400 Date: Thu, 15 Oct 2009 14:28:37 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 01/10] Introduce qmisc module Message-ID: <20091015142837.6c90580a@doriath> In-Reply-To: <20091015163936.GB532@redhat.com> References: <1255037747-3340-1-git-send-email-lcapitulino@redhat.com> <1255037747-3340-2-git-send-email-lcapitulino@redhat.com> <4AD72B88.2040107@codemonkey.ws> <20091015122622.1f93ea2d@doriath> <20091015163936.GB532@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org On Thu, 15 Oct 2009 17:39:36 +0100 "Daniel P. Berrange" wrote: > On Thu, Oct 15, 2009 at 12:26:22PM -0300, Luiz Capitulino wrote: > > On Thu, 15 Oct 2009 09:02:48 -0500 > > Anthony Liguori wrote: > > > > > > > > If we're introducing third-party code under a new license, we need to > > > update the top-level LICENSE file. I took a brief look and it wasn't > > > immediately clear that this license is GPL compatible. According to the > > > FSF, certain versions of this license are incompatible and some are > > > compatible. I think it would have been better to just write something > > > from scratch... > > > > According to the Python's LICENSE file it's compatible since 2001 > > (2.0.1 release). > > > > > > + case '[': > > > > + return do_mklist(fmt, args, ']', count_format(*fmt, ']')); > > > > > > > > > > Because this is bizarre. It looks ahead to count the number of > > > arguments which is a very strange way to parse something like this. > > > > > > Why not a simple recursive decent parser? > > > > I could try it, but I think this is going to take some time as > > I would have to read more about it. > > > > I thought the Python's implementation was a good idea as we're short > > in time and it was easy to adapt and is widely used in production. > > There are at least 6 standalone, pure C [1] json parsers available > already, some of which let you do json formatting too. So writing a > new parser, or untangling one from python seems like more trouble than > its worth to me. Likewise for generating formatted JSON output. Not the right context but I was going to post about this soon, so I think this is a good opportunity to talk about it. I didn't look at all available parsers from json.org, but this one: http://fara.cs.uni-potsdam.de/~jsg/json_parser/ Seems interesting. Anthony, are you ok in using external implementations like that if they meet our requirements?