fexl

I love C but I use it in a disciplined way. Here's the email I sent to the author:

James:

I liked your article on range checking.

I'm very keen on assertions, for example here:

https://github.com/chkoreff/Fexl/blob/fresh/base/src/buf.c#L...

It's still fast as greased lightning. I buffer up 2.6 MB here:

https://github.com/chkoreff/Fexl/blob/fresh/test/src/run.c#L...

It's too fast to notice. I can bump it up to 260 MB and try that:

  $ ./build && time ../bin/run
  : Buffering 260000000 bytes
    length = 260000000

  real	0m1.751s
  user	0m1.608s
  sys	0m0.140s

What the heck, let's try an even 2 GB:

  $ ./build && time ../bin/run
  Compile run
  Link run
  : Buffering 2000000000 bytes
    length = 2000000000

  real	0m13.350s
  user	0m12.049s
  sys	0m1.288s

Ah, but what if I remove my range check?

  $ ./build && time ../bin/run
  Compile buf
  Link run
  : Buffering 2000000000 bytes
    length = 2000000000

  real	0m13.103s
  user	0m11.781s
  sys	0m1.312s

Repeated testing of both ways shows no significant difference.

I think I'll leave in the range check.

Range checks also support one of my favorite programming maxims:

  No Silent Failure!

I've been doing the 135-degree thing for many years, much like the picture there, but without the foot rest. I make sure to squirm around on occasion, and I get up and stretch and walk with the dog regularly. So far so good.

"You can't discriminate based on race - that limits choice but who would support the contrary?"

If someone refuses to serve or otherwise interact with me on account of my race, I would not use the threat of deadly force to change his behavior, nor would I advocate that anyone else do that on my behalf.

That is not to say that I approve of racial discrimination, or that I would do absolutely nothing about it. I am only stating what I would not do about it.

I couldn't take the new Cosmos. It's heavy on special effects and light on content, which is delivered in a breathless style that makes me feel like I'm on a third grade field trip.

The old Cosmos, with Carl Sagan, was fascinating. I was mesmerized watching Carl sitting there with pen and paper explaining the Drake equation, or listening to him explain the history of the library at Alexandria and the murder of Hypatia.

All the "wondrous" CGI-enhanced pablum of the new show leaves me cold.

When I visited Sweden I spoke with a friend there who had been born and raised way up in the north of Sweden. He said the people there would bury and ferment all sorts of things, including seal meat, whale blubber, and birds sewn into seal skins. I can understand how such a tradition would arise, as an effective way to store food in the wild safe from predators, though it's hard to imagine digging that up after six months and chowing down on it.

Good question. I go with -O3 because it does even more optimizations, but to be quite candid I really don't know what impact -fpredictive-commoning, -ftree-vectorize, and others have on my resulting machine code, if any.

I did a quick experiment, compiling one C file with -O2 -finline-functions and another with -O3, using the -S flag so I could see the assembler output.

The only difference I saw was this:

  .comm	free_list,8,8

Versus this:

  .comm	free_list,8,16

Who knows. I guess I'm really using -O3 because "3 is more than 2" -- in other words, "Ours goes to 11!" :)

Agreed, see my post above about -std=c99.

I tend to go with:

  gcc -c -Wall -Werror -std=c99 -pedantic -O3

I use -std=c99 because I use these two features of C:

1. Mixed declarations and code, e.g.

  double x = 4.8 * 5.3;
  printf("x = %.15g\n", x);
  double y = 8.7 * x;
  printf("y = %.15g\n", y);

2. Flexible array members, e.g. for my safe string operations:

  struct str 
      {       
      long len;
      char data[];
      };

If I were to use -ansi (same as -std=c89), instead of -std=c99, then -pedantic would give me these errors:

  error: ISO C90 forbids mixed declarations and code [-Werror=edantic]

  error: ISO C90 does not support flexible array members [-Werror=edantic]

