c3d

Peak 3D performance does not matter.

With Tao3D, I keep pushing graphic cards to their limit, on laptops and desktops. This raymarching example http://www.youtube.com/watch?v=GUMqT9W5BG8 runs fine on my Macbook Pro for about 20 seconds. After that, the heat becomes high enough to throttle the system down. And you end up with a very unpleasant "fast/slow/fast/slow/fast/slow" experience as the system tries to cool down its graphic chip.

So you really don't care about PEAK performance. What you care about is sustained performance, and power consumption in that scenario (not just running idle).

No discussion of ray marching is complete wihtout mentioning Shadertoy (http://www.shadertoy.com) and the work of great shader artists such as Iñigo Quílez, Paul Malin, Dave Hoskins, Reinder Nijhoff and many others. If you are interested in these techniques, check it out.

One of my favorites is Elevated: https://www.shadertoy.com/view/MdX3Rr.

I've converted many of the most beautiful ones to auto-stereoscopic 3D for Tao3D (http://tao3d.sourceforge.net). An infinite landscape in glasses free 3D is a thing of beauty :-)

Never tell the creator of a language "It sounds like you want X". Creating a language is done a) for fun, b) just because, c) as a personal development plan, d) to explore, e) to become master of the universe. None of these is achieved by merely using language X, whatever the value of X is.

These companies care about their "property" more than about legality, unfortunately.

I remember a lawyer from Atari/Infogrames coming at me for having authorised some abandonware site to publish a game I had written in 1990, Alpha Waves. So I dug up the contract I had signed with them. It was a 3 years exclusive licensing and distribution contract, which Infogrames could only renew by sending me royalties every quarter.

I sent a copy of the contract, along with a letter asking for the more 15 years of royalties (after 1993). Never heard back from the lawyer after that.

Old abandonware often belongs to individuals and independent authors. And if they are like me, unlike lawyers, they are just happy that someone remembers the stuff they sweated on for years.

It's based on XL (http://xlr.sf.net).

The main page has shaders in background. This works well if your machine is beefy enough. But it's apparently an issue with systems such as iPads. I've temporarily removed the shader backgrounds.

Multifix is not more general than combinations of the 8 node types in XL, only more powerful than a combination of some subset.

It's not simpler. XL started with a multifix representation, see http://mozart-dev.sourceforge.net/notes.html. Switching to the current representation was a MAJOR simplification.

The current representation captures the way humans parse the code. Infix captures "A+B" or "A and B". Prefix captures "+3" or "sin x". Postfix captures "3!" or "3km". Block captures "[A]", "(A)", "{A}" or indentation. Since humans perceive a difference, you need to record that difference somewhere. XL records that structure in the parse tree itself, not on side data structures such as grammar tables.

This approach also enables multiple tree shapes that overlap. Consider the following XL program (I replaced asterisks with slashes because the asterisk means "italics" for HN):

A/B+C -> multiply_and_add A, B, C

A+B/C -> multiply_and_add B, C, A

A+B -> add A, B

A*B -> mul A, B

In that case, I can match a multifix operator like multiply_and_add without needing a representation that would exclude matching A+B or A/B in other scenarios. This is especially important if you have type constraints on the arguments, e.g.:

A:matrix/B:matrix+C:matrix -> ...

A:matrix/B:real+C:real -> ...

Those would be checked against X/Y+Z in the code, but if X, Y and Z are real numbers, they would not match.

If you want to try it by yourself, you can download Tao from http://www.taodyne.com/shop/dev/en/content/10-compare-versio.... Tao uses XL as the basis of its dynamic document description. There's a tutorial here: http://www.taodyne.com/presentation/tutorial-2.0.html. Please note that the XL implementation used in Tao has several limitations, notably with local functions and closures.

In XL, a multifix is a combination of infix, prefix or postfix. Note that the various nodes exist only for the programmer's convenience, i.e. they represent a user-visible syntax. Internally, I could do with only a node with two children.

Something like [A,B,C,D] writes as:

Block with [] containing Infix , containing Symbol A Infix , containing Symbol B Infix , containing Symbol C Symbol D

