Slashdot Mirror
GNU Texinfo 5.0 Released
Four years after the last release, version 5.0 of Texinfo, the GNU documentation language, has been released. The primary highlight is a new implementation of makeinfo info in Perl rather than C. Although slower, the new version offers several advantages: cleaner code using a structured representation of the input document, Unicode support, and saner support for multiple output backends. There are over a dozen other improvements including better formatting of URLs, improved cross-manual references, and a program to convert Perl POD documentation to Texinfo.
Although slower, the new version offers several advantages: cleaner code using a structured representation of the input document, Unicode support, and saner support for multiple output backends. (emphasis mine).
Whether a end user will notice, I don't know for sure! Who does?
"Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
Can't be much use, it doesn't have a man page.
Only for building the software, and even then (at least with Automake) only if you are generating distribution tarballs or building from the bleeding edge vcs repository and need to regeneration maintainer files. If you're using Automake... it's already written in Perl. And it's basically a hard dependency in the base system of every GNU/Linux distro.
I haven't used TexInfo for years, but what I remember most was the absolutely abysmal standalone "info" reader. That thing was the biggest piece of shit I've ever seen in any program. Hopefully they've abandoned the crappy "info" format and all of the shitty standalone readers to view info documents, and just use HTML by default now.
Why on earth would they have picked perl? Perl isn't really a native gnu project. At least gcc is.
File under 'M' for 'Manic ranting'
I love how a language that was "fast enough" in the '90s is now suddenly "too slow" in 2013.
What's with the "I need all my code hyper-optimized" crowd on /. these days? We running a Gentoo help forum I didn't notice?
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
It's very handy for generating both nroff man pages and their HTML counterparts from the same input text. Being extremely simple, it raises no barrier to writing man-page type documentation.
Neither does nroff -man. If you're in a position where you'd want a man page, a percieved complexity in writing one in nroff is no excuse. Read man(7), groff_man(7) and groff_char(7), and look at some example man pages for inspiration.
Also, if the cvs(1) man page of CVS 1.12.13 is a typical example of what Texinfo generates, I strongly recommend against using it for this. It's ugly and hard to read; doesn't really look like a man page at all.
You sir, are full of it.
Automake does not depend on perl. Perl is not a hard dependency in "the base system" since this concept doesn't exist in "gnu/linux". And it isn't in systems where such a concept does exist, eg FreeBSD (the spurious and wrongful dependency on perl and python listed in the glib2 port Makefile notwithstanding, same with the braindamage brought by the new and improved Xorg with video driver(!) dependencies on dbus(!) and xcb on python).
It'd be nice if the FOSS world would be a little less careless about its veritable forestry of dependencies. Much of it is rather senseless and on balance not worth the trouble when looking a bit further than the happily hackening developer and his magnificent code mangling machine, like when accounting for the users.
Real men use an macros to create documentation.
You sir, are full of it.
Automake does not depend on perl.
$ head -n1 /usr/bin/automake-1.11
#!/usr/bin/perl -w
Perl is not a hard dependency in "the base system" since this concept doesn't exist in "gnu/linux".
Sure it does, it means the core, non-optional components of the OS.
Allow me to initiate the inevitable hatefest:
Every time I run man and get a pointer to texinfo, I want to beat my head on the keyboard. I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation. It's time to interrupt my command-line workflow, go to the nearest GUI and run a web search for the nearest HTML manual.
The 1990s, when HTML documents were readable and not stuffed to the gills with ads and social recommendation detritus. Really all a plain-jane HTML document is missing is a max-width:36em on body to make line lengths sane and a width=device-width on the viewport to make tablets not render it zoomed out.
That high-level C crap is for wannabes, son...real men create their programs in native binary by manipulating the bits on their drive platters with pointy magnets
How do you compile the documentation when you're building Perl's prerequisites from source?
Let me get this straight. These guys ported and anachronistic piece of software from one dead language to a slightly less dead language, and then bragged about using structured programming techniques as a feature.
Hang on, I think Scott Adams has something to say about this.
http://dilbert.com/strips/comic/2013-02-11/
Lisp
http://xkcd.com/224/
MWHAHAHAhahahahHAHhaHahAHahAHahAHa.
...perl...cleaner code...
Now we will have a perl dependency for all GNU stuff, and this to read documentation that is even less nice to read than man pages. The best thing they could have done to texinfo is to get rid of it, IMO.
Texinfo is is a decent format for writing documentation in - nicer and less verbose than HTML or DocBook. You can generate either HTML or DocBook or XML from Texinfo, and then do a bunch of processing on it. For example the documentation for Kawa is written in texinfo, then makeinfo converts it to docbook, which is then converted to html. The result isn't splashy but (if I say so myself) fairly nice.
Sorry, but the world works the way it works, and does not magickally conform itself to your views on How Things Should Be.
I don't like perl, either. ("Loathe" might not be too strong a term.) But neither am I foolish enough to believe that I am likely to wind up with a usable Linux or FreeBSD system if I try to set one of those up without it.
Il n'y a pas de Planet B.
I very happily gave up on man pages (and variants thereof) years ago because they were too obtuse and circular to be useful to me, a mere end user. Early on I figured out that the basic rule of man pages was that the one you need relied on you already having read and digested fifteen others, each of which relied on you having read an digested fifteen others.... actually finding what you needed was an endless exercise in frustration.
Google + Forums is what real people rely on.
Three Squirrels
It has been used as a pretext for not providing correct man pages. For example man sed:
COMMAND SYNOPSIS
This is just a brief synopsis of sed commands to serve as a reminder to those who
already know sed; other documentation (such as the texinfo document) must be con-
sulted for fuller descriptions.
When I have learned unix, man pages were complete, concise, accurate and uptodate documentation of all the system. I feel that because of this textinfo mess, man pages on Linux are incomplete and vague and that the documentation dislayed by info is not very clear.
I'd rather see the format scrapped and replaced with either better man pages or else HTML2. With HTML 2 you can use a text based browser like Lynx, which is more polished and gives you better navigation capabilities. There are also more modules, libraries and packages that can work directly with HTML, so less time is spent trying to reinvent the wheel.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Comment removed based on user account deletion
Breaking them against wheels until the right bits fall out, I'm sure.
Check out my world simulator thingy.
I think that calling C "portable assembly" is really a bit untrue. One of the core features of most any machine language is that flags are part of the result of many computing operations. Yet C completely removes access to it.
Suppose you have a code that adds two things, then jumps on overflow. On most machines that's two instructions if the operands have the right size. You look at it, and the intent is obvious: we add, then jump on overflow.
Things are seriously wrong (IMHO) if a higher level language completely obfuscates this and requires code where it's not obvious at all what you mean! Heck, what's worse, each compiler likely requires slightly different code so that the meaning is extracted by the optimizer and the correct assembly output is produced without paying both code size and performance penalties! In C, the best you can do on a good compiler is to have an inlineable function that returns the numerical part of the result, uses comparisons to "recreate" the detection of overflow, and returns the overflow condition in a char* out-parameter. If the optimizer is good, it'll recognize that the out parameter accesses an automatic variable in the caller, and that your comparison is just checking for overflow. This code, while portable C, will perform horribly as soon as you compile it without state-of-the-art optimization capabilities. I'd think that means that if your compiler wasn't released in the last year or two, and isn't a mainstream decently optimizing one (like gcc, llvm, visual studio), you're out of luck. On many platforms a saturating increment/decrement is also two or three assembly instructions at most, without jumps -- but good luck getting a compiler to actually emit such code.
I think that providing no way to access the flags part of arithmetic operation results is one of the biggest oversights in C. I'd think that every platform C runs on provides such flags.
A successful API design takes a mixture of software design and pedagogy.