From owner-freebsd-arch@FreeBSD.ORG Thu Jul 31 00:50:42 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31D60853; Thu, 31 Jul 2014 00:50:42 +0000 (UTC) Received: from smtp10.server.rpi.edu (gateway.canit.rpi.edu [128.113.2.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3C872BAA; Thu, 31 Jul 2014 00:50:41 +0000 (UTC) Received: from smtp-auth1.server.rpi.edu (route.canit.rpi.edu [128.113.2.231]) by smtp10.server.rpi.edu (8.14.3/8.14.3/Debian-9.4) with ESMTP id s6V0odV8010331; Wed, 30 Jul 2014 20:50:39 -0400 Received: from smtp-auth1.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth1.server.rpi.edu (Postfix) with ESMTP id 587DF5820D; Wed, 30 Jul 2014 20:50:39 -0400 (EDT) Received: from [128.113.24.47] (gilead-qc124.netel.rpi.edu [128.113.124.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by smtp-auth1.server.rpi.edu (Postfix) with ESMTPSA id 4384A5800C; Wed, 30 Jul 2014 20:50:38 -0400 (EDT) From: "Garance A Drosehn" To: "Alfred Perlstein" Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Date: Wed, 30 Jul 2014 20:50:37 -0400 Message-ID: <07923DF8-48CC-4A05-9260-529C51922DA7@rpi.edu> In-Reply-To: <53D944F5.7000207@freebsd.org> References: <20140725044921.9F0D3580A2@chaos.jnpr.net> <20140728054217.AC1A0580A2@chaos.jnpr.net> <20140728055336.GJ50802@ivaldir.etoilebsd.net> <20140729230345.31E9B580A2@chaos.jnpr.net> <53D85495.4050408@mu.org> <20140730053446.DCE8D580A2@chaos.jnpr.net> <53D944F5.7000207@freebsd.org> MIME-Version: 1.0 X-Mailer: MailMate (1.7.2r3905) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 15.10] X-CanIt-Incident-Id: 03MwMODFM X-CanIt-Geo: ip=128.113.124.17; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 Cc: freebsd-arch@freebsd.org, phil@juniper.net, "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 00:50:42 -0000 On 30 Jul 2014, at 15:18, Alfred Perlstein wrote: > The goal of a GSOC project is to get the code into FreeBSD. > > The code can be seen here: > https://socsvn.freebsd.org/socsvn/soc2014/zkorchev/ > [...skip...] > The details for the code are here: > https://socsvn.freebsd.org/socsvn/soc2014/zkorchev/ > > You should be able to do an svn checkout and then get diffs > to see what is going on. If you require any assistance please > let me know. Those two URL's look extremely similar to me. Was the second one supposed to point to some other page? I haven't taken the time to check out the tree and skim through all the changes, but I looked at a few specific files. In .../lib/libsol/sol.c, it looks like the only format implemented so far is JSON. Is that true? Some dumb questions I should probably be able to figure out for myself: Where is SOL_JSON defined? sol.c includes sol.h, but sol.h does not seem to define that value. Also, sol.h includes yajl/yajl_gen.h, but I don't see where that file comes from. I looked at .../usr.bin/du/du.c just to see a simple example. I notice the '#if defined(SOL_ON)'. I assume that's just meant for the initial debugging, so that one could turn off all the SOL support if it was suspected of causing some problem. Is that expected to stay in the code once the code goes into production? If so, I'd rather see it as 'if (SOL_ON) { ... }', so that it's proper C code which the compiler would optimize away if SOL_ON was defined as FALSE. As a general rule I prefer to have the compiler *always* compiling&checking that code, even if some of it ends up producing no object code because SOL_ON is false. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA