Could you (or someone else) possibly expand on that? Is writing in raw HTML generally discouraged? I am totally ignorant in this area, but I am curious about it since I admire Mark's formatting and he seems to get a lot done.
I can't speak for the person you're commenting on - that is, I have no idea what the 'Hm' meant. Also, I don't think it's generally discouraged. Lots of people write raw HTML (in some contexts).
But I certainly wouldn't want to write an entire book in HTML - it forces you to type a lot of brackets and tags. I'm sure your editor could take a lot of work off your shoulders, but even at that you end up typing a ton of macros (I would think). In any case, it seems easier to me to type the bulk of it in Markdown (or the like) and only occasionally drop down to raw HTML. To each, his or her own though.
For longer documents, I haven't written in raw html for quite some time. I use Markdown instead, and had assumed that most everyone (except maybe some web designers) uses some form of prettier markup for writing their longer content-heavy documents; either Markdown, reST, or maybe MoinMoin-style wiki markup. Those seem to be the big three (with reST only making it into that group by virtue of being used for the official Python docs, and thus also for many Python-related projects).
> but I don't understand why they believe this could be "blessed" by inclusion into the repository.
Google is, of course, a big company with lots of very smart people, and they rely on Python (and probably want to rely on it more in the future). Given that they employ Guido and also the primary developers of Unladen, the chances are very good that they will continue to vigorously improve upon it until their performance goals are met.
Hmm, yes, I understand why the Unladen Swallow developers, and to a certain extent Google, would want to do that. It just seems to me that the community would benefit more by waiting a little.
By the developers' own admission, LLVM's JIT infrastructure is immature and integrating it with Python uncovered lots of issues. Sure, clang has pretty good community support, but that doesn't mean that the Python integration - or even the JIT stuff - is equally well-supported. And the Python community doesn't contain many LLVM experts, I'd wager.
> I didn't know languages education was voluntary in the US.
It's mandatory, but you get to choose which language to study. Choice is generally either Spanish, French, or German (and sometimes Japanese). Most kids choose Spanish (at least, that's what it seems like).
You take a few years of it before graduating high school.
And, as someone else posted, it's pretty universal that most people forget almost all of it as soon as they've satisified either their high school or else college requirements. I don't have any idea if colleges require foreign language credits or not.
Often a Lisp program at runtime consist of a 'runtime environment' (memory management, ...) and the data in the heap: functions and all kinds of Lisp objects (characters, lists, hash tables, CLOS objects, ...). An 'image' is a saved dump of this memory.
Typically you can start Lisp and just reload the memory from the heap dump (the image) on disk and do some automatic re-initialisations (for example reopen windows, reconnect to files and databases, restart processes, ...). All the code and data will be restored. You are back, where you saved the image before.
Imagine you would dump the memory of your JVM to disk and restart it later.
The Lisp vendor will provide you with an 'image' that contains the base language, some extensions, graphics, networking, editor, debugger, inspector, gui designer, etc.. You can then write a program, load all the program files, load all the data and configuration files and save an image. When you restart the image later, all your application code and data is back. This can save a lot of time during development.
Interesting. Sounds like you run, step into, and then modify this big blob of binary data (from the inside!) until you've shaped it into what you want. Weird. :)
In both Lisp and Smalltalk you (can in Lisp, must in Smalltalk) develop from an "Image" based point of view instead of a file based one.
The simplest way to understand this is to realize that you are basically living "inside" the running exe that you're writing.
Contrast this with e.g. C++ where you write a bunch of files, fight with the compiler until they turn into some black box exe, then run said exe and try to guess what it's doing based on the blueprints of your source file. To actually see what's happening inside the exe you would have to run some kind of debugger, but you can't take action based on what you see. You're looking through a glass.
Not so with Lisp/Smalltalk. If you see something wrong you can just fix it on the spot and continue running.
> The simplest way to understand this is to realize that you are basically living "inside" the running exe that you're writing.
Ah. Given what I already know, it sounds a lot like opening up a Python REPL, importing all the code you need, and then starting the main loop of the program.
> You're looking through a glass.
Heh, through debugger-colored glasses. :)
I see what you mean though. With C++, if you find your problem, you stop the whole show, go back to your source, take a stab at a fix, recompile, and then run once again in the debugger. With Lisp, you're just there the whole time.
Exactly. And as a consequence of this both Lisp and Smalltalk allow you to restart from exceptions. Lisp has an extremely sophisticated method (most powerful of any language imo) called "restarts". These make it a lot easier to build much more robust software than it is without them. http://www.gigamonkeys.com/book/beyond-exception-handling-co...
I think Bazaar would be more useful if they tightened up their docs to be more concise, while also splitting up the tutorial to have each of the pieces more closely focus on one particular way of working, for example:
* you're working on a project at work where the code is available via ssh at `some_host:/var/repos/the-project`.
* you're working on a project where the code is available via http from the author's site
* etc.
Currently, I think the impression they give is that you only use bzr if you're also using LaunchPad. That needs to change.
BTW, are there any other source code hosting sites that support bzr besides GNU Savannah and SF?
This is pretty amazing news. Last I heard, I thought that UnladenSwallow was 2.x-only. Now it turns out that it's going into 3.x and there will be no 2.x Unladen. Wow.
