Show HN: Servasm – Literate web server in x86 assembler

[ed: I feel I should preface this to say that this is very old code, and something I'd normally show to anyone. But since you asked... :-) ]

Unfortunately it looks like the code that was the best (worst) example of what I'm talking about isn't readily available (I have it some backup-archive or other...) -- and my other code is partially restructured based on what I learnt, and most significantly in Norwegian.

However, one example, while not breaking the function-gap, is a small sub-section from the noweb document that reads (this is java 1.4):

  <<src/AllTests.java>>=
  import junit.framework.*;
  import junit.extensions.*;

  public class AllTests extends TestCase
  {
    public AllTests(String name) 
    {
       super (name);
    }
	
    public static void main(String[] args) 
    {
       junit.textui.TestRunner.run(AllTests.class);
    }

  <<testSucceed>>
  <<testTabell2D>>
  <<testBrikke>>
  }

And the testSucceed-section is just a simplistic sanity check to make sure tests can be run/pass:

  <<testSucceed>>=
  /** Testing the test harness */
  public void testSucceed() throws Exception 
  {
    assertEquals(10, 10);
  }

These two blocks, the test setup, and the meta-test go together in a neglected corner of the document, given only a little more priority than the build.xml-file -- while the more functional tests are moved close to the various interfaces (in this case) they are testing (rather than having them too close to the implementations they're actually testing).

So one could say that this gives us injection without an injection framework. Or something. This is basically fixing a naming issue in java, where you need methods to be bound to a class (except for static stuff etc) -- and is an "abstraction free" (at the language level) way of moving things that go better together -- closer together.

Note that the blocks pretty much lacks comments, as they are a bit gnarly to get to work with both java and noweb and javadoc -- but that is more of a tooling issue than anything else.

In this case (imagine 10s of test cases) the tests might be a bit under-documented when seen in isolation. Note that each block actually holds a couple of test-cases applicable to whatever class/interface-pair it tests.

But it gets even more interesting when you're sharing a block of code that implements a binary search on an array-like structure... does make it a little too easy to trip over local variables though.

The full code (in Norwegian) is at: http://folk.uib.no/st05861/inf101/oblig1/ -- it's not very good, but the noweb source and pdf (oblig1.nw, oblig1.pdf) might be of some very limited interest -- and could be contrasted with the java code under src.

This is all from an entry level programming course, the task was given as a pdf-document with some specs and a few stub interfaces -- the resulting pdf essentially interleaves the questions/specs as given, along with the interface stubs -- and builds up answers to each sub-section/point.

The other code I mentioned was more along the lines of implementing binary search for a an array-like interface etc -- basically Abstract Data Structures.

> My version of literate-programming may have a bit too much possibility of that magic.

To be honest, that was (part of) my initial reaction. But at the same time, playing with noweb, reading a bit of literate C etc -- I think some tooling on the literate side can be good. Sometimes one wishes for too much, and too late realize that the beautiful unique snowflake of a poem one has wrought is, while splendid in its simplicity, as brittle and hard as ice.

It just not something one will be entirely comfortable handing over to someone else to modify -- because even if they could figure out what it did, they'd be hard press to modify it in any meaningful way. Too dense isn't very good either.

Sometimes I think that literate programming and APL stand at opposite corners of some kind of 2d graph of program complexity/simplicity (not necessarily diagonally opposed). I'm not entirely sure what would be in the other corners.

I came across your blog post, and I think we are in agreement on a lot of things:

http://jostylr.tumblr.com/post/83304256984/architectural-fog

But I also think a very real problem with literate programming (to quote Knuth?) is that it demands people to be both good (technical) writers and good programmers. Some are both - more are one or the other.

I think the best way to get a simple, yet featureful literate programming system, is to combine a simple markup language, like RST/Markdown/etc with a language that lends itself to be pulled apart and rearranged. I think something simple, like Smalltalk might be a good candidate.

So far the only real literate programming I do, is with doctests in python -- and to a lesser extent, ipython notebooks.

I remember I looked at Leo: http://leoeditor.com/ -- and have been toying with moving from vim to Emacs+evil partially for the benefit of org-mode -- but these still feel like very heavy solutions to something that I feel should be a rather simple problem. That feeling might be wrong, though.

Another tool I've come across (which might be abandoned, I'm not sure) is: http://pywebtool.sourceforge.net/

Regardless of the state of the tool itself, the page has some interesting points on literate programming.

I must admit, getting something like proper LaTeX typsetting of the code is nice though. I'm still looking for a tool that doesn't botch up the (La)TeX conversion and html+css conversion of simple RST/md-documents -- it seems everyone tries to be way too clever, and bundle the weirdest little themes/template leaving one to pick apart everything just to get some straightforward html/TeX. Not to mention trying to output HTML from (La)TeX.

At least for html output we now have a few half-decent alternatives thanks to everyone writing a static blog engine. And pandoc. Pandoc is great.

I am well aware of the potential advantages of such operations. And the difficulties associated with trying to use them well and identify when they can be an advantage.

However, just because something is useful does not preclude it from being esoteric.

In particular, there are an astounding number of such miscellaneous and less-often-used instructions in x86 and extensions, and trying to remember which ones exist, and which ones have which limitations, is... a fair feat. Hence, esoteric. Understood only by a few with special knowledge or interest.

No, C does not expose a 1:1 mapping to assembly in any architecture, at -O0 or otherwise. To give one simple example, the C pointer types correspond to nothing meaningful in any commonly used ISA.

Android mobile browser requires the full signature chain of authorities who signed the site certificate[0]. It is done to avoid calls to CA servers and reduce network use on mobile devices.

If a person does not concatenate authorities signatures to their site certificate, Firefox and mobile Chrome will alert, desktop Chrome and Safari won't.

[0] https://en.wikipedia.org/wiki/OCSP_stapling