Stoppt die Vorratsdatenspeicherung! Jetzt klicken &handeln! Willst du auch an der Aktion teilnehmen? Hier findest du alle relevanten Infos
  und Materialien:

Skip to content

Parser generation with Ruby

I’ve started to play a little with Treetop, a parser generator library for Ruby.
Why? you might ask. While I’ve been dreaming of my own programming languages and designing them for quite some time now, I never really managed to actually get beyond the design-phase. I’ve come up with several language designs in the past, each time getting closer to something that I think really could work (which doesn’t mean, that it actually could be useful or ‘good’ – if that even makes sense).
While I’ve been looking at many different languages in the past, I’ve found the dynamic, object-oriented and functional high-level languages to be most interesting & fun to work with. Naturally, after working with Ruby alot, I’ve started looking a little bit at Smalltalk and how it differs to Ruby.

Inspired by what Smalltalk and Ruby have to give, I started designing my own language, heavily influenced by those two great, very dynamic, truly object-oriented programming languages and came up with a quite simple language named blockd.

The name is based upon the main principle of the language: Everything is an object, and in the end, all code is defined within blocks – that are ruby / smalltalk like blocks. Naming these blocks is done via simple assignment. So instead of having a huge amount of keywords, the language itself is pretty simple, because all we really need is a way to describe assignments, instantiate objects and easily create blocks to pass to methods or use in an assignment.

So in contrast to Ruby, where there are procs, lambdas and blocks, blockd only knows blocks, which basically behave like Smalltalk like blocks – they simply are anonymous procedures / blocks of code (or functions, if you want to call them that – although not pure as in Haskell).

The syntax is a mix of Ruby’s and Smalltalk’s with some minor tweaks I thought would be cool (or not? I don’t know ;) ).
To give you an example of how the language looks, here is a small snippet of some sample code, that actually doesn’t work yet but might do so in the future :)

?Download sample.blk
# this is just for demonstration
# there probably won't be the need to require the console module from the
# standard library every time you want to print something to the screen ;)
System require: "console"
# we support ruby-style blocks with do ... end and curly braces { ... }
File open: "test.txt" mode: "w" do |f|
  f puts: "what's up, dog?!"
  f puts: "crazy shit, yo!"
  f puts: "hahaha!!"
10 to: 0 do |i|
  Console puts: i
i = 0
(i < 10) while_true: do |i|
  Console puts: i
  i incr
numbers = [1,2,3,4,5] select: {|i| i < 3}
numbers each: do |i|
  puts i
