Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread Dino Viehland
ent: Friday, September 05, 2008 2:21 PM To: Dino Viehland; 'Discussion of IronPython'; 'Curt Hagenlocher' Cc: 'IronRuby' Subject: RE: [IronPython] -X:SaveAssemblies Okay, understood, although I'd think the DLR could just create an abstract base class with vari

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread KE
is capacity. Thanks! -Original Message- From: Dino Viehland [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 5:18 PM To: [EMAIL PROTECTED]; Discussion of IronPython; 'Curt Hagenlocher' Cc: 'IronRuby' Subject: RE: [IronPython] -X:SaveAssemblies The big reason the DLR

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread Dino Viehland
ronRuby'; '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 imp

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread KE
>> >> 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-friendl

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread Curt Hagenlocher
On Fri, Sep 5, 2008 at 1:18 PM, KE <[EMAIL PROTECTED]> wrote: >> -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 th

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread KE
> -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

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread Curt Hagenlocher
On Fri, Sep 5, 2008 at 11:00 AM, KE <[EMAIL PROTECTED]> wrote: > Hi, > > I find it odd that the ConsoleOptions class only has a single FileName > string property. This forces the creation of pyc.py for creating a DLL with > one or more files to compile, whereas I believe the functionality in pyc.py

Re: [IronPython] -X:SaveAssemblies

2008-09-05 Thread KE
Just to add, here are some problems with the pyc.py approach rather than putting this logic into the DLR/DLR-implementor: 1. Worse performance since the file needs to be compiled and run 2. The pyc.py file itself is required to move around with the other libraries when distributing a DLR-based run

[IronPython] -X:SaveAssemblies

2008-09-05 Thread KE
Hi, I find it odd that the ConsoleOptions class only has a single FileName string property. This forces the creation of pyc.py for creating a DLL with one or more files to compile, whereas I believe the functionality in pyc.py of creating a DLL from one or more input files should be right in the D

Re: [IronPython] -X:SaveAssemblies

2007-12-13 Thread Dino Viehland
ng that yet. You're not the only one that wants it though so it's hard to imagine we can completely ignore it. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee Culver Sent: Thursday, December 13, 2007 1:54 PM To: Users@lists.ironpython.com Subject: [IronPython

[IronPython] -X:SaveAssemblies

2007-12-13 Thread Lee Culver
I use the -X:SaveAssemblies command to compile and pass around tools that I create with IronPython... I've noticed that it fails on 2.0A6. Specifically, the exe that it generates gives an "invalid executable" dialog box in windows (with the 3 dlls in the same directory as the .exe file). Is t