autotelicum

Good constructive feedback. I thought about it, so one of the next days when I get time, I'll add a little 'Limit Width' button up on top. It'll be freeflow by default, but just one click for those who prefer a narrower format.

Of course. It started with a pdf/lyx version based on the 400Kb eloquent text file, now the tools (elyxer) made it possible to convert to html with some manual fixes. It would be great to add interactivity next. Not sure when next will be though...

Thanks. I will look into what more I can do tomorrow with the Readability and Kindle documentation, maybe some tweaks to CSS or something.

I made this version. It would be great with 'Pull Request's with the kind of improvements that is being suggested here. The source is at https://github.com/autotelicum/Smooth-CoffeeScript/tree/gh-p...

I would also like to know if the 'Send to Kindle' readability function results in a readable document. That was the reason for making this version.

A pdf version, a quick reference and a JavaScript supplement is on the web site at http://autotelicum.github.com/Smooth-CoffeeScript/

Something new is the in-progress cocoa graphics layer. If you try to compile p9p on Mac OS X then you may encounter a problem compiling devdraw. I did, when I recently tried from the download. Getting the code from the repository instead fixes that with the new layer.

The default font in p9p acme is somewhat rasterized compared to AcmeSAC. I copied over the fonts from there and changed the source code to default to those. There are environment variables that can be set, but it is as easy to change the code and compile it.

In AcmeSAC I have to use `os bash --login' for some commands on the host due to the inferno layer, that is not needed when using the p9p acme, it is speedy and native.

Using the p9p command line tools in iTerm2 with split-screen and multiple windows works very well too.

Indeed. I was just thinking I could try it on the device my neighbor has: A very cheap android 2.2 tablet with a resistive screen and pen, no multitouch. Never mind, it can hardly run android apps.

The [Octopus project](http://lsub.org/ls/octopus.html) has an interesting take on gestures. When right-clicking, it pops up a circular menu where the direction one goes in determines the action. See http://lockerz.com/s/139588614 That might be something for touch tablets.

I daily use AcmeSAC on Mac & Win7 with a trackpad (and MagicPrefs for three finger middle click) and with a Wacom tablet and pen. Very nice for editing without RSI problems.

Wow! Can it run acme? I'm wondering because "treats the touchscreen like a one-button mouse" If so, how is the right and middle click used? Anyway utterly cool stuff!

You can adapt some of the benchmark programs from http://shootout.alioth.debian.org/ I can not see it being used for much except trying a new language or a benchmark.

The compilation performance reminds me of the 'beloved' time sharing systems of the eighties and earlier. Had to go to work in the middle of the night, so compilations didn't take an unpredictably long time. With PC's (CP/M-80, XENIX) came more predictable performance. Feels like a history repeat - going back to the terminal age with HTML forms somewhat like 3270 submit and AJAX more like DEC VT-100. Not exactly of course, but like a pendulum swinging from server-side to client-side and now back to server-side.

I like the concept - really nice. It would be cool to see an update of Calculize use a math library instead of JavaScript numbers.

    In Calculize:
    a = 1/3
    show a+a+a+a+a+a == 6*a
    # => false
    show pow 9,18
    #         => 150094635296999140
    # should be: 150094635296999121
    show 150094635296999122 - 150094635296999121
    # => 0

    In Python 2.6.1:
    >>> p = 1.0/3.0
    >>> p+p+p+p+p+p == 6*p
    False
    >>> pow(9,18)
    150094635296999121
    >>> 150094635296999122 - 150094635296999121
    1

Maybe the results will also vary between browsers, because EcmaScript talks of implementation-dependent approximation's.

[Edit: Oops, python got me with it's own quirk - division needs to be from the __future__ or it's integer]

A temporary workaround for newlines is to copy/paste them in the box. Adding the bookmarklet and then going to http://arcturo.github.com/library/coffeescript/ gives a good way of experimenting with CoffeeScript.

Smooth CoffeeScript is a book about programming, problem solving, looking into how algorithms work, and learning from it. Those things really appealed to me in Eloquent JavaScript.

Smooth CoffeeScript uses CoffeeScript because it can express the code much more clearly than JavaScript, but the book could have been written in another language; Python for example.

I created it because it was a book I would like to read. It is great that there is now a handful of resources so you can pick what suits you best when you decide to learn CoffeeScript.

Well, I did not say that I really wanted to support other formats. Here are my reasons:

JavaScript has always possessed an inner, lisp-like beauty. CoffeeScript allows that beauty to shine through the surface of the syntax. I have tried in Smooth CoffeeScript to let the visual design reflect that in the way the code and text is presented.

I mentioned that I have tried converters and realized what the problems are (beyond lacking support for hyphenation, kerning and ligatures). The book's text is interspersed with code in a fixed width font. Line breaks and hyphenation marks has to be avoided as much as possible in inline code, because they can be highly confusing - does it mean a minus there or what? Then comes CoffeeScript's whitespace awareness, that means that code blocks have to be scaled, it is very confusing to use word wrapping. I have had to hand manage the typesetting by sometimes tweaking the code text, the font sizes or rewriting sentences to avoid formatting issues.

All my devices are capable of presenting pdf quite well, so I have also not felt the need to produce other formats. I checked at http://ebook-reader-review.toptenreviews.com/ and it seems all ebook readers have some support for pdf.

If the reason for other formats is to avoid Adobe, then on the Mac there is a built-in preview utility with excellent pdf support. On Windows Google Chrome has its own pdf support built-in. With this book Chrome does say that there is something it could not render correctly, but I have not been able to find what that something might be. It looks good to me.

Creating the book in pdf has been quite labour intensive - maybe due to my lack of experience in this kind of work - so the prospect of repeating that a couple of times for HTML and EPUB does not appeal much to me. If someone else feels strongly enough about this to dedicate their time and energy to it - and uses freely available tools to do it - then I will be happy to host the result on the project site.

Several of the examples in "smooth" are quite different from "eloquent" and use a http or websocket server, so they require the node.js runtime environment and can not run only in a browser. The setup I use is to have the text next to me on a tablet and a text editor that can run CoffeeScript directly on my laptop. It also takes know-how and time to produce different versions in EPUB and HTML. I tried some free conversion tools but the results were poor. I would like to fix issues and add material, there is an issue tracker on the project page, where errata and suggestions are welcome.

The book's homepage is at: http://autotelicum.github.com/Smooth-CoffeeScript/