Persistent DSL caching issues
A while ago I talked about persistent DSL caching. I was asked why my solution was not a builtin part of Rhino DSL.
The reason for that is that this is actually a not so simple problem. Let me point out a few of the issues that are non obvious.
- Need to handle removal of scripts
- Need to handle updating scripts
- Need to handle new scripts
Those are easy, sort of, but what about this one?
- Need to handle DSL updates
When you are in development mode, you really need to know that changing the way the DSL behaves would also invalidate any cache.
I like to keep a very high bar of quality on the software I make, and there is a fine distinction between one off attempts and reusable ones. One off attempts can be hackish and stupid. Reusable implementations should be written properly.
And no, there isn't anything overly complex here. Just time to test all bases.
Anyone feels like sumbiting a patch?
Comments
hmm.. I'll have to go back and read the persistent caching post, but it doesn't seem like it would be too hard. just keep a cached compiled copy, and compare script dates & maybe sizes on startup, then monitor for changes while running. right?
I'm still catching up in this area so I'm not quite ready to submit a patch. sorry.
I'm thinking the DSL updates could be handled with a simple checksum on the file. Anywhere with some guidelines on how submitting a patch works?
pb,
Yes, you could. Now how do you store that? How do you clean this up?
The best example of how to submit a patch is here:
http://www.hanselman.com/blog/ExampleHowToContributeAPatchToAnOpenSourceProjectLikeDasBlog.aspx
How about caching the check sum per absolute file path? That should handle these four scenarios and worst case scenario is you compile again if not found which is what happens every time now anyway.
pb,
where would you store this?
Environment.GetTempFilePath or something similar
I think it would be best to see the code before moving forward in abstract discussion
Got it compiling after svn and reference finding shenanigans, trying to get unit tests going with mbunit now.
Hooray! Got the test passing. Missing a file reference in VS 2005 project to the _differentoperaionts.boo file and had to use mbunit gui since coudn't get testdriven.net to work with mbunit even with registry hack. Ah, the joys of open source.
I think I'm most of the way there but CompilerContext isn't serializeable and context.GeneratedAssembly doesn't seem to be something I can store. Suggestions?
Here's the basic idea
using System;
using System.Collections.Generic;
using System.Text;
using Boo.Lang.Compiler;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
using System.Security.Cryptography;
using System.Reflection;
namespace Rhino.DSL
{
}
pb,
Let us take the discussion to the rhino tools dev mailing list,
Ok, posted to http://groups.google.com/group/rhino-tools-dev
Comment preview