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…
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.
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 :)
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.
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…
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
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 ;-)
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. :)
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.
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.
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.
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.