art's abode

I’ll be adding more to this post quasi-frequently.

This post is based on the Singularity RDK 2.0 images and source, which are available here: http://www.codeplex.com/singularity.

Singularity can be run fairly easily. You can also roll your own, and compile Singularity from source.

What you will need:

• Singularity RDK 2.0 ISO image.
• Singularity RDK 2.0 sources: if you wish to compile from source.
• A machine: physical, or virtual*.

* I’ve used Microsoft Virtual PC Beta on a Windows 7 7100 x64 host machine. I’m told it works for Virtual PC 2007. I was unable to get it working with VMWare Server 2.0.

Running Singularity

• Download the ISO image.
• Burn it to a CD, or save to a location mountable for your VM.
• Boot the ISO.

You now should have Singularity running, using the default build. If you just wanted to look gangsta–mission accomplished, take your screenshots and begin bragging to on web forums:

However, if you want to explore the OS (such as it is), read on.

What the Hell is This, Min?

OK, don’t panic. Looks daunting, I know. Acquaint yourself with this little gem, for starters: “Singularity_RDK_2.0_Source\docs\Design Notes\SDN87 RDK Applications Guide.pdf“. It is from the RDK 2.0 source download, and will give you a good idea of how to use Singularity commands.

Some commands:

• help: display all commands.
• dir.
• start.
• ipconfig @show: display status of all NICs.
• dns @show: display DNS settings.
• seditor: an EDLIN-like editor.
• sc @show: show status of all services.
• tasklist: show list of all tasks.
• jobs: show a list of all jobs.
• fg n: foreground job number n. Use ^C to quit the job.
• shutdown.

Backgrounding:

Use & to run programs in the background. You can ^Z halt processes, then use bg n to background it.

Compiling From Source

The source comes with a PDF: Building and Running Singularity RDK 2.0.pdf. Read it.

Essentially you follow the instructions as given in that document:

• Get the prerequisites for the environment.
• Run “configure.cmd”.
• Delete/rename the directory “Singularity_RDK_2.0_Source\base.obj”, if it exists.
• Run the “Singularity RDK 2.0” desktop icon which will bring up a command line prepped for building Singularity or debugging it.
• At the prompt, type as below to build Singularity World distro:
  …\base> msb Distro\World.proj
• If it dies saying it couldn’t find a directory within “Singularity_RDK_2.0_Source\base.obj\MSBuildLogs\6\…”, don’t worry. Go into that MSBuildLogs directory and create the 6 directory. Now the MSBuild should work.

• You can find generated ISO image for your build in “Singularity_RDK_2.0_Source\base.obj\Distros”.

If you modify any .scripts, for example, you may wish to recompile to include the modifications on an ISO; you just repeat the above process after making your changes to “C:\src\Singularity_RDK_2.0_Source\base\Distro\Scripts\startup.script”, for example.

As a rough benchmark, it takes me 10-15 minutes to build World on a quad core with 8 GB memory.

Networking

Aye, it works.

If you’re ultra-lazy, just do the following:

Singularity>ipconfig @dhcp /dev/nic0 start

This should get you going with DHCP. It’ll poll the DHCP server for DNS servers too.

You can set a static ip thusly:

Singularity>ipconfig /dev/nic0 192.168.1.99 255.255.255.0 192.168.1.1

The format is ipconfig <device> <ip> <netmask> <gateway>.

Remember that if you set a static IP using ipconfig, you will need to tell Singularity which DNS servers to use, check the dns command.

Enabling VESA

Edit the file “Singularity_RDK_2.0_Source\base\Distro\LegacyPCDistro.xml“.

Enable the line:

<driver name=”S3Trio64″ />

Recompile, and you’ve got VESA.

I prefer without VESA as it has a handy thread statusbar at the top of the blue screen, which is apparently gone in VESA mode. Pity.

FAT drives

For FAT support open your Distro build file (i.e., “Singularity_RDK_2.0_Source\base\Distro\World.proj“), add the following line:

<Application Include=”$(SINGULARITY_ROOT\Services\Fat\Control\FatControl.csproj”/>

Recompile, and you’ve got FAT support.

Make sure you’ve partitioned your FAT drive beforehand. You should be able to see it listed in the /dev tree.

Now, you can @format, @mount and @unmount your FAT drive using fatcontrol.

.script files and customizing startup.script

If you are serious about using Singularity, you will likely want to modify your init/startup.script. The best way to do this is to edit this on your host machine, then msb.

Note that you will have to put ‘single quotes’ around all arguments. For example, the shell command hostname -n=paddington (this changes the machine’s hostname to “paddington”) would be put in startup.script as:

hostname ‘-n=paddington’

There are plenty of examples in the RDK for you to get started with. Here is Singularity booting up, setting hostname, a DHCP connection, a static IP, and mounting a FAT drive:

Jobs

If you try to reboot or shutdown while there are jobs, Singularity will freeze. Nice. For now, just remember to kill all your jobs by foregrounding them (jobs, fg n, ^C).

Developing in Singularity

Read this thread which discusses the best way to develop for Singularity: http://singularity.codeplex.com/Thread/View.aspx?ThreadId=23669.

A quote:

copy an existing project like …\base\Applications\Hello\

to …\base\Applications\MyProj\

cd …\base\Applications\MyProj\

rename .cs and .csproj files, edit them for content.

msb MyProj.csproj (until it compiles)

back to …\base

edit distro\tiny.proj and add a line for your app

<Application Include=”$(SINGULARITY_ROOT\Applications\MyProj\MyProj.proj”/>

msb distro\tiny.proj

In general, I’ve found the process to be fairly straightforward, once you get the hang of it. I would recommend you compile a World distro, and keep the base.obj directory. Now, go into the base directory, and edit your sources/files.

The next time you msb the distro, it will only recompile/update the changed files. This is a pretty quick way to edit the scripts, and not too long if you are coding.

As a benchmark, it takes less than a minute for me to msb world, if I’ve made changes to 1 or 2 code projects within the source tree:

Debugging with WinDbg

Create a named pipe to COM2, and you can call the debugger using “dbg.cmd /pipe”.

Now, when you start up your Singularity VM, it will automatically output the debug to WinDbg:

Caveats

• Some example applications are buggy/not working.
• US keyboard layout only? I couldn’t find a way to change this anywhere in the source.
• Couldn’t get the /dev/audio device with Virtual PC Beta.

Demo Server

I have set up a demo Singularity web server, details here.

Shamelessly modified from the boo example sources, but it’s enough to get you started:

import System.IO
import System.Net
import System.Net.Sockets

server = Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
server.Bind(IPEndPoint(IPAddress.Any, 8200))
server.Listen(1)

while true:
        socket = server.Accept()
        using stream=NetworkStream(socket, true):
                print(StreamReader(stream).ReadLine())

                writer=StreamWriter(stream)
                writer.WriteLine(“Ahoy, this server is running: ${shell(‘booc’, ”)}”)
                writer.WriteLine(“${shell(‘cat’, ‘/proc/cpuinfo’)}”)
                writer.Flush()

MSDN’s System.Net Namespace docs might could also be of use. I’ve tested this on sparc and x86 linux variants with mono.

Hope you find this useful, network programming seems to be a relatively familiar experience if you’ve done it before in another modern language, just took a little bit of scrounging to dig up.

Here’s a document I ran across today which details some of the specific differences in the two languages. Just one of the many glorious tidbits:

Boo uses CLR threads, which generally map one-to-one to kernel threads and therefore exploit multiple processors and are fully preemptive.

In contrast, Ruby uses lightweight threads – threads implemented within the interpreter. Because of their extremely low switching latency, they can be used in situations where kernel threads impose too much overhead…[b]ut Ruby’s threads are limited to one CPU, and block on OS calls.

Microthreads can be implemented in user libraries, but only cooperative threads (as far as I know). I don’t know how important preemptive (within the hosted language) microthreads are. But the CLI (and therefore, Boo) seem to have no standard library implementation of lightweight threads.

All this is specific to the main Ruby implementation. JRuby, like Boo, relies on the underlying VM’s threading model – the JVM’s, in this case – and so its threads are generally fully preemptive and exploit multiple CPUs.

At the end of the day, I suppose comparing boo with ruby is a bit like comparing dicks to pussies, as ruby is an interpreted language through-and-through, whilst boo can be run, for instance using booi in interpreter mode, or using booc compile CLI bytecode binaries (which are absolutely tiny compared with, for instance, ruby2exe’ing a ruby project) to be run with mono/.NET or other CLR.

Also gotta love the mention of the JRuby: now we’re talking optimized best-of-breed solution. Lulz.

Today I ran the Windows binary package of MAngband 0.7.2a. Apart from missing walls and other things, it would consistently crash when I typed ‘:’ to chat. Pretty annoying.

As a result, I’ve compiled a Vista-compatible version of MAngband. You will need at least the Cygwin base set installed, as MAngband requires terminfo definitions. You can check out the project page with all the relevant downloads and information at MAngband-Vista. I hope to release updated versions of MAngband-Vista as new versions of MAngband are made available, and until these issues with Vista are resolved in the official distribution.

It’s pretty easy to handle signals in Ruby, which is sometimes necessary when you want your code to interact with the system running it.

Signalz Ahoy!

If you want to know which kill signals you have:

bash-3.2$ kill -l
1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
5) SIGTRAP      6) SIGABRT      7) SIGEMT       SIGFPE
9) SIGKILL     10) SIGBUS      11) SIGSEGV     12) SIGSYS
13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGURG
17) SIGSTOP     18) SIGTSTP     19) SIGCONT     20) SIGCHLD
21) SIGTTIN     22) SIGTTOU     23) SIGIO       24) SIGXCPU
25) SIGXFSZ     26) SIGVTALRM   27) SIGPROF     28) SIGWINCH
29) SIGINFO     30) SIGUSR1     31) SIGUSR2

If you want to know which kill signals Ruby recognises:

