Computing desk
< January 17	<< Dec \| January \| Feb >>	January 19 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

January 18

Travelling with a Google Chromecast

Will a UK-bought Chromecast still have access to UK-licenced content in other countries? Thanks! 94.12.81.251 (talk) 13:46, 18 January 2016 (UTC)[reply]

Probably not. Much regional-licenced content filters by IP location. If your chromecast is in e.g. Brazil, it will have a Brazillian IP, and as such you have no clear rights to UK content. SemanticMantis (talk) 17:55, 18 January 2016 (UTC)[reply]

In setup, You choose a language. With the YouTube app, possibly the URL of the Video is foreward to the Chromecast when the connection to the adroid phone is establishedy only. --Hans Haase (有问题吗) 20:39, 18 January 2016 (UTC)[reply]

As SemanticMantis has hinted at, it would be more useful to ensure your ChromeCast connects via proxy than it would be to buy your Chromecast in the UK. Actually, I strongly suspect it doesn't matter where you buy it. Nil Einne (talk) 21:14, 18 January 2016 (UTC)[reply]

Partial specialization on a member class of a class template

I have a (third-party) broken iterator:

template<class T> struct Container {
  struct iterator {/*...*/};
  //...
};

It's broken in that it does not define the typedefs for std::iterator_traits. I can specialize std::iterator_traits myself to supply the correct (and obvious) types, but how? Writing

namespace std {
  template<class T>
  struct iterator_traits<typename Container<T>::iterator> {/*...*/};
}

fails because T is not in a deduced context. Of course, if Container::iterator were a typedef (not a member class), and/or if Container was subject to partial specialization itself, then the compiler might have quite a time determining if each subsequent instantiation of iterator_traits matched the "pattern". But the only simpler way to refer to that nested class than to give the canonical name of its containing class would be to use an alias template, which g++ 4.9.2 rejects on the same grounds. Is it simply impossible to produce such a partial specialization? --Tardis (talk) 17:13, 18 January 2016 (UTC)[reply]

I think it's impossible. The top two answers of this question may work for you: either fully specialize iterator_traits for all the contained types that you plan to use, or define an adaptor template with the appropriate typedefs. -- BenRG (talk) 20:00, 18 January 2016 (UTC)[reply]

Further searching (based on the idea that this is a general limitation of template deduction) finds the frustrating result that g++ used to do this but stopped to adhere to the standard. It's obvious that—when the nested name is constrained to be the real name of the type—the deduction is technically possible to implement, but the standard simply says no. --Tardis (talk) 00:32, 19 January 2016 (UTC)[reply]

NuGet question

My company manages most of its internal projects with NuGet packages. This goes so deep down that different .NET C# class libraries within the same product are referenced with each other through NuGet. So I have found out that if I have to make changes to a library referenced to by other class libraries, I have to first build it, then make and publish a new NuGet package of it, and then update all the references. When I say "publish", I mean we only update our internal NuGet repository. The packages only ever go to our company internally and our customers. But I find it a hassle to go through all this every time I want to modify the code in a class library. Is there an easier way to test the changes, before making an official update? My boss suggested temporarily removing the NuGet reference and replacing it with a direct reference, then undoing all this and putting the NuGet reference back in. But I find this a hassle too. Is there any easier way? JIP | Talk 20:58, 18 January 2016 (UTC)[reply]

Does having a phone service reduce available ADSL bandwidth?

My broadband relies on copper telephone wire. Does having telephone service take some of the bandwidth away from the Internet connection? Could I ask for the phone service to be disabled and get slightly faster Internet? --78.148.108.55 (talk) 21:39, 18 January 2016 (UTC)[reply]

ADLS and PSTN coexist, they use different frequencies so they don't "use up" each others bandwidth. Vespine (talk) 22:01, 18 January 2016 (UTC)[reply]

That's the theory, and is probably true in Edinburgh. In practice, if you are at the end of a six-mile stretch of copper, a phone call can make the ADSL stop working completely (for reasons other than bandwidth). It's worth asking your ISP. Dbfirs 23:00, 18 January 2016 (UTC)[reply]

I don't dispute what you're saying (it's common knowledge that ADSL's performance drops rapidly with distance), but this is kind of orthogonal to the original question. ADSL and phone service use different frequencies (the impetus for designing ADSL was to transmit data over existing phone connections by using frequencies above the voiceband frequencies), so disabling the phone service isn't going to add additional bandwidth to the ADSL service. The issue you brought up is interference between phone and ADSL transmissions, but unless you're using the phone, nothing is being transmitted over the phone connection. So, if you don't notice any impact on your ADSL connection when you're using the phone, cancelling the phone service isn't going to improve your ADSL connection. --71.119.131.184 (talk) 00:42, 19 January 2016 (UTC)[reply]

Is it even possible to cancel phone service (as opposed to just unplugging the handset) and keep ADSL? Always thought a phone line has to be live with a number assigned to it in order to carry data. 94.12.81.251 (talk) 11:44, 19 January 2016 (UTC)[reply]

No. Naked DSL is fairly common in some places. In the past, some ISPs even recommended it for VDSL2 in NZ. The phone line does need to be live of course, but there's no need for a PSTN service to be tied to it. One advantage with removing the PSTN service is presuming you're allowed to by your telco and building owner, remove any any extraneous wiring except to the DSL jackpoint. You can do something similar by installing a masterfilter at the phone line entry, with a dedicated connection from the masterfilter to the DSL; but how common these are varies from country to country and the work may be a little more involved (depending on your existing wiring and how far ou want to go). See e.g. [1]. Nil Einne (talk) 13:41, 19 January 2016 (UTC)[reply]

Many years ago, when I had a DSL connection, I was getting a poor error rate (not quite the same thing as poor bandwidth - but the effect was much the same) - and AT&T advised inserting some filters on the phone line. They supplied them for free - and it did fix the problem. I guess the problem is that while a phone shouldn't generate the higher frequencies that DSL uses, old-school phones aren't always that well designed - so maybe it does anyway. Tossing in a low-pass filter shouldn't have a downside - and it can definitely help. SteveBaker (talk) 18:32, 19 January 2016 (UTC)[reply]