"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.454.1331448329.4860.digitalmars-d@puremagic.com...
> On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:
>> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.447.1331426602.4860.digitalmars-d@puremagic.com...
> [...]
>> > In the past, I've even used UserJS to *edit* the site's JS on the fly to rewrite stupid JS code (like replace sniffBrowser() with a function that returns true, bwahahaha) while leaving the rest of the site functional.  I do not merely hate Javascript, I fight it, kill it, and twist it to my own sinister ends.  >:-)
>> >
>>
>> I admire that :) Personally, I don't have the patience. I just bitch
>> and moan :)
>
> Well, that was in the past. Nowadays they've smartened up (or is it dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly because anything that the client end can run will eventually be cracked, so it actually doesn't offer *real* protection in the first place, and OTOH annoying 'cos I really can't be bothered to waste the time and effort to crack some encrypted code coming from some shady site that already smells of lousy design and poor implementation anyway.
>
> So I just leave and never come back to the site.
>

I'd prefer to do that (leave and never come back), but unfortunately, the modern regression of tying data/content to the interface often makes that impossible:

For example, I can't see what materials my library has available, or manage my own library account, without using *their* crappy choice of software. It's all just fucking data! Crap, DBs are an age-old thing.

Or, I'd love to be able leave GitHub and never come back. But DMD is on GitHub, so I can't create/browse/review pull requests, check what public forks are available, etc., without using GitHub's piece of shit site.

I'd love to leave Google Code, Google Docs and YouTube and never come back, but people keep posting their content on those shitty sites which, naturally, prevent me from accessing said content in any other way.

Etc...

And most of that is all just because some idiots decided to start treating a document-transmission medium as an applications platform.

I swear to god, interoperability was better in the 80's.

(And jesus christ, *Google Docs*?!? How the fuck did we ever get a document platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people actually *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out the free crazy-pills?)

>
> [...]
>> In 1994, games had to come with their own sound/video drivers. In 1995, MS fixed that and there was much rejoicing.
>>
>> But in 2012:
>>
>> - Every piece of content is packaged with a pre-chosen viewer.
>
> Blame flash. And JS.
>

It's more than that. Even without one line of JS or Flash, a purely (X)HTML/CSS web app is *still* likely tying content to interface. The only exceptions are things like forum.dlang.org which merely present data from an already-publically-accessible external source. Of course, even *then* the URLs are still tied to the (inevitably web-based) NG client (What's needed is a universal NNTP URL system that's 100% independent of NG client - Just like we already have for HTTP, and FTP, and SSH and five billion other damn things. Image that!)

>
> [...]
>> - If you want to use GitHub/BitBucket-style DVCS features you have to use whichever interface is *provided* by whoever's hosting the repo. BitBucket can't access GitHub-hosted repos/projects. GitHub can't acces BitBucket-histed repos/projects. Neither can access local or self-hosted repos/projects. WTF is this, 1990 all over again?
>
> Yeah seriously. So much for "semantic web". Smells like a pipe dream to me.
>

Yup. Fortunately, HTTP APIs are becoming more and more common though, so at least there's that ray of hope that some of those can consolodate into some standards.

Speaking of all of this though, I have to *rave* about Linode: I just switched to them from my old (and recently bought-out) shared web host a few days ago, and already I *LOVE* it. Not only is it a fantastic service all around, and they *actually* seem to know what they're doing (unlike *every* shared web host I've *ever* encountered), but *everything* about their site and control panel is *PERFECT*. Absolutely flawless, from the functionality and content, to the security, the speed, the compatibility and graceful degredation, all the way down to just simply the *style*: Flawless every step of the way. And they offer an HTTP API for the control panel. I can't remember the last time I saw a site this *professional* and well built. It's one of those exceedingly rare things that's created by grown-ups, for grown-ups. I'm genuinely stunned by it.

"Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:jjhcj8$25sv$1@digitalmars.com...
> "Nick Sabalausky" <a@a.a> wrote in message news:jjh9uh$1vto$1@digitalmars.com...
>>
>> My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs. Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source?
>>
>
> That's not really it...
>
> The problem is that vtables contain every virtual function of a class - and if you instantiate a template function with a new type, it would require a new vtable entry.  Therefore you need to know how every template function in every derived class is instantiated before you can build the base class vtable.  This doesn't work with D's compilation model.
>

