It feels to me like everyone is holding their breath to see how the wholesale "AI can replace people" notion pans out. Whether it proves true or not, betting on the wrong result will hit hard so few want to go all in (outside of the companies that produce the tech itself). If there's anything "AI" has been able to ship at scale, it's uncertainty.
Could be just plain alphabetical. There's a selector for which color name list to use/examine on the bottom of the visualization. There's also a selector for which color space model to use.
Now the problem becomes mobile browsers...
(hover vs. tap, tiny resolutions, differences in form controls, sometimes crippled features that work fine in a "pc" based browser, fluid layout choices, float issues)
What have you needed out of ANSI SQL that is a gap in its Turing Completeness? Totally serious. A great many things can be dismissed as not being Turing Complete, so please provide us with some examples of why this is bad in ANSI SQL.
I did not mean that ANSI SQL was bad. However, by not being turning complete it has fundamental limitations that limit it from expressing certain logic (as you might need to do in a stored procedure). This frequently means that you must use proprietary extensions to SQL (such as PL/SQL) to accomplish these tasks.
My interpretation of the parent post was that it was a response to a comment about vendor lock in. I was only trying to point out that it is not always possible to ensure compatibility between databases by writing strict ANSI SQL.
These words make me close tab for the site I'm looking at right away: "Click to launch site". I came to your website... shouldn't it have launched already? Oh it's not a website - it's a multimedia presentation? Great. That's not what I came to your "website" for. No thanks.
(Though I have to admit, there was a time when I actively looked for those sites. I made some good money going to restaurants and other small businesses around town offering to convert their sites from un-editable flash to a simple, skin-able CMS I had whipped up. They were always skeptical until I said "never pay for changing text or prices on your site again". After that, they were my customer and no longer the customer of the wannabe-techno-hipster that sold them the original contract for site and "updates".)
The phone number and extension is probably what's used to identify where the "sales lead" came from. As for the long-calls, there's probably a minimum connection time before the lead is considered "valid". "aaron" is probably telling everyone 6 minutes keeping in mind that this is a Craig's labor pool and they will probably only really do 2 minutes on average.
That and I don't know of anyone (outside of using them as particles) that has successfully created collision models with voxels in real time. The collision calculations of just a few of their scanned rocks and a ground plane would be plenty complex - a whole scene perhaps even a little insane given today's specs.
They might have to resort to polygonal collision models in the same way that polygonal games end up using low-poly collision models (with the same pitfalls such as moonwalking, blocked projectiles or mystery-bouncing).
Sorry for the belated reply. Yeah, I saw Atommontage and it's quite interesting. Despite the realism of the track marks left and suspension movement, the truck still seems to exhibit some unnatural "floating" feeling. These are the very pitfalls of dealing with lower-res poly collision that I was speaking about. Kind of an uncanny barrier for movement.
I do feel that this author is a bit further along at something ship-able than the Euclideon folks are though.
The more I think about it, the more I realize that of the three pure voxel problems (rendering, animation and collision), rendering is probably the low-hanging fruit - Though I'm not sure if creating a hybrid poly/voxel engine is any harder or easier.
Here's to at least getting a hyper-real Myst someday :)
Collision need not be at the same resolution as the rendering which should help. But animation is probably limited by how much of the scean changes. If it's a small percentage of the enviornment removing the old objects and adding the new ones should be reasonably fast. Or if it's a small number of objects you could always keep them in a seperate tree and translate a ray in the main scean with one for the moving object.
I don't think you're being too harsh. I agree that newT really doesn't seem like a templating engine - it seems more like a HTML generator. It's a pretty complex hammer to drive a carpet tack. Programmatically constructing DOM from that low of a level is still more trouble than it's worth.
For me, I stick to small chunks I can loop on my own if need be and use a simple tokenizer I wrote (see bpmv.toke() at https://github.com/BrynM/bpmv/blob/master/bpmv.js ). Far simpler and I can have anyone whip up HTML boilerplate to use.
Example: https://www.accubeat.com/ntp-ptp-time-servers