From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MwzjA-00036u-GB for qemu-devel@nongnu.org; Sun, 11 Oct 2009 10:48:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mwzj6-00036Q-BG for qemu-devel@nongnu.org; Sun, 11 Oct 2009 10:48:52 -0400 Received: from [199.232.76.173] (port=33833 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mwzj6-00036N-3q for qemu-devel@nongnu.org; Sun, 11 Oct 2009 10:48:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13702) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mwzj4-0006iC-Us for qemu-devel@nongnu.org; Sun, 11 Oct 2009 10:48:47 -0400 Date: Sun, 11 Oct 2009 11:48:34 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH v0 00/10]: More QObject conversions Message-ID: <20091011114834.3fb71699@doriath> In-Reply-To: <877hv31ldb.fsf@pike.pond.sub.org> References: <1255037747-3340-1-git-send-email-lcapitulino@redhat.com> <877hv31ldb.fsf@pike.pond.sub.org> 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: Markus Armbruster Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Sat, 10 Oct 2009 14:31:12 +0200 Markus Armbruster wrote: > Luiz Capitulino writes: > > > Hi there, > > > > Here goes another set of conversions, just to keep the ball rolling. > > > > The first patch introduces a function called qobject_from_fmt(), which can > > be used to build QObjects from a specified printf-like format. > > > > Most of its code was based on a Python function with similiar functionality, > > as far as I could understand the license is compatible and I've added a > > copyright notice. > > > > Is this the right procedure? > > > > Most patches are simple (as we aren't converting errors yet), except the > > last ones. Which use qobject_from_fmt() and are very cool, hopefully they're > > right too. :) > > > > PS: This series apply on top of my last 'Initial QObject conversion' series. > > > > Thanks. > > The separation of presentation from logic seems to work reasonably well > so far. The separation involves building explicit data to be sent by a > separate presentation function instead of printing right away. It's key > that this data building code is about as legible and easy to maintain as > the old, straightforward printing. qobject_from_fmt() helps with that, > in my opinion. Yes, it helps, although adding more abstraction layers usually makes things more complex.. That is, this is never going to be as simple as directly calling monitor_printf(). > Of course, much "interesting" stuff remains, chiefly errors. Yes, and errors are more complicated than regular output because sometimes we have something like: command_handler() func1() func2() func3() <--- calls monitor_printf() on error Also, an error condition has to be differently handled from regular output, so that the protocol can emit it as an error. I've implemented QError, which (IMHO) is a good enough solution for the problem. Will submit it as soon as I get more feedback on this last series. > Also any > output that doesn't fit into the "run command to completion, report its > result" mold (not sure we need that). We'll see how it goes. Do you have an existing example? > PS: Fun to see Greenspun's Tenth Rule in action once more. Let's rewrite qemu in lisp then. :-)