How would you otherwise teleport when the martians attack and the grid is down? Plus, I think that if you have a quantum teleporter, having at least a couple of terawatts locally is basic construction code in most places.
- 80' holographic TV with 360 channels 4D surround sound - Two parking spots for the hovercars - A quantum teleporter (ask for the free subscription to Andromeda Quantum Tours Weekly) - A six terawatt home battery and thorium / fusion nuclear reactor (don't go for the cheap Tesla stuff, nuclear is what you need) - A robosquid and a set of batteries - Six packs of pills for instant beer - An iPhone9 with the Apple Watch, Apple Pay, Apple ID, Apple Travel, iThink, assortment of overpriced cases, cables and chargers - At least one DNA decoder / recoder per room - A 65536-qbit game console for the kid
This one is somewhat specialised, but may still be worth sharing. Back then, I was working on HP ECUTEST, a refrigerator-sized machine that simulated all electrical inputs and outputs for a car engine control unit (ECU). Basically, it was "The Matrix" for an ECU: you plugged the car's brain into it, and it couldn't tell it wasn't in a real car.
The customer wanted a way to create defects on the ECU pins, e.g. short them to the ground. Problem is that an injector signal is 60 amps or so for a diesel engine, and an ignition coil signal is easily 500V. Try shorting this with a low-cost relay, and your relay gets fried pretty fast. But then, we were emitting the "cogwheel" signal that the ECU used to know the position of the engine, A pretty complicated signal in its own right, that varies in shape, amplitude and frequency as engine speed increases. Generating that signal was a story in itself.
Anyway, we wrote software that would synchronise the flipping of the relays to create defects with the rotation of the engine, so that we knew that at the moment we were switching the relay, there was little current and little voltage in the corresponding circuit. Of course, you can imagine how many relays it cost to make the stupid software work as it was supposed to. Well, actually, not that many, all things considered, but the hardware guy who had to replace the relays still cursed me whenever I goofed up.
Did a similar thing back at engineering school, with an old IBM 4341. That machine was a big time-shared computer with tons of students. Someone noticed that your account got a temporary priority bump whenever you had a screen refresh. So in order to speed up compiles and other things, we had a variety of contraptions that would hit the page-up/page-down keys to force the screen to update continuously.
There is a story I remember reading once, but can't seem to find anymore. It was about some space probe that was regularly shutting down. The space engineers finally figured out that it had lost a panel, so the sun light could enter inside and that was enough to corrupt the memory that was hit by sun rays. So NASA modified the program so that it "walk around" physical memory, copying its code and data around memory so as to avoid solar rays. I don't know if that story is true, but if it is, it looks like a good candidate to me.
The HP28C had an infrared output, e.g. For printers, but no input. a friend of mine published a book explaining how to connect an IR diode to trigger some unconnected keyboard lines in the calculator. That made it possible to upload programs to the calculator faster. Of course you also needed the matching hack on a PC to send programs. The 48 had IR in both directions.
If you are a developer and want to go beyond Powerpoint, Tao3D (http://tao3d.sourceforge.net) is a valid open-source option. It takes time to master, but it's a much more effective way to tell a complicated story.
First up, can I suggest adding the word "visualisation" to your standard blurb?
Good idea, done. It was hidden in the middle. Renaming Tao Presentations to Tao3D is similarly an attempt to avoid the misconceptions about "presentations".
I'm talking about a visual confusion. The reason I keep using the word "opaque" is that when I look at the code, the intended (semantic) behaviour is obscured.
Are you sure this has nothing to do with you not being familiar with the language?
You've suggested several times that having effectively only one syntactic structure in the language makes it more consistent, but my object with regards to consistency is precisely the contrary: that the syntactic rule is inconsistent because there is no clear mapping of syntax->semantics.
Maybe the word you are looking for is not "consistency" then. "Consistent" means there are no exceptions to the rule, which is easier to achieve when there are few rules. In C++, f(x,y) may be a macro invocation, a function call, a constructor, and there are different rules in all three cases. In HTML, the "a" tag refers to its URL as "href", but the "img" tag calls it "src". Consistency with the "real world" also matters. In SmallTalk, 2+3*5 is 25, not 17, so SmallTalk is consistent with itself (everything is an object, etc), but not with the rest of the world.
Something helped me immensely in your last post: you put a few code examples. I think that code examples help me figure out what you really mean or what you care about much better.
So ":=" is the assignment operator, but in all your examples you've sugared it over, and basically obscured the logic of your code...?
Why do you call this "sugaring over" now, and not "building an abstraction" (from your previous posts)?
The abstraction for attributes, used consistently, is: each attribute has a name from the real-world, you set the attribute "attr" with "attr value", you get the value of the attribute with "attr", and attributes apply to things that are evaluated later. Not obscure, and consistent, both internally and externally (e.g. with OpenGL).
I don't think it's more practical, because it massively less readable.If I use object.setColor("green"), it's easy to read the intended meaning.
Can't agree on that one. It's totally unreadable (ask any 10 years old kid without a deep training in JavaScript). And for productive programmers, it has the following useless characters: "object.set()".
I would prefer the abstraction object.color = "green" because getter/setter is usually implemented by convention rather than rule (leaving things open to programmer error).
There, you went down three steps down the abstraction ladder. Why not MOV $green.str0, color[object] while you are at it?
But your solution offers less clarity than either.
I have trouble arguing if you tell me that object.color = "green" is a better abstraction than color "green". It's terribly inefficient when you have multiple shapes and multiple attributes, and I have proven with rotation that it does not work for some complex attributes.
You're talking about the computer.
No, I'm talking about the abstraction level, meaning you hide what is irrelevant.
Imperative is superior to declarative only in terms of optimisability
Also in terms of expressive power, in terms of the ability to build abstractions incrementally, in terms of... well... everything;-) Imperative can also describe computations, tests, loops, and so on. Remember my question about how you'd represent repeated divs with HTML alone (no JavaScript)?
a declarative language should be easier to code in,
Really sorry to hear that. But apology gladly accepted;-)
You'll probably hate me for saying this, but why not just write text elements in an established format... like HTML?
Now you can. But HTML is not a very good format for dynamic text. How do you represent the following with HTML?
paragraph "It is currently " & hours & ":" & zero minutes & ":" & zero seconds zero N -> if N < 10 then "0" & N else N
I believe that the typical usage of presentations will see a lot of minor adjustment of the most PowerPoint-like elements
This is true with what Powerpoint can do. With Tao3D, when you discuss a simulation, a lot of time is spent refining the simulation.
For one thing, reusing existing collateral would be more of a cut-and-paste affair
Even without the patch above, you can copy-paste HTML into Tao3D.
the language confuses the two metaphors of series-of-commands vs collection-of-properties.
There is no confusion, there are only series of commands, although with a homoiconic language, they are also data, so you can view them as properties and make them behave like properties if you want to. The fundamental paradigm remains sequential evaluation (using parse tree rewrites in that case).
Ah... what I hadn't noticed was the lack of assignment operator in the language.
There is an assignment operator in the language. The theme getter/setter is define as follows:
theme -> "default" theme T -> theme:= T
If that's what you've done, in theory you have completed the abstraction of objects -- if the caller doesn't need to know how an object works, it shouldn't need to know that it's not changing the properties directly.
I may not have made the abstraction exactly like you wanted, but I've made abstraction more practical than in most languages. The theme "variable" could be a function, I would not know. And the theme T "setter" could do some validation or anything else, same thing, you would not know.
But without an operator, how is it obvious the difference between an assignment, a function passed as argument, a function call and a looked-up value?
The real abstraction is precisely that it is not obvious at the call site. If you have something like do_something theme, it's do_something that decides for example if it evaluates theme or not. If not, it gets the unevaluated name, and it can decide to do something with it, like using it as a prefix for a "function call".
As a developer, you should be avoiding personal taste.
That makes no sense to me. While it's a good thing to be able to fit in an existing environment, when you design from scratch, you have to make choices. And those choices are based on your own taste. Who gets to decide for you if you prefer to write runThing, run_thing(); or (run-thing) or, Knuth forbid, <thing EVALUATION_MODE="run" @ARGS[$nil]>?
That last one, while I don't like it, at least looks consistent
In the Tao3D evaluation model, they are all consistent.
at other times a bag of object properties.
This only shows that imperative is superior to declarative. You can make imperative feel like declarative, not the other way round.
If I edit the attributes of an HTML tag via javascript, it shouldn't really matter which order I edit them in -- the end result is the same.
It's not implicit lists. Tao3D, like Lisp, is strongly homoiconic. In other words, it's primary data structure is used both for programs and data. In Lisp, that primary structure is the list. In Tao3D, it's the parse tree. Manipulating parse tree structures is fundamental in Tao3D programming.
Now, conceptually, you can correctly think of 1,2,3 as a list. But you could as well have 1;2;3, which is also a "list", except it's built with a different infix operator.
So when I write something like: foo X,Y -> bar X; blob Y I'm really describing is a parse tree transform recognising a prefix foo, which matches only if the right is infix with a comma, and will split that infix into its left and right components, and call bar, then blob with the components.
I could similarly do something like that: [A..B where C] -> A-B and that would only match a [ ] block with a child that is an infix "where", when the left child of that infix is an infix "..".
So it's very regular. It does what other languages call function calls, operator overloading, or even macros (because that process also lets you precisely control when arguments are evaluated).
Sure. What I'm saying is that, from the numbers you've provided, your product clearly lots of room for improvement. Even with basic Latin, you're averaging 128 triangles/character for flat text!
While it's only 128 edges (not triangles, I had misinterpreted what I was counting), it was still worth investigating. And I modified the way Tao emits polygons to be more aggressive for small sizes. I also added user-controllable parameters in case the defaults are not suited for a specific use case. Code reviews and comments are welcome.
from the information I had from you, produced 3d extruded text more efficiently.
Then you misinterpreted the information I gave you, because my point was that designer, ideographic or Arabic font have complex outlines. AFAICT, Three.js cannot use such fonts (maybe there's a trick I don't know).
What does Tao3D offer over competing products like these?
These are all great products. What Tao3D offers is: 1. It's notably cheaper, and now there's also a free software version. 2. It's a programming language. That being said, I know Ventuz can at least be scripted, not sure about the other two. 3. Stereoscopy and auto-stereoscopy are just a mouse click away. Ventuz can do some, but it was convoluted last time I checked. 4. Tao3D automatically checks if media, files, sources changed, and reloads them. Great for remote-controlled updates. 5. No need to import media, Tao3D uses media in place (that used to be an issue in Ventuz and Aurora3D, not sure if that's still true).
In a sense, Tao3D is to these tools what a web browser is to Powerpoint: open, extensible, flexible, but harder to get started with. And in this analogy, we see the web-based interface in Tao3D as the equivalent of Wordpress, i.e. a solution to separate concerns between editors, page designers and media content producers.
Ah, I missed your point completely in the GP. Sorry.
The problem it addresses is the complexity of creating the simplest 2D or 3D scripted animation, and how this process does not scale or compose well.
Here are a few random examples: * Create Christmas card pictures for all my friends that are automatically tailored for each of them. * Display fragile objects in a museum, photographed in 3D (or scanned), shown in 2D, in 3D or in glasses-free 3D * Display complex data or simulations for a scientist, in a way that can be explored interactively or shown at conferences. * Teach about fractals by showing interactive models of various fractals.
I'm conscious that with enough effort, some of these can be done with other tools. The purpose of Tao3D is to reduce the effort manyfold.
There was none, indeed. In reality, Tao3D is based on tree rewrites, not lambda calculus.
I'm exploring a bit here what the implications are. Quite frankly, the type system as implemented is totally incomplete and still largely broken at the moment. I understood what needed to be done after 5 years of experimentation, and never got the time to actually implement it. Similarly, the language reference describes a runtime environment for functions, how closures and symbol tables are defined, etc. I prototyped this and got a basic compiler half working, so I know it will work. But the symbol table in Tao3D is a more ancient design, in C++, not visible to the program.
That being said, there are "anonymous tree rewrite" notations very similar to lambda calculus. For example, here is how you can draw an almost convincing Christmas tree:
color "darkgreen" foo with (X -> 3*X^2+7) with 1..8, 2..4
foo R ->
rectangle 0, 0, R, 18
translate_y -20
The with operator here implements a map, i.e. we apply foo with the result of an anonymous rewrite (that's the "lambda") with a list made of values 1 through 8 and then 2 through 4.
The filter operation is implemented with another syntactic form:
foo with (X where X mod 2 = 0) with (X -> 3*X^2+7) with 1..8, 2..4
There's also a reduce operation, but it crashes the compiler at the moment, need to see why:
foo (X,Y->X+Y) with (X where X mod 2 = 0) with (X -> 3*X^2+7) with 1..8, 2..4
With my computer, a code editor, and the (easily accessible) documentation. It took about 10 minutes.
I meant: you probably have some code that looks like: var geom = new THREE.TextGeometry(T, { size : S, height: H, curveSegments: CS, font: F }); I was interested in the parameters to that code.
That statement is either completely false or incoherent. Care to give it another go?
Unless you are rendering bitmap fonts, at some points, your glyph outlines are first rendered to the texture. It may be 2D, chances are it's still done by the graphic card on modern systems.
Sure. What I'm saying is that, from the numbers you've provided, your product clearly lots of room for improvement. Even with basic Latin, you're averaging 128 triangles/character for flat text!
Actually, you are right, the code I quickly implemented was counting the array elements, not the polygons. So, roughly, the number of edges, but counting terminating edges in triangle strips multiple times. My bad. I guess I'm getting tired. The point I was trying to make remains valid: some real fonts (as opposed to the toy fonts in Three.js) quickly generate huge amounts of polygons. As another illustration of my point about WebGL, I can see the Three.js geometry / text example on my iPad, but not on my iPhone 4 or my Android tablet. Maybe you are more lucky with your BlackBerry...
I'm still not convinced the project offers anything over existing solutions.
I'm sorry I did not convince you. But Tao3D does offer a lot over existing solutions.
First, Tao3D is the only practical solution I know for delivering interactive 3D animations, simulations or presentations quickly. What you can do with Tao3D in 25 lines of code is nearly impossible today with Three.js: no support for real TruType fonts, no text layout for 3D meshes, no RTL text support, etc. And I'm just talking about text here. We can do full slides in 3D with 25 lines of code when Three.js is barely capable of doing one line of text in 600+ lines of code at the moment, and then only with relatively serious 3D programming. Tao3D requires 24 times less lines of code. And you say we bring nothing new?
That brings me to the second big contribution. Even if you add text layout features to Three.js, you will still be working at the wrong semantic level, talking about meshes and renderers and such. Again, someone might work this out the way Reveal.js attempted to do for slides. But Tao3D does this today. Today, with Tao3D, you talk about "slides" and "paragraphs" and "color", because that's what you care about.
Finally, a third innovation in Tao3D (though not in the libre edition) is transparent support for practically every stereoscopic or auto-stereoscopic screen under the sun. So you can playback 3D movies without glasses, superimpose 3D text and logos, etc. In the digital signage space, Tao3D brings glasses-free 3D screens at feature parity with 2D screens. And that's also a pretty significant contribution.
I can understand your need to defend it against any and all criticism, real and perceived
Not any criticism. Against uninformed criticism, of which there is a lot on Slashdot, unfortunately.
How is your startup going? What markets have you found the most success? Where do you see the product in the future?
I noticed your "failing" startup comment earlier, don't worry. Like any startup, not enough cash, too many ideas, not enough people, too many things to do, not enough time.
Just to clarify, the poly counts I gave were actual triangles processed by the card when disabling texture-based rendering in Tao3D. This is the only case that always works, so it's both the fallback scenario and the worst case scenario. Therefore, that's the one I'm most interested in.
Not extruded? Why not render the text as a texture and slap it on a triangle strip?
Hmm, how do you draw a glyph with only one triangle per character? Or do you mean that we can use two triangles for multiple characters? We also can store full words in the glyph cache. But currently, we only use that for languages with ligatures such as Arabic.
but that's still way fewer than the approach you're using.
May I suggest that you should study how the Tao3D code works a little more before being so dismissive;-)
You might also want to look at other, clearly more efficient, solutions. Take a look at three.js's ShapeGeometry. and ExtrudeGeometry -- A quick test shows great quality, with far fewer triangles.
Quick test with what? How did you create a text mesh with Three.js to start with?
Furthermore, as soon as you extrude, you need true polygonal rendering. You can't draw on a texture and render quads or two triangles as you suggested. Or if there's a way, I don't know it. So you end up with roughly the number of polygons in the base glyph x N, where N depends on extrusion parameters, e.g. if you create a bezel or not, if you round the bezel, and so on.
That being said, if you want the text to look any good, you have to emit a large number of triangles for even relatively simple text.
On the basis of my experience, I strongly disagree.
Would you please be kind enough to share your experience? That's a hot topic for me.
First, I'd like to point out that even if you can do texture-based rendering, you still need to first render to a texture with polygons or, alternatively, with triangles and a shader doing the Bezier fill.
Let's deal with two cases here. The first case is when texture-based glyph caching applies. In that case, polygon count is rarely a problem for alphabetic languages. For ideographic languages, or languages with ligatures such as Arabic, the chances of finding what you need in the glyph cache are lower, but you can still assume you will draw the same text several frames in a row, so that's still a net win. The animation may skip a bit when the text changes though... So basically, the glyph polygon count defines the worst case "skip" you can get. And westerners don't care, since they use a Latin alphabet with an appropriately low number of glyphs. So in general, we can reuse entries in the glyph cache.
Second case is when you can't use textures. Extruded 3D text is one scenario, that's hardly the only one. Then, you need true polygonal rendering. And the number of basic triangles you had for the front face is multiplied by N, which depends on the shape of the extrusion path (bezel, rounded bezel, etc). Plus this time, you need to render the polygons at every single frame, so polygon counts start playing a big role in performance.
In all cases, even with an curvature-dependent algorithm, you still need a decent number of polygons per glyph or any non-basic font looks like crap. I think the best you can do is something like one triangle per Bezier curve in the glyph (un
Thought for the day: whenever designing something for other people to use, you should take all feedback from your potential users and prove to yourself why the feedback is correct before attempting to show the giver why it's wrong.
Oh, I got it backwards then. I thought you had been trying to prove me wrong all that time... Sometimes, you were right (e.g. black characters on black background). Sometimes, you've made a good point (e.g. align_vertically). Sometimes, I feel your point is less convincing (glTranslate and glColor). Sometimes, I think you are plain wrong (global state is evil), and I express disagreement. That's how a discussion goes. I enjoyed it, sorry to hear that you did't seem to.
if your default response is to prove to everyone that their feedback is so valueless to you
If it felt so valueless to me, do you think I'd still be watching for your answers and typing this in the middle of the night? I don't claim to be perfect. Please reciprocate.
Exercise for you: go **** yourself. That's just patronising.
No, that's trying to help you become an early contributor. I would not have spent the time locating the exact line to patch otherwise. Remember, open source is about you and others being able to influence Tao3D. But since you obviously don't want to do it this time, I patched it myself. Your name in lights, tadaaa.
If we were just talking about text flow in a 2D page, I would agree with you
Well, text layout is still done in a 2D text box. So align specifies the horizontal alignment and justification within a line (the frequent case), and align_vertically the alignment and justification of the lines and paragraphs vertically.
I understand that, but it's wrong. I know a lot of people laugh at the idea of using setColor and getColor as per so many OO style guides, but really, you either need to use assignments or use verb-based names, or the syntax is broken from a human cognitive perspective
It's an interesting point. Tao3D actually went the other way. A setter and a getter for a property typically have the same name. So to adjust the stereoscopic effect, you can say something like eye_distance 20, and that adjusts the property you get with eye_distance. To get the current theme of a slide, you use theme, and to set it theme "Master". I personally see the 'set' and 'get' in that case as noise. But I will admit it's a matter of personal taste. I hope you will understand that Tao3D reflects my tastes and not yours.
At the limit, we began implementing (but never finished) a system of properties named x, y, width, top and so on for coordinates. You could then use any of the following three, to your liking: rectangle 10, 20, 30, 40 rectangle { x 10; y 20; width 30; height 40; } rectangle { left -5; y 20; width 30; bottom 0; } x 10; y 20; width 30; height 40; rectangle
Much like for color, the last one would also set the properties in a persistent way for following shapes to use, much like color or texture today. This means you would then be able to say something like left 20 to left-align a bunch of shapes. It's not done yet, but still in the plans.
They are broken. If you aren't willing to fix the real problems with languages, why write a new one in the first place? Why not just write a library?
I find your use of bold font and "broken" quite antagonistic to your statement that two people can be correct at the same time. You call this a real problem with languages. I just don't see it. Specifically, I don't see color "red" or glColor as broken. In doing so, I'm not saying that you are w
I don't like subroutine names that include something that looks like a parameter, so things like rotatex and rotatey set me on edge a bit.
If you prefer, you can use the plain rotate. But rotating along X, Y or Z is frequent enough to deserve a shortcut. Not different from CSS transform, by the way.
It gets worse when this is inconsistent, and you see a subroutine called vertical_align for vertical alignment, where the seeming parameter (vertical) is now before the generic (align), and separated by an underscore instead of run together. Not only is this an internal inconsistency, but it's inconsistent with English, as "align" is a verb, and we would put in an adverb "vertically" after the verb normally. And then it gets worse again, as the command for horizontal alignment is... "align".
You are right, align_vertically would be more sensible. Exercise for you: fix it;-) As for align, that's the common case, so I'd rather keep it that way.
The grammatical inconsistency continues with other commands/subroutines taking on names with no verb component at all (eg the command color, with no verb or assignment operator.
That derives from OpenGL, which has glRotate and glTranslate, but glColor and not glColorize. BUT it's not inconsistent. It's actually fairly smart. The color is an attribute, and glColor just sets it. So the name is the name of the attribute you set. glRotate and glTranslate modify an attribute (the current model/view matrix), so they are verbs. Unwittingly, I applied the same logic for things that change the color state, e.g. show. Since show changes the color state, it is a verb.
I'm really not happy with the way pattern matching is used as overloading...because you can get yourself in a mess if you split it up into different parts of the code and accidentally overwrite stuff.
How is this different from overloading? That's a FUD argument. In reality, its distributed nature is exactly what makes the construct powerful. It offers a very flexible dynamic dispatch mechanism.
For example, the Slides module draws a background for slides using theme_background. That function is provided by the default theme. But most themes will override it.
In general, this override happens only on part of the pattern. For example, most slide elements are defined by (theme, master), sometimes (theme, master, style). The "master" is the equivalent of the Powerpoint "slide master", i.e. it defines the layout, etc. If you define a new theme, you'll typically define overrides that catch everything for a given theme (e.g. for "BrightRectangles" in the last link). But you may also want to override for a specific combination.
I'm completely baffled why the whole demo recreates the shapes for every single redraw frame rather than keeping them as persistent objects (which necessitates adding a random seed in order to fake them being persistent by pulling up the same colours each time.
The Tao3D drawing model is a feature, not a bug. If you write rectangle 0, 0, 320, 200, it draws the rectangle once, and that's
Suddenly you have to look in dozens of different places to verify what the most basic features of the language are.
Not really. The parsing is defined by xl.syntax, a file that currently contains 62 lines, so it's not complicated. The semantics, on the other hand, comes from libraries, including some that are built-in. In the case of base XL, the library components implemented in XL are in builtin.xl, and the components implemented in C++ are in basics.tbl.
But XL and Tao3D put way more in libraries than regular languages. Remember when we moved from BASIC to C? In BASIC, the 'PRINT' statement was a keyword. In C, 'printf' was a library routine. I argue that the C approach is superior. So of course, an exhaustive catalog of C libraries today is a bit difficult. And there are inconsistencies. But it's still superior.
Lisp has a tiny grammar and a small standard, and that leaves us buggering about with a visual confusion of brackets and parentheses.
And XL as a grammar that is just a little bit less tiny, just enough so that you can get rid of the parentheses.
if the basic behaviour of the language is overridable at will, then it is not consistent from day to day, or from job to job.
That's already the case in any language today that has libraries provided by more than one person. Where is the consistency between C's printf, C++'s iostream and Qt's logging facilities?
XL helps you create new notations that are well suited to the task at hand. It does help you make these notations consistent or useful, not any more than a C compiler makes the name of your C functions consistent or useful.
Why on Earth is anyone going to want to override operator precedence for making a presentation?
Because it lets me define operators such as * ** and *** for bullet points, for example, so now I can write slides like this:
There are more interesting things you can do with custom notations. Here is an example using the Animate module:
import Slides import Animate
picture_slide "Page 1",
page_duration 10
[0..3, ]
color "red"
circle 300 * smooth_ratio, 100, 20
[0..3, ]
color "blue"
circle 300 * ratio, 0, 20
[0..6, 9..10]
color "green"
circle 300 * down_ratio, 0, 20
mouse_x in [0..1000]
color "pink", 0.3
rotate_z 90 * ratio
rectangle 0, 0, 300, 200
picture_slide "Page 2",
page_duration 2, "Page 1"
story
text "We'll return to page 1 shortly"
Once you have learned that Animate gives you a notation [A..B] to indicate when to do something, that the notation X in [A..B] is the same thing with arbitrary values (not just the page time), and that there are variants such as [A..B, C..D] for back-and-forth motion, it becomes really useful, easy to read and quick to write. I can't voucher for your capability to remember this notation, but it turns out this one I did not invent, yet I use it regu
There are several algorithms that are activated separately depending on: whether you draw flat text or extruded 3D text; whether there's a texture or not; the size of the font; and more. The primary ones are: render to textures and draw quads, render polygons for the outline and play that back, or extrude the outline with triangle strips. Then there are some tricks to minimize the number of triangles emitted. I also tried an approach where we rendered triangles and there was a fragment shader doing the bezier curve inside each triangle. That was surprisingly very inefficient on many low-end graphic cards, so I stashed it without going through with it.
That being said, if you want the text to look any good, you have to emit a large number of triangles for even relatively simple text. The text of the previous paragraph is 69475 triangles in Arial, 138950 when extruded, 171298 polygons in font "Amaze" not even extruded, 265636 with the font "Be safe", 561930 with font IthornÎt, and... a whopping 2171202 with Apple's "Chalkduster" font.
That still doesn't answer my question about what you think is lacking in WebGL.
1. Performance (which is getting good on desktop-class devices thanks to improvements in Javascript compilation, but still terrible e.g. on mobile devices). 2. Portability. I gave as an example the fact that using a mere GLSL shader as a background on my tutorial page made it unusable for a good fraction of the readers. 3. At the time we started, Microsoft still had the position that they would never support it. They changed their mind only last year, remember? So anybody using IE before 11 has no WebGL.
Except when it doesn't just work and you have to debug, because then what you describe as "dynamic" starts to feel like "unpredictable" and it takes far longer to work through than it should. I've only looked at a very small example, but I cannot imagine myself ever trying to teach how to program in this language. How do you teach someone to think like something with very little internal logic or consistency?
The fact that its grammar cannot be expressed as EBNF (like Ada) does not mean that it's not precise and consistent. You look at some input and at the xl.syntax file, and you know exactly what parse tree you are getting out of that input. You look at the various rewrite rules (the things given by the rewrite operator -> and you know exactly what's going to be executed and why.
Overall, the grammar is much more consistent than most other languages, if only because it's so small. As I indicated elsewhere in this discussion, scanner and parser together represent some 1500 lines of C++ code, and a syntax file that is currently 62 lines long. A complete and precise description of the core language in plain english takes about 50 pages. Compare that to the 700 pages for the C++ standard, and tell me which one is easier to teach?
If you want to look at your input in a Lisp-ish syntax, you can, there's an option in the compiler to dump the parse tree in such a format. If you build the command-line compiler for XLR, it will be xlr -parse file.xl -style debug -show. You can also try -style dbghtml to see it create HTML coloured boxes corresponding to the program structure. For example, if you have the default syntax file, input http://pastebin.com/TTbCKshW turns into http://pastebin.com/wxZX2Fc0. It's absolutely deterministic.
The additional grammar rules I mentioned earlier, e.g. the distinction between statement and expression, are there to match the way we humans read code. That's what concept programming is about.
So does this mean that Tao3D is call-by-value by default, and this explicitly breaks it to (effectively) call-by-value, rather than leaving the programmer to hack around with statics or constants and individual copies of arguments?
The locally function is conceptually equivalent to running its argument surrounding it with graphics state save/restore code. That's about it. So you can't deduce anything about call-by-value from it.
Now, to address your question in short, XL uses call-by-reference, and lazily evaluates the arguments as required to perform the call. Cases where you need to evaluate include: having to check against a type that is not "tree", comparing against a pattern, comparing for identity between arguments. For more details, see section 3.3. "Evaluation" of https://raw.githubusercontent..... You can also explicitly evaluate something with 'do'. In the 'if-then-else' definition given elsewhere, there is a 'do' for the bodies, to force evaluation of only that argument to if-then-else corresponding to the condition. If the condition is true, you only evaluate the true clause. If it's false, you only evaluate the false clause.
Maybe you never had to work in a large project where the project most productive guy did no care about indentation at all. Whitespace has a semantics for our brain, so we might as well make that consistent with the code. It reduces syntactic noise, in concept programming jargon.
Slashdot Mirror
Um ... what exactly do you need the battery for ?
How would you otherwise teleport when the martians attack and the grid is down? Plus, I think that if you have a quantum teleporter, having at least a couple of terawatts locally is basic construction code in most places.
Here is my quick list:
- 80' holographic TV with 360 channels 4D surround sound
- Two parking spots for the hovercars
- A quantum teleporter (ask for the free subscription to Andromeda Quantum Tours Weekly)
- A six terawatt home battery and thorium / fusion nuclear reactor (don't go for the cheap Tesla stuff, nuclear is what you need)
- A robosquid and a set of batteries
- Six packs of pills for instant beer
- An iPhone9 with the Apple Watch, Apple Pay, Apple ID, Apple Travel, iThink, assortment of overpriced cases, cables and chargers
- At least one DNA decoder / recoder per room
- A 65536-qbit game console for the kid
This one is somewhat specialised, but may still be worth sharing. Back then, I was working on HP ECUTEST, a refrigerator-sized machine that simulated all electrical inputs and outputs for a car engine control unit (ECU). Basically, it was "The Matrix" for an ECU: you plugged the car's brain into it, and it couldn't tell it wasn't in a real car.
The customer wanted a way to create defects on the ECU pins, e.g. short them to the ground. Problem is that an injector signal is 60 amps or so for a diesel engine, and an ignition coil signal is easily 500V. Try shorting this with a low-cost relay, and your relay gets fried pretty fast. But then, we were emitting the "cogwheel" signal that the ECU used to know the position of the engine, A pretty complicated signal in its own right, that varies in shape, amplitude and frequency as engine speed increases. Generating that signal was a story in itself.
Anyway, we wrote software that would synchronise the flipping of the relays to create defects with the rotation of the engine, so that we knew that at the moment we were switching the relay, there was little current and little voltage in the corresponding circuit. Of course, you can imagine how many relays it cost to make the stupid software work as it was supposed to. Well, actually, not that many, all things considered, but the hardware guy who had to replace the relays still cursed me whenever I goofed up.
Did a similar thing back at engineering school, with an old IBM 4341. That machine was a big time-shared computer with tons of students. Someone noticed that your account got a temporary priority bump whenever you had a screen refresh. So in order to speed up compiles and other things, we had a variety of contraptions that would hit the page-up/page-down keys to force the screen to update continuously.
There is a story I remember reading once, but can't seem to find anymore. It was about some space probe that was regularly shutting down. The space engineers finally figured out that it had lost a panel, so the sun light could enter inside and that was enough to corrupt the memory that was hit by sun rays. So NASA modified the program so that it "walk around" physical memory, copying its code and data around memory so as to avoid solar rays. I don't know if that story is true, but if it is, it looks like a good candidate to me.
The HP28C had an infrared output, e.g. For printers, but no input. a friend of mine published a book explaining how to connect an IR diode to trigger some unconnected keyboard lines in the calculator. That made it possible to upload programs to the calculator faster. Of course you also needed the matching hack on a PC to send programs. The 48 had IR in both directions.
If you are a developer and want to go beyond Powerpoint, Tao3D (http://tao3d.sourceforge.net) is a valid open-source option. It takes time to master, but it's a much more effective way to tell a complicated story.
First up, can I suggest adding the word "visualisation" to your standard blurb?
Good idea, done. It was hidden in the middle. Renaming Tao Presentations to Tao3D is similarly an attempt to avoid the misconceptions about "presentations".
I'm talking about a visual confusion. The reason I keep using the word "opaque" is that when I look at the code, the intended (semantic) behaviour is obscured.
Are you sure this has nothing to do with you not being familiar with the language?
You've suggested several times that having effectively only one syntactic structure in the language makes it more consistent, but my object with regards to consistency is precisely the contrary: that the syntactic rule is inconsistent because there is no clear mapping of syntax->semantics.
Maybe the word you are looking for is not "consistency" then. "Consistent" means there are no exceptions to the rule, which is easier to achieve when there are few rules. In C++, f(x,y) may be a macro invocation, a function call, a constructor, and there are different rules in all three cases. In HTML, the "a" tag refers to its URL as "href", but the "img" tag calls it "src". Consistency with the "real world" also matters. In SmallTalk, 2+3*5 is 25, not 17, so SmallTalk is consistent with itself (everything is an object, etc), but not with the rest of the world.
Something helped me immensely in your last post: you put a few code examples. I think that code examples help me figure out what you really mean or what you care about much better.
So ":=" is the assignment operator, but in all your examples you've sugared it over, and basically obscured the logic of your code...?
Why do you call this "sugaring over" now, and not "building an abstraction" (from your previous posts)?
The abstraction for attributes, used consistently, is: each attribute has a name from the real-world, you set the attribute "attr" with "attr value", you get the value of the attribute with "attr", and attributes apply to things that are evaluated later. Not obscure, and consistent, both internally and externally (e.g. with OpenGL).
I don't think it's more practical, because it massively less readable.If I use object.setColor("green"), it's easy to read the intended meaning.
Can't agree on that one. It's totally unreadable (ask any 10 years old kid without a deep training in JavaScript). And for productive programmers, it has the following useless characters: "object.set()".
I would prefer the abstraction object.color = "green" because getter/setter is usually implemented by convention rather than rule (leaving things open to programmer error).
There, you went down three steps down the abstraction ladder. Why not MOV $green.str0, color[object] while you are at it?
But your solution offers less clarity than either.
I have trouble arguing if you tell me that object.color = "green" is a better abstraction than color "green". It's terribly inefficient when you have multiple shapes and multiple attributes, and I have proven with rotation that it does not work for some complex attributes.
You're talking about the computer.
No, I'm talking about the abstraction level, meaning you hide what is irrelevant.
Imperative is superior to declarative only in terms of optimisability
Also in terms of expressive power, in terms of the ability to build abstractions incrementally, in terms of ... well... everything ;-) Imperative can also describe computations, tests, loops, and so on. Remember my question about how you'd represent repeated divs with HTML alone (no JavaScript)?
a declarative language should be easier to code in,
Sorry -- I'm tired and angry about various things
Really sorry to hear that. But apology gladly accepted ;-)
You'll probably hate me for saying this, but why not just write text elements in an established format... like HTML?
Now you can. But HTML is not a very good format for dynamic text. How do you represent the following with HTML?
paragraph "It is currently " & hours & ":" & zero minutes & ":" & zero seconds
zero N -> if N < 10 then "0" & N else N
I believe that the typical usage of presentations will see a lot of minor adjustment of the most PowerPoint-like elements
This is true with what Powerpoint can do. With Tao3D, when you discuss a simulation, a lot of time is spent refining the simulation.
For one thing, reusing existing collateral would be more of a cut-and-paste affair
Even without the patch above, you can copy-paste HTML into Tao3D.
the language confuses the two metaphors of series-of-commands vs collection-of-properties.
There is no confusion, there are only series of commands, although with a homoiconic language, they are also data, so you can view them as properties and make them behave like properties if you want to. The fundamental paradigm remains sequential evaluation (using parse tree rewrites in that case).
Ah... what I hadn't noticed was the lack of assignment operator in the language.
There is an assignment operator in the language. The theme getter/setter is define as follows:
theme -> "default" := T
theme T -> theme
If that's what you've done, in theory you have completed the abstraction of objects -- if the caller doesn't need to know how an object works, it shouldn't need to know that it's not changing the properties directly.
I may not have made the abstraction exactly like you wanted, but I've made abstraction more practical than in most languages. The theme "variable" could be a function, I would not know. And the theme T "setter" could do some validation or anything else, same thing, you would not know.
But without an operator, how is it obvious the difference between an assignment, a function passed as argument, a function call and a looked-up value?
The real abstraction is precisely that it is not obvious at the call site. If you have something like do_something theme, it's do_something that decides for example if it evaluates theme or not. If not, it gets the unevaluated name, and it can decide to do something with it, like using it as a prefix for a "function call".
As a developer, you should be avoiding personal taste.
That makes no sense to me. While it's a good thing to be able to fit in an existing environment, when you design from scratch, you have to make choices. And those choices are based on your own taste. Who gets to decide for you if you prefer to write runThing, run_thing(); or (run-thing) or, Knuth forbid, <thing EVALUATION_MODE="run" @ARGS[$nil]>?
That last one, while I don't like it, at least looks consistent
In the Tao3D evaluation model, they are all consistent.
at other times a bag of object properties.
This only shows that imperative is superior to declarative. You can make imperative feel like declarative, not the other way round.
If I edit the attributes of an HTML tag via javascript, it shouldn't really matter which order I edit them in -- the end result is the same.
A
It's not implicit lists. Tao3D, like Lisp, is strongly homoiconic. In other words, it's primary data structure is used both for programs and data. In Lisp, that primary structure is the list. In Tao3D, it's the parse tree. Manipulating parse tree structures is fundamental in Tao3D programming.
Now, conceptually, you can correctly think of 1,2,3 as a list. But you could as well have 1;2;3, which is also a "list", except it's built with a different infix operator.
So when I write something like:
foo X,Y -> bar X; blob Y
I'm really describing is a parse tree transform recognising a prefix foo, which matches only if the right is infix with a comma, and will split that infix into its left and right components, and call bar, then blob with the components.
I could similarly do something like that:
[A..B where C] -> A-B
and that would only match a [ ] block with a child that is an infix "where", when the left child of that infix is an infix "..".
So it's very regular. It does what other languages call function calls, operator overloading, or even macros (because that process also lets you precisely control when arguments are evaluated).
Sure. What I'm saying is that, from the numbers you've provided, your product clearly lots of room for improvement. Even with basic Latin, you're averaging 128 triangles/character for flat text!
While it's only 128 edges (not triangles, I had misinterpreted what I was counting), it was still worth investigating. And I modified the way Tao emits polygons to be more aggressive for small sizes. I also added user-controllable parameters in case the defaults are not suited for a specific use case. Code reviews and comments are welcome.
Thank you for your input.
from the information I had from you, produced 3d extruded text more efficiently.
Then you misinterpreted the information I gave you, because my point was that designer, ideographic or Arabic font have complex outlines. AFAICT, Three.js cannot use such fonts (maybe there's a trick I don't know).
What does Tao3D offer over competing products like these?
These are all great products. What Tao3D offers is:
1. It's notably cheaper, and now there's also a free software version.
2. It's a programming language. That being said, I know Ventuz can at least be scripted, not sure about the other two.
3. Stereoscopy and auto-stereoscopy are just a mouse click away. Ventuz can do some, but it was convoluted last time I checked.
4. Tao3D automatically checks if media, files, sources changed, and reloads them. Great for remote-controlled updates.
5. No need to import media, Tao3D uses media in place (that used to be an issue in Ventuz and Aurora3D, not sure if that's still true).
In a sense, Tao3D is to these tools what a web browser is to Powerpoint: open, extensible, flexible, but harder to get started with. And in this analogy, we see the web-based interface in Tao3D as the equivalent of Wordpress, i.e. a solution to separate concerns between editors, page designers and media content producers.
Does that make sense?
Ah, I missed your point completely in the GP. Sorry.
The problem it addresses is the complexity of creating the simplest 2D or 3D scripted animation, and how this process does not scale or compose well.
Here are a few random examples:
* Create Christmas card pictures for all my friends that are automatically tailored for each of them.
* Display fragile objects in a museum, photographed in 3D (or scanned), shown in 2D, in 3D or in glasses-free 3D
* Display complex data or simulations for a scientist, in a way that can be explored interactively or shown at conferences.
* Teach about fractals by showing interactive models of various fractals.
I'm conscious that with enough effort, some of these can be done with other tools. The purpose of Tao3D is to reduce the effort manyfold.
Sorry about that. Bug in the packaging script. Should be fixed now.
I don't see the lambda calculus in your example.
There was none, indeed. In reality, Tao3D is based on tree rewrites, not lambda calculus.
I'm exploring a bit here what the implications are. Quite frankly, the type system as implemented is totally incomplete and still largely broken at the moment. I understood what needed to be done after 5 years of experimentation, and never got the time to actually implement it. Similarly, the language reference describes a runtime environment for functions, how closures and symbol tables are defined, etc. I prototyped this and got a basic compiler half working, so I know it will work. But the symbol table in Tao3D is a more ancient design, in C++, not visible to the program.
That being said, there are "anonymous tree rewrite" notations very similar to lambda calculus. For example, here is how you can draw an almost convincing Christmas tree:
color "darkgreen"
foo with (X -> 3*X^2+7) with 1..8, 2..4
foo R ->
rectangle 0, 0, R, 18
translate_y -20
The with operator here implements a map, i.e. we apply foo with the result of an anonymous rewrite (that's the "lambda") with a list made of values 1 through 8 and then 2 through 4.
The filter operation is implemented with another syntactic form:
foo with (X where X mod 2 = 0) with (X -> 3*X^2+7) with 1..8, 2..4
There's also a reduce operation, but it crashes the compiler at the moment, need to see why:
foo (X,Y->X+Y) with (X where X mod 2 = 0) with (X -> 3*X^2+7) with 1..8, 2..4
With my computer, a code editor, and the (easily accessible) documentation. It took about 10 minutes.
I meant: you probably have some code that looks like:
var geom = new THREE.TextGeometry(T, { size : S, height: H, curveSegments: CS, font: F });
I was interested in the parameters to that code.
That statement is either completely false or incoherent. Care to give it another go?
Unless you are rendering bitmap fonts, at some points, your glyph outlines are first rendered to the texture. It may be 2D, chances are it's still done by the graphic card on modern systems.
Sure. What I'm saying is that, from the numbers you've provided, your product clearly lots of room for improvement. Even with basic Latin, you're averaging 128 triangles/character for flat text!
Actually, you are right, the code I quickly implemented was counting the array elements, not the polygons. So, roughly, the number of edges, but counting terminating edges in triangle strips multiple times. My bad. I guess I'm getting tired. The point I was trying to make remains valid: some real fonts (as opposed to the toy fonts in Three.js) quickly generate huge amounts of polygons.
As another illustration of my point about WebGL, I can see the Three.js geometry / text example on my iPad, but not on my iPhone 4 or my Android tablet. Maybe you are more lucky with your BlackBerry...
I'm still not convinced the project offers anything over existing solutions.
I'm sorry I did not convince you. But Tao3D does offer a lot over existing solutions.
First, Tao3D is the only practical solution I know for delivering interactive 3D animations, simulations or presentations quickly. What you can do with Tao3D in 25 lines of code is nearly impossible today with Three.js: no support for real TruType fonts, no text layout for 3D meshes, no RTL text support, etc. And I'm just talking about text here. We can do full slides in 3D with 25 lines of code when Three.js is barely capable of doing one line of text in 600+ lines of code at the moment, and then only with relatively serious 3D programming. Tao3D requires 24 times less lines of code. And you say we bring nothing new?
That brings me to the second big contribution. Even if you add text layout features to Three.js, you will still be working at the wrong semantic level, talking about meshes and renderers and such. Again, someone might work this out the way Reveal.js attempted to do for slides. But Tao3D does this today. Today, with Tao3D, you talk about "slides" and "paragraphs" and "color", because that's what you care about.
Finally, a third innovation in Tao3D (though not in the libre edition) is transparent support for practically every stereoscopic or auto-stereoscopic screen under the sun. So you can playback 3D movies without glasses, superimpose 3D text and logos, etc. In the digital signage space, Tao3D brings glasses-free 3D screens at feature parity with 2D screens. And that's also a pretty significant contribution.
I can understand your need to defend it against any and all criticism, real and perceived
Not any criticism. Against uninformed criticism, of which there is a lot on Slashdot, unfortunately.
How is your startup going? What markets have you found the most success? Where do you see the product in the future?
I noticed your "failing" startup comment earlier, don't worry. Like any startup, not enough cash, too many ideas, not enough people, too many things to do, not enough time.
Our current markets include exhibitions, e.g. tr
Just to clarify, the poly counts I gave were actual triangles processed by the card when disabling texture-based rendering in Tao3D. This is the only case that always works, so it's both the fallback scenario and the worst case scenario. Therefore, that's the one I'm most interested in.
Not extruded? Why not render the text as a texture and slap it on a triangle strip?
Obviously, Tao3D does that when that's possible.
Why not render the glyphs as a large texture and make clever use of UV's?
Tao3D also does that when it makes sense.
(You'd use more triangles, 2 per character
Hmm, how do you draw a glyph with only one triangle per character? Or do you mean that we can use two triangles for multiple characters? We also can store full words in the glyph cache. But currently, we only use that for languages with ligatures such as Arabic.
but that's still way fewer than the approach you're using.
May I suggest that you should study how the Tao3D code works a little more before being so dismissive ;-)
You might also want to look at other, clearly more efficient, solutions. Take a look at three.js's ShapeGeometry. and ExtrudeGeometry -- A quick test shows great quality, with far fewer triangles.
Quick test with what? How did you create a text mesh with Three.js to start with?
Furthermore, as soon as you extrude, you need true polygonal rendering. You can't draw on a texture and render quads or two triangles as you suggested. Or if there's a way, I don't know it. So you end up with roughly the number of polygons in the base glyph x N, where N depends on extrusion parameters, e.g. if you create a bezel or not, if you round the bezel, and so on.
That being said, if you want the text to look any good, you have to emit a large number of triangles for even relatively simple text.
On the basis of my experience, I strongly disagree.
Would you please be kind enough to share your experience? That's a hot topic for me.
First, I'd like to point out that even if you can do texture-based rendering, you still need to first render to a texture with polygons or, alternatively, with triangles and a shader doing the Bezier fill.
Let's deal with two cases here. The first case is when texture-based glyph caching applies. In that case, polygon count is rarely a problem for alphabetic languages. For ideographic languages, or languages with ligatures such as Arabic, the chances of finding what you need in the glyph cache are lower, but you can still assume you will draw the same text several frames in a row, so that's still a net win. The animation may skip a bit when the text changes though... So basically, the glyph polygon count defines the worst case "skip" you can get. And westerners don't care, since they use a Latin alphabet with an appropriately low number of glyphs. So in general, we can reuse entries in the glyph cache.
Second case is when you can't use textures. Extruded 3D text is one scenario, that's hardly the only one. Then, you need true polygonal rendering. And the number of basic triangles you had for the front face is multiplied by N, which depends on the shape of the extrusion path (bezel, rounded bezel, etc). Plus this time, you need to render the polygons at every single frame, so polygon counts start playing a big role in performance.
In all cases, even with an curvature-dependent algorithm, you still need a decent number of polygons per glyph or any non-basic font looks like crap. I think the best you can do is something like one triangle per Bezier curve in the glyph (un
Thought for the day: whenever designing something for other people to use, you should take all feedback from your potential users and prove to yourself why the feedback is correct before attempting to show the giver why it's wrong.
Oh, I got it backwards then. I thought you had been trying to prove me wrong all that time... Sometimes, you were right (e.g. black characters on black background). Sometimes, you've made a good point (e.g. align_vertically). Sometimes, I feel your point is less convincing (glTranslate and glColor). Sometimes, I think you are plain wrong (global state is evil), and I express disagreement. That's how a discussion goes. I enjoyed it, sorry to hear that you did't seem to.
if your default response is to prove to everyone that their feedback is so valueless to you
If it felt so valueless to me, do you think I'd still be watching for your answers and typing this in the middle of the night? I don't claim to be perfect. Please reciprocate.
Exercise for you: go **** yourself. That's just patronising.
No, that's trying to help you become an early contributor. I would not have spent the time locating the exact line to patch otherwise. Remember, open source is about you and others being able to influence Tao3D. But since you obviously don't want to do it this time, I patched it myself. Your name in lights, tadaaa.
If we were just talking about text flow in a 2D page, I would agree with you
Well, text layout is still done in a 2D text box. So align specifies the horizontal alignment and justification within a line (the frequent case), and align_vertically the alignment and justification of the lines and paragraphs vertically.
I understand that, but it's wrong. I know a lot of people laugh at the idea of using setColor and getColor as per so many OO style guides, but really, you either need to use assignments or use verb-based names, or the syntax is broken from a human cognitive perspective
It's an interesting point. Tao3D actually went the other way. A setter and a getter for a property typically have the same name. So to adjust the stereoscopic effect, you can say something like eye_distance 20, and that adjusts the property you get with eye_distance. To get the current theme of a slide, you use theme, and to set it theme "Master". I personally see the 'set' and 'get' in that case as noise. But I will admit it's a matter of personal taste. I hope you will understand that Tao3D reflects my tastes and not yours.
At the limit, we began implementing (but never finished) a system of properties named x, y, width, top and so on for coordinates. You could then use any of the following three, to your liking:
rectangle 10, 20, 30, 40
rectangle { x 10; y 20; width 30; height 40; }
rectangle { left -5; y 20; width 30; bottom 0; }
x 10; y 20; width 30; height 40; rectangle
Much like for color, the last one would also set the properties in a persistent way for following shapes to use, much like color or texture today. This means you would then be able to say something like left 20 to left-align a bunch of shapes. It's not done yet, but still in the plans.
They are broken. If you aren't willing to fix the real problems with languages, why write a new one in the first place? Why not just write a library?
I find your use of bold font and "broken" quite antagonistic to your statement that two people can be correct at the same time. You call this a real problem with languages. I just don't see it. Specifically, I don't see color "red" or glColor as broken. In doing so, I'm not saying that you are w
I don't like subroutine names that include something that looks like a parameter, so things like rotatex and rotatey set me on edge a bit.
If you prefer, you can use the plain rotate. But rotating along X, Y or Z is frequent enough to deserve a shortcut. Not different from CSS transform, by the way.
It gets worse when this is inconsistent, and you see a subroutine called vertical_align for vertical alignment, where the seeming parameter (vertical) is now before the generic (align), and separated by an underscore instead of run together. Not only is this an internal inconsistency, but it's inconsistent with English, as "align" is a verb, and we would put in an adverb "vertically" after the verb normally. And then it gets worse again, as the command for horizontal alignment is... "align".
You are right, align_vertically would be more sensible. Exercise for you: fix it ;-) As for align, that's the common case, so I'd rather keep it that way.
The grammatical inconsistency continues with other commands/subroutines taking on names with no verb component at all (eg the command color, with no verb or assignment operator.
That derives from OpenGL, which has glRotate and glTranslate, but glColor and not glColorize. BUT it's not inconsistent. It's actually fairly smart. The color is an attribute, and glColor just sets it. So the name is the name of the attribute you set. glRotate and glTranslate modify an attribute (the current model/view matrix), so they are verbs. Unwittingly, I applied the same logic for things that change the color state, e.g. show. Since show changes the color state, it is a verb.
I'm really not happy with the way pattern matching is used as overloading ...because you can get yourself in a mess if you split it up into different parts of the code and accidentally overwrite stuff.
How is this different from overloading? That's a FUD argument. In reality, its distributed nature is exactly what makes the construct powerful. It offers a very flexible dynamic dispatch mechanism.
For example, the Slides module draws a background for slides using theme_background. That function is provided by the default theme. But most themes will override it.
In general, this override happens only on part of the pattern. For example, most slide elements are defined by (theme, master), sometimes (theme, master, style). The "master" is the equivalent of the Powerpoint "slide master", i.e. it defines the layout, etc. If you define a new theme, you'll typically define overrides that catch everything for a given theme (e.g. for "BrightRectangles" in the last link). But you may also want to override for a specific combination.
I'm completely baffled why the whole demo recreates the shapes for every single redraw frame rather than keeping them as persistent objects (which necessitates adding a random seed in order to fake them being persistent by pulling up the same colours each time.
The Tao3D drawing model is a feature, not a bug. If you write rectangle 0, 0, 320, 200, it draws the rectangle once, and that's
Suddenly you have to look in dozens of different places to verify what the most basic features of the language are.
Not really. The parsing is defined by xl.syntax, a file that currently contains 62 lines, so it's not complicated. The semantics, on the other hand, comes from libraries, including some that are built-in. In the case of base XL, the library components implemented in XL are in builtin.xl, and the components implemented in C++ are in basics.tbl.
But XL and Tao3D put way more in libraries than regular languages. Remember when we moved from BASIC to C? In BASIC, the 'PRINT' statement was a keyword. In C, 'printf' was a library routine. I argue that the C approach is superior. So of course, an exhaustive catalog of C libraries today is a bit difficult. And there are inconsistencies. But it's still superior.
Lisp has a tiny grammar and a small standard, and that leaves us buggering about with a visual confusion of brackets and parentheses.
And XL as a grammar that is just a little bit less tiny, just enough so that you can get rid of the parentheses.
if the basic behaviour of the language is overridable at will, then it is not consistent from day to day, or from job to job.
That's already the case in any language today that has libraries provided by more than one person. Where is the consistency between C's printf, C++'s iostream and Qt's logging facilities?
XL helps you create new notations that are well suited to the task at hand. It does help you make these notations consistent or useful, not any more than a C compiler makes the name of your C functions consistent or useful.
Why on Earth is anyone going to want to override operator precedence for making a presentation?
Because it lets me define operators such as * ** and *** for bullet points, for example, so now I can write slides like this:
slide "Example",
* "First level bullet"
** "Second level bullet"
There are more interesting things you can do with custom notations. Here is an example using the Animate module:
import Slides
import Animate
picture_slide "Page 1",
page_duration 10
[0..3, ]
color "red"
circle 300 * smooth_ratio, 100, 20
[0..3, ]
color "blue"
circle 300 * ratio, 0, 20
[0..6, 9..10]
color "green"
circle 300 * down_ratio, 0, 20
mouse_x in [0..1000]
color "pink", 0.3
rotate_z 90 * ratio
rectangle 0, 0, 300, 200
picture_slide "Page 2",
page_duration 2, "Page 1"
story
text "We'll return to page 1 shortly"
Once you have learned that Animate gives you a notation [A..B] to indicate when to do something, that the notation X in [A..B] is the same thing with arbitrary values (not just the page time), and that there are variants such as [A..B, C..D] for back-and-forth motion, it becomes really useful, easy to read and quick to write. I can't voucher for your capability to remember this notation, but it turns out this one I did not invent, yet I use it regu
For the algorithms, I'll let you look at the code :-) It's mostly in path3d.cpp, text_drawing.cpp and glyph_cache.cpp.
There are several algorithms that are activated separately depending on: whether you draw flat text or extruded 3D text; whether there's a texture or not; the size of the font; and more. The primary ones are: render to textures and draw quads, render polygons for the outline and play that back, or extrude the outline with triangle strips. Then there are some tricks to minimize the number of triangles emitted. I also tried an approach where we rendered triangles and there was a fragment shader doing the bezier curve inside each triangle. That was surprisingly very inefficient on many low-end graphic cards, so I stashed it without going through with it.
That being said, if you want the text to look any good, you have to emit a large number of triangles for even relatively simple text. The text of the previous paragraph is 69475 triangles in Arial, 138950 when extruded, 171298 polygons in font "Amaze" not even extruded, 265636 with the font "Be safe", 561930 with font IthornÎt, and ... a whopping 2171202 with Apple's "Chalkduster" font.
That still doesn't answer my question about what you think is lacking in WebGL.
1. Performance (which is getting good on desktop-class devices thanks to improvements in Javascript compilation, but still terrible e.g. on mobile devices).
2. Portability. I gave as an example the fact that using a mere GLSL shader as a background on my tutorial page made it unusable for a good fraction of the readers.
3. At the time we started, Microsoft still had the position that they would never support it. They changed their mind only last year, remember? So anybody using IE before 11 has no WebGL.
Except when it doesn't just work and you have to debug, because then what you describe as "dynamic" starts to feel like "unpredictable" and it takes far longer to work through than it should. I've only looked at a very small example, but I cannot imagine myself ever trying to teach how to program in this language. How do you teach someone to think like something with very little internal logic or consistency?
The fact that its grammar cannot be expressed as EBNF (like Ada) does not mean that it's not precise and consistent. You look at some input and at the xl.syntax file, and you know exactly what parse tree you are getting out of that input. You look at the various rewrite rules (the things given by the rewrite operator -> and you know exactly what's going to be executed and why.
Overall, the grammar is much more consistent than most other languages, if only because it's so small. As I indicated elsewhere in this discussion, scanner and parser together represent some 1500 lines of C++ code, and a syntax file that is currently 62 lines long. A complete and precise description of the core language in plain english takes about 50 pages. Compare that to the 700 pages for the C++ standard, and tell me which one is easier to teach?
If you want to look at your input in a Lisp-ish syntax, you can, there's an option in the compiler to dump the parse tree in such a format. If you build the command-line compiler for XLR, it will be xlr -parse file.xl -style debug -show. You can also try -style dbghtml to see it create HTML coloured boxes corresponding to the program structure. For example, if you have the default syntax file, input http://pastebin.com/TTbCKshW turns into http://pastebin.com/wxZX2Fc0. It's absolutely deterministic.
The additional grammar rules I mentioned earlier, e.g. the distinction between statement and expression, are there to match the way we humans read code. That's what concept programming is about.
So does this mean that Tao3D is call-by-value by default, and this explicitly breaks it to (effectively) call-by-value, rather than leaving the programmer to hack around with statics or constants and individual copies of arguments?
The locally function is conceptually equivalent to running its argument surrounding it with graphics state save/restore code. That's about it. So you can't deduce anything about call-by-value from it.
Now, to address your question in short, XL uses call-by-reference, and lazily evaluates the arguments as required to perform the call. Cases where you need to evaluate include: having to check against a type that is not "tree", comparing against a pattern, comparing for identity between arguments. For more details, see section 3.3. "Evaluation" of https://raw.githubusercontent..... You can also explicitly evaluate something with 'do'. In the 'if-then-else' definition given elsewhere, there is a 'do' for the bodies, to force evaluation of only that argument to if-then-else corresponding to the condition. If the condition is true, you only evaluate the true clause. If it's false, you only evaluate the false clause.
Semantic whitespace makes me sad. :-(
Maybe you never had to work in a large project where the project most productive guy did no care about indentation at all. Whitespace has a semantics for our brain, so we might as well make that consistent with the code. It reduces syntactic noise, in concept programming jargon.
I put the sample code on http://tao3d.sourceforge.net/ closer to the beginning. Hope that helps.
That being said, people don't seem to like the "Reveal.js" form factor too much overall. I may have to change that.