Right, but when I tell something like rdmd to pass all my files into DMD, then DMD *does* have all the information needed. I understand that it can't be done in *all* build setups, but it would seem to be possible in many build setups, so why should *all* projects suffer when really only *some* projects have to have that limitation? That's what I've never understood.

>>
>> Now, as for whether or not D actually *does* omit the vtable entry for non-override finals, I wouldn't know. Although I seem to vaguely remember doing optimizations once that seemed to imply it did. If that's so, I don't know whether its guaranteed per D spec or just implementation-defined. A UFCS approach would definitely be guaranteed not to affect the vtable, of course.
>>
>
> D (dmd) does not create a vtable entry for final functions that don't override anything.  It's in the frontend, so it should be the same for all the d compilers.

I see. Thanks.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.453.1331446837.4860.digitalmars-d@puremagic.com...
> On Sat, Mar 10, 2012 at 11:31:47PM -0500, Nick Sabalausky wrote:
>> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.436.1331412193.4860.digitalmars-d@puremagic.com...
> [...]
>> My understanding is that the *only* thing preventing vitrual template functions is the possibility of pre-compiled closed-source static libs.  Which is why I've long been in favor of allowing vitrual template functions *as long as* there's no closed-source static libs preventing it. Why should OSS have to pay costs that only apply to closed source?
>
> I thought the reason was that every instance of the template will need a vtable entry, and the compiler may not be able to know beforehand which instances will actually exist? You *could* in theory have the compiler scan the entire program for all instances, I suppose, but that will prevent incremental compilation and loading of dynamic libs, OSS or not. Plus it may slow down the compiler significantly.
>

What I'm suggesting is flipping that around: Instead of saying "Virtual template functions prevent incremental compilation and dynamic libs: And that's an unreasonable limitation", we say "Incremental compilation and dynamic libs prevent virtual template functions: So *if you need to use those*, you can't use virtual template functions."

Keep in mind too, that even incremental compilation and dynamic libs *can* still work with virtual template functions *provided that* there's no overriding across compilation unit boundaries. I don't think that's a totally unreasonable limitation for virtual template functions to be worthwhile for _many_ people, even if it doesn't make virtual template functions practical for *everyone*.

>
> [...]
>> Another great one, which is very similar to one I've enjoyed repeating:
>>
>> What are a redneck's last words? "Hey y'all, watch this!"
> [...]
>
> And another one in response:
>
> Famous last words: I *think* this will work...
>

Yet another one, I just recently came across (not actually for real, but it would be funny):

Written on someone's tombstone: "I *told* you I was sick!"