So this allows me to represent multifix along with their expected syntax. I could also represent for example:

[A, B; C, D]

if A then B else C unless D

for A in B..C loop D

The last one is actually one of the for loop forms in XL

True, 'if 3' will stay there if there is no rewrite for it. You can also use treat a lack of possible rewrite as an error, this is what the Tao 3D document description language does. You'd get an error like "No form matches 'if 3'".

Underneath, there is a rewrite operator, ->, that means to transform the shape on the left into the shape on the right.

The precise semantics are a tiny bit more complicated than that, but it iterates until there is no more transformation that applies. Some specific rewrites will be transformed into "opcodes" of the underlying machine model. So A+B with integers on each side will execute an addition (the inner representation of the transform is something like A+B -> opcode Add).

For more details, you can read http://xlr.sourceforge.net/sites/default/files/XLRef.pdf. I badly need to update it, it's out of date, I have a more recent version, but I need to learn the new way to connect to SourceForge.

The XL programming language (http://xlr.sf.net) has a rather unique approach to parsing. There is a short article about it here: http://grenouille-bouillie.blogspot.fr/2010/06/xl-axioms-rec....

XL features 8 simple node types, 4 leafs (integer, real, text, name/symbol) and 4 inner nodes (infix, prefix, postfix and block). With that, you can use a rather standard looking syntax, yet have an inner parse tree structure that is practically as simple as Lisp. The scanner and parser together represent 1800 lines of C++ code with comments. In other words, with such a short parser, you have a language that reads like Python but has an abstract syntax tree that is barely more complicated than Lisp.

It's also the basis for the Tao 3D document description language used at Taodyne, so the approach has demonstrated its ability to work in an industrial project.

If you are interested in this kind of tool, you should also conside Tao Presentations. See http://www.taodyne.com/shop/dev/blog/288-building-a-dali-sty... for an example of what you can do with it (in that case, a real-shader-based real-time ray traced clock).

Real-time shader editing, complex scenes built using a real-time 3D document description language, animations, multiscopic 3D movies playback, 2D and 3D text layout, dynamic textures, etc. In short, Tao is a rather complete toolbox for real-time 3D.

+1. But then, is it necessary? Jobs and Gates were not exactly moderate, as far as we know.

I really love the "in-world" editing. However, I'm not convinced by the description of the scene. Here is what it should look like: https://www.youtube.com/watch?v=paJG7Fy5Few.

A lot of the discussion here has been around Lua, but not around what they do with it.

I think that putting yet another language and runtime in the OS kernel is a bad idea. It makes the amount of code to validate much bigger. I much prefer the Mill Computing approach to security, where "everybody works the same" including the kernel (see http://millcomputing.com/docs/security/ if you have not seen it already). That's also the idea behind many microkernels.

Although the Mill CPU embeds basic mechanisms in the hardware to make it easier, I believe this could be achieved on modern x86 or ARM as well with reasonable performance. You don't need privileged instructions to deal with packet routing or CPU throttling, you only need controlled memory access to specific regions of memory (e.g. device registers, buffers, etc). I see no reason why the scripts could not do their work from user-space, with kernel-controlled access to the regions of memory they need to operate. And the overhead in doing that is practically zero (basically, it's the cost of the TLB translations, which is paid for every single memory access anyway).

Obviously, you also need inter-process and inter-CPU synchro, interrupt handling, etc. But all these are already presented in a virtualised form to user-space.

Also, if you want the flexibility of a scripting language, you are willing to forego quite a bit of performance in the process. Is the cost of a user-kernel transition really that relevant in this scenario? And if it is, there are mechanisms to mitigate that cost, e.g. pooling requests, deferring, sending to another CPU, etc.

I'm a bit appalled by the way they measure the overhead (Section 5 of the article). They say that their CPU rethrottling code runs in "only" 8 microseconds. Well, if compared to the rescheduling interval, it may seem small, 8 microseconds in kernel code is actually a lot. It means 1/125 of a regular millisecond tick. All this just to change the frequency of the CPU?

In short, I agree with the objectives (making the OS more extensible and more flexible), but the way they did it seems dangerous and under-optimal.

Most people assumed that the Apple encryption was designed in reaction to NSA intrusion into everybody's privacy. But it might also be a strong sales argument in markets where intrusion into people devices is just normal.

This page uses a specific shader courtesy ShaderToy that does real-time ray-tracing in the background. You can verify that it's real-time by moving the mouse. Moving left and right changes the amount of "frosting" on the cakes. Moving up and down changes the zooming factor. Enjoy.

This is based on Reveal.js. You can download the source code directly from the web site. To see changes in background shaders, move left and right using the arrows at the bottom right of the page. Note that this requires WebGL to work ;-)

