On Tue, Mar 3, 2015 at 11:07 AM, Justin Hibbits
wrote:
> On Tue, Mar 3, 2015 at 10:39 AM, Alfred Perlstein wrote:
> >
> >
> > Sent from my iPhone
> >
> >> On Mar 3, 2015, at 9:32 AM, hiren panchasara <
> hi...@strugglingcoder.info> wrote:
> >>
> >>> On 03/02/15 at 07:33P, Alfred Perlstein wrote:
On Mon, Mar 2, 2015 at 7:33 PM, Alfred Perlstein wrote:
>
>
> Actually I want to shame third party ports into adopting libxo (or at
least providing machine readable output).
Well if upstream third party ports adopt libxo will remain to be seen.
However, one thing we can do is to make it super-du
On Wed, Mar 4, 2015 at 1:11 PM, John Baldwin wrote:
> On Wednesday, March 04, 2015 10:35:34 AM Alfred Perlstein wrote:
> > On 3/4/15 8:21 AM, John Baldwin wrote:
> > > I would probably want
> > > pciconf -l in that case to dump the entire PCI header (right now the
> > > human-readable pciconf -l
On Wednesday, March 04, 2015 10:35:34 AM Alfred Perlstein wrote:
> On 3/4/15 8:21 AM, John Baldwin wrote:
> > I would probably want
> > pciconf -l in that case to dump the entire PCI header (right now the
> > human-readable pciconf -l only dumps a subset), and I would want it to dump
> > fields in
On 04.03.2015 19:21, John Baldwin wrote:
> On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote:
>> Hopefully there's a lesson here that we can learn from: human-readable
>> formats do not make good intermediate representations when communicating
>> between tools.
>
> I think this is actual
On 3/4/15 8:21 AM, John Baldwin wrote:
On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote:
Hopefully there's a lesson here that we can learn from: human-readable
formats do not make good intermediate representations when communicating
between tools.
I think this is actually an argum
On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote:
> Hopefully there's a lesson here that we can learn from: human-readable
> formats do not make good intermediate representations when communicating
> between tools.
I think this is actually an argument against libxo-ification in the one
On 3 Mar, David Chisnall wrote:
> On 3 Mar 2015, at 01:32, Andrey Chernov wrote:
>>
>> So, why you ever need to modify wc? Just load wc inside your
>> json/xml/etc writer, replacing its printf at the ld-elf.so level.
>
> You can't get structured output from printf() because printf() takes
> uns
On Tue, Mar 03, 2015 at 09:09:43AM +, David Chisnall wrote:
>
> If your argument is about binary size, then it would be relatively
> easy for us to add a version of libxo for static linking into the
> versions in /rescue that only supported plain-text output, but
> again, please quantify your
On 2 March 2015 at 00:25, Craig Rodrigues wrote:
> On Sun, Mar 1, 2015 at 10:49 AM, Harrison Grundy <
> harrison.gru...@astrodoggroup.com> wrote:
>
> > Thanks!
> >
> > That does seem useful, but I'm not sure I see the reasoning behind
> > putting into base, over a port or package
> >
>
>
> > , si
On Tue, Mar 3, 2015 at 11:14 AM, Alfred Perlstein wrote:
>
>
>> On Mar 3, 2015, at 11:07 AM, Justin Hibbits wrote:
>>
>>> On Tue, Mar 3, 2015 at 10:39 AM, Alfred Perlstein wrote:
>>>
>>>
>>> Sent from my iPhone
>>>
> On Mar 3, 2015, at 9:32 AM, hiren panchasara
> wrote:
>
> On
> On Mar 3, 2015, at 11:07 AM, Justin Hibbits wrote:
>
>> On Tue, Mar 3, 2015 at 10:39 AM, Alfred Perlstein wrote:
>>
>>
>> Sent from my iPhone
>>
On Mar 3, 2015, at 9:32 AM, hiren panchasara
wrote:
On 03/02/15 at 07:33P, Alfred Perlstein wrote:
Actua
On Tue, Mar 3, 2015 at 10:39 AM, Alfred Perlstein wrote:
>
>
> Sent from my iPhone
>
>> On Mar 3, 2015, at 9:32 AM, hiren panchasara
>> wrote:
>>
>>> On 03/02/15 at 07:33P, Alfred Perlstein wrote:
>>>
>
>>>
>>> Actually I want to shame third party ports into adopting libxo (or at least
>>>
Sent from my iPhone
> On Mar 3, 2015, at 9:32 AM, hiren panchasara
> wrote:
>
>> On 03/02/15 at 07:33P, Alfred Perlstein wrote:
>>
>>
>> Actually I want to shame third party ports into adopting libxo (or at least
>> providing machine readable output).
>>
>> I know it's scary to try
On 03/02/15 at 07:33P, Alfred Perlstein wrote:
>
>
> > On Mar 2, 2015, at 7:14 PM, Julian Elischer wrote:
> >
> >> On 3/2/15 5:30 PM, Alfred Perlstein wrote:
> >>
> On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote:
>
> > On 02.03.2015 22:55, Julian Elischer wrote:
> > On 3/
On 3 Mar 2015, at 01:32, Andrey Chernov wrote:
>
> So, why you ever need to modify wc? Just load wc inside your
> json/xml/etc writer, replacing its printf at the ld-elf.so level.
You can't get structured output from printf() because printf() takes
unstructured input. It's a string with some v
> On Mar 2, 2015, at 7:14 PM, Julian Elischer wrote:
>
>> On 3/2/15 5:30 PM, Alfred Perlstein wrote:
>>
On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote:
> On 02.03.2015 22:55, Julian Elischer wrote:
> On 3/2/15 5:27 AM, Alfred Perlstein wrote:
>
>
>>> On 3/2/
On 3/2/15 5:30 PM, Alfred Perlstein wrote:
On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote:
On 02.03.2015 22:55, Julian Elischer wrote:
On 3/2/15 5:27 AM, Alfred Perlstein wrote:
On 3/2/15 4:14 AM, Julian Elischer wrote:
On 3/1/15 10:49 AM, Harrison Grundy wrote:
Thanks!
That does see
> On Mar 2, 2015, at 6:27 PM, Andrey Chernov wrote:
>>
>>
>> The responsibility is on you to provide something better, both the
>> architecture AND code. So if you want it backed out, then write something
>> better. Otherwise step back and let progress happen.
>
> As it seems you know a lot
On Mon, Mar 02, 2015 at 05:30:31PM -0800, Alfred Perlstein wrote:
>
> Read the library. It doesn't care what output format it needs.
> It is up to the translation layer to do it. You could even do
> a csv format or most any other structured output format without
> changing the userland utils.
>
On 03.03.2015 4:45, Alfred Perlstein wrote:
>
>
>> On Mar 2, 2015, at 5:37 PM, Andrey Chernov wrote:
>>
>>> On 03.03.2015 4:30, Alfred Perlstein wrote:
>>>
>>>
> On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote:
>
>> On 02.03.2015 22:55, Julian Elischer wrote:
>> On 3/2/15 5:27
> On Mar 2, 2015, at 5:37 PM, Andrey Chernov wrote:
>
>> On 03.03.2015 4:30, Alfred Perlstein wrote:
>>
>>
On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote:
> On 02.03.2015 22:55, Julian Elischer wrote:
> On 3/2/15 5:27 AM, Alfred Perlstein wrote:
>
>
>>> On
On 03.03.2015 3:48, Allan Jude wrote:
> On 2015-03-02 19:22, Andrey Chernov wrote:
>> On 02.03.2015 22:55, Julian Elischer wrote:
>>> On 3/2/15 5:27 AM, Alfred Perlstein wrote:
On 3/2/15 4:14 AM, Julian Elischer wrote:
> On 3/1/15 10:49 AM, Harrison Grundy wrote:
>> Thanks!
>
On 03.03.2015 4:30, Alfred Perlstein wrote:
>
>
>> On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote:
>>
>>> On 02.03.2015 22:55, Julian Elischer wrote:
On 3/2/15 5:27 AM, Alfred Perlstein wrote:
> On 3/2/15 4:14 AM, Julian Elischer wrote:
>> On 3/1/15 10:49 AM, Harrison Gr
> On Mar 2, 2015, at 4:22 PM, Andrey Chernov wrote:
>
>> On 02.03.2015 22:55, Julian Elischer wrote:
>>> On 3/2/15 5:27 AM, Alfred Perlstein wrote:
>>>
>>>
On 3/2/15 4:14 AM, Julian Elischer wrote:
> On 3/1/15 10:49 AM, Harrison Grundy wrote:
> Thanks!
>
> That does seem
On Mon, Mar 2, 2015 at 3:45 PM, Alfred Perlstein wrote:
>
>
> On 3/2/15 4:57 PM, Adrian Chadd wrote:
>
>> .. we can/should do both.
>>
>> Just make sure the json/html/xml output is versioned, otherwise you're
>> going to end up with /exactly the same problems/ you have with the
>> current format.
On 2015-03-02 19:22, Andrey Chernov wrote:
> On 02.03.2015 22:55, Julian Elischer wrote:
>> On 3/2/15 5:27 AM, Alfred Perlstein wrote:
>>>
>>>
>>> On 3/2/15 4:14 AM, Julian Elischer wrote:
On 3/1/15 10:49 AM, Harrison Grundy wrote:
> Thanks!
>
> That does seem useful, but I'm not s
On 02.03.2015 22:55, Julian Elischer wrote:
> On 3/2/15 5:27 AM, Alfred Perlstein wrote:
>>
>>
>> On 3/2/15 4:14 AM, Julian Elischer wrote:
>>> On 3/1/15 10:49 AM, Harrison Grundy wrote:
Thanks!
That does seem useful, but I'm not sure I see the reasoning behind
putting into base
On 3/2/15 4:57 PM, Adrian Chadd wrote:
.. we can/should do both.
Just make sure the json/html/xml output is versioned, otherwise you're
going to end up with /exactly the same problems/ you have with the
current format.
+1
-Alfred
___
freebsd-cur
.. we can/should do both.
Just make sure the json/html/xml output is versioned, otherwise you're
going to end up with /exactly the same problems/ you have with the
current format.
-adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freeb
On 03/02/15 11:55, Julian Elischer wrote:
> On 3/2/15 5:27 AM, Alfred Perlstein wrote:
>>
>>
>> On 3/2/15 4:14 AM, Julian Elischer wrote:
>>> On 3/1/15 10:49 AM, Harrison Grundy wrote:
Thanks!
That does seem useful, but I'm not sure I see the reasoning behind
putting into base
On 3/2/15 2:53 PM, Julian Elischer wrote:
On 3/2/15 5:25 AM, Alfred Perlstein wrote:
On 3/2/15 4:25 AM, David Chisnall wrote:
On 2 Mar 2015, at 09:16, Julian Elischer wrote:
if we develop a suitable post processor with pluggable grammars, we
save a lot of work.
given enough examples you c
On 3/2/15 5:27 AM, Alfred Perlstein wrote:
On 3/2/15 4:14 AM, Julian Elischer wrote:
On 3/1/15 10:49 AM, Harrison Grundy wrote:
Thanks!
That does seem useful, but I'm not sure I see the reasoning behind
putting into base, over a port or package, since processing XML in
base
is a pain, and
On 3/2/15 5:25 AM, Alfred Perlstein wrote:
On 3/2/15 4:25 AM, David Chisnall wrote:
On 2 Mar 2015, at 09:16, Julian Elischer wrote:
if we develop a suitable post processor with pluggable grammars,
we save a lot of work.
given enough examples you could almost have automatically
generated gra
On Mon, 2 Mar 2015 09:23:55 + David Chisnall wrote
> On 1 Mar 2015, at 21:29, Rui Paulo wrote:
> >
> > On Mar 1, 2015, at 11:11, David Chisnall wrote:
> >> How would it be in a port? It involves modifying core utilities (some of
> >> which, like ifconfig, rely on kernel APIs that change b
On 3/2/15 4:14 AM, Julian Elischer wrote:
On 3/1/15 10:49 AM, Harrison Grundy wrote:
Thanks!
That does seem useful, but I'm not sure I see the reasoning behind
putting into base, over a port or package, since processing XML in base
is a pain, and it can't serve up JSON or HTML without additio
On 3/2/15 4:25 AM, David Chisnall wrote:
On 2 Mar 2015, at 09:16, Julian Elischer wrote:
if we develop a suitable post processor with pluggable grammars, we save a lot
of work.
given enough examples you could almost have automatically generated grammars.
This decoupled approach is problemat
On 2 Mar 2015, at 09:24, Harrison Grundy
wrote:
>
> It would seem like the libxo stuff runs the risk of becoming this same
> API.
Why? The 'API' in the case of an libxo-ised program is a stream on stdout that
is then consumed by a JSON or XML parser. XML and JSON are intrinsically
extensible
On 03/02/15 01:23, David Chisnall wrote:
> On 1 Mar 2015, at 21:29, Rui Paulo wrote:
>>
>> On Mar 1, 2015, at 11:11, David Chisnall
>> wrote:
>>> How would it be in a port? It involves modifying core
>>> utilities (some of which, like ifconfig, rely on kernel APIs
>>> that change between rele
On 2 Mar 2015, at 09:16, Julian Elischer wrote:
>
> if we develop a suitable post processor with pluggable grammars, we save a
> lot of work.
> given enough examples you could almost have automatically generated grammars.
This decoupled approach is problematic. A large part of the point of lib
On 1 Mar 2015, at 21:29, Rui Paulo wrote:
>
> On Mar 1, 2015, at 11:11, David Chisnall wrote:
>> How would it be in a port? It involves modifying core utilities (some of
>> which, like ifconfig, rely on kernel APIs that change between releases) to
>> emit structured output. Maintaining two co
On 3/1/15 11:10 AM, Allan Jude wrote:
On 2015-03-01 13:49, Harrison Grundy wrote:
Thanks!
That does seem useful, but I'm not sure I see the reasoning behind
putting into base, over a port or package, since processing XML in base
is a pain, and it can't serve up JSON or HTML without additional
u
On 3/1/15 10:49 AM, Harrison Grundy wrote:
Thanks!
That does seem useful, but I'm not sure I see the reasoning behind
putting into base, over a port or package, since processing XML in base
is a pain, and it can't serve up JSON or HTML without additional
utilities anyway.
(If I'm reviving a lon
On 2 March 2015 at 04:47, Allan Jude wrote:
> On 2015-03-01 19:20, Arseny Nasokin wrote:
> > On 1 March 2015 at 22:10, Allan Jude wrote:
> >
> >> On 2015-03-01 13:49, Harrison Grundy wrote:
> >>> Thanks!
> >>>
> >>> That does seem useful, but I'm not sure I see the reasoning behind
> >>> putting
On 3/1/15 4:57 PM, Harrison Grundy wrote:
I like the idea behind this... where I'm running into difficulty is why
these bits of functionality need to be combined. What someone does with
ifconfig on the command line, versus what someone wants to know about
their network interfaces in an XML dump
On 3/1/15 4:29 PM, Rui Paulo wrote:
On Mar 1, 2015, at 11:11, David Chisnall wrote:
How would it be in a port? It involves modifying core utilities (some of
which, like ifconfig, rely on kernel APIs that change between releases) to emit
structured output. Maintaining two copies of each ut
How about we allow JSON input on those utils too... Then we get into
full-blown hell faster.
Hmm... I would like to talk with system using JSON. JSON would be in
utils that are or at least function similarly to rm, mv, ls, find,
mount, zpool, zfs, geom, mdconfig, tar, df, netstat, ifconfig... (or
On 2015-03-01 19:20, Arseny Nasokin wrote:
> On 1 March 2015 at 22:10, Allan Jude wrote:
>
>> On 2015-03-01 13:49, Harrison Grundy wrote:
>>> Thanks!
>>>
>>> That does seem useful, but I'm not sure I see the reasoning behind
>>> putting into base, over a port or package, since processing XML in b
On 1 March 2015 at 22:10, Allan Jude wrote:
> On 2015-03-01 13:49, Harrison Grundy wrote:
> > Thanks!
> >
> > That does seem useful, but I'm not sure I see the reasoning behind
> > putting into base, over a port or package, since processing XML in base
> > is a pain, and it can't serve up JSON or
On 03/01/15 13:25, Craig Rodrigues wrote:
> On Sun, Mar 1, 2015 at 10:49 AM, Harrison Grundy <
> harrison.gru...@astrodoggroup.com> wrote:
>
>> Thanks!
>>
>> That does seem useful, but I'm not sure I see the reasoning behind
>> putting into base, over a port or package
>>
>
>
>> , since proces
On Mar 1, 2015, at 11:11, David Chisnall wrote:
> How would it be in a port? It involves modifying core utilities (some of
> which, like ifconfig, rely on kernel APIs that change between releases) to
> emit structured output. Maintaining two copies of each utility, one in the
> base system wi
On Sun, Mar 1, 2015 at 10:49 AM, Harrison Grundy <
harrison.gru...@astrodoggroup.com> wrote:
> Thanks!
>
> That does seem useful, but I'm not sure I see the reasoning behind
> putting into base, over a port or package
>
> , since processing XML in base is a pain, and it can't serve up JSON or
>
On Mar 1, 2015, at 5:33, Sulev-Madis Silber (ketas) wrote:
> Hello.
>
> First, I would be happy to have JSON and XML output about filesystems,
> users, routes... but I don't like how it makes code of df, w, netstat
> hard to read/maintain and often broken.
>
> I don't think it would be good to
On 03/01/15 11:11, David Chisnall wrote:
> On 1 Mar 2015, at 18:49, Harrison Grundy
> wrote:
>>
>> That does seem useful, but I'm not sure I see the reasoning
>> behind putting into base, over a port or package, since
>> processing XML in base is a pain, and it can't serve up JSON or
>> HTML with
On 1 Mar 2015, at 18:49, Harrison Grundy
wrote:
>
> That does seem useful, but I'm not sure I see the reasoning behind
> putting into base, over a port or package, since processing XML in base
> is a pain, and it can't serve up JSON or HTML without additional
> utilities anyway.
How would it be
On 2015-03-01 13:49, Harrison Grundy wrote:
> Thanks!
>
> That does seem useful, but I'm not sure I see the reasoning behind
> putting into base, over a port or package, since processing XML in base
> is a pain, and it can't serve up JSON or HTML without additional
> utilities anyway.
>
> (If I'm
Thanks!
That does seem useful, but I'm not sure I see the reasoning behind
putting into base, over a port or package, since processing XML in base
is a pain, and it can't serve up JSON or HTML without additional
utilities anyway.
(If I'm reviving a long-settled thing, let me know and I'll drop it
On Sun, Mar 1, 2015 at 9:25 AM, Harrison Grundy <
harrison.gru...@astrodoggroup.com> wrote:
>
>
> If someone could summarize what this is, I'd greatly appreciate it.
>
https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015633.html
___
freebsd-cu
On Mar 1, 2015, at 09:25, Harrison Grundy
wrote:
> Due to the lack of XML parsing code in -base, the difficulty in
> maintaining yet another interface, and the overhead involved in doing
> it, I don't quite see where one would really want XML output *and* be
> entirely opposed to ports or package
On 03/01/15 05:33, Sulev-Madis Silber (ketas) wrote:
> Hello.
>
> First, I would be happy to have JSON and XML output about
> filesystems, users, routes... but I don't like how it makes code of
> df, w, netstat hard to read/maintain and often broken.
>
> I don't think it would be good to contin
On Sun, 01 Mar 2015 11:26:01 -0500
Allan Jude wrote:
> On 2015-03-01 08:33, Sulev-Madis Silber (ketas) wrote:
> > Hello.
> >
> > First, I would be happy to have JSON and XML output about
> > filesystems, users, routes... but I don't like how it makes code of
> > df, w, netstat hard to read/mai
On Sun, Mar 01, 2015 at 11:26:01AM -0500, Allan Jude wrote:
> On 2015-03-01 08:33, Sulev-Madis Silber (ketas) wrote:
>
> Is there a specific bug you are running in to? So far the only bugs I've
> seen with the xo-ification have been ones where the JSON output was not
> always well formed.
>
Give
On 2015-03-01 08:33, Sulev-Madis Silber (ketas) wrote:
> Hello.
>
> First, I would be happy to have JSON and XML output about filesystems,
> users, routes... but I don't like how it makes code of df, w, netstat
> hard to read/maintain and often broken.
>
> I don't think it would be good to contin
Hello.
First, I would be happy to have JSON and XML output about filesystems,
users, routes... but I don't like how it makes code of df, w, netstat
hard to read/maintain and often broken.
I don't think it would be good to continue with this. Maybe the effort
should be put to creating new layer/li
64 matches
Mail list logo
