If only it would do something entirely different faster. :-(
Somebody really needs to rethink the entire commitment to meta-programming. I had some hope that concepts would improve reporting, but they seem to actually make it worse, and -- if they improve compile times at all, I'm not seeing it.
And it has nothing to do with historicity. Every time I visit another modern language (or use it seriously) I am constantly reminded that C++ compile times are simply horrible, and a huge impediment to productivity.
Is an XLST page a valid atom feed? Is it really so terrible to have to two different pages -- one for the human readable version, and one for the XML version?
Yes, an <?xml-stylesheet href="..."?> directive is valid in every XML document. You can use CSS to get many of the benefits of XSLT here, but it doesn't let you map RSS @link attributes to HTML a/@href attributes, and CSS isn't designed for interactivity. That's a rather significant gap in functionality.
It is rather terrible to have two different pages, because that requires either server or toolchain support, and complicates testing. The XSLT approach was tried, tested, and KISS – provided you didn't have any insecure/secure context mismatches, or CORS issues, which would stop the XSL stylesheet from loading. (But that's less likely to spontaneously go wrong than an update to a PHP extension breaking your script.)
Sounds like EVERYBODY agrees that there isn't sufficient market value then. Even the original maintainer. And the that is indeed why the feature is being dropped: insufficient market value. Happy happy happy!
I don't think a maintainer refusing to answer spam issues from billion dollar corporations that contributes nothing back is evidence of no value to the maintainer. Unless you think FFmpeg has no market value, who has taken the same stance.
Unable to create the media database. Failed to upgrade the database from version 3 to version 6. SQL Query failed. Syntax error at column 29 near "wehre". ("SELECT id`Thumbnail from tThumbailIndex wehre idFile=?").
(Messages are pre-pended to inner errors as one progresses up the stack). Yes, a gruesome error message. But it's a gruesome error condition.
I've also used inner exceptions in a large Enterprise product, and was very pleased with the result. (Java has them, .net has them, C++ and Typescript can have them if you want them). At the top level, the error message goes:
Unable to connect to the media database.
Failed to upgrade from version 3 to version 6.
SQL Query error failed.
Syntax error at column 6 near 'ndex.
("SELECT idI'ndex from T_ThumbnailIndex")
(each successive error message contained in a successive inner exception).
The advantage: no need to assemble multiple lines of logged errors from a logfile that end-users really don't want to be digging around in.
A more prosaic and actually end-user-helpful chained message might be:
Unable to connect to the media database.
Failed to create the file /var/MediaServer/mediaIndex.db
Out of disk space.
It's a solution that addresses a fundamental problem in C: that it's often baroquely complex to do that in C, and incredibly easy to make mistakes. It is possible, but it is very often not at all simple. Thanks, but no thanks.
Presumes that an error code provides sufficient context to determine what the actual problem is. It does not. Which is why exceptions carry some form of text error message which may include (for example) the name of the file that could not be opened because permission was denied.
What data can you encode in an out-of-band return value (exception), that you can't encode in a parameter or in-band return value? An exception isn't a magic data type, there is nothing you couldn't also return as a return value or a parameter.
The filename to be opened is likely passed as a string in an argument, so it IS present in the function interface contract.
Just include the file name in the error message. And all of this is predicated on logging errors, which is not at all user-friendly, and not remotely acceptable in GUI applications.
I was talking about catching different classes, not about logging. Even if you’re just implementing a string description, there’s nothing stopping you from designing that string for use in a UI element, or implementing a structured message that can specify more details usable for defining UI elements, similarly to how many REST HTTP-driven web UIs work. I don’t think I’m quite following your criticism.
Very sad that their prints have discolored so badly.
For reasons that I cannot imagine, the Canadian National Art Gallery has a complete set of Escher prints that was bequeathed to the gallery by M.C. Escher himself.
If you ever get a chance to see them exhibited, you MUST do so. I have loved Escher prints, ever since I discovered them as a teenager. But seeing the actual prints in person is extraordinary. They were larger than I expected, and they display incredible craftsmanship that photographs do not convey at all -- beautiful paper, blindingly white, with broad white borders, crisp dense black ink, each one meticulously printed. As physical objects, they have gravitas and seriousness. Its is obvious that an enormous amount of effort went into producing perfect prints. Fun as photographs, but fiercely beautiful in person.
Unfortunately, for obvious reasons, the Canadian National Gallery does not display them often. I regularly visit the National Gallery, but I've only ever seen them once.
I wonder whether there are conservation steps that the Boston Public Library can take to deal with the discoloration.
Somebody really needs to rethink the entire commitment to meta-programming. I had some hope that concepts would improve reporting, but they seem to actually make it worse, and -- if they improve compile times at all, I'm not seeing it.
And it has nothing to do with historicity. Every time I visit another modern language (or use it seriously) I am constantly reminded that C++ compile times are simply horrible, and a huge impediment to productivity.
reply