All the Perl that's Practical to Extract and Report

first steps in coding in rakudo

lilstevey on 2009-11-01T12:53:12

Ok. So I've managed to install perl 6. And Rakudo. And run "hello world". Clever me. Not.

Anyway. Having installed parrot I'd like to have a play, and try to do something marginally less trivial. Whilst not a popular view in certain circles, I enjoyed developing software in java until recently. In particular, I found the remoting capabilities and ease of such in Spring quite delightful to work with. To me, a comment on Ovids Blog by Dominus summed up what I perceived to be the underlying principal that gave rise to the aforemention sentiment.

I realized after a couple of years that architects have the same distinction. They have "structural" and "functional" elements. The simplest example is a tent. It has a functional element, which is the cloth; the cloth is the whole point of the tent, which keeps the rain off of you. But it also has a structural element, the tent pole, whose purpose is to hold up the cloth. The pole is a pure liability. If you could get the cloth to stay up with no pole, you would, but you can't.

So instead of "natural" and "synthetic" I now discuss it in terms of "functional" and "structural" code, which I think makes the point better.

From memory, the way this was approached was that remoting was treated as a configuration - in code, an interface was written, and a configuration file was used to expose this as a service. The plumbing ( structural elements? ) was hidden from the code, and I didn't need to care about it. If I wanted, I could test the implementation of the service, without having to start up http deamons or such like.

So, what I would like to do is create an interface in perl 6, and write some external code to allow a remote client to access this service. For starters I'll make a bloated service, rather than delegating the functionality to some manner of model or domain layer - just to keep it simple.

My first task is to figure out how I'm going to accomplish this. In stumbling about on t'interweb, I found a comment and subsequent thread on perl monks interesting Re: Open to debate on mixins and traits..

So I assume that I need a role to specify the behavour of the underlying class, and a trait to provide the glue between server and client? Or do I need to use signatures?.

I guess I'll have to wait and see. I'll start off with something simple - trying to define a role describing a greeting method on a class, and some other code which will implement said role.

Firstly, I'll try to get a simple example together:

Test.pl
use TestInterface;
use TestImplementation;

my TestInterface $a = TestImplementation.new();
$a.Greet();
TestInterface.pm
# TestInterface
role TestInterface
{
   method Greet(){}
}
TestImplementation.pm
use TestInterface;
class TestImplementation does TestInterface
{
   method Greet()
   {
      say "Hello World";
   }
}

Executing the above code snippets results in the following:

C:\ ... >perl6 Test.pl
Hello World

What I like about using an interface is it seperates an agreement of function to the performance of said function. IF the above code is valid, it seems to acheive that. The next stage I want to go onto is to squeeze into the tidy little arrangement, and make the client ( Test.pl ) Less dependenant on the specifics of the implementation. I'll do this for the time being by introducing a factory class - the modified examples look like:

test.pl
use TestInterface;
use TestFactory;

my TestInterface $a = TestFactory.new().TestInstance();
say $a.Greet();
TestFactory.pm
use TestInterface;
use TestImplementation;

class TestFactory
{
   method TestInstance() returns TestInterface
   {
      return TestImplementation.new();
   }
}
The only other change is the alteration of the method Greet in TestImplementation.pm to return rather than say the greeting. Now at the moment, this might seem like a lot of unecessary waffle. However, in practice, the TestFactory class becomes part of the framework, reducing this additional step.

Running this code results in the same result as earlier.

So. Whats next? For me at the moment, bed calls. And a day at work. More to come after. I guess the next step is to find some socket code in perl 6 and try to knock up some remoting, before trying to see what kinda bindings can be done automajically.

Returning to it after a couple of evenings off. Once again, watching tv simultaneosuly. This night, "Jumper" and Coraline are on the cards...

The path now diverges.... In order to construct a simple RPC "layer" I need a means of communication - perhaps using a simple httpd for starters. I also need some means of reading the "interface" role, and "somehow" tieing it to said client and server. I'll start by trying to make a simple server.

So, to start with I need a server, fortunately http-daemon has been ported to perl6.

http://gitorious.org/http-daemon

I don't have GIT so I need to get it. I google up http://git-scm.com/ - a site which appears to have one of the coolest looking logos going. finding the git on windows mysys varient. I'll give it a blast.

C: .. \httpd>perl6 Configure.pl

Configure.pm is preparing to make your Makefile.

Found a PARROT_DIR to be C:/install/parrot-1.7.0
but there is no Rakudo nearby. Please contact the proto people.

drat!

It turns out RAKUDO_DIR environmental problem is not set. I try, but no luck - still fails. I try the RAKUDO_DIR argument to Configure - same message.

Have a browse of the configure code. It loks like its expecting rakudo-in-parrot or parrot-in-rakudo. My setup looks a little unconventional. I made a new folder "languages" in PARROT_DIR, create a rakudo subdir, and copy the contents of the rakudo install DIR. The output of configure.pm now looks a little more promising:

C: ... \httpd>perl6 Configure.pl

Configure.pm is preparing to make your Makefile.

PERL6 C:/install/parrot-1.7.0/languages/rakudo/perl6Use of uninitialized value
PERL6LIB /lib
PERL6BIN /bin
RAKUDO_DIR C:/install/parrot-1.7.0/languages/rakudo

Makefile is ready, running 'make' on it.
Use of uninitialized value
'make' is not recognized as an internal or external command,
operable program or batch file.
Configure and 'make' have finished. Use 'make help' to view other options.

However, the "make" errors look worrying.

C:\ ... \httpd>mingw32-make
mingw32-make: *** No rule to make target `lib/HTTP/Daemon.pir', needed by `all'.
Stop.

A little digging later and I stumble across proto - this looks well worth a look - though perhaps tommorow as it's time for bed. Perhaps it might also be pragmatic to at least rerun configure and make on rakudo in its new location - or just re-install things in what appears to be a more normal layout?