The multiplicity of APIs demonstrates that the problem is hard. The needs of game developers pull the APIs in a specific direction. And these requirements must be addressed, because the games market is huge and pushes the envelope.

But other users may have different needs. OpenGL is used by games, but not just games. For example, at Taodyne, we use OpenGL for real-time 3D rendering of business information on glasses-free 3D screens. I can tell you that my pet peeves with OpenGL have nothing to do with what's being described in any of the articles.

Some of the top issues I face include 3D font rendering (way too many polygons), multi-view videos (e.g. tiled videos, which push texture size limites, or multi-stream videos, that bring a whole bag of threading issues), large numbers of large textures without the ability to manually optimise them (e.g. 12G of textures in one use case).

Heck, even the basic shader that combines 5, 8 or 9 views into one multiscopic layout for a lenticular display makes a laptop run hot for a mere HD display, and requires a rather beefy card if you want to have any bandwidth left for something else while driving a 4K display.

Many of these scenarios have to do with limitations of textures sizes, efficient ways to deal with complex shapes and huge polygon counts that you can't easily reduce, very specific problems with aliasing and smoothing when you deal with individual RGB subpixels, etc.

Of course, multiscopic displays are not exactly core business right now, so nobody cares that targeting them efficiently is next to impossible with current APIs.

Yet another entry. The Christmas tree in Tao Presentations is less than 30 lines of code, with a star at the top and blinking lights. Code here: http://www.taodyne.com/shop/dev/en/blog/275-a-christmas-tree....

There's already work under way on tools to visualize such massive amounts of data in a comfortable and interactive way. See http://www.taodyne.com/shop/en/blog/76-visualize-one-billion... for an example.

We need technical tools to be able to communicate. If these tools are subverted, the political fight is harder to organize. So both go hand in hand.

If you want to play with shaders interactively, take a look at Tao Presentations. Will let you combine shaders and real-time 2D/3D animations. http://www.taodyne.com/shop/en/blog/67-real-time-stereoscopi... for an example, http://www.taodyne.com/shop/en/blog/60-screencast-building-a... for another one.

Call me unimpressed by the "proof by eminent authority", in particular when said authority offers only a "proof by public ridicule".

Wikipedia article http://fr.wikipedia.org/wiki/Le_Père_de_nos_pères

Interestingly, this very same hypothesis was the basis for a novel by french author Bernard Werber called "le père de nos pères" (the father of our fathers), published in 1998.

If you have nothing to hide, then you don't matter. In this information age, data is money. There's a difference between having nothing to be ashamed of and having nothing to hide.

I have the same issue from France. First thing I checked was the blog post announcing the end of CalDAV, and yes, that's September.

Something else is not working right. Google may be testing just how much trouble shutting down CalDAV would cause... Or they may simply have made a mistake.

Agreed. fortunately, there's LLVM for the back end now. And XL for the front end/AST

At Taodyne, we also developed our own language. That lets us do that: http://www.youtube.com/watch?v=9vv18SFljzA. No other language fits the bill.

Try that in Javascript or PHP and see if you can fit the whole thing in 15 minutes (the YouTube upload limit)

Sometimes designing your own language is just the right thing to do.

What about the native APIs? NTFS and HFS have their roots in non-Posix worlds. The basic operations are somewhat similar in all platforms (open file, read directory, ...) But the "modern" stuff is not standard, otherwise it would not be modern.

This is probably the reason only FAT fits the bill: it's a lowest common denominator that has so few features that it can appear "native" on all platforms.