0834
No snow today. The commute was easy. Last night, I downloaded the DLR and worked with it a little. I’ve hosted a gzipped binary version of the assembly on colliertech.org as well as a bzip2ed tarball of the source. A quick google search tells me that the OSI has approved the Microsoft Public License (Ms-PL). I asked #debian-devel on oftc whether the license meets the Debian Free Software Guidelines, and received a tentative “probably.”

I’m building a tarball dist of the source using Prebuild‘s autotools target. I’ve not built any libraries sans snk before, so Prebuild was generating incorrect Makefile.am files in this case. I’ll submit the fix here Real Soon Now. – done

Miguel told me that the Second Life folks have created a Continuation system. This can be used to implement Perl6’s continuations, I bet…

0859
Notes on the wiki
Democratizing The Cloud With Volta

Volta is a framework for making the creation of “Web 2.0” applications (multi-tiered, asynchronous) easier.

0939
It looks like you’ll need gmcs from svn to compile the DLR. I’ve gotten an autotools system built using Prebuild… now to make dist and put it up on the web server…
Here it is. Note that I have very little bandwidth allocated, so you’ll probably not be able to get it. Sorry :)

http://colliertech.org/downloads/DLR/dlr-solution-1.0.tar.gz

1016
Seo Sanghyeon got my attention on #debian-devel and told me that he’s been building patches which make IronPython build on Mono for a year now. Nifty :) He maintains a list of reports about versions of Iron Python on Mono at the FePy project page.

1125
I’ve been kinda’ ignoring the presentations and fiddling with the DLR autotools distribution. There is now a *very* simple example included in the solution distribution. It basically includes a ‘using Microsoft.Scripting.Ast’ and a definition of ‘Microsoft.Scripting.Ast.CodeBlock cb;’ along with a Console.WriteLine(“Hello World”). Basically enough to prove that the assembly links correctly.

I’ll go see if meebey is interesed in packaging all this stuff as a .deb…

1315
Some folks on #mono recommended that we not package the DLR in its current state, as it is pre-release. I mentioned that we could build a package that we ensured would not make its way out of sid. Nobody objected, so I’m going to see if I can figure it out.

12:09 <@cj> meebey: you about?
12:10 <@meebey> cj: wussup?
12:10 <@cj> meebey: can you download this?
12:10 <@cj> http://colliertech.org/downloads/DLR/dlr-solution-1.0.tar.gz
12:11 <@cj> meebey: if you can, can you .deb-ify it?
12:11 <@meebey> cj: what the heck is that and why should I package it? :)
12:12 <@cj> meebey: it's the "Dynamic Language Runtime."  A set of classes to 
            ease the implementation of dynamic languages on the [CLI]
12:13 <@meebey> cj: how come its on your server? who developed it, does it run 
                on mono and which license it is under
12:13 <@cj> meebey: It's on my server because I cropped it out of a few 
            packages.  It was developed by Microsoft and is released under the 
            Ms-PL (OSI approved, uncertain about DFSG)
12:14 <@cj> meebey: I wrapped an autotools build system around it
12:15 < vargaz-away> cj: I think we should package the DLR with the languages 
                     which use it, since it is not api stable at all.
12:15 <@cj> vargaz-away: ah.  wasn't aware of that.  I was wondering why it was 
            being bundled with every language implementation.
12:16 <@meebey> so I should wait for a language that uses it
12:31 <@cj> meebey: IronPython and IronRuby are two of the first.  There's also 
            LOLSCRIPT
12:31 <@meebey> cj: ironpython would be in debian already if not a developer 
                would block it
12:33 <@cj> meebey: the pre-release version is on the DLR... the stuff that's 
            been released isn't generalized into a separate assembly/namespace
12:34 <@cj> meebey: can you add an attribute to a .deb that ensure that it 
            never leaves sid?
12:35 <@cj> meebey: if so, it might be worthwhile to package an alpha version 
            of the DLR
12:35 <@meebey> cj: just file a RC bugreport, then it will not migrate to 
                testing
12:36 <@cj> meebey: feel like mentoring me through the process of building the 
            dlr package?  It may be released by the time I figure it all out 
            anyway :)
12:39 <@cj> I'd probably need to create a debian/ directory and put a rules and 
            control file, eh? :)
12:54 <@meebey> cj: start with dh_make, the debian new maintainer guideline, 
                the debian policy and the debian cli policy
12:55 <@meebey> cj: most important the last one :-P with that you will get sexy 
                CLI packages
12:56 <@meebey> cj: for specific questions join #debian-mono on OFTC

1328
Babbage Linden stopped by #mono to talk with Miguel about Second Life’s currently-executing rolling reboot to the Mono-based scripting engine. I grabbed him and asked him to join me on #perl6 to discuss with Larry his group’s implementation of closures on the .NET platform. Here’s an excerpt:

12:15 < babbagelinden> evening all
12:16 < cj> TimToady: babbagelinden is responsible for second life's 
            continuation implementation