(By the way, I have no idea why the error message omits the "p" from pedantic there. That doesn't smell right. I hope the gcc people fix that.)

I use -O3 for optimization, and I chose level 3 because that enables -finline-functions. I typically avoid macros, even for simple one-liners like this:

  /* Increment the reference count. */
  void hold(value f)
      {
      f->N++;
      }

With -finline-functions enabled (via -O3), I can see that function being expanded inline, by examining the assembly output of gcc -S -O3.

It's possible. I'm wary of anything from Google.

Yeah, though I refactored their code to avoid the "goto", as an exercise. It would indeed facilitate making separate functions for common swaths of code, notably the duplicate code blocks beginning with ReadyHash and ending with SSLHashSHA1.final. Exactly as I said, goto makes it harder to refactor code.

A few days ago I wrote up something on this same issue:

http://fexl.com/goto-considered-harmful

However, after discussing the issue on the cryptography mailing list, I realized that the really serious problem here was not the use of goto itself, but the lack of an obvious test case.

Clearly Apple did not have a single test case which made the SSLVerifySignedServerKeyExchange function call sslRawVerify. Since the whole point is to call sslRawVerify, this is an astounding omission in testing.

The "goto fail" pattern is common throughout OpenSSL. I of course think OpenSSL stinks to high heaven, but for reasons not directly related to "goto". I do think the use of "goto" gives off a bad "code smell" though.

I myself never use goto. When I'm writing code, I always create "if" or "while" blocks and then fill them in. It never even occurs to me to use goto.

My main objection to "goto", aside from the spaghetti code which might arise from it, though not necessarily, is that goto makes it difficult to refactor code.

Normally it's pretty easy to move a chunk of code into a separate function. However, if that code contains "goto", then you're pretty much stuck until you factor out the goto.

Looks like yet another dependency that I'll have to build from source code, and test, fix, and refactor myself.

Good point. Particularly interesting because you are suggesting an inverse correlation between work hours and wealth. Can you point me to some evidence for that?

I might expect some sort of parabola, e.g. people who work very few hours tend to be less wealthy, and people who work too many hours tend to be less wealthy, but people who work at the "sweet spot" in between are the most wealthy. But an actual negative linear correlation? I wouldn't expect that.

He wants to ban the use of a public ledger with private and public keys.

Yeah, should be "leery", as in "The clear ends of FRNs for either transacting in illegal goods and services or speculative gambling make me leery of its use."

I bet if he had redirected the output to /dev/null it wouldn't be slower with 'B'.

And no BASE jumping either.

I've taken to defining "@" as the Y combinator, so it looks kind of like a "goto" label for looping, e.g.:

  (@\fact\n \n==n <= n 0 1 (* n (fact (- n 1))))

(The \n==n forces an eager evaluation, to avoid building a tower of deferred operations with large n.)

The symbol "fact" is arbitrary, e.g. you could say this instead:

  (@\loop\n \n==n <= n 0 1 (* n (loop (- n 1))))

To define a name "fact" for that function, it's:

  \fact = (@\loop\n \n==n <= n 0 1 (* n (loop (- n 1))))

I did see that comment. However, I was addressing Mr. Watt's conclusion from the story: "What this means then is that money is nothing but bookkeeping."

I disagree. What that story means is that the people were left holding paper certificates worth exactly nothing.

It is true that before the loss of gold was discovered, each individual who received a certificate and then spent it suffered no loss.

He did suffer a loss upon receiving a certificate, but he didn't know it because nobody knew the certificates were worthless. He then suffered an offsetting gain when he spent the certificate.

All along the way, people were suffering losses and transferring those losses to others. They just didn't know it was happening.

Similarly, you might receive a counterfeit $100 bill and not know it, and then spend it at a store successfully. Only the poor sap who discovers that he holds a counterfeit and consequently decides not to spend it loses in the end.

I doubt the loss of gold would devastate that economy. Some people holding large quantities of the worthless certificates would indeed be personally devastated. However, I would expect that the wealth of that society would already vastly exceed the value of the lost gold, since the people would no doubt be the owners of other physical commodities, capital equipment, trade secrets, and other forms of value.

Gold, like any form of money, does not have to exist in an amount "equal to" the amount of (other) wealth in a society. That's an infantile notion. A single piece of money can be traded thousands of times per second, and can support far more economic activity than its face value would suggest. Money is traded at the margin.

Therefore I agree that the loss shouldn't gum up the entire economy forever, though it could be very stunning and painful until the people recovered from their very real losses.

In the South Pacific island story, when the gold was lost, the money was lost. That was a loss of a physical substance with a unique combination of specific physical characteristics. If it had been silver, copper, platinum, rhodium, or iron, I doubt they would have said "Oh well, we didn't really lose anything." The loss was real.

Some say that gold is useless, but I find it hard to imagine that any substance which is so durable, ductile, malleable, divisible conductive, rare, pretty, non-corrosive, and non-reactive could ever be "useless" to human beings. For example, it is excellent for electrical conductors in a salt water environment. Human beings have also found that those same physical characteristics make it useful as money.

There is no irony in expending effort to dig it up and then putting it back underground in vaults. That's because it is more useful in the form of bars than in the form of raw ore.

Sure, that makes sense. Wow, I didn't know it was cystic fibrosis.

I like your comment about the medical care that you two are "supposed to require." :)

