From 4b6c0e31385f5f27a151088c0a2b614495c4e589 Mon Sep 17 00:00:00 2001
From: Paul Duncan <pabs@pablotron.org>
Date: Thu, 14 Oct 2021 12:47:50 -0400
Subject: initial commit, including theme

---
 ...-12-charming-ruby-compiler-not-so-charming.html | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 content/posts/2006-01-12-charming-ruby-compiler-not-so-charming.html

(limited to 'content/posts/2006-01-12-charming-ruby-compiler-not-so-charming.html')

diff --git a/content/posts/2006-01-12-charming-ruby-compiler-not-so-charming.html b/content/posts/2006-01-12-charming-ruby-compiler-not-so-charming.html
new file mode 100644
index 0000000..f1f3f7a
--- /dev/null
+++ b/content/posts/2006-01-12-charming-ruby-compiler-not-so-charming.html
@@ -0,0 +1,37 @@
+---
+date: "2006-01-12T21:10:33Z"
+title: Charming Ruby Compiler, Not So Charming
+---
+
+<p>Earlier this month on the <code>ruby-core</code> mailing list there was a post
+about the <a href="http://www.dtek.chalmers.se/~d00farre/thesis/">Charming Ruby Compiler (CRC)</a>, which looks promising.
+It's a preliminary <a href="http://ruby-lang.org/">Ruby</a> to <a href="http://cminusminus.org/">C--</a> compiler.  Unfortunately, it's
+also got <a href="http://gnome.org/">GNOME</a>-style dependencies (i.e. from hell).  You can grab a
+pre-compiled binary for <a href="http://www.dtek.chalmers.se/~d00farre/thesis/">CRC</a>, but the <a href="http://cminusminus.org/">C--</a> compiler itself depends
+on both <a href="http://caml.inria.fr/">Objective CAML</a> and <a href="http://lua.org/">Lua</a>.</p>
+
+<p>For some reason, I just don't feel like installing the runtime and
+development libraries for <em>three</em> separate programming languages just to
+try out a preliminary compiler for <em>one</em> programming language.</p>
+
+<p>The thread wasn't a total loss, however.  I learned about both <a href="http://nekovm.org/">Neko</a>
+and <a href="http://llvm.cs.uiuc.edu/">LLVM</a>, and they both look interesting. <a href="http://nekovm.org/">Neko</a> is a lightweight
+<acronym title='Virtual Machine'>VM</acronym> for dynamic languages
+(like <a href="http://ruby-lang.org/">Ruby</a> and <a href="http://python.org/">Python</a>) written in <acronym title='American
+Netional Standards Institute'>ANSI</acronym> C.  Instead of targeting
+assembly, and compiling that to bytecode, <a href="http://nekovm.org/">Neko</a> provides it's own
+low-level programming language with primitives for things like strings,
+numbers, and objects.  Seems like <a href="http://nekovm.org/">Neko</a> has a lower barrier to entry
+than <a href="http://parrotcode.org/">Parrot</a>, although the lack of an encoding attribute for string
+elements kind of bothers me -- maybe that's something higher-level
+languages are supposed to take care of?</p>
+
+<p>On another note, I've generated the 
+<acronym title='HyperText Markup Language'>HTML</acronym> for 
+this post using <a href="http://www.deveiate.org/projects/BlueCloth">BlueCloth</a>, a <a href="http://daringfireball.net/projects/markdown/">Markdown</a> processor for <a href="http://ruby-lang.org/">Ruby</a>.
+If you can get over the funky bracket syntax for links, <a href="http://daringfireball.net/projects/markdown/">Markdown</a>
+does seem to make writing posts a whole lot easier.  All I need now is a
+decent post-processor for acronyms and I'd be set.  Maybe I'll come up
+with something for my new page backend, if it ever gets completed.</p>
+
+
-- 
cgit v1.2.3