12:16 < cj> babbagelinden: TimToady is the primary author of the perl6 spec
12:17 <@TimToady> er, yeah, that's me
12:17 < babbagelinden> hi tim
12:17 <@[particle]> babbagelinden: his friends call him larry wall :)
12:18 < cj> babbagelinden: TimToady earlier asked... are the 2nd life 
            continuations real continuations or just database continuations?
12:18 <@TimToady> how would you characterize the limitations of your 
                  continuations?
12:18 < PerlJam> his enemies call him larry wall too
12:18 <@TimToady> I usually just answer to "hey you"
12:18 < cj> "don't call me late for dinner!"
12:18 < babbagelinden> well, it's horribly inefficient as you end up copying 
                       the CLI stack to the heap as a continuation
12:19 <@[particle]> urk
12:19 < babbagelinden> and it causes assembly bloat due to the generated stack 
                       frame classes
12:19 <@TimToady> so you presumablyu 
12:19 < babbagelinden> (which will be less bad with generic code sharing)
12:19 <@TimToady> only when explicitly asked to do so
12:19 < babbagelinden> and managed pointers aren't currently supported
12:19 < babbagelinden> apart from that it mostly works :-)
12:20 < babbagelinden> and it works on any CLI runtime: .NET or Mono on any 
                       platform
12:20 <@TimToady> but you wouldn't use it for, say, backtracking in logic 
                  programming...
12:20 < babbagelinden>  i wouldn't use it if i was building a vm
12:20 <@TimToady> if you wanted to evaluate many alternatives rapidly
12:21 < babbagelinden> but it's a usable hack if you're bolting someone elses 
                       vm in to your system :-)
12:21 <@[particle]> are there bsr/ret ops?
12:22 < babbagelinden> the approach has been used a number of times to 
                       implement migrating agents in Java
12:22 <@TimToady> here I reveal my profound ignorance, but does SL generally 
                  use its own VM or someone else's?
12:22 < babbagelinden> see JavaGoX and brakes
12:22 < cj> babbagelinden: the reason your team developed this was to save a 
            second life character's state when moving from one server to 
            another, wasn't it?
12:22 < babbagelinden> we were using our own vm
12:23 < cj> babbagelinden: so it's probably optimized for 
            once-ever-now-and-then use?
12:23 < babbagelinden> it's mainly to deal with migrating running scripts 
                       between processes
12:23 < babbagelinden> but it works well enough that we can use it for threading
12:23 < cj> TimToady: they are in the process (this very moment) of moving from 
            their VM to Mono :)
12:23 <@TimToady> are different VMs compatible at the continuation level?
12:24 < babbagelinden> yes, if you use a soap formatter
12:24 < babbagelinden> you could pass a continuation from mono to .NET
12:24 < cj> babbagelinden: that's pretty fancy.  migrating states between 
            processes...
12:24 < babbagelinden> which would be fun
12:24 < babbagelinden> if you used a binary formatter it might work
12:25 < babbagelinden> but its less likely
12:25 <@TimToady> my guys tend to like yaml, but it's like "whatever.." :)
12:25 <@[particle]> so you can write it to disk, and save the continuation for 
                    after the processor has lunch or whatever
12:25  * cj grabs some lunch...
12:26 <@TimToady> babbagelinden: thanks for the braindump
12:27 < babbagelinden> np
12:27 < babbagelinden> there are details on my blog
12:27 < babbagelinden> http://blog.secondlife.com/author/babbagelinden
12:27 < lambdabot> Title: babbagelinden ? Official Linden Blog
12:27 <@TimToady> I'm sure if I really knew what I was talking about I'd have 
                  more questions... :)
12:27 <@TimToady> 'k thanks
12:27 < babbagelinden> you need to scroll back a couple of years for the theory 
                       ;-)

1402
There was an interesting talk on a tool which integrates FxCop and re-factoring tools. It was given by a guy whose name is probably Serge. This is an obvious extension. I’m glad someone has done it. :)

1419
Currently there is a “Power Shell” talk. It seems neat, but it seems only to be applicable to win32. It might be neat to create a managed shell application. The CLI representation of, for instance System.Diagnostics.Process, is pretty useful. Making an alternate graphical representation of the textual content displayed to a shell is a pretty neat concept.

1424
Babbage invited Miguel to take a look at the Second Life Mono sandbox. Miguel’s desktop crashed while trying to start the Linux client. I was able to get the client running, but it looks like I can’t get through Microsoft’s firewall. Miguel was able to get on using the OS X client.

2026
I finished up a .deb of the DLR before I left the campus today. It is on the laptop, and I’m on the wife’s computer, so publishing it will have to wait until I get around to pulling it out of my backpack. Probably won’t happen until tomorrow morning. Compiling the .dll requires a version of gmcs from subversion. It won’t normally require such a new version to run it, but you’ll find hit an exception in some edge cases if you try to run a DLR language on the stock 1.2.6.

2048
I guess I was wrong about not having time to do it tonight. I’ve uploaded the various debian package source bits and the architecture-independent .deb to my web server.

http://colliertech.org/downloads/DLR/