Sep 09 2007

The glory of Subversion

Published by matt under Uncategorized

I really have to say, version control can be a wonderful thing in the classroom context.

I’m 1/3rd of the way through marking my student’s homeworks. However, I didn’t struggle with some handin system, or having them send me email, or anything like that.

You see, every student has a repository.

They do their work, commit it into their repository, and when they’re done, they just walk away (after their final commit). This means that their HW is backed up from their laptop, and it is sitting safely on a remote server.

It also means that I can check out their repository. So, before I did the grading, I did an ‘update’ on each of their repositories, so I got the most recent version of their code. To make comments in their files, I used block comments:

#| 20070909 MCJ
... some comment here
|#

and then created a text file in their repos with any additional comments.

Now, they don’t all have commit lists, so they don’t automatically get an email when I’m done. In the future, I may set that up. Not today, though. I manually send each one an email to say I’m done, and they can do an ‘update’ to get the most recent changes.

All-in-all, it’s a great workflow. I can improve it in a few different ways, but overall, it’s efficient for me, they’re getting good practice using a repository as part of their programming practice, and it provides a good, hard-to-loose communications channel regarding their feedback.

I think it’s awesome, even if no one else does.

One response so far

Aug 23 2007

As recently seen on the Untyped Subversion commit list…

Published by matt under Uncategorized

I personally watch commits go by for several projects, and it is instructive in many ways to read the commit messages and code. It is a way to learn new things about the software process as well as the implementation of solutions in code. That said, very occasionally, you actually get a giggle from the process…

Today was one of those times.

Date: 2007-08-22 12:22:06 +0100 (Wed, 22 Aug 2007)
New Revision: 1398
Log:
[DJG] IDCheck trunk:

Tests tests tests.
Date: 2007-08-22 12:41:46 +0100 (Wed, 22 Aug 2007)
New Revision: 1399
Log:
[DJG+NHW] IDCheck trunk:

Testing all the way.
Date: 2007-08-22 12:49:21 +0100 (Wed, 22 Aug 2007)
New Revision: 1400
Log:
[NHW+DJG] IDCheck trunk:

Oh what fun it is to ride on a one horse testing sleigh.

The song ends there, I’m afraid… but it does seem like Dave and Noel are a bit cracked out today. Perhaps they should be out playing frisbee instead of coding this fine Thursday. As I’m not in the same timezone, it’s difficult to say what’s going on over there…

Comments Off

Sep 13 2006

A live hash-table using XML-RPC

Published by matt under Uncategorized

I received a question the other day about using our XML-RPC library, and thought I’d put the response here. It’s still a simple example, but it illustrates one or two things. You must be running PLT Scheme 352.5 or greater for this to work, as we’re using some nifty new features that make things more stable.

I’m going to implement a “live hash-table”. By this, I mean I’m going to have a PLT Scheme hash-table that I can access from anywhere via XML-RPC. I created a “testing” directory in in the “servlets” directory of my server. Inside of that “testing” directory, I created a servlet called “live-hash.ss”. It looks like this:

