Re: [dev] Some thoughts about XML
Evan Buswell dixit:
>like you're gonna put UTF-8 parsing into cat.
cat is just a sendfile, it’s not doing anything with the content.
On the other hand, for a data exchange format, some measure of
data types is a commodity. JSON is not binary-safe, true, but the
Unix/Plan 9 way doesn’t need it to be.
>On Sat, Oct 19, 2013 at 4:33 PM, Dmitrij D. Czarkoff
>wrote:
Oh and, for fucks sake, learn writing eMails!
Read http://www.afaik.de/usenet/faq/zitieren/ (this has links to
the English and Dutch version as well).
bye,
//mirabilos
--
> Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
Re: [dev] Some thoughts about XML
Evan Buswell said: > I'm really not saying something very profound here, so I'm a bit > confused by the sarcastic response. For certain things it's pointless > and inefficient to parse something and then deparse it later. It's not > like you're gonna put UTF-8 parsing into cat. This brings you into encoding detection and either assumptions or guessing. I just can't believe you're willingly dragging yourself into it. I really don't want some special support for utf-8 in cat, because my local files generally have the same encoding with my terminal, and I won't lose much resources when I have to cope with differently encoded files. But it has nothing to do with network-interfacing format, where any spec ambiguity directly translates into either loss of resources (bandwidth, time, processing power) or loss of clients. That's not to mention that you may have another encoding specified elsewhere in your delivery chain (eg. in http headers). -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
I'm really not saying something very profound here, so I'm a bit confused by the sarcastic response. For certain things it's pointless and inefficient to parse something and then deparse it later. It's not like you're gonna put UTF-8 parsing into cat. On Sat, Oct 19, 2013 at 4:33 PM, Dmitrij D. Czarkoff wrote: > Evan Buswell said: >> I can care that this is UTF-8 when I need to, and not care otherwise. > > I would love to see the code that detects whether you care or not. > > -- > Dmitrij D. Czarkoff >
Re: [dev] Some thoughts about XML
Evan Buswell said: > I can care that this is UTF-8 when I need to, and not care otherwise. I would love to see the code that detects whether you care or not. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
It's still UTF-8 in practice. It's just IMO not the job of parsers of this sort to start enforcing or translating the character set of strings. All the parser has to look for is \" " and \\. I can care that this is UTF-8 when I need to, and not care otherwise. I didn't start replacing commas with null bytes or ridiculous crap like that. On Sat, Oct 19, 2013 at 3:28 PM, Thorsten Glaser wrote: > Evan Buswell dixit: > >>playing with that adds symbolic references and uses binary instead of >>utf-8 strings); RST is better for structured text---though I'm not > > Oh yeah, let’s all do binary now instead of passing around plaintext! > > Wait. No! > > Pointing out Unix/Plan 9 way works just fine, > //mirabilos > -- > Beware of ritual lest you forget the meaning behind it. > yeah but it means if you really care about something, don't > ritualise it, or you will lose it. don't fetishise it, don't > obsess. or you'll forget why you love it in the first place. >
Re: [dev] Some thoughts about XML
Evan Buswell said: > But OTOH, I do like the idea of separating the translation-to-html bit > from the generate-sensible-output bit. XSLT may have done this poorly, > but it's on the right track (and what else works better for this, Awk? > Perl? m4?). I mean, I take the point that we can't really make the web > stack all that much better, but at least we can containerize suck? > Yes? Containerize suck of web stack? It is already containerized in browsers - choose the one that sucks less. See, the problem with web stack are not somewhere between the stack and the rest of your software and data. You readily may have your data in whatever format you want and share it via whatever protocol you like. Eg. you may have a bunch of JSON files accessible via their URLs as they are and via werc (or your custom CGI script) as HTML. The problem with web stack is the ugliness of web stack itself, and there is no workaround for that. -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Evan Buswell dixit: >playing with that adds symbolic references and uses binary instead of >utf-8 strings); RST is better for structured text---though I'm not Oh yeah, let’s all do binary now instead of passing around plaintext! Wait. No! Pointing out Unix/Plan 9 way works just fine, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Re: [dev] Some thoughts about XML
I loathe XML, but I think the OPs bigger point was: hey look, here is
a way that we can try and create a space between the suck of the web
and our code. So we support browsers through XSLT, and do something
slightly more sane with XML. I think that's a pretty valid suggestion.
IMO, this doesn't go far enough as XML is really not good for
anything. JSON is better for data (or a variant "KSON" I've been
playing with that adds symbolic references and uses binary instead of
utf-8 strings); RST is better for structured text---though I'm not
sure I really like any of the structured text formats.
But OTOH, I do like the idea of separating the translation-to-html bit
from the generate-sensible-output bit. XSLT may have done this poorly,
but it's on the right track (and what else works better for this, Awk?
Perl? m4?). I mean, I take the point that we can't really make the web
stack all that much better, but at least we can containerize suck?
Yes?
On Sat, Oct 19, 2013 at 11:54 AM, Evan Buswell wrote:
> I loathe XML, but I think the OPs bigger point was: hey look, here is a way
> that we can try and create a space between the suck of the web and our code.
> So we support browsers through XSLT, and do something slightly more sane
> with XML. I think that's a pretty valid suggestion.
>
> IMO, this doesn't go far enough as XML is really not a good for anything.
> JSON is better for data (or a variant "KSON" I've been playing with that
> adds symbolic references and binary instead of utf-8 strings); RST is better
> for structured text---though I'm not sure I really like any of the
> structured text formats.
>
> But OTOH, I do like the idea of separating the translation-to-html bit from
> the rest of it. I mean, I take the point that we can't really make the web
> stack all that much better, but at least we can containerize suck? Yes?
>
> On Oct 19, 2013 9:04 AM, "Dmitrij D. Czarkoff" wrote:
>>
>> Szymon Olewniczak said:
>> >> s/HTML/XML+XSLT/g is quite a revolution.
>> > But it's something whitch I can use in my application straight away
>> > without forcing user to change their web browsers.
>>
>> You aren't really about replacing HTML with XML+XSLT; you are about
>> *generating* HTML with XML+XSLT, are you?
>>
>> > It's about whole "modern web" stack and ways we can make it better,
>> > without a huge revolution.
>>
>> We can't.
>>
>> 1. We have nothing to do with its development.
>> 2. It only gets worse over time.
>> 3. It is {,mis,ab}used on such scale that it can't be sanitized.
>>
>> You can't have a sane tool for doing everything.
>>
>> --
>> Dmitrij D. Czarkoff
>>
>
Re: [dev] [sbase] Command list
On 2013-10-19 11:47, Alex Pilon wrote: > On Sat, Oct 19, 2013 at 05:00:44AM +0400, Alexander S. wrote: > > 4) we need some standard way to separate file names in a stream. > > Basically, ^@ is our only refuge, because path can contain any other > > character. But maybe newline is good enough? > > Why not just play it safe? Would it really add any noticeable > complexity, even if just an option? In my opinion, having no way to write secure programs using these tools due to this would undermine all the great work being done in sbase. pgplaV3dC0cGb.pgp Description: PGP signature
Re: [dev] [sbase] Command list
Apologies for the spam, some typos here… though you likely knew what I meant. On Fri, Oct 18, 2013 at 10:41:55AM -0400, Alex Pilon wrote: > No. ‘du -0 | cut -f 2-’, at least. `du -a …` > du -a \ > | cut -f 2- \ > | while read -rd f; do `while read -rd '' f; do` Still not portable outside of bash and mksh due to the use of `-d`, to the detriment of busybox or d?ash users.. Regards, Alex Pilon pgpvUNMlm5cWf.pgp Description: PGP signature
Re: [dev] Some thoughts about XML
Szymon Olewniczak said:
>> s/HTML/XML+XSLT/g is quite a revolution.
> But it's something whitch I can use in my application straight away
> without forcing user to change their web browsers.
You aren't really about replacing HTML with XML+XSLT; you are about
*generating* HTML with XML+XSLT, are you?
> It's about whole "modern web" stack and ways we can make it better,
> without a huge revolution.
We can't.
1. We have nothing to do with its development.
2. It only gets worse over time.
3. It is {,mis,ab}used on such scale that it can't be sanitized.
You can't have a sane tool for doing everything.
--
Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
Alexander S. said: >> SVG and MathML are probably the best arguments against XML ever. I am >> yet to see two SVG libraries that would render sufficiently complex >> spec-complient SVG equally. And I have no hope for seeing any >> spec-complient SVG rendering library ever. > > I'd not agree that SVG render problems are due to XML parsing. Neither do I. The XML-related problem with SVGs is that every library has its own view on splitting the data between tags, attributes and values. I had a couple of sessions of hand-editing SVG files to get them displayed properly, though from metadata it was obvious that files were generated by software. SVG software sucks really dramatically by the way. It is not uncommon to find an SVG that can be reduced to third of its size without data loss. hiro said: > SVG is irrelevant, cause nobody uses it. It is used quite a lot, actually. Wikipedia is full of SVGs, and it is definitely the most common vector graphics format on the net. (Well, PDF is more common, but it is rarely used for vector graphics, I believe.) > Don't forget: you don't need to read XML specs to write working HTML. HTML isn't XML. Valid XML parser isn't valid HTML parser. They tried to make HTML a strict subset of XML - XHTML Strict - but it didn't make it. -- Dmitrij D. Czarkoff
Re: [dev] [sbase] Command list
On Sat, Oct 19, 2013 at 05:00:44AM +0400, Alexander S. wrote: > 4) we need some standard way to separate file names in a stream. > Basically, ^@ is our only refuge, because path can contain any other > character. But maybe newline is good enough? Why not just play it safe? Would it really add any noticeable complexity, even if just an option? > Not once nor twice had I written the glorious "tr '\n' '\0' | xargs -0" > to turn it off). Which does nothing for safety. `xargs -d '\n'` would have been just as good. > ptree -maxdepth 2 | ftest "( perm 111 || newer ./reference ) && user root" | > xargs rm The Solaris and SunOS users *might* not like you for that choice of name (“ptree”), but who cares? It's inconsequential. Regards, Alex Pilon pgp6lRFZpURJX.pgp Description: PGP signature
Re: [dev] [st][patch] scrollback buffer
Roberto E. Vargas Caballero said: > What should we do? May it be isolated so that it could be enabled/disabled during compilation? -- Dmitrij D. Czarkoff
Re: [dev] Some thoughts about XML
HTML is there, other kinds of XML are avoidable. SVG is irrelevant, cause nobody uses it. Don't forget: you don't need to read XML specs to write working HTML. On 10/19/13, Alexander S. wrote: > 2013/10/18 Dmitrij D. Czarkoff : >> Szymon Olewniczak said: >>> Another advantage of XML is its adaptation. We've already have MathML, >>> SVG and many many others[1] all build on top of XML. >> >> SVG and MathML are probably the best arguments against XML ever. I am yet >> to >> see two SVG libraries that would render sufficiently complex >> spec-complient >> SVG equally. And I have no hope for seeing any spec-complient SVG >> rendering >> library ever. >> >> MathML is yet worse. To save words: http://aiju.de/rant/XML/MathML > > I'd not agree that SVG render problems are due to XML parsing. I think > it's just that anything that attempts to draw SVG according to a spec > must be *very* capable, with all those filters and transforms and > animations and ecmascripts. It might as well be a TeX extension, and > we would have the same (actually, probably even more) problems. > >
Re: [dev] [st][patch] scrollback buffer
> I wouldn't have thought scrollback editing was generally seen as > useful - why would people want that? Scrollback history files also > don't sound that interesting. I always thought the way people use 9term and edit and then re-send certain commands is great. But the more I used it the clearer it got to me that it's not worth my confusion. When I see scrollback as an extension of my memory it shouldn't be changeable by future actions: I lose time coherency.
Re: [dev] [sbase] S_ISVTX?
On Fri, Oct 18, 2013 at 11:49:07PM +0200, Markus Wichmann wrote: > Hi all, > > Now my question: Does someone here have a personal vendetta against > S_ISVTX? Not me, unless anyone objects, feel free to send in some patches. Thanks, sin
Re: [dev] [st][patch] scrollback buffer
On Sat, Oct 19, 2013 at 02:39:14AM +0300, Otto Modinos wrote:
> You can use shift+{pgup,pgdown} to scroll in the linux tty.
>
Well it seems it does not work for me on raspberry, not that it is a huge loss,
as I said I got used to this.
Re: [dev] [st] [patch] Cleanup config.def.h, eliminate mappedkeys, simplify matching.
2013/10/19 Mark Edgar :
> A series of patches for consideration.
>
> The first patch is purely aesthetic: it cleans up column headings (comments)
> and internal tabs in the shortcuts/key/mshortcuts tables in config.def.h. It
> also renames the fields in Key to match the nicer names given in
> config.def.h.
>
> The second patch removes the mappedkeys[] optimization. I tested this by
> adding 1.000.000 additional entries to the end of key[]:
>
> static Key key[] = {
> ...
> #include "lots"
> /*
> * "lots" contains 999.999 repetitions of this entry, which is crafted
> * to hit all the tests in kmap() and fail the last:
> * { 'x', XK_ANY_MOD, "nope", .keypad=-1, .cursor=-1, .crlf=1 },
> */
> { 'x', XK_NO_MOD, "exit" },
> };
>
> While gcc goes from a few seconds to more than a minute to compile and link
> the above, I could not detect a performance regression in st. ;)
>
> The third patch simplifies the matching logic in kmap() and match() without
> changing the behavior. Hopefully, it is straightforward, but it probably
> deserves a careful reading to make sure I haven't made any mistakes.
Why removing mappedkeys? Sure, there may be no visible regression, but
checking every keypress against key bindings seems unreasonable to me.
As for the last patch: it seems to me that behaviour is unchanged.
However, I do not like using != as a logical operator. I'd suggest
using (IS_SET(MODE_APPKEYPAD) ? kp->keypad < 0 : kp->keypad > 0),
which is about the same length, but a bit more clear. I'd also suggest
following the same pattern for all three clauses, as nested if() is
unnecessary (clearly, kp->keypad == 2 may evaluate to true only if
kp->keypad is nonzero).
Re: [dev] [st][patch] scrollback buffer
"Roberto E. Vargas Caballero" wrote: > It is a complicated point. A lot of people like it a lot, and a lot of > people hate it a lot, so I don't know what is the next step here. As far as > I know there are these solutions: > > - Ignore the patch > - create a wiki where publish these kind of patches > - Create a new branc for it > > What should we do? It is not complicated at all. A lot of good additions to suckless.org went through the patch wiki[0] before they were merged into MASTER. As much as I would love to see scrollback in st's HEAD (I _do_ think it's the terminal's job, the only good multiplexer is vim[1]), the wiki is the right place for now. ~koneu [0]http://st.suckless.org/patches/ [1]https://code.google.com/p/conque/
Re: [dev] [st][patch] scrollback buffer
On Fri, Oct 18, 2013 at 10:24:41PM +, Mihail Zenkov wrote: > Thanks Jochen! This implementation really tiny and useful for many > people. Maybe we can create st-sb branch for it (like before for utf) > ? It is a complicated point. A lot of people like it a lot, and a lot of people hate it a lot, so I don't know what is the next step here. As far as I know there are these solutions: - Ignore the patch - create a wiki where publish these kind of patches - Create a new branc for it What should we do? Regards, -- Roberto E. Vargas Caballero ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
