jonpryor
-
So it looks like the extension is needed, despite it working as I'd expect under xsltproc and the fragment technique being listed in a book.
about 22 hours ago
from TweetDeck
-
Damn; : In particular, it is not permitted to use the /, //, and [] operators on result tree fragments.
about 22 hours ago
from TweetDeck
-
I shouldn't need an MS XSLT extension to convert a result tree into a node set, which works w/o extensions under Mono, xsltproc, etc.
about 23 hours ago
from Twirssi
-
.NET's System.Xml looks brain-damaged compared to Mono's (msxsl:nodeset()? wtf?). Porting mdoc to .NET will be less trivial than I thought.
about 23 hours ago
from Twirssi
-
.@ .NET XslCompiledTransform is much faster than XslTransform: 1.74s for .NET vs. ~1.5s for Mono. I'll have to update mdoc now...
7:22 PM Nov 24th
from Twirssi
-
I feel like I've lost hours today trying to make sure VS actually does a clean build so my tests run properly...
1:33 PM Nov 24th
from Twirssi
-
Things I didn't know: in SQLite, primary keys must be INTEGER, not "int", to permit auto-generating the primary key.
10:16 AM Nov 24th
from Twirssi
-
@ Yes, but their collection support is type-specifc, and thus can't support user-defined types. :-(
8:41 AM Nov 24th
from Twirssi
in reply to JustinEtheredge
-
@ So they're catching up to C# (though C# collection initializers are still better), though underscores in numbers is nice.
8:12 AM Nov 24th
from Twirssi
in reply to JustinEtheredge
-
Though, for comparison's sake, xsltproc processes the same files in 0.218s.
6:38 AM Nov 24th
from Twirssi
-
Some say mono is slow. For XSLT, not true. 'mdoc export-html' on mono: 0:01.52 (< 2s); .NET: 3:07.68 (> 3 minutes)
6:10 AM Nov 24th
from Twirssi
-
@ FxCop can't, as IL doesn't have that info. StyleCop could do it...
7:45 AM Nov 23rd
from Twirssi
in reply to KevinHazzard
-
@ Won't happen, as it's a de-facto breaking change (which will cause mountains of code to break).
7:20 AM Nov 23rd
from Twirssi
in reply to KevinHazzard
-
@ Plus, I suspect that there's very rarely a "future-proof" true/false condition, so enums are "safer"...
6:56 AM Nov 23rd
from Twirssi
in reply to KevinHazzard
-
@ Yes, at least until Resharper always requires use of named parameters for boolean parameters...
6:56 AM Nov 23rd
from Twirssi
in reply to KevinHazzard
-
wrt 11.2, Evolution is nice (Google calendar integration!), but sucks: window Z order is odd (can't raise windows), etc.
6:20 PM Nov 22nd
from Twirssi
-
@ I'm still thinking Cadenza, but what do you think of Intermezzo - "short melodies that connect the main parts of a composition."
3:41 PM Nov 20th
from TweetDeck
-
@ ...and will likely waste the dev's time, as if/when these patches are submitted upstream they'll need further review.
10:07 AM Nov 20th
from Twirssi
in reply to sandyarmstrong
-
@ So Google is wasting Google's time (by re-fixing already fixed bugs)...
10:06 AM Nov 20th
from Twirssi
in reply to sandyarmstrong
-
@ It's because Linux isn't using the most up-to-date code, and is reimplementing the wheel.
10:06 AM Nov 20th
from Twirssi
in reply to sandyarmstrong
|
|