Keep up the good work. You'll be more independent when you stop depending on food stamps, but you're on your way. Also, I recommend ordinary reusable cups instead of plastic disposables.

Why the downvotes on onion's comment? I don't see anything factually incorrect about it.

I love the goat-herding idea, but here's something that may help you short of taking such a big step. Grab a plastic garbage bag, and go walk two miles out along a road, and then on the two miles back, pick up all the garbage you can.

(It's not a solution to all your problems, it's just an experiment to see how it affects your consciousness.)

15 years of Perl and I just now learned about the yadda-yadda ... thanks!

Nevermind, I figured it out. I did Export some certs from Chromium and Import them into Firefox, but it wasn't working. However, when I restarted Firefox, it worked.

By the way, I looked in the list of trusted root CAs in Chromium, and I didn't see anything called "Positive SSL CA 2" there. If I had seen it, I could have just exported it from Chromium and imported to Firefox.

The purpose of any computer program is to produce side effects. A program which has no side effects has no observable behavior and is therefore useless. In that sense, side effects are good, so embrace them.

That implies that the purpose of a functional program is also to produce side effects.

The only problem with side effects is managing them properly. Side effects can become tangled and conceptually incoherent. Functional programs can help manage side effects.

For example, if I call (draw_line P1 P2), I expect a line to appear on the screen joining points P1 and P2. That is a side effect.

As a simpler example, if I call (say "Hello"), I expect the line "Hello" to be output to my terminal. That too is a side effect.

Those are good side effects.

The way I like to encapsulate side effects in a functional language (such as Fexl, a language which I wrote), is to use closures. Take your mutable data, and bury it inside a closure.

If you object to closures (pun intended), then think again. If you're a C programmer and you write printf("Hello\n"), you are in effect using a closure. How? Because stdout is effectively buried inside printf -- i.e. you don't have to pass it as a parameter.

If I saw (draw_line P1 P2), I am using a closure. How? Because most likely some X window gadget is buried somewhere down inside draw_line.

Fexl does provide a "var" construct which is a mutable variable. Pure functionalists might object to that. But why? The X window gadget is a variable. Your screen memory is a variable. All the memory in your computer is a variable. The buffer for stdout is a variable. The whole world is a variable. Stop fighting it.

I would prefer to avoid using "var" in Fexl, and aim toward pure functions, but sometimes that's ridiculous. For example, what if I wanted to simulate the behavior of draw_line, so instead of it going into an X windows gadget, the effects get stored in memory so I can use them differently, maybe for testing.

In that case I might use a var which simply collects all the draw_line and other graphic commands into a big list.

So let's stop fighting side effects and learn to embrace them, and recognize the value of functional languages in managing those side effects rationally.

Nice discussion of branch prediction there!

Does anyone know how to disable TLS 1.0 in Firefox 26.0 (on Linux)? I found this article:

http://www.spotht.com/2010/06/how-to-enabledisable-ssl-30-an...

However, the Options in my browser do not include a tab called "Encryption", as the article discusses.