I was thinking on file change delete the cached dll which would force the next compile to actually occur but I guess depending on the order of things that wouldn't work. I would need to put part of the checksum functionality on the storage class interface and file implementation then because it might differ for other url types.
On Sep 11, 9:28 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote: > Yes, persistent in this case means surviving application restar. > > > > On Fri, Sep 12, 2008 at 5:06 AM, webpaul <[EMAIL PROTECTED]> wrote: > > > On the storage interface there is a notify on change event. Any reason > > you can think of to not just use that instead of the checksum? > > > On Sep 11, 8:37 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote: > > > Yeah :-)Load it using Assembly.Load(File.ReadAllBytes(file)) > > > > Nasty, but works. > > > > On Fri, Sep 12, 2008 at 4:12 AM, webpaul <[EMAIL PROTECTED]> wrote: > > > > > Ok, it was compiling to memory, was able to get it to compile to a > > > > file and cache it after that. The file is getting locked though so I > > > > can't clean it up in the tests without closing mbunit. Looks like this > > > > is going to take longer than I thought. :) > > > > > On Sep 11, 3:22 pm, webpaul <[EMAIL PROTECTED]> wrote: > > > > > That's what I was trying to do but that wasn't working out for me, > > the > > > > > file wasn't there for some reason. I'll try again later, maybe I'm > > > > > missing something. > > > > > > On Sep 11, 2:05 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote: > > > > > > > Sorry, the cache is persistent, it has to survive app restarts. > > > > > > We already have transient cache. I am not sure that I follow why > > > > serializing > > > > > > the context is good. You can just start a new one with the cached > > > > generated > > > > > > assembly > > > > > > > On Thu, Sep 11, 2008 at 9:21 PM, webpaul <[EMAIL PROTECTED]> > > wrote: > > > > > > > > From my first look at the code that seemed to be the easiest way > > to > > > > do > > > > > > > the caching. The last thing I tried was accessing the DLL > > location > > > > > > > created by the compiler context and when retrieving the cached > > copy > > > > to > > > > > > > populate the object with the info but that didn't work either, > > that > > > > is > > > > > > > in fact how the code is as-posted right now. So I tried > > serializing > > > > > > > the whole object and that, but neither seemed to work. I'm open > > to > > > > > > > suggestions if you think there is an easier way to do it. > > > > > > > > On Sep 11, 9:12 am, "Ayende Rahien" <[EMAIL PROTECTED]> wrote: > > > > > > > > Why do you need to save the compiler context? > > > > > > > > > On Thu, Sep 11, 2008 at 4:44 PM, webpaul <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > Working on doing this as per: > > > > >http://www.ayende.com/Blog/archive/2008/09/10/Persistent-DSL-caching-. > > > > > > > .. > > > > > > > > > > Can someone suggest how to serialize or otherwise save a > > > > > > > > > CompilerContext instance without modifying the Boo project as > > > > well?- > > > > > > > Hide quoted text - > > > > > > > > > - Show quoted text -- Hide quoted text - > > > > > > > - Show quoted text -- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
