Re: dmd 2.057 release
Jonathan M Davis:
On Friday, December 16, 2011 22:37:50 Christian Manning wrote:
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
...
Regardless, the compiler shouldn't be ICEing though.
Is it in Bugzilla?
Bye,
bearophile
Re: dmd 2.057 release
On Saturday, 17 December 2011 at 11:02:41 UTC, bearophile wrote:
Jonathan M Davis:
On Friday, December 16, 2011 22:37:50 Christian Manning wrote:
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
...
Regardless, the compiler shouldn't be ICEing though.
Is it in Bugzilla?
Bye,
bearophile
Looks to be the same issue as
http://d.puremagic.com/issues/show_bug.cgi?id=4414
Re: New homepage design of d-p-l.org is now live. eom
On 17/12/2011 06:35, Nick Sabalausky wrote: snip But if it'sijust/i ordinary text that simply needs to bebbolded/b oriitalicized/i, then handling it in any roundabout way like that is justiridiculous/i (and self-documenting would be completely inapplicable). You miss the point - why would you need to bold or italicise ordinary text? If the point is to illustrate what bold looks like, or what italics look like, _then_ it might make sense to use presentational markup In such a situation, replacing hardcoded bold or italic with some vague concept of emphasis (old-school example: theem tag) em isn't really an old-school example. It's the proper semantic markup for emphasis. or extra-emphasis, etc, is not only a useless abstraction merely for the sake of abstraction, itbican/i/b subtly change meaning/interpretation of the actualicontent/i because only theiauthor/i, not the stylist, is able to look at the final result and know whether the result bicorrectly/i/b depicts the amount/type of emphasis intended. It seems to me that the essence of what you're saying is that the choice of em and strong is too coarse-grained for your purposes. I'm not sure how best to deal with this either. Moreover, what markup are you going to use so that it looks/sounds/feels right in non-graphical browsers? Additionally, how does the stylist know if a given styling is going to cause too much visual noise? Or be too visually monotone? Theyican't/i, because it'sicompletely/i dependent on the text that the biauthor/i/b writes. It might be too much visual stuff for one article and just right for another. Only the text's author can know what's appropriate, not the stylesheet. If the author is overusing emphasis, manually setting font weights and stuff to compensate seems to me to be trying to fix the wrong problem. Stewart.
Re: New homepage design of d-p-l.org is now live. eom
On Saturday, 17 December 2011 at 13:09:40 UTC, Stewart Gordon wrote: What built-in support does HTML/JS/CSS have for dragging of elements? http://dev.w3.org/html5/spec/dnd.html It started as an IE5 feature, and is now being expanded to everyone else. In the old IE, it only worked on some text, links, and images, but the new standard says you can set it on whatever you want. Still, if you want to support them all, a is the way to do it. Moreover, dummy hrefs are an abomination. Not just compatibility when JS is disabled - this link is also the one followed when you open a link in a new window/tab. This regularly bites me. Yea, I hate them too. In practice, I try to put them somewhere useful, if I can. (In my app with the drag drop, the links lead to the contact profile page; this is a mailing list/CRM app.) But I am made to wonder why. What will happen when HTML6 comes out? I guess the idea is there won't be a html6; instead they'll just keep sbreaking/s evolving the current thing and expect everyone to keep up. No, because in order to determine whether it's well-formed, one must know whether it's meant to be in SGML-based HTML, HTML5 or XHTML. Meh, it works anyway. One reason is websites tend to be so poorly written that if you tried to be strict, you'd just break most of them! Anyway, this said, if dpl.org wanted to validate, I don't think it'd be a *bad* thing. (I'd say go with xhtml; I feel dirty saying this, but I almost like. xml for this kind of thing.) So it's something that web authors can use to store custom data in an element for scripting purposes, but browsers aren't supposed to have any built-in handling of them? Right. You aren't even supposed to use them with other third party tools; the idea is that area is completely open for the page author and his scripts to do with as he pleases.
Re: New homepage design of d-p-l.org is now live. eom
Stewart Gordon smjg_1...@yahoo.com wrote in message news:jci2bj$225s$1...@digitalmars.com... On 17/12/2011 06:35, Nick Sabalausky wrote: snip But if it'sijust/i ordinary text that simply needs to bebbolded/b oriitalicized/i, then handling it in any roundabout way like that is justiridiculous/i (and self-documenting would be completely inapplicable). You miss the point - why would you need to bold or italicise ordinary text? To be clear, I didn't mean that as in plaintext...if that's what you meant...? I meant like the examples in that paragraph (not all of which were literal examples of bold/italic). If the point is to illustrate what bold looks like, or what italics look like, _then_ it might make sense to use presentational markup Only might? ;) In such a situation, replacing hardcoded bold or italic with some vague concept of emphasis (old-school example: theem tag) em isn't really an old-school example. It's the proper semantic markup for emphasis. Ok. It was a dedicated HTML tag instead of a span/div with class attribute. Seems like most of those are non-kosher these days. or extra-emphasis, etc, is not only a useless abstraction merely for the sake of abstraction, itbican/i/b subtly change meaning/interpretation of the actualicontent/i because only theiauthor/i, not the stylist, is able to look at the final result and know whether the result bicorrectly/i/b depicts the amount/type of emphasis intended. It seems to me that the essence of what you're saying is that the choice of em and strong is too coarse-grained for your purposes. Yes. Well, too vague, really. I'm not sure how best to deal with this either. It's easy to deal with: You just say Fuck dat 'purity' booshit, I'm usin' b and i!! :) And as far as inferring semantic meaning, I think it's pretty obvious that b and i imply this text is emphasised. (Not that I can imagine any realistic use for being able to identify what text is emphasised.) Moreover, what markup are you going to use so that it looks/sounds/feels right in non-graphical browsers? Non-graphical browsers are going to result in a *lot* of difference from the original style/layout anyway. There's a lot of stuff that's going to be wrong. If you're using one, it's just understood that you're merely viewing an approximation. Additionally, how does the stylist know if a given styling is going to cause too much visual noise? Or be too visually monotone? Theyican't/i, because it'sicompletely/i dependent on the text that the biauthor/i/b writes. It might be too much visual stuff for one article and just right for another. Only the text's author can know what's appropriate, not the stylesheet. If the author is overusing emphasis, manually setting font weights and stuff to compensate seems to me to be trying to fix the wrong problem. Not necessarily. Imagine a paragraph that uses a fair amount of italic, but not quite an overuse of italic, so it still looks fine. If that's done with, say em, and the stylist changes em from italic to either bold or bold+italic, it's suddenly going to look like shit. It'll *become* an overuse, and the only way for the stylist to fix it is to just let the author choose bold/italic/etc on their own. Maybe I'm just atypical as an author, but when I write something and use emphasis, I take into account things like bold/italic and how it'll look when I decide what to emphasise, how, and how much. If I *do* use things like em, I inevitably end up choosing them based *not* on level of emphasis but on whether they end up being bold/italic/underline/etc...Which obviously defeats the whole damn point of em, etc. I'd be surprised if most people do it any different from that. Heck, I almost always end up changing my emphasis/bold/italic/etc after writing+previewing it because it never looks right until I've tweaked it *taking into account* the final presentation. Honestly, I can't imagine how anyone could do it effectively without having direct control over such things (even if it's by abusing levels of emphasis as euphamisms for more specific stylings). I think there's good reason wiki markups invariably have syntax for bold and italic rather than emphasis. There's two basic problems with the idealistic separation of presentation from content: 1. (X)HTML and CSS are just simply not very good as (X)HTML is content and CSS is presentation. You can get by in *some* cases, but in general they're just poorly suited for it. I think that *part* of the problem may be that it's like ColdFusion: A mediocre Model and a mediocre View hooked directly together with basically no Controller. 2. Content and presentation *are not always separable*. There *is* interplay. And this makes a strict and complete separation of content and presentation nothing more than yet another example in programming's long history of idealistic dreams (like Java's everything must be OO
Re: New homepage design of d-p-l.org is now live. eom
Adam D. Ruppe destructiona...@gmail.com wrote in message
news:xjikejblvuxulhoqx...@dfeed.kimsufi.thecybershadow.net...
On Saturday, 17 December 2011 at 13:09:40 UTC, Stewart Gordon wrote:
But I am made to wonder why. What will happen when HTML6 comes out?
I guess the idea is there won't be a html6; instead they'll just
keep sbreaking/s evolving the current thing and expect
everyone to keep up.
And why not? That's what they've been doing all along. *cough* object
*cough* ;)
No, because in order to determine whether it's well-formed, one must know
whether it's meant to be in SGML-based HTML, HTML5 or XHTML.
Meh, it works anyway. One reason is websites tend to be so poorly
written that if you tried to be strict, you'd just break most of
them!
Anyway, this said, if dpl.org wanted to validate, I don't think
it'd be a *bad* thing. (I'd say go with xhtml; I feel dirty
saying this, but I almost like. xml for this kind of
thing.)
Yea, HTML looks, acts and feels like XML so it may as well actually *be*
XML. Plus, tranformations to/from HTML is one of the main reasons for XML
anyway. So they *should* be compatible.
('Course there's *technically* SGML too, but honestly, HTML is the only
reason anyone's ever cared about or even known about SGML. It may as well
not exist.)
Re: New homepage design of d-p-l.org is now live. eom
On 2011-12-17 13:09:35 +, Stewart Gordon smjg_1...@yahoo.com said: Strange. I don't recall ever seeing !DOCTYPE html before HTML5 came along. But I am made to wonder why. What will happen when HTML6 comes out? Or have they decided that validators are just going to update themselves to the new standard rather than keeping separate HTML5/HTML6 DTDs (or whatever the HTML5+ equivalent of a DTD is)? Thing is, if they could have removed the doctype completely they would have done so. The doctype doesn't tell anything meaningful to a browser, except that today's browser use the presence of a doctype to switch between a quirk mode and a standard mode. !DOCTYPE html was the shortest thing that'd make every browser use standard mode. The problem was that forcing everyone to specify either one or another HTML version is just a exercise in pointlessness. Most people get the doctype wrong, either initially or over time when someone updated the site to add some new content. If you're interested in validating your web page, likely you'll know which version you want to validate against and you can tell the validator. Stuff like improperly closed tags or bad entity encoding can break, but that's pretty well independent of doctype validation. That's simply a matter of the document being well-formed. No, because in order to determine whether it's well-formed, one must know whether it's meant to be in SGML-based HTML, HTML5 or XHTML. Perhaps for it matters for validation if you don't say which spec to validate against, but validating against a spec doesn't always reflect reality either. There is no SGML-based-HTML-compliant parser used by a browser out there. Browsers have two parsers: one for HTML and one for XML (and sometime the HTML parser behaves slightly differently in quirk mode, but that's not part of any spec). And whether a browser uses the HTML or the XML parser has nothing to do with the doctype at the top of the file: it depends on the MIME types given in the Content-Type HTTP header or the file extension if it is a local file. HTML 5 doesn't change that. Almost all web pages declared as XHTML out there are actually parsed using the HTML parser because they are served with the text/html content type and not application/xhtml+xml. A lot of them are not well formed XML and wouldn't be viewable anyway if parsed according to their doctype. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
D bindings for openssl added to Deimos
Courtesy of David Nadlinger. https://github.com/D-Programming-Deimos/openssl