(1 .. 100) each: {|i| Console puts: i}
squares = (1 .. 100) collect: {|i| i * i}
# define a square method
square = { |x|
  x * x
# or like this:
abs = { |num|
  (num > 0) if_true {
    return num
  num * -1

I’m still tweaking the syntax and haven’t decided upon all things completely yet, but I guess I’ve found the pretty basic “feel” of it.

While I haven’t shown you any code that defines a class or modules, it still does show a little of the languages syntax. I’ve started the parser today and it successfully parses the code above, meaning, that since the syntax isn’t too complicated, I expect to be able to parse all the remaining stuff (classes & modules and some minor other things) pretty soon. I then intend to start writing the actual implementation – an interpreter written in Ruby. While I could come up with my own runtime, class library etc, I want to make use of the Ruby infrastructure as much as possible. For one reason, it makes it easier to actually implement something useful, on the other hand, since the language is very close to Ruby’s object model and semantics, I hope I can use most of Ruby’s code directly. This also would mean, that the interpreter could also run on other Ruby implementations like JRuby, IronRuby etc. And maybe, some day, it could also run natively compiled with the Ruby compiler I’ve been working on recently as well – but that’s still far into the future, since the compiler isn’t finished yet.

I guess that’s it for now. More to come soon :)

Posted in General. Tagged with , , , , , , , , , .

Creating a simple game in Ruby – Episode 5

This is the 5th episode on creating a simple game in Ruby. In this episode, we’ll add some automated testing via the BDD framework RSpec. We’ll also start to implement the Character class.

Posted in General, Ruby Screencast. Tagged with , , , , , , , , .

Creating a simple game in Ruby – Episode 4

In this episode we’ll do some little refactoring.

Posted in General, Ruby Screencast. Tagged with , , , , , , , , , .

Creating a simple game in Ruby – Episode 3

Posted in General, Ruby Screencast. Tagged with , , , , , , , .

Creating a simple game in Ruby – Episode II

Here’s the first ‘real’ episode, showing some actual coding.

Posted in General, Ruby Screencast. Tagged with , , , , , , , .

Screencast series: Creating a simple game in Ruby – Episode I

Today I started a new screencast series, titled “Creating a simple game in Ruby”.

Basically, I show how to create a simple (very simple) game in Ruby form scratch. Beginning with a simple text-based interface, I’ll slowly move on to a more sophisticated graphical user interface (written with the GUI library Shoes by _why) and explain my design decisions etc.

The reason I’m doing this is, that I’ve started writing a little game together with my girlfriend, since she wanted me to teach her a little about programming in Ruby. The idea for the game came from her.

Basically, the game is a Tamagotchi-Clone (called “Jimi”), where you have a little “virtual pet” you have to take care of, feed it etc.

Nothing very special, but I thought other newcomers to Ruby might be interested as well and could also learn something, hence the screencast.

I’ll post more videos, as I finish them.

Have fun watching them and leave some comments, if you want to.

Posted in General, Ruby Screencast. Tagged with , , , , , .

Why a self-hosted system is great

I’ve been asked recently, why writing a Ruby compiler in Ruby would make any sense. The argument was, that by compiling Ruby code to native machine code, you’d lose all the benefits of a ’scripting language’.
Now, you could argue, if you’d want to degrade Ruby simply to a scripting language – and I don’t think that Ruby is only that (whatever a ’scripting language’ may be…) – then you’d lose quite some flexibility (e.g. simply changing a file and run it again etc.).

But there’s a more important thing to consider here:
All the implementations out there currently are (mostly) written in another language. JRuby in Java, IronRuby in C#, MRI (default Ruby intepreter) in C and even Rubinius is written to great part in C++.
The reason is simple: Since you need some way to actually get your code running, you’ll need a host language to get the Ruby VM running on.

Now consider writing a native Ruby compiler in Ruby itself:
Once you’re able to bootstrap the compiler (meaning, to be able to compile it with itself), you’ve got a natively compiled executable, written in Ruby, where you don’t need any runtime/VM for. You could actually write a Ruby Interpreter / VM completely in Ruby itself, since you could also compile it with the native compiler. Additionally, making changes and understanding the source code of all these parts would be much easier for a normal Ruby programmer than any other system, since it’s all written in the language it’s targeting.
Now this would be awesome, wouldn’t it?
Any Ruby programmer could actually work on the language platform with the language itself. I think this would just be really cool.

So once the compiler would work well enough to actually compile quite large programms, it shouldn’t be too hard to get a Ruby Interpreter written in Ruby. :)

Of course, writing a language implementation in the language it’s implementing isn’t something new. Most Lisp implementations have been written in Lisp, the same goes for C & C++ compilers. In the case of Lisp, we have a dynamically typed language which gets compiled. And if you take a look at some performance benchmarks, you’ll see that there are Common Lisp implementations out there, that are really fast for a dynamic language (very well comparable to the speed of C!). This obviously takes some time, but it shows what can be possible. ;)

Posted in General. Tagged with , , , , , , , .

Hacking Ruby again

I’ve been writing some Ruby again for a while.
If you ever wanted to know, how a compiler for a ruby-like language (written in ruby) might look, check out this series by Vidar Hokstad: Writing a compiler in Ruby

