[IronPython] -X:SaveAssemblies

[Dino Viehland]

The big reason the DLR doesn't currently handle it all is that languages are ultimately responsible for how they load the code back - for example IronPython will load the code after it's been AddReference'd.  Combine that with wanting a consistent interface which both takes and returns ScriptCode objects and you start to see why the languages need to be involved.  And unfortunately ScriptCode objects are outside of the hosting APIs so there's not necessarily an easy way to get at them.  But if you do get a ScriptCode object in theory you can write that out to disk & load it back up.

I think there's some issues which prevent Ruby from using precompilation anyway though.


-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of KE
Sent: Friday, September 05, 2008 1:28 PM
To: 'Curt Hagenlocher'
Cc: 'IronRuby'; 'Discussion of IronPython'
Subject: Re: [IronPython] -X:SaveAssemblies

>>
>> Okay, but my question still stands of whether or not part or all of the
>> function of pyc.py should be moved into the DLR (obviously with some
>virtual
>> methods for implementers)?
>
> The bulk of the compiler code is actually in the DLR and in IronPython
> itself.  pyc.py is a user-friendly wrapper around that functionality.
> There's no reason you couldn't use pyc.py to compile itself, if you
> wanted to distribute it in a binary form.
>
> If you've got a real-world scenario that you don't think we've
> adequately addressed, you'll need to provide more information before
> we can understand the shortcomings of this approach.

The question began when I was investigating an equivalent to pyc.py in
IronRuby. ir.exe has an experimental option called -save (which doesn't
currently work) -- instead of some kind of irc.rb -- but it shows that the
lack of a consistent approach to compiling source code files into an
Assembly causes confusion for language implementers and, ultimately, users.

The approach in ir.exe is inherently broken because the base DLR
OptionsParser parses a single file input argument (called FileName), whereas
compiling usually (not always) needs to compile more than one source file
into the output file.

As you mention, the DLR methods like ScriptCode.SaveToAssembly already do
the bulk of the work, so why not work into this into the DLR?

Thanks,

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com