Along similar lines (this one's a true story), my Dad's Aunt and Uncle bought their own tombstone ahead of time, and had their picture taken sitting on each side of it, both of them smoking. (The irony was, of course, deliberate. My family's a bit weird ;) )

On 11/03/2012 09:15, Nick Sabalausky wrote:

>
> Written on someone's tombstone: "I *told* you I was sick!"
>

Spike Milligan's epitaph reads "Duirt mé leat go raibh mé breoite", Irish for "I told you I was ill."

A...

On 2012-03-10 20:41, Nick Sabalausky wrote:

> You know what I think it is (without actually looking at the code): I think
> they tried to do some highly misguided and even more poorly implemented hack
> (which they no-doubt thought was clever) for dealing with *cough* "old"
> *cough* browsers by inserting a meta redirect to a hardcoded URL, and then
> used JS to disable the meta redirect. If that's the case, I don't know how
> the fuck they managed to convince themselves that make one drop of sense.

But they're redirecting to http://m.drdobbs.com/, which seems to be adapted for mobile devices.

> When I used one of my web developer plugins to disable meta redirects, the
> screwy behavior stopped. And like you, I have JS off by default (WTF do you
> need JS for on a goddamn *ARTICLE*?). So that's probably what the numbnuts
> over at Dr Dobbs did.

Yeah, probably.

-- 
/Jacob Carlborg

On 2012-03-10 21:27, H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 02:41:53PM -0500, Nick Sabalausky wrote:
> [...]
>> You know what I think it is (without actually looking at the code): I
>> think they tried to do some highly misguided and even more poorly
>> implemented hack (which they no-doubt thought was clever) for dealing
>> with *cough* "old" *cough* browsers by inserting a meta redirect to a
>> hardcoded URL, and then used JS to disable the meta redirect. If
>> that's the case, I don't know how the fuck they managed to convince
>> themselves that make one drop of sense.
>>
>> When I used one of my web developer plugins to disable meta redirects,
>> the screwy behavior stopped. And like you, I have JS off by default
>> (WTF do you need JS for on a goddamn *ARTICLE*?). So that's probably
>> what the numbnuts over at Dr Dobbs did.
> [...]
>
> I've always believed that Javascript is the hellspawn of evil incarnate.

I usually agree, but there are useful and cool things you can do with JavaScript. Two of the tools I'm using when I'm doing web development uses JavaScript:

* LiveReload - A browser plugin that  will automatically reload the a web page when a file has changed in a specified folder.

http://livereload.com/

* TextMate Rails stack trace - A greasemonkey script that will make your stack trace lines open in TextMate

https://github.com/ryankshaw/rails-stacktrace-textmate-linker-greasemonkey-script


-- 
/Jacob Carlborg

On Sun, Mar 11, 2012 at 01:45:19PM +0100, Jacob Carlborg wrote:
> On 2012-03-10 21:27, H. S. Teoh wrote:
[...]
> >I've always believed that Javascript is the hellspawn of evil incarnate.
> 
> I usually agree, but there are useful and cool things you can do with JavaScript. Two of the tools I'm using when I'm doing web development uses JavaScript:
[...]

Oh, I know how useful it is. I've written some cool stuff with it too. That's what makes it so evil. :-) It's so cool and so easy to write, that everybody and his neighbour's dog writes it and sticks it everywhere it doesn't belong.


T

-- 
Change is inevitable, except from a vending machine.

On 03/11/2012 05:47 AM, Nick Sabalausky wrote:
> "H. S. Teoh"<hsteoh@quickfur.ath.cx>  wrote in message
> news:mailman.454.1331448329.4860.digitalmars-d@puremagic.com...
>> On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:
>>> "H. S. Teoh"<hsteoh@quickfur.ath.cx>  wrote in message
>>> news:mailman.447.1331426602.4860.digitalmars-d@puremagic.com...
>> [...]
>>>> In the past, I've even used UserJS to *edit* the site's JS on the
>>>> fly to rewrite stupid JS code (like replace sniffBrowser() with a
>>>> function that returns true, bwahahaha) while leaving the rest of the
>>>> site functional.  I do not merely hate Javascript, I fight it, kill
>>>> it, and twist it to my own sinister ends.>:-)
>>>>
>>>
>>> I admire that :) Personally, I don't have the patience. I just bitch
>>> and moan :)
>>
>> Well, that was in the past. Nowadays they've smartened up (or is it
>> dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly
>> because anything that the client end can run will eventually be cracked,
>> so it actually doesn't offer *real* protection in the first place, and
>> OTOH annoying 'cos I really can't be bothered to waste the time and
>> effort to crack some encrypted code coming from some shady site that
>> already smells of lousy design and poor implementation anyway.
>>
>> So I just leave and never come back to the site.
>>
>
> I'd prefer to do that (leave and never come back), but unfortunately, the
> modern regression of tying data/content to the interface often makes that
> impossible:
>
> For example, I can't see what materials my library has available, or manage
> my own library account, without using *their* crappy choice of software.
> It's all just fucking data! Crap, DBs are an age-old thing.
>
> Or, I'd love to be able leave GitHub and never come back. But DMD is on
> GitHub, so I can't create/browse/review pull requests, check what public
> forks are available, etc., without using GitHub's piece of shit site.
>
> I'd love to leave Google Code, Google Docs and YouTube and never come back,
> but people keep posting their content on those shitty sites which,
> naturally, prevent me from accessing said content in any other way.
>
> Etc...
>
> And most of that is all just because some idiots decided to start treating a
> document-transmission medium as an applications platform.
>
> I swear to god, interoperability was better in the 80's.
>
> (And jesus christ, *Google Docs*?!? How the fuck did we ever get a document
> platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people actually
> *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out
> the free crazy-pills?)

Nick, how would you implement (protocols, architecture, whatever) an online document editor?