(module live-hash mzscheme

  (require
   ;; For the 'xmlrpc-server' and 'add-handler' functions
   (planet "xmlrpc-module-servlet.ss"
                   ("schematics" "xmlrpc.plt" 1 3))
   ;; For 'raise-exn:xmlrpc'
   (planet "base.ss"
           ("schematics" "xmlrpc.plt" 1 3))
           )

  (provide interface-version manager timeout start)

  ;; I'm using 'equal here so that strings can be
  ;; used as hashtable keys.
  (define table (make-hash-table 'equal))

  ;; CONTRACT
  ;; insert : (U string number) any -> bool
  ;; PURPOSE
  ;; The 'insert' method will insert a value into the
  ;; hashtable, and return #t. We return a boolean in all
  ;; casees because XML-RPC has no natural coercion for the
  ;; #<void> value.
  (define (insert key value)
    (if (or (string? key)
            (number? key))
        (begin (hash-table-put! table key value) #t)
        #f))

  ;; CONTRACT
  ;; get : (U string number) -> any
  ;; PURPOSE
  ;; The 'get' method returns a value from the hashtable, or
  ;; raises an XML-RPC fault.
  (define (get key)
    (hash-table-get
     table key
     (lambda ()
       (raise-exn:xmlrpc
        (format "No value in hash for key '~a'" key))
       )))

  ;; Make 'insert' and 'get' available to the
  ;; outside world.
  (add-handler 'insert insert)
  (add-handler 'get get)

  )

If you can execute this in the “module” language of DrScheme and not get any errors, there’s a good chance that it will run under the webserver. At least, that’s a first step.

On the client side, I have some code that declares that the PLT webserver running on my local machine (with the “live-hash.ss” servlet) is an XML-RPC endpoint. I then map two local functions, “ins” and “get” to the remote methods provided by the server. Lastly, I do a quick test: I insert some data, and then request it back.

The client-side looks like:

(module live-hash-client mzscheme

  (require (planet "xmlrpc.ss"
                   ("schematics" "xmlrpc.plt" 1 3)))

  ;; Declare where the endpoint for this XML-RPC call is
  (define local (xmlrpc-server
                 "localhost"
                 8080
                 "servlets/testing/live-hash.ss"))

  ;; Define the mappings from local method calls to remove
  ;; method calls. In this case, the local name "ins" is bound
  ;; to the method "insert" running on the server.
  (define ins (local 'insert))
  (define get (local 'get))

  ;; Try inserting some data
  (for-each (lambda (key val)
              (ins key val))
            '(1 2 3 4 5)
            '(a b c d e))

  ;; Now, try retrieving it
  (for-each (lambda (key)
              (printf "K: ~a V: ~a~n" key (get key)))
            '(1 2 3 4 5))

  )

Again, I’m working under the “module” language here.

If all goes well, you can run the client-side, and see the data go round-trip to the server. Well, you can’t exactly “see” it, but you can guess that it goes round-trip to the server.

Welcome to DrScheme, version 352.5-svn28aug2006.
Language: (module ...).
K: 1 V: a
K: 2 V: b
K: 3 V: c
K: 4 V: d
K: 5 V: e

That’s perhaps not a lot to be getting on with; there’s more documentation in the “doc.txt” file included in the distribution. And it’s not quite as cool as Tony’s explorations with Erlang, but… well, this library has been around for a while, and occasionally, someone finds a use for it.

(Pretty-printing of code to HTML made possible by Paste Scheme at scheme.dk. Woot.)

Comments Off

Aug 08 2006

XML-RPC 1.2

Published by matt under Uncategorized

Things are rolling along on our XML-RPC library for PLT Scheme. At this point, the client is stable and well tested, and both the servlet and Apache CGI server implementations work and are poorly tested. However, one or two people were asking to make use of the server-side code, so we’ve made it available. Caveat developer.

Implementing an XML-RPC servlet is really quite straight-forward:

(require (planet "xmlrpc-servlet.ss"
                 ("schematics" "xmlrpc.plt" 1 2)))

(define (add x y) (+ x y))
(add-handler 'math.add add)

(handle-xmlrpc-requests)

Dropping this code somewhere under the ‘/servlets’ directory should get you going. I’m still unhappy with the current state of the CGI code:

#!/path/to/mzscheme -gqr
(require (lib "config.ss" "planet"))
(PLANET-DIR "/tmp/PLaneTWeb/dir")
(CACHE-DIR "/tmp/PLaneTWeb/cache")
(LINKAGE-FILE "/tmp/PLaneTWeb/linkage")
(LOG-FILE #f)

(require (planet "xmlrpc-cgi.ss"
                 ("schematics" "xmlrpc.plt" 1 2)))

(add-handler 'add (lambda (a b) (+ a b)))

(output-http-headers)

(handle-xmlrpc-requests)

I imagine we’ll absorb the output-http-headers into the handle-xmlrpc-requests macro, and I really want to do something to improve the state of affairs w.r.t. PLaneT package handling in the CGI environment. As I said above: the server code in the library is in motion, and it will likely change.

As an aside, I expect stress-testing the server-side code will be interesting; Noel suggested using Ethereal to record interactions between clients (in other languages) and our server implementations, and then replay those interactions in SchemeUnit unit tests. A neat idea, and not something I had thought of.

Comments Off