I'm in the EDA world since 15 years at least and I'm still surprised why many (but not all) vendors have adopted TCL as their scripting language of choice for their public API; my opinion is because it is quite close to shell scripting and so more suitable than Perl or Python for engineers which are not experienced with real software development. Another reason is due probably to the good integration with the Tk UI library that allows to easily associate a UI interface to some of the scripting tasks, something that is highly appreciated by many engineers: this is not easy to accomplish if you use Pyhton or Perl. However I agree that Tcl is a terrible language that I would avoid for any modern project.
I think Tcl's popularity in EDA has to do with the fact that the very first EDA tool, Magic, was scripted in Tcl. In fact, Magic and Tcl were written by the same person.
I think there is another reason, besides Magic being scripted in Tcl. Back in the days when some EDA companies decided on Tcl there were only a few languages which could be embedded. Tcl was the only one with some popularity, documentation about embedding including sample code and a commercially viable license.
For Perl for instance the embedding feature was largely undocumented at the time (early 90s I think) and Perl is GPL which is a no-go for commercial software. Ruby did not exist yet and Python maybe just was not visible enough.
Mentor Grpahics Calibre has a very good interface written in Tk. Also some utilities from the Encounter suite have Tk interfaces (not the whole suite of course as Tk is not suitable for graphicslly intensive applications)
The other thing I use Tk for at work is writing test scripts for hardware. Often the hardware has a serial port or an ethernet connection in it somewhere. Tcl includes serial port support, and also has an event loop that supports callbacks for both serial port and sockets. I don't think _any_ other solution beats Tcl/Tk for this type of thing. In a way, it's a shame so few people know about Tcl/Tk these days ...
For my modelsim scripts, I usually incorporate a menu in the main modelsim toolbar for my projects. The menu will incorporate menu items for things like library compile, rtl compile, testbench compile, listing all available testbenches for selecting and running. Usually my menu will be organised using submenus. That sort of thing is very quick to do, and it makes developing RTL a little less painful.
Compared with the web based apps we had in the past the LinkedIn one is a great step forward. The main point according to me is not the fact that web vieww apps are slow, for sure things will improve in the future and web view perofrmances will increase in the time thus reducing the performance impact in most apps. The main point that should be discussed is why these guys insist in using html and js. People seem to forfet where html is coming from: it was a way to layout a page on screen. The reason why html acquired "desktop application like" capabilities was to provide some desktop features to internet based apps: at the end the clear winner was html5+js+css, while java applet failed and flash is its decline. Looking at the efforts done by LinkedIn engineers, you may appreciate the hard work they did and the interesting way they faced several challenges, but what surprises me is why those guys didn't follow the Obj-C approach that would have given to them the possibility to reach better results in a more natural way. According to me html should be used only in those cases where it is superior to Obj-C: publishing. It offers much more capabilities than PDF at lower cost. All other usages are wrong.
Someone may anseer that LinkedIn preferred to follow the html based approach to leverage their investment i. The web site, but I will object that:
1. Html5 is the only choice for the web in the computers, which are not mobile devices, but it's a poor choice for all mobile devices that have a native development environment
2. The effor they did in fixing all webview issues could have been moved to do a better API for native apps.
And yes, if you compare their app to Flipboard you notice the difference.
I completely agree. Using 4.x today allows to write code in a much cleaner and efficient way; a few examples: gestures (for iPhone), blocks, GCD. Besides multitasking and background processing allows features that were impossible to get or required complicated hacks. And now that we must provide iOS4 and iOS5 mixed compatibility, we cannot absolutely maintain any compatibility with iOS3.
It is quite impressive that in just over a year developers are able to start requiring iOS 4.
I hope that iOS 5's OTA updates we could get to the point where iOS versions older than a few months are considered obsolete.
Apple has done a great job at fostering this culture of upgrading as soon as possible. Microsoft and Google still have problems were the average consumers see OS updates as something that can cause problems, not bring new features.
>I hope that iOS 5's OTA updates we could get to the point where iOS versions older than a few months are considered obsolete.
While a very nice idea, I'm not convinced it much will change due to old hardware being incompatible with new versions of iOS. It's rarely the x.y versions which are the barriers to progress, but the x.0 versions.
That is true but Apple does seem to have a higher adoption rate with their physical products. iOS 4 killed support for the original iPhone and now iOS 5 is killing support for the iPhone 3G.
When the iPhone 5 comes out this fall I think by June of next year there will be enough penetration of iOS 5 that some apps will be able to put that requirement on it.
Heck if we're lucky iOS 6 will finally kill support for non-Retina displays.
You shouldn't consider this as a TM failure but just as an HDD failure. You may have some very o,d Snow Leopard backed-up data (e.g. parts of the OS which are never updated) or several months old documents which have been saved once by TM and never touched again. So TM cannit be blamed for such old filesystem nodes which have been damaged by the HDD failure and not TM one. What you tried to do is to completely wipe your HDD and do a complete restore by TM. This operation should be better accomplished using a fresh carbon-copied HDD image, that ensures all data are new and safe. What you can ask to Apple engineers eventually is to add a "cold restore" operation, that is asking to do some sort of simulated restore in order to check needed data integrity only, thus preventing users to make risky operations such as the one you tried to do.
How does TM know if it can reuse file from the previous backup or should create a new version. If it's just timestamp then it's not such a good idea, it should use hash of the content, and if it has and stores content hash it can and should verify backups once in a while to e sure against bad sectors etc. Doesnt have to be on each backup, and doesn't have to be all files at once, but it can, say, check backed up file content once a month/week or so.
Thanks for the comment viggio! Never considered it as a failure of Time Machine but I sure think it is something that can be prevented by Time Machine by just running a integrity check on the disk drive (even as optional feature) prior to doing a backup. After all its a backup that you rely on :)
Move the multi choice option after more time: currently it is faster to reply using the multichoice feature instead of typing. Or, another possibility, when a competitor replies using multichoice, don't reject the typed answer as too slow.
Anyway nice game, nice idea.
The problem is that you don't get those 3 points if the opponent rushed the multi-choice and got it right. Denying your opponents points is a valid strategy considering the goal is simply to have the most points after 10 questions. Even if I face a very easy question, pressing multi-choice and picking the correct answer is preferable to typing the answer in and possibly being too slow.
You could possibly solve that by making the multi-choice feature buttons use 1 second to work. Basically, I click banana, and 1 second after that the server actually acknowledged my answer.
Fair point. Note taken. I'm hoping once they're more questions and more players online there'll be an option to play with only alternatives or only typed ones. Especially since on an iphone for example it's hard to type as fast as you can on a desktop computer.
