Computing desk
< February 4	<< Jan \| February \| Mar >>	February 6 >

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.

February 5

Chrome - "The following plug-in has crashed: Shockwave Flash"

Getting the above message frequently in Google Chrome on Windows 7. Looked for help. Found lots of less than helpful and quite outdated non-help from Google.

Anybody? HiLo48 (talk) 02:43, 5 February 2012 (UTC)[reply]

If it happens rarely, ignore it. If it happens often, try a download and reinstall of Flash. StuRat (talk) 04:29, 5 February 2012 (UTC)[reply]

It happens several times a day. Since your post I've reinstalled Flash, rebooted, and it's still happening. HiLo48 (talk) 15:57, 5 February 2012 (UTC)[reply]

Have you tried re-installing Chrome itself? --Mr.98 (talk) 16:28, 5 February 2012 (UTC)[reply]

http://techlogon.com/2011/08/11/shockwave-flash-crashes-in-google-chrome/ Von Restorff (talk) 16:33, 5 February 2012 (UTC)[reply]

Thank you for that link. I have been having the very same problem with Chrome and Flash. → Michael J Ⓣ Ⓒ Ⓜ 12:23, 7 February 2012 (UTC)[reply]

Yes, it helped in my case too. Has reduced the frequency of the problem a lot, but not totally eliminated it. HiLo48 (talk) 08:43, 9 February 2012 (UTC)[reply]

Used copy of Spore

Hi- I just got a used copy of Spore (game) (on a Mac). It came with the manual so I've got a validation key. When I enter it, it says that my key could not be validated. I assume this is the message that you see when you're trying to use an already-used key. Is there some sort of official way that I can get EA to revalidate this key? I know their extreme DRM was partly an effort to kill the used market for Spore. Am I just out of luck then? Thanks- 24.60.54.68 (talk) 04:13, 5 February 2012 (UTC)[reply]

You can try [1], but you'll have to pay US$10. Nil Einne (talk) 07:50, 5 February 2012 (UTC)[reply]

Thanks- I decided to just ask EA myself. Here's the reply I got, in case anybody cares:

"Please note that as you have purchased the used copy of the game I am unable to assist you with this issue. I suggest you to please contact retailer from where you have purchased the game or you can purchase the new key. As a valuable customer of EA, please accept the 15% origin discount (W6XAC-EAPAL-GMXT4) code for your next purchase. This code is valid for one month and can not be used for pre-orders. The code can only be redeemed here: http://store.origin.com"

Yes that's the real code- I won't be using it. 24.60.54.68 (talk) 17:01, 5 February 2012 (UTC)[reply]

The correct response to this kind of DRM nonsense is piracy. Von Restorff (talk) 17:13, 5 February 2012 (UTC)[reply]

Von Restorff, we do not accept or tolerate piracy on the reference desk. This is part of the official policy against contributory copyright violation, and the fine folks who are allowing you to use Wikipedia free-of-charge take this policy very seriously. If you do not understand the difference between free software and stolen software, I recommend you read our article on free software. If you simply want to get video games for free, here is a list of zero-cost games. If you don't like the selection, I recommend you browse over to the website of the Free Software Foundation, and start a campaign to make "free video games for Von Restorff" part of the high-priority projects. Nimur (talk) 18:11, 5 February 2012 (UTC)[reply]

Wut? You must be aware of the fact my comment is piracy nor copyvio, so your response to it is a bit weird and very offtopic. Von Restorff (talk) 18:37, 5 February 2012 (UTC)[reply]

I'm with VR on this one. He wasn't participating in piracy, he just mentioned it. --Ouro (blah blah) 18:41, 5 February 2012 (UTC)[reply]

It would be different if I would've said: "download a keygen here".

Von Restorff (talk) 18:46, 5 February 2012 (UTC)[reply]

I too am finding Nimur's response a tad mystifying. Von Restorff is making the rather cogent point that if you penalise genuine purchasers of games with onerous DRM requirements or treat them with contempt as EA are blatantly doing so (bad show chaps!) in this case, you run the risk of angering them sufficiently that they will resort to pirated material simply because it will actually work. It's like those beastly unskippable copyright warnings and films on DVDs these days - pirated versions have them all removed, they only waste the time of genuine purchasers. It's also a symptom of the software industries attempt to destroy thousands of years of economic principles by not allowing the customer to actually own what they purchase outright, to resell or dispose of as they see fit. Taking the view that the second hand software market is an evil parasite on their business they are attempting to change the paradigm of software that you only buy a finite license to use the software under whatever ridiculous restrictions they deem correct and you cannot sell that license on once your need for the software has ended, unlike the previous model where you simply uninstalled the software and you could perfectly legally sell it on for someone else to use in their turn. It's enough to make a chap really quite miffed! Quintessential British Gentleman (talk) 01:26, 6 February 2012 (UTC)[reply]