Fortunately, the code has been online at GitHub for a while now here:
Since I’ve always been interested in language design and how compilers work, I forked the project and started working on it as well. I’m still learning a lot, but the code is still small enough to actually understand it even if you haven’t done anything like that before. The blog posts by Vidar especially help alot here, since a great deal of how the code actually works is explained there.
More and more this is turning into a compiler for the Ruby language and I’m excited to see where this is going :)

Posted in General. Tagged with , , , , , , , .

Simple portscanner in Erlang

Recently, CallToPower has posted a simple portscanner written in Java. To make a small comparison, I wrote a version in Erlang. Since Java isn’t very well suited for parallel programming, I think my version should beat the one in Java. Maybe someone wants to make a real benchmark? :)

Heres the code:

?View Code ERLANG
%% simple portscanner written in simple erlang :)
-author({"Christopher Bertels", ""}).
%% start portscanner process.
start() ->
    Host = io:get_line("host?\n") -- "\n",
    Start = list_to_integer(io:get_line("start port?\n") -- "\n"),
    End = list_to_integer(io:get_line("end port?\n") -- "\n"),
    io:format("host: ~s, start: ~p, end: ~p~n~n", [Host, Start, End]),
    start_threads(Host, Start, End).
%% start End - Start threads, each connecting to each port in that range.
start_threads(Host, Start, End) when Start > End ->
    io:format("started all scanning processes on ~p~n", [Host]);
start_threads(Host, Start, End) when Start =< End ->
    spawn(fun() ->
		  connect(Host, Start)
    start_threads(Host, Start + 1, End).
%% connects to Host on Port and prints a message, if connetion works.
connect(Host, Port) ->
    Connection = gen_tcp:connect(Host, Port, [binary, {packet, 0}]),
    case Connection of
	{ok, S} ->
	    io:format(">> Port open ~s:~p~n", [Host, Port]),
	_ ->

Posted in General.

Programming Erlang: eFreeTPd

I’ve been learning Erlang for quite a while now and started working on a small Erlang-based Project: eFreeTPd – a free ftp daemon written in Erlang.
I’ve bought myself the Programming Erlang book by Joe Armstrong at Pragmatic Programmers, a very nice book to read if you’re interested in Erlang and parallel programming – or COP (Concurrency Oriented Programming) – in general.

So yeah, Erlang is fun. It’s really easy to learn, if you ask me. If you know some Prolog, that’ll definately help a bit, since Erlang is influenced by it. But even if you’ve never heard of Prolog before, the language in itself is really small and easy. Just a few concepts you’ll have to learn including those of message passing style concurrency with processes instead of shared memory threads and mutable state. The syntax might seem weird at first, but I found this to be no real burden in the end.

eFreeTPd isn’t finished yet, but I’ll keep up development. It shouldn’t take too long though until there’s a somewhat stable or functional version out :)

Next time I’ll write a little more on how eFreeTPd actually is implemented in terms of what design and overall structure is used.

Posted in General. Tagged with , , , , , , , , , , , .

Ihr Browser versucht gerade eine Seite aus dem sogenannten Internet auszudrucken. Das Internet ist ein weltweites Netzwerk von Computern, das den Menschen ganz neue Möglichkeiten der Kommunikation bietet.

Da Politiker im Regelfall von neuen Dingen nichts verstehen, halten wir es für notwendig, sie davor zu schützen. Dies ist im beidseitigen Interesse, da unnötige Angstzustände bei Ihnen verhindert werden, ebenso wie es uns vor profilierungs- und machtsüchtigen Politikern schützt.

Sollten Sie der Meinung sein, dass Sie diese Internetseite dennoch sehen sollten, so können Sie jederzeit durch normalen Gebrauch eines Internetbrowsers darauf zugreifen. Dazu sind aber minimale Computerkenntnisse erforderlich. Sollten Sie diese nicht haben, vergessen Sie einfach dieses Internet und lassen uns in Ruhe.

Die Umgehung dieser Ausdrucksperre ist nach §95a UrhG verboten.

Mehr Informationen unter