Ironruby core - Sep 2008 - [IronPython] -X:SaveAssemblies

> -X:SaveAssemblies is for debugging purposes and does not produce
> output equivalent to that produced by pyc.py.
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)?

Thanks,

>>
>> 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,

Okay, understood, although I''d think the DLR could just create an
abstract
base class with various Save/Load methods? The logic in pyc.py is not
incredibly complex.

BTW, I''d be interested in what Ruby precompilation issues
you''re talking?
I''d like to use IronRuby in this capacity.

Thanks!

-----Original Message-----
From: Dino Viehland [mailto:dinov at microsoft.com] 
Sent: Friday, September 05, 2008 5:18 PM
To: hellosticky at gmail.com; Discussion of IronPython; ''Curt
Hagenlocher''
Cc: ''IronRuby''
Subject: RE: [IronPython] -X:SaveAssemblies

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