Exactly what has happened here, is there no way the original owner can uninstall and make the key valid for reuse? That is the facility I would expect EA to support. Otherwise if it has an install limit I'm with EA here and it was up to the person who sold the game to check it had the right to. Another way round would be to require games to check on the web every so often but that has other problems. Dmcq (talk) 09:26, 6 February 2012 (UTC)[reply]

There is a deauthorisation tool ([2]) but I believe it requires the tool to be run on the authorised computers [3]. More importantly I believe the bigger problem is the key is permanently associated with an EA account. If the original owner had provided the EA account, then I suspect the OP will have options. However if there are multiple games associated with that account, this may not be possible for the owner. BTW, if I understand the response correctly, the $10 for a new key option is available ('or you can purchase the new key'). Even if it's not, you could just not tell them it was bought used since from the description I don't see what's stopping it. Whether this will violate the EULA and whether this term would be valid in your country, I can't say. Nil Einne (talk) 11:19, 6 February 2012 (UTC)[reply]

I just had a look at the article for the game and it looks like there may not be such a tool for the Mac, only the exe for the PC. That makes a mess of the situation. I think the only right the OP has is to take it back to the person who sold it to them for a refund, but EA has caused trouble to the original buyer by selling them something they couldn't sell on without telling them. So really are they willing to spend the extra $10 or do they want a refund? Dmcq (talk) 13:40, 6 February 2012 (UTC)[reply]

I only paid $1 for my copy at a library book sale, so I'm not really out that much, and I'm certainly not going to complain to the library about it. And the verification is only to access online "shared" content. So I can still play the more-or-less full game, just can't get the online stuff that is supposed to be a big feature. I don't think it's worth the $10 for me to get the online stuff. The person who really makes out here is the original owner- they can still play the full game (which doesn't require the disc in the drive) with online content, and they are free to resell with the guarantee from EA that the later owner won't usurp their registration. I guess I can install and resell it too... probably for more than $1. I'm pleased that EA called me "a valuable customer"- I am not now nor will I in the future be their customer. 24.60.54.68 (talk) 21:51, 6 February 2012 (UTC)[reply]

The 'valuable customer' bit is PR lingo, and means close to nothing, but just in case they're better off believing you're on their side, so that you don't publish the letter somewhere citing bad treatment of 'customers' should they include something less cuddly and warm ;) --Ouro (blah blah) 10:43, 7 February 2012 (UTC)[reply]

fast C/C++ coroutines?

Can anyone recommend a super-fast coroutine hack or library for C or C++? It should be very simple, i.e. have a fixed sized stack area per coroutine, and simply bang the machine registers to switch coroutines, rather than copying stacks around or anything like that. I guess it will have to know about the compiler's calling conventions so that parameters can be passed in registers. The application is monstrous amounts of SAX-style XML parsing, where writing stateful event handlers is getting too tedious. For now I don't care much about portability, if it works with gcc/x86. Thanks. 64.160.39.72 (talk) 10:29, 5 February 2012 (UTC)[reply]

Is your concern the context switch time, or should you be more worried about keeping code and data inside the CPU cache? Hcobb (talk) 15:39, 5 February 2012 (UTC)[reply]

The problem is, on new x86 platforms, the register bank is already virtualized. (Register renaming, among other fancy tricks). In short, the x86 microarchitecture is implemented to make fast context-switching automatic, unlike a small controller where you manually swap register banks by calling a context or bank switch instruction. So, you probably will gain nothing by trying to improve register utilization - it's already optimized. In a situation like this, the first step is to profile the program to determine exactly how wall clock time is being spent. I'll second the comment above - can you try to resize your data structures and functions so that the working set remains in the lowest cache level possible? The valgrind utility can help you analyze your program at the cache and memory transaction level. Cache utilization and performance will be more rewarding than context-switch tuning on most x86 machines. As always, I'll caveat my advice: the profiler analysis of your code on your machine is the best and most canonical source of information. Nimur (talk) 17:24, 5 February 2012 (UTC)[reply]

A context switch on x86 costs thousands of cycles. I'm not sure where you got the idea that it's fast. Register renaming has no relevance to context switching that I can see. -- BenRG (talk) 00:16, 6 February 2012 (UTC)[reply]

