Re: [perl #38023] [TODO] build - support pkgconfig

[Joshua Hoblitt]

I've add simple install support for pkgconfig as r11035.  It's currently
hardcoded as being under libdir as this is what every automake installed
package I know of does.  If there's ever compelling reason to install it
someplace else we can add a separate 'pkgconfigdir' option for it.

Cheers,

-J

--
On Mon, Jan 09, 2006 at 03:20:37PM -1000, Joshua Hoblitt wrote:
> On Tue, Jan 10, 2006 at 01:06:29AM +, Nick Glencross wrote:
> > Joshua Hoblitt (via RT) wrote:
> > 
> > >Parrot should support pkgconfig by installing a pc data file.  It should
> > >probably be named parrot.pc.
> > >
> > Ok, I can do this. I've had an initial stab at it, and one thing that 
> > I've had to do is provide a quoting mechanism into the configuration 
> > file substitution because pkgconfig too uses ${name} for other purpose. 
> > I've going to suggest ${{name}} as something which will be replaced 
> > literally by ${name}.
> 
> Great.  There is another bug to change the interpolation syntax to @foo@
> to avoid just this issue.  Since you've already added the escape
> mechanism so lets leave it in place but consider it temporary.
> 
> As a side note, Parrot::Configure::Step is only partially tested and I'm
> rather nervous about messing with it until it has better test coverage.
> 
> > I think that most projects leave the .pc in the top-level directory; I 
> > don't think that we have anywhere better at the moment.
> 
> Seems reasonable.  That's what I with my autotool packages too.
> 
> > The file isn't yet installed because I don't know how to update the 
> > MANIFEST.generated file to place it in .../lib/pkgconfig. Any help would 
> > be great.
> 
> Another install type/class will have to be added.  I'll take care of
> this when I get home this evening.  Lets leave the bug open until I've
> gotten the install working.
> 
> Cheers,
> 
> -J
> 
> --




pgpca5fMVHXFs.pgp
Description: PGP signature

[perl #38197] [TODO] docs - add linking discussion to docs/embed.pod

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #38197]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38197 >


Using pkg-config and/or parrot-config to link against libparrot should
be discussed.

-J

--


pgpE5W8hsPgSA.pgp
Description: PGP signature

Re: [perl #38023] [TODO] build - support pkgconfig

[Nick Glencross]

On 1/10/06, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 10, 2006 at 01:06:29AM +, Nick Glencross wrote:
> > Joshua Hoblitt (via RT) wrote:
> >
> > >Parrot should support pkgconfig by installing a pc data file.  It should
> > >probably be named parrot.pc.
> > >
> > Ok, I can do this. I've had an initial stab at it, and one thing that
> > I've had to do is provide a quoting mechanism into the configuration
> > file substitution because pkgconfig too uses ${name} for other purpose.
> > I've going to suggest ${{name}} as something which will be replaced
> > literally by ${name}.
>
> Great.  There is another bug to change the interpolation syntax to @foo@
> to avoid just this issue.  Since you've already added the escape
> mechanism so lets leave it in place but consider it temporary.

As you say, what I've done fits in with how things are currently and
can be changed (it's only been one extra line of code). @foo@
certainly matches the autoconf notation, so is more consistent.

I'll continue now that we've got the 'pkgconfigdir' option, thanks!

Nick

Re: SKIP blocks and the debugger

[Adam Kennedy]

Kirrily Robert wrote:
Does anyone else find that SKIP: { } blocks bugger up the debugger?   
I'll be happily bouncing on the "n" key to get to round about the  
vicinity of the failing test, and then blam, it sees a skipped test  and 
just fast-forwards to the end.


K.




Yep

Actually, eval does this all the time as well. If you next your way 
though an eval, it's prone to running away to the end of a program.


Adam K

Re: [svn ci] Changes to dynoplibs build process

[Nick Glencross]

On 1/10/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> "Jonathan Worthington" <[EMAIL PROTECTED]> wrote:
> > Note that dynamic op libs do not *work* on Win32 yet
> They do now - I'm using them with my .NET to PIR translator and they work
> nicely.
>
> I would really like some feedback from MinGW and cygwin folks on how
> dynoplibs build and work for them

Works straight off on cygwin. :-) Gives the answers you wanted.

How much info did you want about the way it builds?

[I suspect that this isn't the answer that your asking for, but it
seems to run ops2c.pl for each runcore on the dynops, and then builds
.o from each one, and then finally just builds DLLs from them (i.e.
2x4 DLLs)]

cygwin seems to be able to use both .def files or just export all the
symbols from a DLL, the latter being what is done here.

Nick

Re: [svn ci] Changes to dynoplibs build process

[Jonathan Worthington]

"Nick Glencross" <[EMAIL PROTECTED]> wrote:

On 1/10/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> I would really like some feedback from MinGW and cygwin folks on how
> dynoplibs build and work for them

Works straight off on cygwin. :-) Gives the answers you wanted.


That's great, thanks.


How much info did you want about the way it builds?
I badly phrased my question - I guess I shoulda written "if" rather than 
"how".  That's what happens when I write emails at 2AM.  ;-)



[I suspect that this isn't the answer that your asking for, but it
seems to run ops2c.pl for each runcore on the dynops, and then builds
.o from each one, and then finally just builds DLLs from them (i.e.
2x4 DLLs)]


That's what I'd expect, yep.


cygwin seems to be able to use both .def files or just export all the
symbols from a DLL, the latter being what is done here.
Good.  I want to do away with the .def files for all platforms we can - it's 
a pain as the main one keeps getting out of sync with the code.  Knowing 
cygwin can handle exporting by decorating the code helps towards that.  And 
I'd guess it points to MinGW handling it too as both use gcc.


Thanks for testing,

Jonathan 

Re: [perl #37940] substr and memory issues

[Leopold Toetsch]

Leopold Toetsch wrote:


On Dec 14, 2005, at 12:52, Joshua Isom (via RT) wrote:


[ substr related PANIC ]


After a lengthy session with gdb and some added debug prints, I've now 
tracked down and fixed the reason for the memory panic. The sweep code 
tried to avoid freeing buffers, if there were plenty of PMCs left 
usable, which of course is totally bogus for string-only code. I've 
removed that part.


Anyway, the COW-ping-pong issue is *not* solved, just the PANIC. 
Reversing a string of 10 bytes (1/10th of the example code) with the 
posted rev.pir takes:


time30 s   [1]
GC runs   7147
memory collected   1.8 GByte

[1] unoptimized build, default runcore, but that really doesn't matter ;)

leo

Re: [perl #38197] [TODO] docs - add linking discussion to docs/embed.pod

[Nick Glencross]

On 1/10/06, via RT Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by  Joshua Hoblitt
> # Please include the string:  [perl #38197]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=38197 >
>
>
> Using pkg-config and/or parrot-config to link against libparrot should
> be discussed.

Ok, here's an initial stab at this section.

We don't currently install parrot-config, and I believed that it's
more of a troubleshooting tool. Shall I write a section on its use?

I'll commit it some time later today based on feedback.

Nick
Index: embed.pod
===
--- embed.pod   (revision 11037)
+++ embed.pod   (working copy)
@@ -233,6 +233,75 @@
 
 =back
 
+=head1 COMPILING
+
+Your application will need to include the appropriate header files and
+link against parrot and its dependencies.
+
+Since the location of these files can vary from platform to platform,
+and build to build, a general method is provided to find out the
+necessary flags to use.
+
+The pkg-config is a helper tool which many packages have adopted to
+provide the necessary compiler and linker flags required to build
+against a library. parrot will install the parrot.pc which can be
+queried using pkg-config.
+
+To start with, let's find out what version of parrot is installed
+
+  pkg-config --modperson parrot
+  0.4.1
+
+To find out the necessary -I flags, use
+
+  pkg-config --cflags parrot
+
+and to find the necessary -L and -l flags, use
+
+  pkg-config --libs parrot
+
+Where both compiling and linking are performed in one step, both sets
+of flags can be queries with
+
+  pkg-config --cflags --libs parrot
+
+The pkg-config command can be incorporated with a compile as shown here.
+
+  cc src/disassemble.c `pkg-config --cflags --libs parrot`
+
+Most applications will probably choose to run pkg-config as part of a
+configure script, so if you are using autoconf you could use a test
+such as this.
+
+  PARROT_REQUIRED_VERSION=0.4.1
+  AC_SUBST(PARROT_REQUIRED_VERSION)
+  PKG_CHECK_MODULES(PARROT, parrot >= $PARROT_REQUIRED_VERSION,
+[AC_DEFINE([HAVE_PARROT], 1, [define if have parrot])])
+  AC_SUBST(PARROT_LIBS)
+  AC_SUBST(PARROT_CFLAGS)
+
+If parrot has been installed system-wide, then any of the previous
+lines should have returned the relevent flags. If it is not installed
+in one of the standard places that pkg-config looks, then you will get
+an error message.
+
+  pkg-config --libs parrot
+  Package parrot was not found in the pkg-config search path.
+  Perhaps you should add the directory containing `parrot.pc'
+  to the PKG_CONFIG_PATH environment variable
+  No package 'parrot' found
+
+As stated in the error message, an environment varable can be used to
+make pkg-config look in more locations.
+
+  export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
+
+The last part of the variable will almost certainly be
+.../lib/pkgconfig. This variable will have to be set in your login
+scripts if you need it to be available in future.
+
+=back  
+
 =head1 SEE ALSO
 
 F and F for the implementation.

Re: [perl #38197] [TODO] docs - add linking discussion to docs/embed.pod

[Nick Glencross]

On 1/10/06, Nick Glencross <[EMAIL PROTECTED]> wrote:
> On 1/10/06, via RT Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> > # New Ticket Created by  Joshua Hoblitt
> > # Please include the string:  [perl #38197]
> > # in the subject line of all future correspondence about this issue.
> > # https://rt.perl.org/rt3/Ticket/Display.html?id=38197 >
> >
> >
> > Using pkg-config and/or parrot-config to link against libparrot should
> > be discussed.
>
> Ok, here's an initial stab at this section.

One point that I will need to stress more is that this only works once
parrot has been installed, and not while you're still working in the
build directory (pkg-config has a solution to this,
parrot-uninstalled.pc, but we don't need that yet).

Nick

Re: [perl #38196] [PATCH] bug wrangler doc

[jerry gay]

On 1/9/06, via RT Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by  Joshua Hoblitt
> # Please include the string:  [perl #38196]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/rt3/Ticket/Display.html?id=38196 >
>
>
> Hi Folks,
>
> I started writing this document months ago and it's just been siting
> around every sense.  Is it worth putting this in the repo in hopes that
> others will incrementally improve it or should I just throw it away?
>
yes, please check this in, however i'd stick it under
docs/dev/wranglers.pod, as that's the audience it's intended for.

~jerry

Re: [perl #38023] [TODO] build - support pkgconfig

[jerry gay]

On 1/9/06, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> As a side note, Parrot::Configure::Step is only partially tested and I'm
> rather nervous about messing with it until it has better test coverage.
>
i'll work on this now.
~jerry

How to best have statements execute only during dev/testing?

[Matisse Enzer]

I'd like to create a class that provides a bunch of assertion  
methods, like Carp::Assert, etc. I want to have an object oriented  
interface, so in some code I'm developing I would have:



  use Devel::Assert;
  my $tester = Devel::Assert->new( on_fail => carp ); # or   on_fail  
=> cluck, etc.


  my $data_structure = blah_blah();
  $tester->save($data_structure);   # Saves a clone of the data in a  
unique slot

  #
  #  do stuff with $data_structure
  #
  $tester->has_changed($data_structure);

The trick I want is that if my code is running in a production  
environment (perhaps determined at compile-time) then I want my  
Devel::Assert stuff to basically disappear. So the question is, what  
is the lowest-impact way to do that?


One easy, but probably not best way is to like this:

  sub has_changed {
 return if is_production();
 # do actual stuff
   }

I'll note here that Carp::Assert handles this issue by having you  
make all the test calls conditional:


   ASSERT( $a == $b) if DEBUG;

-M

---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: How to best have statements execute only during dev/testing?

[Paul Johnson]

On Tue, Jan 10, 2006 at 08:11:43AM -0800, Matisse Enzer wrote:

> I'd like to create a class that provides a bunch of assertion  
> methods, like Carp::Assert, etc. I want to have an object oriented  
> interface, so in some code I'm developing I would have:
> 
> 
>   use Devel::Assert;
>   my $tester = Devel::Assert->new( on_fail => carp ); # or   on_fail  
> => cluck, etc.
> 
>   my $data_structure = blah_blah();
>   $tester->save($data_structure);   # Saves a clone of the data in a  
> unique slot
>   #
>   #  do stuff with $data_structure
>   #
>   $tester->has_changed($data_structure);
> 
> The trick I want is that if my code is running in a production  
> environment (perhaps determined at compile-time) then I want my  
> Devel::Assert stuff to basically disappear. So the question is, what  
> is the lowest-impact way to do that?
> 
> One easy, but probably not best way is to like this:
> 
>   sub has_changed {
>  return if is_production();
>  # do actual stuff
>}
> 
> I'll note here that Carp::Assert handles this issue by having you  
> make all the test calls conditional:
> 
>ASSERT( $a == $b) if DEBUG;

This isn't an answer to your question, but in general production is the
environment in which your code will be exposed to the data and
conditions which have had the least testing, and to which you will have
the least access and freedom to change things.  This is precisely the
environment in which I like to have checks to discover problems as early
as possible and to provide the most information about them.

Should you have considered this found that the checks are just too
expensive, for example, one possibility which is slightly better than
the one you proposed might be to to replace all the methods in
Devel::Assert with empty subs.  This will mean that you will still have
the overhead of a method call, which is (un)reasonably expensive in
Perl, so to eliminate the call completely you are left with a solution
such as the one you noted, where the call is conditional on some
constant which can be set to false allowing the optimiser to remove the
whole thing from the op tree.

I suppose you could consider a source filter, but I couldn't recommend
that.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: How to best have statements execute only during dev/testing?

[Matisse Enzer]

By the way - I have also been looking at Test::Assertions

---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Re: How to best have statements execute only during dev/testing?

[Matisse Enzer]

On Jan 10, 2006, at 8:44 AM, Paul Johnson wrote:

I suppose you could consider a source filter, but I couldn't recommend
that.


I am in fact considering using a filter, but it scares me - perhaps  
because I have never done it before.



---
Matisse Enzer <[EMAIL PROTECTED]>
http://www.matisse.net/  - http://www.eigenstate.net/

Lua2PIR translator

[Klaas-Jan Stol]

Hi,

As you know, I've been playing with Lua for some time now, and my 
attempt to write a Lua compiler targetting Parrot has not been 
completely unsuccessful, but it was quite some work.


Anyway, at some point I realized that PIR looks very much like Lua 
bytecodes (which I had inspected at that time already). So, I thought it 
may be a nice project to write a Lua2PIR translator, which takes a 
binary Lua file (compiled with the Lua compiler, so you'll need to get 
Lua (to be found at www.lua.org))


If you are interested, it can be found at

   http://members.home.nl/joeijoei/lua2pir/

It works pretty good. It needs still many tests, in order to check if 
all special cases are covered, but quite complex examples do work 
already. Furthermore, the Lua PMCs have to be integrated, as it just 
uses the Parrot basic types (Float, String, Hash, etc). It's also nice 
to see what kind of code the Lua compiler should more or less be generating.


Kind regards,

Klaas-Jan Stol

Re: [perl #38176] [PATCH] Fix string-to-integer conversion with multiple leading spaces

[Leopold Toetsch]

Until r10938, string-to-integer conversion was possible even when the
string contained more than one space before the start of the integer.


Thanks, applied - r11042.
leo

Re: How to best have statements execute only during dev/testing?

[Ben Evans]

On Tue, Jan 10, 2006 at 05:44:45PM +0100, Paul Johnson wrote:
> 
> This isn't an answer to your question, but in general production is the
> environment in which your code will be exposed to the data and
> conditions which have had the least testing, and to which you will have
> the least access and freedom to change things.  This is precisely the
> environment in which I like to have checks to discover problems as early
> as possible and to provide the most information about them.

Absolutely.
 
> Should you have considered this found that the checks are just too
> expensive

Then you should go back again and prove it beyond any shadow of a doubt with 
benchmarks. 

Then add assertion guards using 

if ($DEBUG) {
 # Assertion goes here
}

and benchmark again. If they are still too expensive, then you have 
bigger problems than assertion checking, notably that your application
is probably written in the wrong language.

> I suppose you could consider a source filter, but I couldn't recommend
> that.

I'd make a slightly stronger statement than that: If you were congenitally 
insane, wilfully stupid or drunk, you could consider a source filter for this.

Ben

Re: [perl #38197] [TODO] docs - add linking discussion to docs/embed.pod

[Nick Glencross]

On 1/10/06, Nick Glencross <[EMAIL PROTECTED]> wrote:
> On 1/10/06, Nick Glencross <[EMAIL PROTECTED]> wrote:
> > On 1/10/06, via RT Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
> > > # New Ticket Created by  Joshua Hoblitt
> > > # Please include the string:  [perl #38197]
> > > # in the subject line of all future correspondence about this issue.
> > > # https://rt.perl.org/rt3/Ticket/Display.html?id=38197 >
> > >
> > >
> > > Using pkg-config and/or parrot-config to link against libparrot should
> > > be discussed.
> >
> > Ok, here's an initial stab at this section.

Committed as r11045.

I'll close the call in a few hours (if I can).

Cheers,

Nick

Re: How to best have statements execute only during dev/testing?

[dakkar]

Matisse Enzer wrote:

The trick I want is that if my code is running in a production
environment (perhaps determined at compile-time) then I want my
Devel::Assert stuff to basically disappear. So the question is, what  is
the lowest-impact way to do that?


This entry in BooK's use.perl journal might help you:
http://use.perl.org/~BooK/journal/25445

--
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88


signature.asc
Description: OpenPGP digital signature

Re: How to best have statements execute only during dev/testing?

[A. Pagaltzis]

Hi Ben,

* Ben Evans <[EMAIL PROTECTED]> [2006-01-10 18:20]:
>I'd make a slightly stronger statement than that: If you were
>congenitally insane, wilfully stupid or drunk, you could
>consider a source filter for this.

Depends. Additive filters that the same code can run without are
sane when used carefully, and they’re easy to create if the
trigger is a special comment or better yet POD section:

$foo = bar();

=begin testcode

assert( defined( $foo ) );

=end testcode

frobnitz( $foo );

In production, the code runs *without* a filter so the POD
section blinkers perl reliably; what you see is exactly what
executes. Potential for mysterious bugs: zero.

In testing, the code runs with an extremely simple filter.
Potential for mysterious bugs: non-zero, but miniscule.

This is pretty sane.

Regards,
-- 
Aristotle Pagaltzis // 

Parrot 0.4.1 in pkgsrc

[Anders Nor Berle]

Parrot 0.4.1 has been committed to pkgsrc. Anybody who uses pkgsrc,
feel free to try it and let me know if it works ok. The repository may
be browsed here:

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/parrot

--
- Anders Nor Berle

divide by zero exceptions

[Leopold Toetsch]

The integer and floatval opcodes div, fdiv, and cmod now all throw a 
E_ZeroDivisionError exception with the text "Divide by zero". JIT/i386 
and JIT/ppc are also adapted accordingly.


Updates for Integer, Float, Complex, BigInt PMCs are welcome.

leo

Dynamic op libs now part of normal build

[Jonathan Worthington]

Hi,

As of tonight, dynamic op librareis are now built as a standard part of the 
Parrot build process, plus there are some tests for them.


Jonathan 

[perl #38201] Integer pmc doesn't make store an int

[via RT]

# New Ticket Created by  Joshua Isom 
# Please include the string:  [perl #38201]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38201 >


Given the code

.sub main :main
 $N0 = 3.14
 $P0 = new .Integer
 $P0 = $N0
 print $P0
 print "\n"
.end

this will print 3.14, not 3.  The same occurs if using an S register 
instead of an N register.  This is with the latest revision.

[perl #38202] [TODO] divide by zero exceptions for PMCs

[via RT]

# New Ticket Created by  jerry gay 
# Please include the string:  [perl #38202]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38202 >


see below.
~jerry

-- Forwarded message --
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Jan 10, 2006 3:57 PM
Subject: divide by zero exceptions
To: Perl 6 Internals 


The integer and floatval opcodes div, fdiv, and cmod now all throw a
E_ZeroDivisionError exception with the text "Divide by zero". JIT/i386
and JIT/ppc are also adapted accordingly.

Updates for Integer, Float, Complex, BigInt PMCs are welcome.

leo

[perl #38200] [PATCH] trivial omission in hints/cygwin.pm

[via RT]

# New Ticket Created by  Greg Bacon 
# Please include the string:  [perl #38200]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38200 >


The attached patch against r11052 adds a missing trailing comma so
parrot can configure and build on Cygwin.

Enjoy,
Greg
Index: config/init/hints/cygwin.pm
===
--- config/init/hints/cygwin.pm (revision 11052)
+++ config/init/hints/cygwin.pm (working copy)
@@ -27,7 +27,8 @@
 libs=> $libs,
 has_static_linking  => 0,
 has_dynamic_linking => 1,
-parrot_is_shared=> 1
+parrot_is_shared=> 1,
+libparrot_is_shared => 1,
 );
 
 # We need to define inet_aton on Cygwin.  The contents of the --define

Re: [perl #38200] [PATCH] trivial omission in hints/cygwin.pm

[Jonathan Worthington]

"Greg Bacon (via RT)" <[EMAIL PROTECTED]> wrote:


The attached patch against r11052 adds a missing trailing comma so
parrot can configure and build on Cygwin.

Seems someone with a commit bit has beaten your patch to it.  ;-)  Though 
the "libparrot_is_shared" line seems to be gone altogether now.


Many thanks anyway,

Jonathan 

Documentation for Pugs / Parrot interaction

[Peter Schwenn]

Dear Internists,

Could someone post two or three pointers to documentation that gives an 
overview (and more) of how to use Pugs with embedded Parrot, use Parrot 
"external" to Pugs, and other means of interaction of Pugs and Parrot: 
PGE, ... ?


PeterS

Re: [perl #38201] Integer pmc doesn't make store an int

[Will Coleda]

FYI, the builtin types automatically shimmer based on assignment.

.sub main :main
 $N0 = 3.14
 $P0 = new .Integer
 $P0 = $N0
 $S0 = typeof $P0
 print $S0
 print "\n"
 print $P0
 print "\n"
.end

prints:

Float
3.14

The assignment of an N register causes the Integer PMC to morph to a  
Float.


On Jan 10, 2006, at 3:32 PM, Joshua Isom (via RT) wrote:



.sub main :main
 $N0 = 3.14
 $P0 = new .Integer
 $P0 = $N0
 print $P0
 print "\n"
.end

Late Summary

[Matt Fowles]

All~

Fear not this weeks summary will come out... just a bit late.  I have
it half written, but my bed is calling oh so sweetly.

Night all,
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary