vmind

I think the main issues were accessibility, IE support without a canvas stand-in which could be very slow, and accessibility. Also, general rendering is pretty speedy on all browsers, whereas canvas rendering was pretty variable until recently (and still is for fast redraws).

Also makes theming changes quite a lot easier using css.

(http://groups.google.com/group/ace-internals/browse_thread/t..., http://groups.google.com/group/ace-internals/browse_thread/t...)

Ace is gradually gaining full IDE features like syntax checking, split views, and responsive behaviours such as auto-brace/bracket/parens insertion.

If you want an online-only workflow, Cloud9 already offers github as a backend for an Ace powered IDE. I think Ajax.org have hired someone to work on IntelliSense style auto-complete for Cloud9, not sure if those will be suitable to be put into Ace itself.

I've contributed some changes and documentation to Ace, really awesome project, great to see it hitting Github!

Support for IE<9 older browsers is a little sketchy at the moment, but hopefully greater exposure through github will see more fixes and features contributed. (Fabian Jakobs seems quite open to new features as long as they fit in with the projects goals)

Unfortunately it's a lot of smaller charts and they're embedded in an SVG based diagram interface as foreignObjects, which doesn't support a WebGL context (in Chrome at least). I'd love to play with WebGL, but not usable for this task.

Writing the whole interface in a WebGL canvas could be really fun, but far too much work for an MVP, and would kind of mess with making it work on iPad etc.

And here I am trying to get a bunch of 2d lines rendering quickly in a 2d canvas for some charts. So strange to me that something 'simple' like drawing 20,000 lines chugs along at ~20fps and a water simulation with caustics is there running at 30fps just fine. Goes to show how much you gain from a GPU if you're using it for something it's designed to do.

Looks like the dosbox is loaded depending on which version of chrome you're running, and there's only 12 and 13 up, so 14/15 tries to get a file that doesn't exist.

Bit of silly coding, given the ABI is fixed from 13 onwards.

Deferring javascript loading definitely makes sense when you're loading a really heavy chunk of script that doesn't need to be around immediately. I saw load times drop from ~500-600ms to ~150ms with use of LABjs, as the server was rendering the page almost entirely (syntax highlighted client side) but the page editor component (ACE + jQuery + other dependencies) was a good ~500-600kb of javascript for the browser to parse and run, but having the edit button appear half a second or later after the page shows isn't a real problem. ACE loading a full editor as well as syntax highlighting a few 100kb of text on the page isn't a light task.

If your site is rendered client side with backbone and templating etc, then there probably aren't many gains to be had there.

Quick few points

* Using scroll for zoom in a 2d workspace probably makes sense with a mouse, but with the macbook touchpad it was rather annoying to be unable to pan around (as moving quickly around is rather a benefit to flicking through a mindmap). Not sure how to fix that, but my inclination would be to offer keybinds for zooming in and out, or an option to allow panning with scroll.

* Behaves badly with browser zoom, you probably want to do some kind of dpi detection and rescale the interface as required.

* Possibly allow moving of the central idea.

* Showing/hiding child branches is very nice.

* Select a links child if you click on it? (as link settings are associated with the child) Also, possible to update the link colour immediately?

Overall very nice.

It seems to choke if you have a hyphen in your username.

'Collections should keep track of their views' seems badly explained. You're not keeping references to views on a collection, you're keeping a reference to subviews inside a view that uses a collection. The code is correct, and agnostic to whether the collection is local to the view, or a shared collection.

It's just an additional alias in the grammar, no real measurable slow down given the size of the parser as is.

2 lines in the parser: http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_langua...

The RFC (https://wiki.php.net/rfc/shortsyntaxforarrays) was actually rejected by the developers, I think it's only really been put in to appease large userland pressure. Find it rather amusing that a 2 change to the parser for an alias would be rejected on 'maintainability' grounds.

I'm rather wary of emulating Safari here..

The new two finger default page gesture is proving rather problematic for the web-app I'm currently working on (which has a workspace larger than the screen which you can scroll around). If you scroll to the left you can accidentally do a page-back and leave the app. Setting a beforeunload handler actually makes the problem worse because the confirmation dialog doesn't appear until the page has completely disappeared, and if you choose to stay on the page, Safari just shows a blank page instead of redisplaying the app.

I don't quite understand the by-default conflation of two actions (scrolling and paging) using two fingers. It's all very well that I can myself change to three finger swipes for paging, but I can hardly instruct all Lion/Safari users to change their system settings. (I understand that a workspace web-app is rather the edge case).

Point 7 seems like the biggest for me. Recently wanted to plan/discuss a few days away with the family. A shared google calendar with a circle and discussion around that would be superb for such things.

Well, yes, but it comes with all the overhead of being a (partly) flawed language. Having a bytecode that allows, for instance, optional static and dynamic types would be much more direct than relying on type inference or separate native APIs (as are being introduced). Of course we have javascript now, so pragmatically languages should be compiled to it if we want them, but if there were to be an additional web bytecode, there would be many areas for improvement in terms of performance and safety.

Some kind of flexible bytecode implemented across browsers would be fantastic, and you could always implement a fallback interpreter in javascript (or if feeling fancy, a decompiler).

I think the issue with Clojure is that it does runtime bytecode rewriting for macros, so to get the whole language working on android they had to bundle the dalvik translator as well.

There's also TNetStrings which mongrel2 is using now. (http://tnetstrings.org/)

They're adding Group Policy support and msi installers (http://www.youtube.com/watch?v=3YkEUpJQP3o&feature=playe...). There's not a lot of detail there but they're not ignoring it.

It's also confusing to note they don't mention whether they even contacted the authors of the paper to see if an implementation (even partial) had been made, or clarification could be provided on implementation details.

A general idea is to 'compile' user queries to a lucene query with the various default options that give the best search, and not to use raw lucene queries from the user. The knobs need to be there for turning, whether you expose those knobs to the end user is a design decision.

Am I right in thinking that, with an embedded database such as Neo4j, I would be required to use the server standalone and use the remote capabilities from a separate JVM in order to escape the virility of the license? (And if distributing, refer to their site for installation of the server?)

Though this is a much welcome change from AGPL or commercial.

The slides (http://talks.php.net/show/dojo/1) seem good as a quick overview of the talk. The take home messages generally being: make sure you know where your application is spending its time using strace, and to track superfluous overhead (such as configurable fallbacks that you can hardcode in a deployed application). Also: HipHop is not a magic bullet. Without heavily computational application code it gives only marginal improvements over PHP with APC, at least in these tests.

Have you considered LuaJIT instead of v8? Given you are using v8 as a target VM for compiling another language to javascript, and lua is quite similar, although if other javascript libraries are used that could be a major factor. (This is assuming you are writing Chrysalis/Stencil)

I think as it is only shown when selecting a book or on the screensaver, and not during main usage, quite a lot of people.

Would it be possible to use pushState as the main mechanism on the client, and use a #! as a fallback? You would end up with two different possible URLs, but if the same library handles the calls then it would be fairly straightforward to move from one to the other.

This just looks like a great way to make your back-end depend on your front-end. AJAX calls are usually best served in an API like manner (here's some data, do what you like). This lets you iterate on the client without messing with the server, which this would destroy. If you have an application style client, you're also probably making the same data requests for different purposes.

Granted it's quite neat, but it seems like a bad idea. I think too many libraries recently are focusing on length of code to the detriment of good principles and clarity.

Basically: Qubits (sort of) encode all possible states that a standard string of bits can take at the same time as a superposition, such that when you measure them, you have a possibility of observing each possible setting of the bits.

You can manipulate the possibility of observing certain states by performing operations on the bits (which are effectively interference). So a quantum calculation is more a probabilistic restriction on which state you want, rather than a direct calculation. In order to be sure of a result, you need to repeat the calculation to get a desired confidence (or just check the answer directly if that would be faster).

Some truly bad graphs there, displaying response time on same axis as responses per second? Leaving in a bracket probably to contain outliers and flattening the rest of the graph?

Because of how the markup is generated, it's not too nice to get a 1:1 pdf. I have been looking at PhantomJS (headless webkit) which can render out to a pdf, but it seems not to like something about the libraries used, as the fonts and math are not displayed. Hopefully that can be fixed.