Simultaneous multithreading, or hyper-threading, is essentially performing a context switch as often as every instruction. Each thread explicitly uses eight or sixteen architectural registers, but these are virtualized and translated by the microarchitecture. The actual number of registers, and the actual number of simultaneous threads in the pipeline, is one of the parameters that differentiates different chip series. The Intel architectural philosophy is to perform these optimizations at runtime; they are completely opaque to a programmer. Some explanation as it pertains to Core i7; Intel's official documentation refers to this technology specifically as both context switching and as register renaming (depending on runtime thread policy). For peak performance, follow Intel's guidelines: run your co-routine on a thread, using an operating system thead library or Intel's processor enumeration utilities. It's unlikely that any "custom" parallelism scheme can outperform the standard system thread model, which already takes advantage of the hardware implementation. Nimur (talk) 06:23, 6 February 2012 (UTC)[reply]

Nimur, HT is not context switching in any useful sense. It actually appears as parallel cpu's at the software level. Anyway I think you basically don't understand the original question. Coroutines are not intended as a means of implementing parallelism. They're just like subroutines except the control mechanism is different, so there's no distinction between "call" and "return", which makes some types of programs cleaner. It's pretty trivial in assembler on most machines, though it requires hackery (that PuTTY thing being an example) in stack-oriented languages like C. Yes you can simulate coroutines with threads, but it's ridiculous overkill, like replacing a C function call with interprocess communication. As for the speed, see the thread-ring benchmark from Alioth. You notice GHC, Go, Mozart, and Erlang are around an order of magnitude faster than C or C++ (except for "C++ #4" which I'll get to in a second). That's because GHC, Go, etc. manage their own concurrency without using OS threads, i.e. they use something like coroutines instead (but with an OS-like scheduler inside the language runtime, so it's still less fast than using coroutines directly). "C++ #4" if you look in the code is also (per the code comments) not using real threads, but some other thing with a pthreads-like interface. In between are languages like F# and Smalltalk, that presumably also aren't dealing with OS threads (F# uses .net fibers), but are slower than GHC/Go/Hipe because they have interpreted VM's instead of native code compiers. While researching this last night I found a good article[4] about how Lua implements coroutines, that might be of interest to you. Anyway, I'm still weighing different approaches for the program I'm writing, but using multiple threads is completely unsuitable for this purpose. On a typical 2 ghz x86 you should be able to switch coroutines at least 100 million times a second. There is no way you can do that with threads. 64.160.39.72 (talk) 06:26, 7 February 2012 (UTC)[reply]

Thanks, I hadn't been thinking of context switching, just single-threaded user mode coroutines that I hoped would be basically as fast as subroutines. If you're talking about using multiple OS threads, I'd expect the mutexes alone would be a big bottleneck. I don't yet have any code to profile. I'm still writing with explicit callbacks which are something of a control inversion, so I'm for now only at the stage of trying to figure out a more convenient approach. Re cache effects: the working set is already reasonably small. 64.160.39.72 (talk) 20:36, 5 February 2012 (UTC)[reply]

Subroutine call overhead is so tiny that trying to migrate to coroutines will most likely be a monumental waste of effort that could've gone chasing real bottlenecks. There is no "copying stacks around" (not unless you're trying to pass kb-sized objects to a subroutine by value). In x64, either the first four or the first six parameters (depending on the compiler and the calling convention) are passed in registers. --Itinerant1 (talk) 00:01, 6 February 2012 (UTC)[reply]

I think you didn't read the question very carefully. The OP wants to switch to coroutines to make the code easier to understand, not to make it faster. Copying stacks around is something the coroutine library should avoid doing, not something he/she thinks the current code does. -- BenRG (talk) 00:16, 6 February 2012 (UTC)[reply]

The PuTTY source code has a very simple and limited coroutine implementation in standard C using switch/case, described here. If you need something more robust (and more complicated), take a look at coroutine and fiber (computer science), which link to some libraries. -- BenRG (talk) 00:16, 6 February 2012 (UTC)[reply]

Thanks. Yes, BenRG understands what I'm looking for. The PuTTY page is nice and I might just use those switch macros instead of worrying about real coroutines. Their main drawbacks I can see are 1) having to put the local variables in statics (I can live with that for something this simple) and 2) probably defeating some compiler optimizations, but hopefully by not enough to matter. I'm ok with taking a few percent slowdown to help keep the code straightforward, but 1.5x or 2x would be too much. I did look at a few existing coroutine libraries and they seemed too heavyweight, and some of them did copy the call stack around (probably more robust than using static stack areas, but I think static areas are ok with not too much code and a little care). 64.160.39.72 (talk) 01:23, 6 February 2012 (UTC)[reply]

The PuTTY code is "nice"? I barely got through the first example beforee coming back to try and dissuade you... but then I saw that the site itself tells you: "Of course, this trick violates every coding standard in the book. Try doing this in your company's code and you will probably be subject to a stern telling off if not disciplinary action! You have embedded unmatched braces in macros, used case within sub-blocks, and as for the crReturn macro with its terrifyingly disruptive contents . . . It's a wonder you haven't been fired on the spot for such irresponsible coding practice. You should be ashamed of yourself." Don't use this programming paradigm! It's a neat concept, from a hacker point of view; it's got aesthtetic stylings that probably give Don Knuth warm fuzzies, but it's bad code. It's hard to maintain, harder to debug, and even harder still to modify. It explicitly does the opposite of what Intel tells you is best practice for peak performance; so you've ended up with code that's bad for human-use, and even worse for machine-use. It's not portable, it's not thread-safe, it's not re-entrant. Aside from toy problems, it has no place in your programs.

Place your coroutine work in a separate thread; let your compiler and your hardware help you get your job done in the most efficient and most maintainable way. This is better practice in the long run. Nimur (talk) 06:55, 6 February 2012 (UTC)[reply]

The PuTTY page was nice in the sense that it was educational and fun to read. Yes the code is an awful hack (among other things, it occurs to me that there's no way to switch out of the coroutine from within a nested function call) but what I'm doing is pretty hacky anyway. But, the handwritten state machine is even uglier and less maintainable than the Putty macro. The traditional solution would be an assembly language subroutine that does the coroutine switch by just banging the hardware stack pointer (I guess that can be done sort of portably with setcontext and I might try benchmarking that). I can guarantee you from long experience with thread programming that threads would be unacceptably slow for this. 64.160.39.72 (talk) 08:16, 6 February 2012 (UTC)[reply]

display old Mac bitmap fonts

I have a sporadic project that involves old bitmap fonts, such as the standard Macintosh set from 1984. FontForge can display them, but it only sees the smallest size in a file (or maybe it prefers 12 point), and I want to look at the biggest.

Okay, I thought: I'll get the PPC from the closet, fire up MacOS 10.4 (which purports to run old apps by emulating MacOS 9), and use Font/DA Mover or ResEdit to build a suitcase containing only the biggest sizes of all the fonts I have. To my horror, neither Mover nor ResEdit responded to a click on the File menu. I'm just about beyond caring why not; hooking up the old computer is not something I want to do more than once in a week.

Can someone point me to

a MacOS X application that can display those old fonts? or, failing that,
a successor to ResEdit, with which I can modify suitcase files? or, failing that,
advice on how to write a Python program to interpret the font resources themselves?

—Tamfang (talk) 23:49, 5 February 2012 (UTC)[reply]

Can't help but think you can get FontForge to work. Have you read all of this? ¦ Reisio (talk) 03:30, 6 February 2012 (UTC)[reply]

Yes. Prompted thereby, I tried File→Import (rather than Open); that doesn't recognize the files. —Tamfang (talk) 05:37, 6 February 2012 (UTC)[reply]

Where can one of these fonts be found? ¦ Reisio (talk) 11:24, 6 February 2012 (UTC)[reply]

Other than on CDs that I've saved since 2000? I don't know offhand. —Tamfang (talk) 22:23, 6 February 2012 (UTC)[reply]

Ah, there's ResKnife. —Tamfang (talk) 22:28, 6 February 2012 (UTC)[reply]

... which does not recognize a font file as something that it can open. —Tamfang (talk) 23:08, 6 February 2012 (UTC)[reply]

If one of the font files was called foo.fnt, what does file foo.fnt (in the terminal) report? -- Finlay McWalterჷTalk 22:28, 6 February 2012 (UTC)[reply]

empty, because all the content is in the resource fork. —Tamfang (talk) 23:08, 6 February 2012 (UTC)[reply]

You might try posting your question on comp.sys.mac.system. If they don't know the answer, you might get a pointer in the right direction. RudolfRed (talk) 02:24, 7 February 2012 (UTC)[reply]

My mistake. FontForge apparently imports all the sizes at once, and the View menu allows choosing among them. —Tamfang (talk) 04:57, 7 February 2012 (UTC)[reply]

That's a relief. When FontForge can't do something, we're all in trouble. ¦ Reisio (talk) 13:27, 8 February 2012 (UTC)[reply]