The new management abandoned their old codebase (and users) to suffer the slow decline of bitrot. Meanwhile they took Chromium, repainted it, added 2 features nobody cares about, left out 99% of the features people used in Opera 12 and called it a day. Then to add insult to injury and cause maximum pain to their old users, and confusion to everyone else, they called the new software package Opera and gave it a higher version number, despite it sharing no code and no features with the original software.
And, just because that wasn't enough, their new management forced employees to lie on public forums and twitter about how they were going to work towards feature parity.
I don't understand why you had to pour anger into your post. That version of Opera uses the Chromium engine, that's important to distinguish the old vs new versions...
Hi Luna, from my perspective async.js is about control flow whereas operations.js is about creating well defined operations that can be composed, queued, cancelled, reused and monitored. It's more of a workhorse.
Yeah, operations.js is meant for more complex scenarios than that. For example if we were spawning hundreds of operations that interact with networks/file systems. We can set an upper limit on concurrent operations using queues and express complex dependencies between them, compose them and cancel them.
I just compared Inconsolata and Consolas side by side and couldn't believe how similar they actually are. Whenever I just swap between the two, it's hard to compare, since Consolas seems to run about a point bigger looking than Inconsolata, so I have to scale it back a bit to give a real comparison.
Not surprising considering the author of Inconsolata cites Consolas as his primary inspiration, but I'd never noticed exactly how close they are. Both great monospace fonts. Very nice characters, but what really makes them stand out to me is that they both manage their kerning very well, especially around thin characters. Many other monospace fonts, including M+, end up with awkward gaps that approach a full space width and give the text a slinky-like compression/decompression effect, making reading and determining word breaks at a glance difficult.
My reactive programming language can handle cyclic dependencies; DAGs are too inexpressive for general use (e.g. iterative computations). Getting that to work correctly is kind of scary though (especially when non-monotonic change is also supported).
Yinyang still. I want to release something soon, but need to find a purpose for it; right now it's just fly by night language design. I was also thinking about porting the editor to mono.cairo so more than just win users could play with it (going to javascript is a no go given no multithreading with shared memory).
I guess "working correctly" for cyclic dependencies means you need to introduce the concept of time and be careful to update everything in the proper moment? What is this useful for?
See http://research.microsoft.com/apps/pubs/default.aspx?id=2112... if you haven't already. I have both time and phases; time is used for versions and discrete updated via event handling; phases are used to ensure state doesn't get "stuck" in a cycle on a non-monotonic change. Rollback is used instead of carefully updating anything in the right order, phases however suppress when updates can be seen during processing.
It's generally useful for writing reactive, incremental, iterative programs.
Nice... I did make an attempt to filter out sensitive stuff but clearly did a bad job. Thanks for letting me know. I will eventually introduce a demo app rather than my own site.
Tbh, probably fairly bad atm. I haven't done anything empirical but atm Silk will create a record for every SQL query executed during the request/response cycle effectively doubling the number of queries. Not only that but it also saves down any non-binary HTTP body to a TextField, and this isn't yet configurable.
I think the Elasticsearch/Celery option is a good shout if this were to ever be used in production. Celery would help with the issue of response time but it wouldn't solve the load impact on the database (although I guess could also configure a different SQL database in Django).
I will certainly do some investigation into this at some point :)
That's not a bad idea, it would probably be more natural than the rigid filters that are currently in place for the requests and profiles. As far as having this running in prod I've only really thought of siphoning off the results to celery or something similar to avoid impacting response time, but a spray and pray at Elasticsearch would work just as well.
What's nice about the current setup is that it takes very little effort to get up and running but I suppose could make that configurable...