irb(main):002:0> Signal.list.keys.join ", "
=> "USR1, BUS, USR2, TERM, SEGV, KILL, EMT, EXIT, STOP, SYS, TRAP, INFO, IOT, HUP, INT, WINCH, XCPU, TTIN, CLD, TSTP, FPE, IO, TTOU, PROF, CHLD, CONT, PIPE, ABRT, VTALRM, QUIT, ILL, XFSZ, URG, ALRM"
irb(main):003:0>

Some quick-n-dirty source code:

There’s probably better ways of doing this, but here’s a stupid little example demonstrating how it could work:

bash-3.2$ cat signal.rb

$hups = 0

def quit_on_int
  puts "Quitting on interrupt signal."
  exit
end

def quit_on_quit
  puts "U sure killed me guud!"
  exit
end

def handle_hup
  $hups=$hups+1
  puts "HUP! (count: #{$hups})"
end

while true
  trap("INT") {quit_on_int}
  trap("HUP") {handle_hup}
  trap("QUIT") {quit_on_quit}
end

Example in use:

bash-3.2$ ruby signal.rb
HUP! (count: 1)
HUP! (count: 2)
HUP! (count: 3)
^CQuitting on interrupt signal.
bash-3.2$

We run the program as above, then send it three SIGHUPs (i.e., using "kill -HUP pid"). We break out the program using ^C (ctrl-c), sending an Interrupt. Note this may not work in windows.

bash-3.2$ ruby signal.rb
U sure killed me guud!
bash-3.2$

Here we run the program again, and send it a SIGQUIT ("kill -QUIT pid").

The new VMWare Server 2.0 is out on public beta, you can register at VMWare for a free serial for any platform it supports. One of the supposed great new features is exactly my gripe with Microsoft Virtual Server 2005 R2: it is only accessible via a web interface.

Yes that’s right gentlefolks, it actually installs an Apache Tomcat server. The interface is pretty sleek, but there was a noticeable lag in loading compared with VMWare Server 1.x.

Vista host seems OK, and it does support network bridging (finally!). I couldn’t get it to power on VMs on bootup using an XP host. Kinda annoying. It also uses a new format to store VM configuration settings and disk storage, but still supports all the other VMWare formats.

Apart from the improved 64bit support for host and guests, and improved Vista host support, having to load up a web browser to access a web server that’s purely dedicated to hosting web pages configuring your LAN virtual machines is a total harpoon up the arse. I think I’ll stay with 1.x for now.

… and it looks like MAngband’s site has been completely redone, and the new development team has taken oven. Nice one, as they say. After a few years, I think we’ve all had enough of the good ol’ blackie-reddie theme.

Nothing like a CSS makeover!

Well, after years and years of slow and patient progress from Crimson, he’s made an official post on the official MAngband website stating that he intends to step down from maintaining MAngband, in lieu of the the current developers working hard at pushing out 1.0!

11/27/2007         Moving Day.    

On Tuesday, December 5th, 2007, MAngband begins a new era.

Finally admitting both to myself and the community that I simply no longer have the time to properly support the game,
I have delegated control and stewardship of it to a much more dedicated team of people, who have already started
making massive advances towards getting us up and running on 1.0 stable, as well as a much more structured development cycle.

I have been honored to have sat in stewardship of the game for these many years, and I
deeply appreciate both the trust, patience, and support I have received from the community at large during this time.

I will, of course, continue to participate in the game, and look forward to talking, and playing with the group.

Sincerely,

Robert L. Seifer

–Crimson

I can’t say I disagree with Crimson’s decision. Out with the mold, in with the new. I had a chat with someone on #mangband@irc.mangband.org earlier, and we had a pleasant discussion about some of the things MAngband 1.0 needs most–a code enema and some UI enhancements. While MAngband has always been the multiplayer roguelike, I’m sure few can say it’s been a pleasant multiplayer experience these past years. The interface is truly roguelike, to the extent that multiplayer interactions (like chatting) become awkward.

• RubyCLR, a ruby bridge to .NET:

A high-performance Ruby to .NET bridge that allows seamless integration of CLR and Ruby objects in the same Win32 process. Use it to create rich client applications using the Windows Forms or Windows Presentation Foundation libraries.

• John Lam (the RubyCLR developer) discusses DLR, ruby and Silverlight.

• An insightful video on mashing up Silverlight (using the Dynamic Language Runtime) and ruby, together with Python, VB and JavaScript:

Presented by Jim Hugunin, John Lam
Duration: 72 minutes, 26 seconds

Often I want to compile something for my normal user account. In these cases, it doesn’t make sense to install system-wide. Lots of source tarballs nowadays allow you to compile and install a program in a particular location.

In general, you should be doing something like so:

$ tar -jxvf some_fantastic_warez.tar.bz2
…
$ cd some_fantastic_warez
$ ./configure ––prefix=~/usr
…
$ make
…
$ make install

make install will place your compiled binary into the path you specified with the ––prefix option when running configure. In this case I’ve set it to install it under the directory tree ~/usr (i.e., /home/username/usr).

If the source is fairly standard, you will then find the binary as ~/usr/bin/some_fantastic_warez.

You may wish to read about modifying your $PATH, so that you don’t need to specify the full path to run your program.