"Ary Manzana" <ary@esperanto.org.ar> wrote in message news:jjis50$23se$1@digitalmars.com...
> On 03/11/2012 05:47 AM, Nick Sabalausky wrote:
>> "H. S. Teoh"<hsteoh@quickfur.ath.cx>  wrote in message news:mailman.454.1331448329.4860.digitalmars-d@puremagic.com...
>>> On Sat, Mar 10, 2012 at 09:14:26PM -0500, Nick Sabalausky wrote:
>>>> "H. S. Teoh"<hsteoh@quickfur.ath.cx>  wrote in message news:mailman.447.1331426602.4860.digitalmars-d@puremagic.com...
>>> [...]
>>>>> In the past, I've even used UserJS to *edit* the site's JS on the fly to rewrite stupid JS code (like replace sniffBrowser() with a function that returns true, bwahahaha) while leaving the rest of the site functional.  I do not merely hate Javascript, I fight it, kill it, and twist it to my own sinister ends.>:-)
>>>>>
>>>>
>>>> I admire that :) Personally, I don't have the patience. I just bitch
>>>> and moan :)
>>>
>>> Well, that was in the past. Nowadays they've smartened up (or is it dumbened down?) with the advent of JS obfuscators. Which, OT1H, is silly because anything that the client end can run will eventually be cracked, so it actually doesn't offer *real* protection in the first place, and OTOH annoying 'cos I really can't be bothered to waste the time and effort to crack some encrypted code coming from some shady site that already smells of lousy design and poor implementation anyway.
>>>
>>> So I just leave and never come back to the site.
>>>
>>
>> I'd prefer to do that (leave and never come back), but unfortunately, the modern regression of tying data/content to the interface often makes that impossible:
>>
>> For example, I can't see what materials my library has available, or
>> manage
>> my own library account, without using *their* crappy choice of software.
>> It's all just fucking data! Crap, DBs are an age-old thing.
>>
>> Or, I'd love to be able leave GitHub and never come back. But DMD is on GitHub, so I can't create/browse/review pull requests, check what public forks are available, etc., without using GitHub's piece of shit site.
>>
>> I'd love to leave Google Code, Google Docs and YouTube and never come
>> back,
>> but people keep posting their content on those shitty sites which,
>> naturally, prevent me from accessing said content in any other way.
>>
>> Etc...
>>
>> And most of that is all just because some idiots decided to start
>> treating a
>> document-transmission medium as an applications platform.
>>
>> I swear to god, interoperability was better in the 80's.
>>
>> (And jesus christ, *Google Docs*?!? How the fuck did we ever get a
>> document
>> platform *ON TOP* of a fucking *DOCUMENT PLATFORM* and have people
>> actually
>> *TAKE IT SERIOUSLY*!?! Where the hell was I when they started handing out
>> the free crazy-pills?)
>
> Nick, how would you implement (protocols, architecture, whatever) an online document editor?

I wouldn't make it an online editor. Just let a normal editor access remote files. Done. As for specifically html documents on the web, doesn't http already have provisions for updating anyway? Hell, the *original* web browser was *both* an editor and a viewer. But then Mosaic came along, scrapped the editor part, and everything since has followed suit.

"Jacob Carlborg" <doob@me.com> wrote in message news:jji5fa$qma$1@digitalmars.com...
> On 2012-03-10 20:41, Nick Sabalausky wrote:
>
>> You know what I think it is (without actually looking at the code): I
>> think
>> they tried to do some highly misguided and even more poorly implemented
>> hack
>> (which they no-doubt thought was clever) for dealing with *cough* "old"
>> *cough* browsers by inserting a meta redirect to a hardcoded URL, and
>> then
>> used JS to disable the meta redirect. If that's the case, I don't know
>> how
>> the fuck they managed to convince themselves that make one drop of sense.
>
> But they're redirecting to http://m.drdobbs.com/, which seems to be adapted for mobile devices.
>

Mobile sites have traditionally required less-fancy implementations, so it's not unreasonable to think that some sites would use their mobile version *as* their low-tech fallback version. That's becoming less and less true these days, of course. But looking at http://m.drdobbs.com/ I have a strong feeling that was originally created for things like AvantGo (ie, on PalmOS) which really were very limited: no JS, no nested tables, very low resolution, often not even any color, very low memory, etc. Not that anything about what they're doing really makes a whole lot of sense anyway, though.